Quando un modello di intelligenza artificiale risponde a una domanda o completa un compito, esegue l'inferenza, cioè utilizza un modello addestrato per generare un output a partire da un input. Farlo su larga scala, però, è molto più difficile di quanto possa sembrare. Eseguire un grande modello linguistico su una GPU è una sfida; servirlo contemporaneamente a migliaia o milioni di utenti e agenti IA rappresenta un'altra problematica ancora più complessa.

Le richieste arrivano con priorità e lunghezze diverse, ognuna con esigenze computazionali uniche. Alcuni utenti si aspettano una risposta immediata a query semplici, mentre altri inviano lavori lunghi che possono essere eseguiti in background. Il traffico generato dagli agenti IA introduce un nuovo modello: gli agenti possono inviare esplosioni di richieste correlate, fare pause per chiamare uno strumento, per poi tornare con quasi lo stesso contesto. Nel frattempo il sistema deve utilizzare efficientemente gli acceleratori, costosi, evitando code lunghe o ricalcoli ripetuti.

Una metafora aerea

Questa sfida ricorda il controllo del traffico aereo. Un aeroporto trafficato non può semplicemente inviare ogni aeromobile alla prima pista disponibile. I controllori nella torre devono tenere conto della posizione, della destinazione, della dimensione e del carburante dell’aeromobile, oltre al traffico già presente. Il compito sarebbe semplice se i controllori dovessero solo mantenere occupate le piste, ma un aeroporto non è un parcheggio e non tutti gli aerei possono essere trattati allo stesso modo.

Che cos’è l’inference distribuita?

L'inference distribuita svolge un ruolo simile per l'inferenza dei LLM, operando sopra i server di modello come vLLM e SGLang. Mentre questi motori eseguono i modelli efficientemente su server singoli, un framework di inference distribuita coordina gruppi di server all'interno di un cluster. Il suo router considera la profondità delle code, la disponibilità della cache e i ruoli dei server prima di decidere a quale destinazione inviare una richiesta.

Le sei innovazioni tecniche di llm‑d

Per capire come funziona l’inference distribuita, analizziamo le sei innovazioni chiave introdotte da llm‑d, un framework open‑source nativo di Kubernetes:

Routing consapevole del prefisso cache (prefix‑cache‑aware routing)
Offloading della KV‑cache
Controllo del flusso (flow control)
Ottimizzazione dell’inferenza batch
Disaggregazione prefill/decode
Parallelismo ampio degli esperti (wide expert parallelism)

1. Routing consapevole del prefisso cache

Quando un modello di linguaggio legge un prompt, genera una rappresentazione interna delle parole e delle loro relazioni, memorizzando gran parte di questo stato intermedio in una key‑value cache (KV cache). Se una richiesta successiva inizia con lo stesso testo, o con una sua parte, il modello può riutilizzare la computazione già effettuata anziché rielaborare il testo condiviso. Per esempio, se il primo prompt è “Qual è la capitale del Kansas?” e più tardi chiediamo “Qual è la capitale della California?”, la porzione “Qual è la capitale del” può essere riutilizzata dalla KV cache.

Questa opportunità si presenta frequentemente nei carichi di lavoro reali: un chatbot riceve le stesse istruzioni di sistema all’inizio di ogni conversazione; un assistente di programmazione analizza ripetutamente lo stesso repository; un agente IA ricontrolla lunghi registri di passaggi precedenti mentre sperimenta soluzioni diverse. In tutti questi casi, gran parte del prompt rimane invariata da turno a turno.

Un bilanciatore di carico tradizionale potrebbe inviare la richiesta al server meno occupato, indipendentemente dal fatto che la sua cache contenga il contesto rilevante. Di conseguenza il modello deve rileggerе materiale già elaborato altrove.

Il prefix‑cache‑aware routing si pone due domande: qual è il server che già possiede la più ampia porzione del prefisso di questo prompt e quale server ha capacità sufficiente per gestire la richiesta. Il router di llm‑d utilizza informazioni sulla cache e sulle condizioni operative per assegnare un punteggio ai server disponibili e selezionare la destinazione più adatta. Esistono due implementazioni: una approssimativa, con un indice leggero delle decisioni di routing recenti, e una precisa, basata sui dati reali dei token e sugli aggiornamenti dello stato della cache provenienti dai server di modello.

