Alla PyTorch Conference North America è stato annunciato llm‑d 1.0, un importante traguardo per l’infrastruttura AI open‑source. Si tratta di una rete di serving di inferenza distribuita, nativa Kubernetes, che consente di distribuire stack di inferenza per qualsiasi modello, su qualsiasi acceleratore e in qualsiasi cloud.
Un progetto collaborativo e neutro rispetto ai fornitori
Il rilascio dimostra che llm‑d è passato dalla dimostrazione di singole tecniche di performance a una piattaforma pronta a supportare le realtà di produzione: efficienza sostenuta sotto carichi variabili, bilanciamento delle priorità di servizio e capacità di gestire la crescente domanda. Con i costi di inferenza in aumento, llm‑d aiuta le aziende a internalizzare il deployment dei modelli e a ottenere ritorni sugli investimenti in IA.
Il lavoro è stato sviluppato da una comunità open‑source in crescita, che include fornitori hardware, sviluppatori di modelli, piattaforme cloud e utenti enterprise. I manutentori principali – Red Hat, IBM e Google – hanno trasformato tecniche avanzate di inferenza in un sistema coordinato scalabile. Il progetto è nato lo scorso anno grazie a CoreWeave e NVIDIA; successivamente hanno partecipato AMD, Cisco, Hugging Face, Intel, Lambda e Mistral AI.
Il risultato è un’alternativa neutrale rispetto ai fornitori per le organizzazioni che desiderano performance di inferenza di livello frontiera senza dipendere interamente da un unico provider proprietario, cloud o hardware.
Pronto per le operazioni “day 2”
“llm‑d è pronto per le operazioni day 2”, ha dichiarato Carlos Costa, Distinguished Engineer di IBM Research e co‑fondatore del progetto. “La versione 1.0 aggiunge la maturità necessaria a gestirlo come qualsiasi altro servizio critico: API stabile, più tenant con priorità concorrenti, e aggiornamenti senza interruzioni.”
Fin dal lancio, llm‑d ha focalizzato cinque approcci chiave per migliorare l’inferenza AI:
- Routing consapevole del prefix‑cache: indirizza le richieste verso infrastrutture che già possiedono il contesto condiviso.
- KV‑cache offloading: estende la vita utile della cache spostandola tra GPU, CPU e storage.
- Ottimizzazione dell’inferenza batch: raggruppa i lavori per una più efficiente elaborazione.
- Disaggregazione prefill/decode: separa la lettura del prompt dalla generazione della risposta.
- Wide expert parallelism: distribuisce grandi modelli mixture‑of‑experts su molti acceleratori.
Queste idee non sono nuove nella 1.0; ciò che è nuovo è il livello di integrazione e maturità operativa che le unisce.
Gestione di carichi concorrenti e qualità del servizio
Con la versione 1.0, llm‑d supporta operazioni day 2, ovvero tutto ciò che avviene dopo il deployment di un servizio AI: gestione di carichi con priorità diverse, requisiti di performance eterogenei, mantenimento dell’efficienza, priorizzazione dei servizi critici e affidabilità nel tempo. Un benchmark può mostrare un miglioramento di throughput, ma un sistema di produzione deve mantenere quella performance di fronte a variazioni di traffico, guasti hardware, aggiornamenti software o concorrenza tra utenti.
llm‑d 1.0 introduce supporto per multi‑tenant quality of service, operazioni a zero downtime e serving “agent‑aware”, garantendo performance sostenuta nelle comuni operazioni di produzione. Un servizio AI enterprise può ricevere richieste sia da persone sia da agenti autonomi attraverso lo stesso endpoint, ma i carichi si comportano diversamente: un assistente di codifica richiede risposte rapide, mentre un agente può inviare burst di richieste, fare pause per usare strumenti e poi tornare con ulteriori chiamate al modello.
Controllo del flusso e priorità
Il “flow control” di llm‑d 1.0 gestisce le priorità concorrenti, sia quando i carichi condividono lo stesso hardware sia quando si estendono su un mix di acceleratori. Il controllo del flusso, l’equità e la prioritizzazione impediscono che carichi a scoppi impediscano i servizi sensibili alla latenza. In situazioni di alta domanda, il sistema decide in modo più deliberato quali richieste devono ricevere risorse per prime.
Le richieste possono rimanere “pinned” all’infrastruttura appropriata attraverso più turni, mantenendo caldo il prefix‑cache e aumentando la probabilità di riutilizzare il contesto già elaborato anziché ricalcolarlo.
Implicazioni economiche e casi d’uso reali
Questa attenzione alla produzione influisce direttamente sull’economia dell’IA. Con l’IA che entra nelle operazioni quotidiane, l’inferenza diventa una spesa ricorrente. I sistemi agentici possono aumentare questa spesa perché un singolo compito può richiedere molteplici round di ragionamento, uso di strumenti, valutazione e revisione. Se ogni passaggio richiede al modello di rileggerе lo stesso materiale, si paga ripetutamente per lavoro già svolto.
In un test recente su un carico di lavoro di codifica agentica, il router consapevole del prefix ha catturato il 97 % del riutilizzo di cache disponibile. Evitando calcoli ripetuti e sfruttando meglio l’hardware esistente, queste tecniche possono ridurre il costo del servizio AI su larga scala.
In un’altra dimostrazione, IBM e Red Hat hanno eseguito 3 000 agenti di ingegneria del software in concorrenza su una distribuzione self‑hosted, ottenendo costi da 5 a 10 volte inferiori rispetto al prezzo di servire lo stesso modello open‑source come servizio.
Quando un’organizzazione gestisce la propria infrastruttura, essa diventa parte di una struttura di costi gestibile. Combinando modelli open‑weight con uno stack di serving open‑source, llm‑d offre alle aziende un’opzione in più per controllare il rapporto tra consumo di IA, spesa infrastrutturale e valore di business.
Integrazione con l’ecosistema open‑source
llm‑d funziona con engine di inferenza come vLLM o SGLang, aggiungendo il routing distribuito e le capacità operative necessarie a trasformare i server di modello in servizi di produzione.
Ciò conferisce a llm‑d un ruolo importante nel più ampio ecosistema open‑source. PyTorch è strettamente legato a chi sviluppa modelli e applicazioni IA, mentre la Cloud Native Computing Foundation (CNCF) – che ospita llm‑d come progetto sandbox – si concentra maggiormente sul deployment e sull’operatività in produzione. Il progetto llm‑d è un ponte tra questi mondi.
“llm‑d unifica gli ecosistemi PyTorch e CNCF portando l’orchestrazione nativa Kubernetes direttamente a vLLM e ai moderni engine di inferenza”, ha commentato Stephen Watt, vicepresidente di Red Hat. “Offre inferenza distribuita ad alte prestazioni con l’affidabilità e la scala richieste dalle imprese, tutto entro un modello operativo già noto.”
Il contributo di IBM a llm‑d riflette un approccio di lunga data: prendere idee che migliorano il calcolo e trasformarle in tecnologie aperte utilizzabili nel mondo reale. Con llm‑d 1.0, questo lavoro ha prodotto uno stack di inferenza progettato non solo per eccellere in performance, ma anche per mantenere tali performance quando l’IA diventa infrastruttura critica. L’inferenza AI open‑source è ora pronta per essere operata, governata e ottimizzata in ambienti di produzione.