Il progetto open source llm-d ha annunciato, in occasione della PyTorch Conference North America, il rilascio della versione 1.0 della propria infrastruttura per l’esecuzione distribuita dei modelli linguistici. La piattaforma è progettata per realizzare sistemi di inference serving basati su Kubernetes, capaci di distribuire le richieste tra più acceleratori, gestire i carichi di lavoro di applicazioni e agenti AI e ottimizzare l’utilizzo delle risorse di calcolo. L’obiettivo dichiarato è rendere possibile l’installazione di modelli su differenti tipologie di acceleratori e ambienti cloud, limitando la dipendenza da un singolo fornitore hardware o da servizi proprietari di inferenza. Red Hat, IBM e Google sono i principali maintainer del progetto, fondato insieme a CoreWeave e NVIDIA, al quale contribuiscono anche AMD, Cisco, Hugging Face, Intel, Lambda e Mistral AI. llm-d è ospitato dalla Cloud Native Computing Foundation come progetto sandbox e integra motori di inferenza esistenti, tra cui vLLM e SGLang, aggiungendo un livello di orchestrazione, instradamento e gestione operativa destinato alle installazioni distribuite. La versione 1.0 segna il passaggio dalla sperimentazione di singole tecniche di ottimizzazione a una configurazione maggiormente orientata alla continuità dei servizi, alla gestione simultanea di più utenti e alla manutenzione delle infrastrutture in esercizio.
Uno degli aggiornamenti principali riguarda la qualità del servizio nelle installazioni multi-tenant, nelle quali più applicazioni o gruppi di utenti condividono gli stessi acceleratori. Il sistema introduce meccanismi di flow control basati su priorità ed equità nell’assegnazione delle risorse, con possibilità di limitare o scartare in maniera controllata parte del traffico quando la capacità disponibile non è sufficiente a soddisfare tutte le richieste. Tra i componenti figurano un probabilistic admitter, destinato a gestire probabilisticamente l’ammissione delle richieste, criteri di fairness consapevoli del programma applicativo e un sistema di turn-priority scoring che attribuisce priorità ai diversi turni di elaborazione. Questi strumenti permettono di distinguere le richieste sensibili alla latenza dai carichi agentici caratterizzati da improvvisi aumenti del traffico, evitando che un’attività particolarmente intensa monopolizzi l’intera infrastruttura. La configurazione dei controlli viene raccolta nel campo unificato flowControl. L’architettura supporta inoltre installazioni con acceleratori differenti, nelle quali l’assegnazione delle richieste deve considerare sia le caratteristiche delle risorse disponibili sia le esigenze di continuità dei singoli processi applicativi.
La versione 1.0 introduce anche funzionalità destinate agli aggiornamenti senza interruzione del servizio. Il router supporta configurazioni ad alta disponibilità con hot standby e procedure di rolling update, mentre il controller DisaggregatedSet permette di gestire congiuntamente le repliche utilizzate nelle fasi di prefill e decode. Il prefill corrisponde all’elaborazione iniziale dei token del prompt e alla costruzione delle rappresentazioni necessarie per proseguire l’inferenza; il decode riguarda invece la generazione progressiva dei token di risposta. Separare queste attività permette di assegnarle a risorse differenti e di dimensionarle in funzione delle caratteristiche del carico. Il controller coordina distribuzione e aggiornamento delle repliche come un’unica unità logica, introducendo rollout sincronizzati, aggiornamenti lockstep, verifiche di disponibilità basate sugli snapshot dei Pod e instradamento nativo verso differenti revisioni del servizio. L’API di configurazione del router raggiunge la versione stabile v1 e il percorso di selezione degli endpoint viene rafforzato per migliorare affidabilità, prestazioni e scalabilità. La Responses API supporta inoltre il parametro previous_response_id, che consente di collegare le richieste successive allo stato delle interazioni precedenti.
Un’ulteriore area di sviluppo riguarda il serving consapevole delle caratteristiche degli agenti AI. I sistemi agentici eseguono frequentemente più interrogazioni consecutive mantenendo invariata una parte considerevole del contesto, situazione nella quale trasferire ripetutamente le richieste tra nodi differenti può provocare la perdita dei vantaggi associati alla cache. llm-d introduce un plugin session-state-producer e meccanismi evoluti di session affinity, destinati a mantenere le conversazioni multi-turno in prossimità delle risorse che conservano le informazioni contestuali già elaborate. Il sistema utilizza anche la priorità dei turni e le informazioni sullo stato della Responses API per favorire il riutilizzo delle rappresentazioni precedenti. Queste funzionalità si aggiungono alle tecniche già sviluppate nel progetto: prefix-cache-aware routing, che seleziona gli endpoint in base alla presenza di prefissi condivisi nella cache; KV-cache offloading, che trasferisce le rappresentazioni di key e value tra memoria GPU, CPU e sistemi di archiviazione; ottimizzazione dell’inferenza mediante batching; disaggregazione delle fasi di prefill e decode; e wide expert parallelism, utilizzato per distribuire modelli mixture-of-experts di grandi dimensioni su numerosi acceleratori. Le tecniche erano già presenti nelle precedenti attività del progetto, mentre il rilascio 1.0 si concentra sulla loro integrazione in un’infrastruttura gestibile durante aggiornamenti, guasti hardware e variazioni del traffico.
Il pacchetto comprende ulteriori componenti per l’integrazione e la manutenzione. Tutti i moduli principali vengono allineati alla versione 1.0.0 e sono disponibili immagini dei model server basate su vLLM e SGLang per diversi acceleratori. L’integrazione con ai-dynamo/modelexpress introduce funzionalità di caricamento peer-to-peer dei pesi dei modelli, mentre llm-d-api-extensions e llm-d-pd-utils forniscono rispettivamente estensioni delle API e strumenti diagnostici. Il progetto ha inoltre dismesso la produzione delle proprie immagini container llm-d-rocm, modificando la strategia di distribuzione per questo ambiente. Le nuove istruzioni per la disaggregazione prefill/decode richiedono LeaderWorkerSet almeno alla versione 0.11.1, con attivazione dell’API DisaggregatedSet. Sono disponibili anche indicazioni per l’utilizzo di acceleratori con consapevolezza della topologia attraverso DRA e DRANET. Secondo Carlos Costa, Distinguished Engineer di IBM Research e cofondatore del progetto, la disponibilità di API stabili, gestione multi-tenant e aggiornamenti senza interruzioni costituisce un passaggio necessario per trattare i sistemi di inferenza come servizi infrastrutturali critici, anziché come singole installazioni sperimentali.
Le capacità della piattaforma sono state esaminate attraverso benchmark dedicati ai carichi agentici. In una valutazione pubblicata il 22 luglio 2026 è stato utilizzato GLM-5.2, descritto nella relativa configurazione come un modello mixture-of-experts da 744 miliardi di parametri complessivi, dei quali 39 miliardi attivi, distribuiti su 78 livelli. L’analisi del traffico ha preso in considerazione 219 sessioni di produzione di Claude Code, nelle quali la richiesta mediana dell’agente principale comprendeva circa 195.000 token in ingresso e 317 token in uscita. Il 96% dei turni dell’agente principale riutilizzava almeno il 90% del contenuto in ingresso, evidenziando un carico caratterizzato da prompt molto estesi e da un’elevata ripetizione del contesto. In queste condizioni, il routing consapevole della cache ha consentito di sfruttare il 96-97% del riutilizzo potenzialmente disponibile. Assumendo un costo di noleggio pari a 2,71 dollari per ora-GPU NVIDIA H200, due configurazioni da 64 GPU hanno prodotto stime di costo comprese tra 0,05 e 0,08 dollari per milione di token in ingresso e tra 1,92 e 3,55 dollari per milione di token in uscita. Le cifre considerano esclusivamente il noleggio delle GPU e presuppongono un carico sostenuto, senza includere tutti gli altri costi associati alla gestione di un’infrastruttura produttiva.
Una seconda dimostrazione realizzata da IBM e Red Hat ha impiegato 544 GPU NVIDIA H100 per distribuire GLM-5.2, indicato in questa configurazione come modello open-weight da circa 753 miliardi di parametri complessivi e 39 miliardi attivi. L’infrastruttura ha raggiunto un picco superiore a 6,6 milioni di token generati al minuto, servendo fino a 3.000 agenti di programmazione contemporaneamente senza preemption. Con 2.500 agenti attivi è stata misurata una capacità sostenuta di 7.612 richieste al minuto. Il piano dati disaggregato ha completato 6,2 milioni di trasferimenti di KV cache, con una dimensione media di 2,71 GiB per trasferimento, senza registrare errori nei trasferimenti; anche i benchmark complessivi sono terminati senza errori di serving. Sulla base delle tariffe cloud considerate, IBM stima che l’esecuzione autonoma di GLM-5.2 su H100 attraverso llm-d possa ridurre il costo per token da cinque a dieci volte rispetto a servizi API commerciali ritenuti equivalenti. La stima dipende tuttavia dalle condizioni economiche e operative adottate nel confronto. Il rilascio 1.0 riunisce quindi meccanismi di distribuzione del carico, controllo della latenza, riutilizzo della cache e gestione degli aggiornamenti, con l’obiettivo di rendere l’inferenza dei grandi modelli un servizio distribuito amministrabile attraverso strumenti cloud native.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)