Come un aereo che ha passeggeri, bagagli e crew già pronti a una porta, inviare la macchina a un'altra porta introdurrebbe lavoro inutile. Analogamente, il sistema di inference distribuita cerca di indirizzare la richiesta al server che già contiene il contesto necessario, riducendo così il calcolo ridondante, la latenza e aumentando il throughput.

In una dimostrazione recente del team di llm‑d, il routing consapevole del prefisso ha catturato il 97 % del riutilizzo possibile nel carico di lavoro testato. La tecnica risulta particolarmente utile per i sistemi agentici, poiché le loro richieste spesso condividono istruzioni lunghe, materiale sorgente, storie di conversazione e output di strumenti.

2. Offloading della KV‑cache

Il routing basato sulla cache è più efficace quando le informazioni memorizzate rimangono disponibili. Tuttavia, la memoria degli acceleratori, seppur veloce, può riempirsi rapidamente a causa di prompt lunghi, numerosi utenti simultanei e sessioni di agente estese.

Quando lo spazio scarseggia, un server di modello può evictare le voci più vecchie della KV‑cache. Se una richiesta successiva ha bisogno di quel materiale, il modello deve ricalcolarlo, sprecando cicli dell’acceleratore per ricostruire un contesto che era disponibile pochi istanti prima.

La KV‑cache offloading affronta il problema scegliendo un target di offload in base ai requisiti del carico di lavoro. Le voci più utili rimangono nella memoria ad alta larghezza di banda dell’acceleratore, mentre altre possono essere spostate in tier più grandi ma più lenti, come la memoria CPU, lo storage SSD locale o un file system condiviso. Un indice di cache traccia dove è archiviato ogni elemento, consentendo al livello di routing di includere anche i dati offloaded nelle decisioni.

Recuperare informazioni dalla memoria CPU o dallo storage è più lento rispetto alla lettura diretta dalla memoria dell’acceleratore, ma è comunque molto più veloce ed economico rispetto al ricalcolo completo del prompt. L’offload quindi espande la capacità efficace della cache oltre la memoria fisica disponibile sugli acceleratori.

Nei test di llm‑d, la memoria GPU ha fornito dal 90 % al 92 % dei prefissi riutilizzabili per 128 richieste concorrenti, mentre l’offload su CPU ha permesso di preservare i prefissi al di sopra della capacità GPU. In un benchmark a lungo termine guidato da agenti, l’offload su CPU ha mantenuto alta la velocità di throughput e ridotto il tempo al primo token, poiché le operazioni di offload avvengono durante il prefill e le scritture su tier più lenti sono asincrone.

3. Controllo del flusso (flow control)

Il router decide dove indirizzare una richiesta, ma sotto carico il sistema deve anche stabilire quali richieste avanzare per prime e quali attendere. Quando un’ondata di traffico arriva simultaneamente, trattare ogni richiesta allo stesso modo può far sì che una query sensibile alla latenza rimanga bloccata dietro un backlog di lavoro a bassa priorità.

Gli stessi controllori del traffico aereo affrontano il problema con la gestione del flusso: quando la domanda supera la capacità, mediano le partenze, sequenziano gli arrivi e trattengono il traffico a bassa priorità a terra, garantendo che un aereo commerciale in avvicinamento non sia ritardato da un cargo che può attendere qualche minuto.

Analogamente, llm‑d implementa un flow control che assegna priorità alle richieste in base a parametri quali latenza richiesta, livello di servizio e dati di utilizzo della cache. Le richieste ad alta priorità vengono instradate verso server meno occupati o con cache più adeguata, mentre le richieste a bassa priorità possono essere messe in coda o indirizzate a server con più capacità disponibile.

4. Ottimizzazione dell’inferenza batch

L’inferenza batch aggrega più richieste in un unico passo computazionale, sfruttando al massimo la parallelizzazione offerta dagli acceleratori. Tuttavia, le richieste con lunghezze di token molto diverse possono creare inefficienze, perché il batch deve attendere che la richiesta più lunga termini il prefill.

