Il progetto open‑source llm‑d ha annunciato la versione 1.0 il 20 ottobre 2026 alla conferenza PyTorch North America, evidenziando una pila di servizi di inferenza distribuita nativa di Kubernetes pronta per la produzione. IBM Research ha pubblicato l’annuncio, sottolineando che la nuova release va oltre le dimostrazioni di tecniche di performance isolate e si propone di aiutare le organizzazioni a gestire internamente il deployment di modelli, in un contesto di costi di inferenza in costante aumento.

Architettura e ecosistema

llm‑d è progettato per distribuire pile di inferenza per qualsiasi modello, su qualsiasi acceleratore e su qualsiasi cloud. Red Hat, IBM e Google ne curano la manutenzione, avendo co‑fondato il progetto insieme a CoreWeave e NVIDIA. Tra i contributori più recenti figurano AMD, Cisco, Hugging Face, Intel, Lambda e Mistral AI. La Cloud Native Computing Foundation (CNCF) ospita llm‑d come progetto sandbox, garantendo una governance indipendente dai fornitori.

Secondo le parole di Carlos Costa, ingegnere eminente di IBM Research e co‑fondatore di llm‑d, la versione 1.0 fornisce la maturità necessaria per trattare llm‑d come un servizio critico: API stabile, supporto multitenant con priorità concorrenti e aggiornamenti senza interruzioni.

Principali novità della versione 1.0

    • Controllo dei flussi multilocatore: gestione delle priorità, equità, delega controllata del carico e meccanismo di ammissione probabilistica.
    • Alta disponibilità del router: istanza di backup a caldo e aggiornamenti progressivi sicuri.
    • DisaggregatedSet controller: gestisce repliche di pre‑fill e decoding come un’unica unità logica, con upgrade sincronizzati e routing nativo per revisione.
    • API v1 per il router e API Responses con supporto per previousresponseid e percorso di selezione endpoint più robusto.
    • Guida acceleratori topologia‑aware per DRA e DRANET.
    • Modulo session‑state‑producer per mantenere il contesto multi‑turno vicino alla cache, con pianificazione basata sulla priorità dei turni.
    • Integrazioni: ai‑dynamo/modelexpress per il caricamento P2P dei pesi, pacchetto llm‑d‑api‑extensions e strumenti diagnostici llm‑d‑pd‑utils.
    • Deprecazione immagini ROCm: ora le immagini server includono vLLM e SGLang per vari acceleratori.
    • Separazione pre‑fill/decoding: richiede LeaderWorkerSet v0.11.1 o successivo con API DisaggregatedSet attivata.

Tecniche fondamentali e controllo dei flussi

Il progetto si concentra su cinque approcci chiave per ottimizzare l’inferenza:

    • Routing basato sul cache dei prefissi, che indirizza le richieste verso infrastrutture già in possesso del contesto condiviso.
    • Off‑loading del cache KV, spostando i dati tra GPU, CPU e storage.
    • Batching dell’inferenza per massimizzare l’utilizzo delle risorse.
    • Separazione del pre‑fill dal decoding, dissociando lettura del prompt e generazione della risposta.
    • Parallellismo esteso degli esperti, distribuendo modelli Mixture‑of‑Experts su più acceleratori.

Queste tecniche erano presenti nelle versioni precedenti, ma llm‑d 1.0 le integra in modo operativo, aggiungendo discipline di gestione post‑deployment per garantire prestazioni costanti nonostante variazioni di traffico, guasti hardware o aggiornamenti software.

Gestione delle priorità e dell’equità

Il nuovo controllo dei flussi impedisce che carichi di lavoro a raffica sovraccarichino i servizi sensibili alla latenza, sia che condividano lo stesso hardware sia che siano distribuiti su acceleratori eterogenei. Le richieste mantengono la loro affinità con l’infrastruttura appropriata per più turni, preservando i cache dei prefissi attivi.

llm‑d opera con motori di inferenza come vLLM o SGLang, a cui aggiunge capacità di routing distribuito e gestione avanzata delle risorse. Stephen Watt, VP di Red Hat, ha affermato che llm‑d unifica gli ecosistemi PyTorch e CNCF integrando l’orchestrazione nativa di Kubernetes con i moderni motori di inferenza.

Risultati di benchmark e costi

Un articolo pubblicato il 22 luglio 2026 descrive i risultati di un test di performance su GLM‑5.2, modello Mixture‑of‑Experts da 744 miliardi di parametri (39 miliardi attivi, 78 layer). Il test ha coinvolto 219 sessioni di produzione con Claude Code, con una mediana di 195 000 token di input e 317 token di output per turno. Il 96 % dei turni ha riutilizzato almeno il 90 % delle proprie entrate.

Il routing basato sui prefissi ha permesso di catturare il 96‑97 % della potenziale riutilizzazione della cache. Assumendo un costo di noleggio di una GPU H200 di 2,71 $ / ora‑GPU, il servizio auto‑hosted per due configurazioni da 64 GPU costa tra 0,05 $ e 0,08 $ per milione di token di input e tra 1,92 $ e 3,55 $ per milione di token di output, includendo solo il costo delle GPU e supponendo carico sostenuto.

In una dimostrazione separata, IBM e Red Hat hanno distribuito GLM‑5.2 su 544 GPU NVIDIA H100. Il modello, descritto come open‑weight con circa 753 miliardi di parametri e 39 miliardi attivi, ha mostrato scalabilità lineare e mantenuto latenza sotto 30 ms per token su carichi misti, confermando l’efficacia della pila llm‑d in ambienti di produzione su larga scala.

Implicazioni per le organizzazioni

La capacità di gestire in modo autonomo l’inferenza su più cloud, acceleratori e provider riduce la dipendenza da soluzioni proprietarie e consente di ottimizzare i costi operativi. Le aziende possono ora:

    • Deployare modelli di grandi dimensioni su infrastrutture ibride senza lock‑in.
    • Sfruttare il controllo dei flussi per garantire SLA di latenza anche sotto carichi di picco.
    • Aggiornare componenti critici senza downtime grazie all’alta disponibilità del router.
    • Beneficiare di un ecosistema CNCF con supporto da leader di settore come Red Hat, IBM e Google.

In sintesi, llm‑d 1.0 rappresenta un passo decisivo verso l’inferenza di grandi modelli AI in produzione, combinando innovazioni tecniche consolidate con una maturità operativa adatta a scenari enterprise.