NVIDIA ha presentato ModelExpress, un’infrastruttura software progettata per accelerare la distribuzione dei pesi dei grandi modelli linguistici nei cluster di calcolo. Con checkpoint che raggiungono centinaia di gigabyte o superano il terabyte, il trasferimento dei parametri è diventato una parte rilevante del tempo necessario per avviare una nuova istanza, aumentare il numero dei server durante i picchi di domanda, distribuire un aggiornamento o sincronizzare i modelli impiegati nel post-training con reinforcement learning. ModelExpress interviene su questo passaggio individuando automaticamente la copia compatibile più vicina e scegliendo il percorso più rapido per portarla nella memoria delle GPU.
Nel funzionamento tradizionale, ogni nuova replica deve recuperare autonomamente il checkpoint da uno storage remoto o locale, trasferirlo attraverso la memoria della CPU e collocarlo nelle GPU prima di poter iniziare l’inferenza. Questo meccanismo genera cold start prolungati e moltiplica inutilmente il traffico quando più server scaricano contemporaneamente lo stesso modello. ModelExpress verifica invece se nel cluster esiste già una replica che utilizza pesi compatibili e, quando la trova, li trasferisce direttamente dalla GPU sorgente alla GPU di destinazione mediante comunicazioni peer-to-peer RDMA gestite dalla NVIDIA Inference Xfer Library, evitando object storage, disco locale e memoria host.
La compatibilità tra le repliche viene controllata attraverso un identificatore ricavato dal modello e dalle impostazioni di runtime che determinano la disposizione dei tensori. Il piano di controllo individua le sorgenti disponibili utilizzando metadati conservati in Redis, risorse Kubernetes o servizi compatibili con ambienti serverless, ma non trasporta direttamente i dati. Il piano dati utilizza invece NIXL e può operare su reti come InfiniBand, RoCE, NVLink ed EFA. Dopo aver ricevuto i pesi, anche la nuova replica entra nel gruppo delle sorgenti disponibili, trasformando l’espansione del servizio in una distribuzione progressiva da GPU a GPU invece che in una serie di download separati.
Quando viene avviato il primo worker e non esiste ancora una GPU dalla quale copiare il modello, ModelExpress seleziona il percorso più rapido disponibile dallo storage. Se il checkpoint risiede in un bucket cloud, ModelStreamer legge in parallelo i tensori distribuiti tra i diversi shard e li trasferisce verso la GPU attraverso un buffer riutilizzabile nella memoria della CPU, senza salvare preventivamente l’intero modello sul disco locale. In una configurazione tensor parallel, i vari rank si dividono le letture e condividono i dati, evitando che ogni GPU scarichi autonomamente una copia completa.
Nei cluster dotati di una cache su storage condiviso, ModelExpress coordina inoltre il download iniziale per impedire richieste duplicate. NVIDIA cita il caso di dieci repliche che devono recuperare contemporaneamente il modello DeepSeek-V4 Pro da 806 GiB: senza coordinamento verrebbero trasferiti complessivamente circa 8 TiB di dati identici. Il Model Cache Service assegna invece atomicamente il download a una sola istanza, mentre le altre ne monitorano l’avanzamento e riutilizzano la copia memorizzata.
Per i checkpoint conservati localmente, il sistema può utilizzare GPUDirect Storage per leggere i file direttamente nella memoria della GPU, evitando lo staging attraverso la memoria host. Se questa funzione non è disponibile, ModelStreamer esegue letture multithread dal disco verso un buffer CPU e sovrappone l’input-output al trasferimento dei tensori sulla GPU. ModelExpress verifica le capacità dell’infrastruttura durante l’avvio e segue una catena di priorità composta da trasferimento peer-to-peer RDMA, ModelStreamer, GPUDirect Storage e, come ultima alternativa, il loader tradizionale basato su input-output POSIX e memoria host.
NVIDIA ha testato ModelExpress con DeepSeek-V4 Pro su un nodo composto da otto GPU B200 e schede di rete ConnectX-7, utilizzando vLLM con tensor parallelism pari a otto. Il trasferimento dei pesi e degli artefatti della cache JIT da una replica già attiva a una nuova istanza è stato completato in meno di dieci secondi, mentre il tempo complessivo necessario per rendere disponibile l’API è sceso da oltre otto minuti a un minuto e 44 secondi. La differenza tra il tempo di copia e quello totale dipende dalle ulteriori operazioni necessarie per inizializzare completamente il motore di inferenza.
Il caricamento dei pesi non rappresenta infatti l’unico costo del cold start. Durante le prime esecuzioni, framework e librerie compilano o ottimizzano kernel specifici per modello, tipo di dato, quantizzazione e architettura GPU, generando cache per componenti come Triton, DeepGEMM, TileLang, CuTe DSL e FlashInfer e acquisendo i grafi CUDA. ModelExpress può trasferire anche questi artefatti già prodotti da una replica compatibile, utilizzando buffer registrati nella memoria host e comunicazioni RDMA tra CPU. Il nuovo server evita così di ripetere la medesima compilazione e può ereditare una configurazione già riscaldata, purché modello, stack software e hardware coincidano.
L’infrastruttura comprende anche ottimizzazioni per la registrazione della memoria necessaria ai trasferimenti RDMA. I grandi modelli sono composti da decine di migliaia di tensori e registrarli singolarmente introduce un ritardo significativo. La modalità pool registration registra una sola volta le allocazioni CUDA sottostanti, riducendo il numero delle operazioni tra l’80 e il 99% nei modelli tipici. La modalità VMM arena registration convoglia invece le allocazioni utilizzate durante il caricamento in un’unica area virtuale da 16 TiB e registra l’intervallo effettivamente occupato come una sola regione di memoria, sostituendo migliaia di chiamate con un’unica registrazione.
ModelExpress può essere utilizzato anche nel post-training con reinforcement learning, dove i pesi cambiano ripetutamente e devono essere trasferiti dai server di addestramento ai worker che generano i rollout. In questo scenario ogni rank del trainer pubblica i tensori o gli shard posseduti con le informazioni su forma, tipo di dato, collocazione e corrispondenza dei parametri; il worker di inferenza individua le sorgenti, adatta la distribuzione dei pesi alla propria configurazione e legge direttamente le porzioni necessarie. Il flusso è quindi guidato dal ricevente e può gestire layout differenti tra trainer e motore di inferenza, compresi FSDP, DTensor e configurazioni Megatron basate su tensor, pipeline ed expert parallelism.
NVIDIA sta inoltre sperimentando trasferimenti basati sulle sole differenze tra una versione dei pesi e la successiva, con l’obiettivo di ridurre ulteriormente i dati spostati tra cluster durante le iterazioni di reinforcement learning. Le funzioni principali sono già integrate nativamente con vLLM e SGLang e supportano ambienti di serving come NVIDIA Dynamo e llm-d, mentre sono previste integrazioni più profonde con TensorRT-LLM e altri framework.
ModelExpress non accelera direttamente i calcoli del modello e non riduce le risorse necessarie all’inferenza: ottimizza il ciclo di vita dei pesi e degli artefatti indispensabili per rendere operativa una replica. Il vantaggio principale emerge quindi nei servizi soggetti ad autoscaling, negli aggiornamenti progressivi e nei workflow di post-training, dove la capacità di avviare rapidamente nuovi worker riduce i periodi nei quali GPU costose rimangono occupate dal trasferimento dei dati senza produrre output utili.