Il framework di llm‑d introduce una strategia di batching dinamico che raggruppa le richieste con prefissi simili e lunghezze compatibili, riducendo al contempo i tempi di attesa. Questa strategia è combinata con il routing consapevole della cache, in modo che le richieste con lo stesso prefisso vengano batchate insieme e inoltrate allo stesso server.

5. Disaggregazione prefill/decode

Il processo di generazione di un token si suddivide tipicamente in due fasi: prefill, in cui il modello elabora l’intero prompt, e decode, in cui genera i token successivi uno alla volta. La disaggregazione prefill/decode separa le risorse hardware dedicate a ciascuna fase, permettendo di utilizzare acceleratori più grandi per il prefill e acceleratori più piccoli o CPU per il decode, ottimizzando così il rapporto costo‑prestazioni.

In llm‑d, i server possono essere configurati con ruoli specializzati: alcuni agiscono come prefill nodes, mantenendo ampie KV‑cache e gestendo i prompt lunghi, mentre altri fungono da decode nodes, focalizzati sulla generazione rapida di token sequenziali. Il router assegna le richieste in base al loro stato corrente, migliorando sia la latenza che il throughput complessivo.

6. Parallelismo ampio degli esperti (wide expert parallelism)

Molti grandi modelli moderni, come quelli basati su architetture Mixture‑of‑Experts (MoE), dividono il lavoro tra “esperti” specializzati. Il wide expert parallelism consente di distribuire questi esperti su più nodi, sfruttando capacità di memoria e calcolo addizionali senza dover duplicare l’intero modello.

llm‑d supporta questa modalità via un’interfaccia di routing che connette le richieste ai diversi esperti in base al token di attivazione, garantendo che ogni esperto operi su dati già presenti nella sua cache locale o offloaded. Questo approccio riduce il traffico di rete interno e migliora l’efficienza della pipeline di inferenza.

Storia e community di llm‑d

llm‑d è stato lanciato a maggio 2025 grazie alla collaborazione di IBM Research, Red Hat, Google Cloud, NVIDIA e CoreWeave. Al momento del lancio hanno partecipato anche AMD, Cisco, Hugging Face, Intel, Lambda e Mistral AI, oltre a sostenitori accademici dell’Università della California, Berkeley e dell’Università di Chicago.

Oggi IBM Research, Red Hat e Google Cloud continuano a guidare lo sviluppo, mentre la community di partner e contributori è cresciuta notevolmente. Nel marzo 2026 i fondatori hanno donato llm‑d alla Cloud Native Computing Foundation come progetto sandbox, con l’obiettivo di promuovere l’adozione di stack di inferenza per qualsiasi modello, su qualsiasi acceleratore e in qualsiasi cloud.

Benefici concreti e scenari d'uso

Riduzione della latenza: il routing consapevole della cache elimina la ricomputazione di prefissi comuni, abbattendo i tempi di risposta per le richieste sensibili.
Aumento del throughput: il batching dinamico e il flow control mantengono le GPU occupate al massimo, evitando code ocolte.
Efficienza della memoria: l’offload della KV‑cache estende la capacità cache oltre i limiti della GPU, riducendo gli eviction e i ricalcoli.
Scalabilità multi‑cloud: grazie al design nativo Kubernetes, llm‑d può essere distribuito su diverse regioni e provider, garantendo coerenza operativa.
Supporto per modelli MoE: il wide expert parallelism consente di sfruttare modelli con centinaia di esperti senza replicare l’intero modello su ogni nodo.

Conclusioni

L’inference distribuita rappresenta il “controllore del traffico” dei grandi modelli di IA, coordinando richieste eterogenee, massimizzando l’uso della cache e gestendo la capacità computazionale in modo dinamico. Le sei innovazioni introdotte da llm‑d — routing consapevole del prefisso, offloading della KV‑cache, flow control, batching dinamico, disaggregazione prefill/decode e parallelismo ampio degli esperti — dimostrano come una combinazione di orchestrazione intelligente e architettura flessibile possa mantenere efficienti sistemi di IA su scala globale. Con il sostegno di un ecosistema robusto di partner industriali e accademici, llm‑d si pone come spina dorsale per il futuro dell’inferenza su larga scala, permettendo a modelli sempre più potenti di servire milioni di utenti senza sacrificare costi o prestazioni.