NVIDIA will mit ModelExpress einen Engpass adressieren, der beim Betrieb sehr großer Sprachmodelle schnell teurer wird als ein einzelner Request: das wiederholte Laden identischer Gewichte. Statt jede neue Replica aus Object Storage zu bootstrappen, soll sie ein bereits laufendes Peer per GPU-zu-GPU-RDMA als Quelle nutzen.
Der am 24. Juli veröffentlichte Technical Blog beschreibt ModelExpress (MX) als Schicht für den gesamten Weight-Lifecycle. Das ist keine neue Modellarchitektur, sondern eine Infrastrukturidee mit klarer Betriebswirkung: Ein Cluster bootstrapt einmal aus Storage; danach kann das Scale-out zu einem Fan-out zwischen kompatiblen Serving-GPUs werden.
Der Mechanismus: erst suchen, dann laden
MX berechnet aus Modell- und Runtime-Einstellungen eine mx_source_id und akzeptiert nur Peers mit passendem Tensor-Layout. Existiert ein solcher Peer, überträgt MX die Gewichte direkt über P2P RDMA und NVIDIAs Inference Xfer Library (NIXL). Der Control Plane obliegen Discovery und Metadaten; die Gewichtsdaten selbst sollen nicht durch sie fließen.
Die entscheidende Verschiebung: Eine bereits warme Replica wird nicht nur Kapazität, sondern auch Verteilquelle für weitere Replicas.
Gibt es noch keinen kompatiblen Peer, verwendet MX eine abgestufte Auswahl: P2P RDMA → ModelStreamer → GPUDirect Storage → Standard-Loader. Für Object Storage beschreibt NVIDIA paralleles Tensor-Streaming in einen begrenzten CPU-Puffer und direkt weiter in den GPU-Speicher. In Clustern mit Shared Cache soll ein koordinierter Download verhindern, dass etwa zehn Replicas ein 806-GiB-Checkpoint jeweils separat aus dem Netz laden.
Was die Messung sagt – und was sie nicht beweist
Auf einem 8×B200-System mit ConnectX-7 nennt NVIDIA für DeepSeek-V4 Pro weniger als zehn Sekunden, um Gewichte und JIT-Kernel-Artefakte von einer Serving-Replica auf eine neue zu übertragen. Die gesamte Startup-Zeit sinke im gezeigten Setup von acht Minuten auf 1:44 Minuten. Das ist ein Herstellerbenchmark, kein universeller SLO: Modellgröße, Netzwerkfabric, Parallelisierungsgrad, Runtime und der Zustand eines vorhandenen Peers entscheiden über den Effekt.
| Vorheriges Muster | MX-Muster | Betriebsfolge |
|---|---|---|
| Jede Replica lädt aus Storage | Ein Bootstrap, danach Peer-Fan-out | Weniger Ingress und kürzere Scale-out-Phase |
| Weights und Kernel-Caches werden getrennt warm | File-basierte JIT-Artefakte können per RDMA folgen | „Geladen“ kommt näher an „bereit“ |
| Einzelne Tensor-Registrierungen für RDMA | Pool- oder VMM-Arena-Registrierung | Weniger Registrierungs-Overhead bei großen Checkpoints |
Warum Kernel-Caches wichtiger sind als die Ladezeit allein
Eine Replica mit Gewichten im Speicher ist noch nicht zwingend serving-ready. JIT-Kompilierung, Autotuning und CUDA-Graph-Capture können den Rest der Anlaufzeit dominieren. MX überträgt deshalb laut NVIDIA auch file-basierte Artefakte wie Triton-, DeepGEMM-, TileLang- und FlashInfer-Caches zwischen Host-Puffern via CPU-zu-CPU-RDMA. Damit ersetzt es in diesem Pfad nicht einfach Storage durch RDMA; es versucht, die wiederholte Warmup-Arbeit gleich mit zu eliminieren.
Was Plattformteams jetzt prüfen sollten
- Kompatibilitätsgrenze: Welche Runtime- und Modellparameter müssen identisch sein, damit ein Peer als Quelle sicher ist?
- Fabric: Ist P2P RDMA über die vorhandene Kombination aus InfiniBand, RoCE, NVLink oder EFA tatsächlich erreichbar und beobachtbar?
- Fallback: MX fällt bei fehlenden Fähigkeiten zurück. Das ist gut – aber Startup-SLOs müssen den langsamen Pfad weiterhin enthalten.
- Autoscaling-Test: Nicht nur Cold Start messen: einen laufenden Peer gezielt als Quelle belassen und Zeit bis API-Readiness, Ingress und Fehlerraten vergleichen.
- Cache-Hygiene: Die Source-ID muss Modell, Quantisierung, GPU-Architektur und Software-Stack sauber trennen. Ein schneller inkompatibler Cache wäre ein Produktionsfehler, kein Optimierungserfolg.
MX integriert sich laut NVIDIA nativ mit vLLM und SGLang und unterstützt Serving-Frameworks einschließlich Dynamo und llm-d. Für Teams mit großen, häufig skalierten Modellen ist die interessante These daher nicht „RDMA ist schneller“. Sie lautet: Der bereits laufende Inferenzpool kann den nächsten Start beschleunigen – sofern die Infrastruktur aus warmen Replicas verlässlich eine sichere Verteilquelle macht.
Quelle: NVIDIA Technical Blog: ModelExpress: Distributing Model Artifacts at the Speed of Light (24. Juli 2026).
Schreibe einen Kommentar