Llm-D 1.0 debutta alla PyTorch Conference con uno stack di inferenza per la produzione

I collaboratori del progetto llm-d hanno annunciato llm-d 1.0, uno stack distribuito per il serving dell’inferenza nativo per Kubernetes, il 20 ottobre 2026 alla PyTorch Conference North America, secondo un annuncio di IBM Research. IBM ha dichiarato che questa versione porta llm-d oltre la dimostrazione di singole tecniche per migliorare le prestazioni e mira ad aiutare le organizzazioni a gestire internamente la distribuzione dei modelli, mentre i costi dell’inferenza aumentano.

llm-d è progettato per distribuire stack di inferenza per qualsiasi modello, su qualsiasi acceleratore e in qualsiasi cloud. Red Hat, IBM e Google sono i principali responsabili della manutenzione del progetto e hanno fondato llm-d insieme a CoreWeave e NVIDIA; AMD, Cisco, Hugging Face, Intel, Lambda e Mistral AI hanno aderito come collaboratori. La Cloud Native Computing Foundation (CNCF) ospita llm-d come progetto sandbox. IBM descrive il risultato come un’alternativa indipendente dai fornitori, pensata per le organizzazioni che desiderano quelle che definisce prestazioni di inferenza di livello frontier senza dipendere interamente da un unico fornitore di modelli proprietari, cloud o piattaforma hardware.

Carlos Costa, Distinguished Engineer presso IBM Research, cofondatore di llm-d e responsabile principale della manutenzione del progetto, ha affermato che la versione 1.0 offre la maturità necessaria per gestire llm-d come qualsiasi altro servizio critico, indicando un’API stabile, la possibilità per più tenant con priorità in conflitto di condividere la stessa infrastruttura e aggiornamenti che non interrompono le operazioni.

Le novità della versione 1.0

Le note di rilascio di v1.0.0 del progetto, pubblicate su GitHub il 20 ottobre 2026 con tag firmati e verificati, mettono in primo piano la qualità del servizio in ambienti multi-tenant: controllo del flusso attento alle priorità e all’equità, con riduzione controllata del carico, che include un meccanismo di ammissione probabilistica, equità basata sul programma e attribuzione di punteggi di priorità ai turni. In questo modo, le richieste sensibili alla latenza e i carichi di lavoro agentici con picchi di attività possono condividere un parco di risorse senza che uno dei due venga penalizzato durante i sovraccarichi. La configurazione del controllo del flusso è raccolta in un unico campo flowControl.

Per operare senza tempi di inattività, il router acquisisce funzionalità di alta disponibilità con standby a caldo e aggiornamenti progressivi sicuri; un controller DisaggregatedSet gestisce le repliche di prefill e decode come un’unica unità logica, con distribuzioni coordinate, aggiornamenti sincronizzati, verifiche di disponibilità subordinate allo snapshot del Pod e instradamento nativo per revisione. L’API di configurazione del router passa alla versione v1, l’API Responses supporta previous_response_id e il percorso delle richieste dell’endpoint picker è stato rafforzato per garantire affidabilità, prestazioni e scalabilità. È inclusa una guida agli acceleratori consapevole della topologia per DRA e DRANET.

Il serving consapevole degli agenti introduce un plug-in per la produzione dello stato di sessione e un’affinità di sessione dinamica, così da mantenere le conversazioni su più turni vicine al contesto memorizzato nella cache; include inoltre la pianificazione basata sulla priorità dei turni e lo stato dell’API Responses, per aiutare gli agenti a riutilizzare il contesto da un turno all’altro. La versione porta i componenti del progetto alla v1.0.0 e aggiunge elementi all’ecosistema, tra cui un’integrazione con ai-dynamo/modelexpress per il caricamento peer-to-peer dei pesi dei modelli, il pacchetto llm-d-api-extensions e gli strumenti diagnostici llm-d-pd-utils; inoltre, rende obsoleti i build delle immagini container llm-d-rocm sviluppate dal progetto. Le immagini dei server di modelli includono build di vLLM e SGLang per diversi tipi di acceleratori; la guida alla disaggregazione di prefill e decode richiede ora LeaderWorkerSet v0.11.1 o versioni successive, con l’API DisaggregatedSet abilitata.

Tecniche fondamentali e controllo del flusso

