Az NVIDIA ModelExpress (MX) célja a nagy nyelvi modellek súlyainak mozgatásához kapcsolódó ismétlődő idő- és sávszélességköltség csökkentése: ahelyett, hogy minden replikát külön hideg indításként kezelne, MX először megkeresi, hol található már kompatibilis, GPU-memóriában lévő másolat, majd az elérhető leggyorsabb forrásból tölti azt be.
Miért fontos ez
A modell checkpointok mérete ma könnyen elérheti a több száz gigabájtot vagy akár a terabájtot, és a súlyok áthelyezése a klaszteren belül gyakori — hideg indításnál távoli tárolóból töltés, autoscaling és rolling update során új replikák feltöltése, valamint reinforcement learning (RL) utótréningnél a tréner és a rollout munkások közötti folyamatos frissítés. Minden ilyen művelet előtti várakozás lassítja a hasznos munkakezdést; az MX ezt a „mozgatási adót” próbálja minimalizálni.
Hogyan működik a ModelExpress
Az MX két alapelvre épít: (1) ha egy már működő szervizreplikán kompatibilis súlyok vannak GPU-ban, akkor azok közvetlenül GPU–GPU P2P RDMA-n keresztül kerülnek átmásolásra NIXL (NVIDIA Inference Xfer Library) használatával, elkerülve az objektumtár, helyi lemez és host memória fölösleges eléréseit; (2) ha nincs elérhető peer, akkor a gyorsabb támogatott útvonalról bootstrap-ol: tárhelyről streamel disk-re történő leszállás nélkül közvetlenül a GPU memóriába.
Gyors példa: DeepSeek‑V4 Pro
MX képes a DeepSeek‑V4 Pro súlyait és a JIT kernel cache-hez tartozó artefaktumokat egy működő replikáról egy friss replikába kevesebb mint 10 másodperc alatt átvinni, és így a teljes startup időt 8 percről 1 perc 44 másodpercre csökkenteni.
A betöltési utak optimalizálása
Minden új munkás három forrás közül kaphat súlyokat: távoli objektumtárból (például Hugging Face vagy S3), helyi tárolóból vagy egy már szolgáló munkástól. Az MX először bootstrappeli az első munkást a leggyorsabb elérhető tárhelyi úton (stream vagy helyi gyors tároló), majd az első dolgozó után automatikusan preferálja a GPU–GPU P2P RDMA-t, és csak akkor esik vissza tárhelyre, ha nincs kompatibilis peer.
Távoli objektumtárból GPU-ba: Model Streamer
Ha a checkpoint egy felhővödörben van és nem szeretnénk lemezcache-t üzemeltetni, az MX Model Streamer komponense safetensors fájlokat tölt be újrahasználható CPU staging pufferrel és közvetlenül helyezi el a GPU memóriában anélkül, hogy a checkpoint helyi lemezre kerülne. A Model Streamer több szálon, párhuzamos tensor-range olvasásokkal dolgozik, és amint egy tensor megérkezik, továbbítja azt az inferencia motor felé, így átfedésben tartva hálózatot, tárolót és GPU-másolást, miközben a host memória használata korlátos.
Tensor-parallel környezetben a rangok megosztják a távoli olvasásokat (tipikusan NCCL-en keresztül), és a disztribút streamet közvetlenül az inferencia motor weight loader-éhez csatlakoztatja az MX, így az első munkaadó gyorsan válhat P2P forrássá.
Klaszter ingress: egyszer töltse le minden replika helyett
Ha a klaszter megosztott lemezcache-t használ (például Kubernetes persistent volumes), az MX Model Cache Service biztosítja, hogy az objektumtárból történő letöltés egyszer történjen meg: egy atomikus igénylés a Metadata Store-ban választ egy letöltőt, a többi replika nyomon követi az előrehaladást és újrahasználja a cache-t. Például ha 10 replika egyszerre igényelne egy 806 GiB-os DeepSeek‑V4 Pro modellfájlt, ez hozzávetőleg 8 TiB azonos adat átvitelét jelenthetné; MX ezt egyetlen külső letöltéssel kiváltja.
Helyi tárolóból GPU-ba: GPUDirect Storage és ModelStreamer
Ha a rendszer támogatja a GPUDirect Storage (GDS)-t, az MX NIXL GDS backendje több szálon, közvetlenül a helyi fájlrendszerből olvasva tölti a GPU memóriát, megkerülve a host-memória staginget. Ha a GDS nem elérhető, a ModelStreamer helyi fájlok felől is képes párhuzamos olvasásra: itt ugyan van host-memory staging, de az olvasások és GPU elhelyezés pipeliningja és az OS page cache használata gyors elérési utat ad.
Peer-to-peer betöltés: a kulcsfunkció
Amint egy replikán már GPU-ban vannak a post-processzált, inferencia-motorhoz optimalizált súlyok, MX úgy kezeli azt a replikát, mint élő súlyforrást. A kontroll sík (Redis, Kubernetes CRD-k vagy k8s-service metadata backend) felfedezi a kompatibilis peereket és cseréli a metaadatokat, de maga a súlyadatátvitelt nem kezeli — azt a NIXL végzi a data plane-en keresztül, több hálózati háttérrel kompatibilisen (Infiniband, RoCE, NVLink, EFA stb.).
Minden átvitel előtt MX kiszámít egy mx_source_id-t a modell és runtime beállítások alapján, majd csak az azonos ID-val rendelkező peereket veszi figyelembe, így elkerülhetők az inkompatibilis layoutok.
NIXL memória-regisztráció optimalizálása
Az RDMA-hoz a GPU memóriát regisztrálni kell (ibv_reg_mr hívás, rkey visszaadással). Egy nagy modell tízezres nagyságrendű tensorral rendelkezhet, és egyesével regisztrálni minden tenzort költséges. Két opt-in stratégia csökkenti ezt a költséget:
- Pool registration: a cudaMalloc alapszintű allokációkat regisztrálja egyszer, nem minden tensort külön — tipikus modelleknél 80–99% regisztrációs csökkenést eredményezhet.
- VMM arena registration: egy 16 TiB-os virtuális címteret használó CUDAPluggableAllocator összegyűjti a betöltési allokációkat, majd egyszerre regisztrálja a tényleges használatot dmabuf-alapú memóriaterületként — így a regisztráció egyetlen hívássá kollapszol.
Egy mérést DeepSeek‑V4‑Pro TP=8 és vLLM motor használatával végeztek az egyes megközelítések átlagos NIXL regisztrációs idejének összehasonlítására.
Biztonságos visszaesés és útválasztási sorrend
Induláskor MX feltérképezi a környezet képességeit és a támogatott betöltési útvonalakat priorizálva kipróbálja őket. Az aktív sorrend: P2P RDMA -> ModelStreamer -> GDS -> alapértelmezett loader (host-staged POSIX I/O). Ha egy útvonal nem elérhető vagy hiba lép fel a modell állapotának módosítása előtt, az MX automatikusan továbblép a következő opcióra; ha már részben írt súlyok keletkeztek, a modellt újrainicializálja, hogy ne szolgáljon részben írt állapotot.
End-to-end eredmények (tesztkonfiguráció)
A mérésekben DeepSeek‑V4‑Pro modellel 8×B200 GPU csomóponton, NVIDIA ConnectX‑7 hálózati kártyákkal hasonlították össze a teljes modellbetöltési időt különböző cold start forgatókönyvekben. Minden replika vLLM 0.23.0-t használ TP=8 beállítással és a --enable-flashinfer-autotune opcióval. Az MX P2P RDMA és Model Streamer útvonalai jelentősen csökkentették a teljes betöltési időt a hagyományos disk- vagy objektumtár-alapú megoldásokhoz képest.
Többlet: JIT-kernel cache megosztása — "warm" indítás
A súlyok GPU-ba töltése önmagában nem garantálja, hogy a modell készen áll a kis késleltetésű inferenciára: az első előreirányítások alatt az engine JIT-fordítja és autotunolja a kerneljeit, és készít CUDA graphokat a pontos modell/dtype/quantizáció/GPU kombinációhoz. DeepSeek‑V4 Pro esetén ez több percet is igénybe vehet, így miután az MX lerövidítette a súlybetöltést, ez a kompilációs költség válik dominánssá.
MX Artifact Transfer API csomagolja a fájl-alapú artefaktumokat (Triton/DeepGEMM/TileLang/FlashInfer cache-ek stb.), átviszi őket NIXL CPU–CPU RDMA útvonalon regisztrált host-memória puffereken keresztül, majd ellenőrzi és telepíti a cél motor cache könyvtárába. Ez megszünteti a szükségét egy közös RWX volumennek Kubernetesben, és egy mx_source_id biztosítja, hogy csak kompatibilis replikák örökölhessék a cache-t. A mérés szerint az artefakt-átvitel jelentősen csökkentette az indítási időt.
RL post-training: frissítések terjesztése
Az RL utótréning (post-training) esetén a súlyok lépésről lépésre változnak, és a rollout munkásoknak frissített súlyokat kell felvenniük a következő generáláshoz. MX egy vevő-vezérelt refit folyamatot definiál négy lépésben: Publish (a tréner közzéteszi, mely shardokat birtokolja), Discover (a rollout lekérdezi a forrásokat), Plan (a vevő leképezi a forrásokat a saját target layoutjára) és Pull/convert/load (a vevő egyoldalú olvasásokat indít a források felé). MX ezen építőköveket biztosítja, és ügyfelek aktív integrációk keretében értékelik őket; tesztelnek delta weight diff refiteket is cross‑cluster átvitelhez.
Integrációk, roadmap és elismerések
MX natív integrációkat tartalmaz vLLM és SGLang projektekhez, és támogatja a Dynamo és llm-d szerverezési frameworköket. A Dynamo közösség tovább dolgozik a TensorRT-LLM integráción és szélesebb inferencia-képességeken.
Köszönet illeti az MX csapatot, Zhongdongming Dai-t és Tanushriya Singh-et a projekt központi munkájáért, valamint Itay Neeman-t, Anish Maddipoti-t, Istvan Haller-t és Omri Kahalon-t a műszaki irányításért, továbbá Will Eaton-t a Red Hat-től az llm-d integráció támogatásáért.
