P2P-Verteilung von Modellen löst das Problem des Ladens großer Artefakte in Kubernetes. Wir analysieren, wie Dragonfly die Belastung des Ursprungs verringert und die Lieferung beschleunigt.
Das Problem zeigt sich nicht sofort — bis die Größe der Modelle und der Maßstab des Clusters zu multiplizieren beginnen. Ein typisches Szenario: 200 GPU-Knoten in Kubernetes und ein Modell von etwa 130 GB. Jeder Knoten zieht eine Kopie aus dem gemeinsamen Hub. Insgesamt sind das etwa 26 TB ausgehendem Datenverkehr vom Ursprung, der auf (bandwidth) und (rate limiting) stößt. Selbst wenn NFS, fertige Images oder Spiegel von Object Storage verwendet werden, zahlt das System einen anderen Preis: operationale Komplexität, Risiko veralteter Versionen und übermäßige Speicherung. Die Frage wird architektonisch: Wie kann sichergestellt werden, dass die Belastung des 200. Knotens in der Geschwindigkeit nicht von der des ersten abweicht?
Die Lösung besteht darin, die Verteilung auf die Ebene der Infrastruktur zu verlagern und sie P2P zu gestalten. Dragonfly realisiert dies durch ein Peer-Netzwerk: Jeder Knoten, der ein Modell herunterlädt, wird gleichzeitig zur Quelle für andere. Der entscheidende Kompromiss besteht darin, auf eine zentralisierte Fan-Out-Architektur zugunsten einer verwalteten P2P-Topologie zu verzichten. Dies reduziert den Druck auf den Ursprung auf O(1) Last und verlagert die Verbreitung auf das Cluster (O(log N) während der Verbreitung der Teile). Der Preis ist die Notwendigkeit, die Topologie zu planen und über den Scheduler zu koordinieren, aber der Gewinn in (throughput) und Lieferzeit ist entscheidend für große Modelle.
In der Implementierung zerlegt Dragonfly die Datei in kleine Teile und verteilt sie als Mikrojobs. Der Seed-Peer greift einmal auf den Ursprung zu und beginnt sofort, Teile zu teilen, nachdem sie empfangen wurden — ohne auf den vollständigen Download zu warten. Dies ist ein Streaming-Modell, bei dem die Verteilung parallel zum primären Download startet. Der Scheduler berechnet die P2P-Topologie, und die GPU-Knoten tauschen Teile direkt aus. Infolgedessen sinkt der gesamte Datenverkehr zum Ursprung für ein Modell von 130 GB von etwa 26 TB auf ~130 GB. Dies ist keine Optimierung, sondern die Beseitigung eines Engpasses.
Bis vor kurzem gab es eine praktische Rauheit: Die Haupt-Hubs der Modelle erforderten die Umwandlung von URLs in rohes HTTPS. Dies brach die Authentifizierung, das Pinning von Revisionen und die Semantik der Repositories. Neue Schemas hf:// und modelscope:// im dfget-Client lösen dies auf der Ebene der Backends. Jedes Schema wird auf eine Backend-Implementierung mit einer einheitlichen Schnittstelle abgebildet, in der Fabrik registriert und ohne zusätzliche Konfiguration verfügbar. Ein wichtiger Punkt ist, dass rekursive Downloads weiterhin mit den ursprünglichen Schemas und nicht mit umgewandelten Links arbeiten. Dies bewahrt Tokens, Kontext und Einheitlichkeit der Pipeline.
Das Verhalten der Hubs variiert, und dies spiegelt sich in den Backends wider. Hugging Face verwendet ein Resolve-Muster mit möglichen Weiterleitungen zu Git LFS; der HTTP-Client verarbeitet diese transparent. ModelScope bietet eine REST-API für das Listing mit Rekursion und strukturierten Metadaten. In beiden Fällen wird eine tokenbasierte Authentifizierung unterstützt, die über die Operationen stat, get und exists weitergegeben wird. Dies ist wichtig für private Repositories und gated-Modelle.
Aus Sicht des Betriebs ist der Effekt in drei Szenarien am deutlichsten. Erstens — massenhaftes Deployment in Kubernetes: Statt N unabhängiger Downloads ein Download auf dem Seed und anschließende P2P-Verbreitung. Zweitens — CI/CD und Modellbewertung: Bei der Festlegung von Revisionen (revision pinning) und dem Vorhandensein eines Caches liest Dragonfly bei wiederholten Durchläufen Daten aus der P2P-Ebene, wodurch Flakes aufgrund instabiler Downloads reduziert werden. Drittens — isolierte Umgebungen: Der Seed kann im Perimeter mit Internetzugang vorab geladen werden, wonach das Cluster ohne externes Netzwerk arbeitet.
Ein zusätzlicher Vorteil ist die Vereinheitlichung der Quellen. Teams verwenden oft gleichzeitig verschiedene Hubs. Mit nativer Unterstützung für hf:// und modelscope:// entsteht eine einheitliche Lieferungsebene: ein P2P-Netzwerk, ein Cache, einheitliches Betriebsmodell. Das Hinzufügen neuer Hubs passt in dieselbe Architektur: Backend implementieren und Schema registrieren.
Die Metriken in der Quelle sind auf das Beispiel mit der Reduzierung des Datenverkehrs zum Ursprung auf ~130 GB für 200 Knoten und ein Modell von 130 GB beschränkt. Daten zu Latenz oder End-to-End-Beschleunigung werden nicht bereitgestellt, aber die Kausalität ist offensichtlich: Parallele Verteilung von Teilen und die Beseitigung des Engpasses beim Ursprung reduzieren die gesamte Lieferzeit.
Fazit — eine pragmatische Lösung für ein systemisches Problem. Modelle wachsen, Cluster wachsen, die Anzahl der Hubs wächst. P2P-Verteilung auf der Ebene der Infrastruktur mit nativer Kenntnis der Quellen beseitigt eine Klasse von Engpässen, ohne die Benutzeroberfläche zu verkomplizieren. Für Highload-AI-Plattformen wird dies zu einer grundlegenden Fähigkeit und nicht zu einer Option.