Ein großes Update für ein Spiel herunterladen – mehrere Hundert Gigabyte. Der Download startet, man holt Kaffee, und beim Zurückkommen läuft er immer noch. Irgendwann ist die Datei da, aber Entpacken und Installieren dauern. Bis zum Spielen ist der Abend vorbei. So fühlt es sich an, wenn ein großes KI-Modell startet. Die Gewichte – die gelernten Parameter – sind oft hunderte Gigabyte schwer. Sie müssen nicht nur einmal, sondern immer wieder bewegt werden: beim ersten Start (Cold Start), beim Hochskalieren neuer Repliken, bei Updates, beim Reinforcement Learning. Jedes Mal liegt das Modell brach, während die Daten transportiert werden.
NVIDIA hat mit ModelExpress (MX) eine Lösung vorgestellt, die diesen Flaschenhals verkürzt. Die Kernidee: Bevor du Gewichte aus der Cloud holst, frag erst, ob irgendwo im Cluster schon eine passende Kopie in GPU-Speicher existiert. Warum etwas herunterladen, wenn du es von einem Nachbarn per Direct Memory Access abholen kannst? ModelExpress baut eine Hierarchie von Transferwegen auf – und wählt für jede Situation den schnellsten aus.
Das Problem: Jedes Byte kostet Zeit
Modelle wie DeepSeek-V4-Pro wiegen rund 800 Gigabyte. Wenn zehn Repliken gleichzeitig starten, müssen insgesamt acht Terabyte durch die Leitung. Selbst bei schnellem Netzwerk dauert das Minuten. Während des Transfers kann kein Token inferiert werden. Das ist nicht nur bei der Erstbereitstellung ärgerlich, sondern auch bei Autoscaling-Events oder wenn nach einem Training neue Gewichte verteilt werden. Der Autor des NVIDIA-Blogs beschreibt diese Zeitsteuer als „das Gleiche: Zeit, die mit dem Bewegen von Gewichten vergeht, bevor nützliche Arbeit beginnt.“
Herkömmliche Ansätze laden jedes Modell unabhängig – jeder Pod zieht sich die Daten aus dem Object Store, schreibt sie auf die Festplatte und lädt sie dann in den GPU-Speicher. Das ist redundant und langsam. ModelExpress behandelt das gesamte Cluster als einen verteilten Cache für Modellgewichte.
Wie ModelExpress den schnellsten Weg findet
Das System besteht aus zwei Ebenen: der Control Plane und der Data Plane. Die Control Plane sucht nach kompatiblen Quellen – zum Beispiel über Redis-Metadaten oder Kubernetes-Custom-Resources. Sie entscheidet, ob ein Peer im GPU-Speicher die passenden Gewichte hat. Die Data Plane führt den eigentlichen Transfer durch, über eine priorisierte Kette von Methoden, die automatisch durchprobiert werden.
Die Priorität: P2P RDMA von einem Serving-Peer über NIXL (NVIDIA Inference Xfer Library) ist am schnellsten. Danach kommt ModelStreamer, der direkt aus einem Object Store streamt, ohne die lokale Festplatte zu belasten. Dann GPUDirect Storage (GDS), falls verfügbar. Als letztes der Fallback auf host-staged POSIX I/O. Das System testet bei jedem Start, welche Methoden die Umgebung unterstützt, und wählt die erste funktionierende aus.
Die erste Replik: Bootstrapping aus dem Speicher
Wenn noch kein Peer existiert, muss die erste Instanz ihre Gewichte irgendwoher bekommen. ModelExpress kann das auf zwei Arten tun: direkt aus einem Object Store (wie S3 oder Hugging Face) oder von einer lokalen Festplatte. Es vermeidet unnötige Zwischenschritte. Beim Streamen aus Object Storage nutzt es ModelStreamer, der die Safetensor-Dateien parallel über mehrere Threads liest und die Tensoren direkt in den GPU-Speicher legt. Die Daten landen nie auf der SSD, es gibt keinen zwischengelagerten Download. Das spart I/O und Zeit.
Alternativ kann MX auch von einer lokalen Festplatte laden – entweder über GPUDirect Storage, das die GPU direkt die Platte lesen lässt, oder über einen gepipelineten Lesevorgang mit ModelStreamer, der Hintergrund-I/O mit GPU-Platzierung überlappt. In tensor-parallelen Deployments teilen sich die Ranks die Arbeit: Sie laden nur einen Teil der Daten und tauschen sie über NCCL aus, statt jeder einzeln alles zu holen.
Jede weitere Replik: GPU-zu-GPU über RDMA
Sobald die erste Replik läuft, ändert sich die Strategie. Ihre Gewichte liegen bereits fertig prozessiert im GPU-Speicher – genau die Daten, die jede neue Replik braucht. Statt sie erneut aus dem Storage zu holen, fragt MX bei der Control Plane nach einem Peer. Wenn ein passender gefunden wird – eine Replik mit demselben Modell und derselben Tensor-Layout-Konfiguration – startet der Transfer direkt von GPU zu GPU über RDMA. Der Autor beschreibt, dass MX dabei NIXL als Standard-Engine nutzt, die hinter den Kulissen verschiedene Netzwerke wie InfiniBand, RoCE, NVLink oder EFA unterstützt.
Die Metadaten – welche GPU, welcher Speicherbereich – werden über die Control Plane ausgetauscht, die Gewichte selbst wandern nie durch die CPU. Das ist der entscheidende Vorteil: keine Kopie in den Host-Speicher, keine unnötigen Latenzen. So kann ein neues Replica in weniger als zehn Sekunden die 800 Gigabyte Gewichte von einem Serving-Peer beziehen. Der gesamte Startup (inklusive JIT-Kernel-Kompilierung) sinkt von acht Minuten auf eine Minute und 44 Sekunden.
Optimierung der Speicherregistrierung
Damit RDMA funktioniert, muss der GPU-Speicher vorher registriert werden – der Treiber teilt dem Netzwerkkarten-Stack mit, welche Speicherbereiche für Remote Access freigegeben sind. Bei einem Modell mit zehntausenden Tensoren summiert sich das Registrieren jedes einzelnen Tensors schnell. ModelExpress bietet zwei Optimierungen: Pool-Registrierung (Zusammenfassen der cudaMalloc-Allokationen) und VMM-Arena-Registrierung (alles in einen großen virtuellen Adressraum legen und nur einmal registrieren). Die VMM-Variante reduziert die Anzahl der ibv_reg_mr-Aufrufe von mehreren Tausend auf einen einzigen. Die Messungen im Blog zeigen, dass die Zeit dafür von über 600 Millisekunden auf etwa 20 Millisekunden sinkt – ein winziger Teil der Startup-Zeit, aber dennoch beachtlich.
Fallback und Fehlersicherheit
Nicht jede Umgebung unterstützt GPUDirect RDMA. Wenn ein Pfad nicht verfügbar ist oder fehlschlägt, fällt MX automatisch auf den nächsten zurück – aber nur, solange noch keine Gewichte geschrieben wurden. Falls nach dem Start des Schreibens ein Fehler auftritt, initialisiert MX das Modell neu, um inkonsistente Zustände zu vermeiden. Das System kann auch mehrere Peers ausprobieren, aber nur bei Metadaten-Fehlern vor dem eigentlichen Transfer. So bleibt die Startup-Logik robust, ohne das Anwendungsmodell zu gefährden.
Mehr als nur Gewichte: Auch kompilierte Kernel profitieren
Ein Modell ist nicht startklar, sobald die Gewichte im GPU-Speicher liegen. Die Inference-Engine muss JIT-kompilierte und autotuned Kernel für die spezifische Modellkonfiguration generieren – etwa für Flash Attention oder DeepGEMM. Normalerweise passiert das bei den ersten Forward-Passes und kann Minuten dauern. ModelExpress überträgt auch den fertigen JIT-Kernel-Cache inklusive aller Optimierungen zusammen mit den Gewichten. Die neue Replik muss nicht noch einmal die gesamte Kompilierung durchlaufen, sondern kann sofort loslegen. Im Benchmark mit DeepSeek-V4-Pro sank die Startzeit dadurch noch einmal deutlich.
Ergebnisse und Einordnung
Die mitgelieferten Messungen zeigen: P2P RDMA über NIXL ist um ein Vielfaches schneller als der Standard-Weg über Object Store und host-staged I/O. Für DeepSeek-V4-Pro auf einem 8x-B200-Node mit ConnectX-7-NICs verkürzt sich die reine Ladezeit von über sieben Minuten auf unter fünf Sekunden. Der gesamte Startup inklusive Modell-Laden, Kernel-Cache-Transfer und Initialisierung fällt von acht Minuten auf unter zwei Minuten. Das verändert, wie wir über horizontale Skalierung und Rolling Updates denken.
Praktisch bedeutet das: KI-Systeme können agiler auf Lastspitzen reagieren. Eine neue Replik ist in weniger als zwei Minuten betriebsbereit statt in zehn Minuten. Bei großen Clustern mit hunderten Repliken summiert sich die gesparte Bandbreite: Statt tausendfach die gleichen 800 Gigabyte aus dem Object Store zu ziehen, reicht ein einmaliger Download. Weitere Repliken beziehen ihre Gewichte über schnelle GPU-to-GPU-Verbindungen. Das reduziert nicht nur die Netzlast, sondern auch die Kosten für den Object Store.
Der Autor beschreibt ModelExpress als einen Schritt hin zu einem „distributed artifact cache“ für KI-Workloads. Die Idee, vor dem Laden zu fragen, wo die Daten bereits in optimaler Form vorliegen, mag naheliegend klingen. Aber sie konsequent umzusetzen – mit automatischer Pfadwahl, RDMA-Integration und Kernel-Caching – erfordert einiges an Engineering. NVIDIA hat das für die eigene Plattform realisiert. Ähnliche Ansätze werden bald Standard in der KI-Infrastruktur sein.
Zeit ist kostbar, besonders wenn GPUs darauf warten, Rechenarbeit zu verrichten. ModelExpress zeigt, dass das Bewegen von Modellgewichten nicht der Flaschenhals sein muss, der den Betrieb ausbremst. Statt bei jedem Start die Welt neu zu laden, fragen wir einfach unseren Nachbarn – und schon geht es weiter.
Quelle: developer.nvidia.com