Fin dal lancio, il progetto si è concentrato su cinque approcci per migliorare l’inferenza: l’instradamento consapevole della cache dei prefissi, che indirizza una richiesta verso un’infrastruttura che potrebbe già contenere il contesto condiviso; lo spostamento della cache KV, che trasferisce le informazioni memorizzate nella cache tra GPU, CPU e risorse di archiviazione; l’ottimizzazione dell’inferenza batch; la disaggregazione di prefill e decode, che separa la lettura di un prompt dalla generazione di una risposta; e il parallelismo esteso degli esperti, che distribuisce i grandi modelli mixture-of-experts su numerosi acceleratori. Queste tecniche precedono la versione 1.0; secondo IBM, le novità sono la loro integrazione, la maturità operativa che le accompagna e la disciplina di gestione operativa del day 2, ossia la capacità di mantenere le prestazioni quando cambiano i flussi di traffico, si guastano i componenti hardware, si aggiorna il software o utenti diversi competono per le stesse risorse.

Nella versione 1.0, il controllo del flusso, l’equità e la definizione delle priorità mirano a impedire che i carichi di lavoro con picchi di attività sopraffacciano i servizi sensibili alla latenza, sia quando condividono lo stesso hardware sia quando utilizzano una combinazione di acceleratori. Inoltre, le richieste possono rimanere associate all’infrastruttura appropriata per più turni, mantenendo calde le cache dei prefissi. llm-d funziona con motori di inferenza come vLLM o SGLang, ai quali aggiunge funzionalità di instradamento distribuito e di gestione operativa. Stephen Watt, vicepresidente nell’ufficio del direttore tecnico di Red Hat, ha affermato che llm-d unifica gli ecosistemi PyTorch e CNCF portando l’orchestrazione nativa per Kubernetes direttamente in vLLM e nei moderni motori di inferenza.

Risultati dimostrati e costi dichiarati

In un post sui benchmark pubblicato il 22 luglio 2026, il progetto ha misurato il serving agentico di GLM-5.2, descritto nel post come un modello mixture-of-experts da 744 miliardi di parametri, con 39 miliardi di parametri attivi e 78 strati. L’analisi del carico di lavoro si è basata su 219 sessioni di produzione di Claude Code, nelle quali la richiesta mediana dell’agente principale conteneva 195.000 token in input e restituiva 317 token in output; inoltre, il 96% dei turni dell’agente principale riutilizzava almeno il 90% dei token in input. Il post riferisce che il routing consapevole dei prefissi ha sfruttato il 96–97% del riutilizzo della cache reso possibile dal carico di lavoro. Considerando una tariffa di noleggio ipotizzata di H200 pari a 2,71 $ per GPU-ora, stima che il serving su infrastruttura autogestita, con due configurazioni da 64 GPU, costi da 0,05 a 0,08 $ per milione di token in input e da 1,92 a 3,55 $ per milione di token in output. Gli autori precisano che queste cifre coprono solo il noleggio delle GPU e presuppongono un carico sostenuto.

In una dimostrazione separata, IBM e Red Hat hanno implementato GLM-5.2 su 544 GPU NVIDIA H100. Nel resoconto di IBM Research, il modello è descritto come un modello open-weight da circa 753 miliardi di parametri, con circa 39 miliardi di parametri attivi. IBM riferisce che, al picco, l’implementazione ha raggiunto oltre 6,6 milioni di token in output al minuto, servendo fino a 3.000 agenti di coding simultanei senza alcuna preemption; inoltre, con 2.500 agenti, ha mantenuto un ritmo di 7.612 richieste al minuto. IBM afferma che, alle attuali tariffe di noleggio nel cloud, il self-hosting di GLM-5.2 su GPU H100 con llm-d costa da 5 a 10 volte meno per token rispetto ai prezzi di API commerciali equivalenti. «Servire migliaia di agenti simultanei senza preemption offre agli operatori un percorso credibile per passare dai risultati di un benchmark a un’implementazione in produzione», ha dichiarato Maroon Ayoub, ingegnere senior principal specializzato in machine learning nel team di ingegneria dell’inferenza di Red Hat.

Secondo lo stesso resoconto, alla base di questi risultati il piano dati disaggregato ha completato 6,2 milioni di trasferimenti della cache KV, con una media di 2,71 GiB per trasferimento e senza alcun errore di trasferimento; tutti i benchmark si sono conclusi senza errori di serving.