Le stesse 16 GPU, il doppio degli utenti: routing consapevole con l'inferenza per i cluster LLM

Breve riassunto: le stesse 16 GPU, il doppio degli utenti. La spesa per le GPU rimane invariata mentre la capacità raddoppia. Un cluster che gestiva 20 utenti simultaneamente, ora ne gestisce 200. Lo strumento di pianificazione dell'inferenza di llm-d consente di ottenere risultati come questo: è stato creato per instradare ogni richiesta in un cluster distribuito con visibilità su ogni nodo, coda e cache. Le richieste dei modelli linguistici di grandi dimensioni (LLM) sono lente, disomogenee e costose: lo strumento di pianificazione dell'inferenza è progettato proprio per questo.

Il modello che funziona ovunque

La GPU ha un prezzo orario. Quanto lavoro riesci a fare con la tua GPU?

Con Kubernetes crei, distribuisci e gestisci servizi distribuiti in modo scalabile. In una configurazione Kubernetes standard, definisci un deployment, imposti un numero di repliche, mentre un servizio Kubernetes ti offre un punto di accesso con bilanciamento del carico round robin su tutti i pod. Questo modello è ideale per le API REST, i servizi web e i microservizi. Le richieste sono rapide e uniformi e ciascuna richiede circa lo stesso tempo (meno di un secondo) per essere completata.

Tuttavia, nel momento in cui inizi a fornire modelli generativi di grandi dimensioni in modo scalabile, come modelli open source di classe Llama, Mistral o GPT, questo presupposto non è più valido.

I limiti dell’approccio round robin

Le richieste di inferenza LLM non sono come le normali richieste HTTP e sono le differenze che interrompono il bilanciamento del carico standard.

• Variabilità temporale: l'esecuzione di una richiesta può durare meno di un secondo o più di un minuto, a seconda di ciò che si chiede al modello. Il metodo round robin distribuisce le richieste, non il lavoro. Se una replica riceve una sequenza di richieste lunghe e costose, si crea un ingorgo e altre richieste restano in attesa.
• Variabilità della forma: i prompt brevi con risposte lunghe si comportano in modo diverso dai prompt lunghi con risposte brevi. Profilo di elaborazione, carico di memoria e tempo di completamento sono diversi.
• Variabilità di fase: ogni richiesta di inferenza ha due fasi interne. La precompilazione elabora l'intero prompt di input in un'unica operazione parallela, mentre la decodifica genera la risposta un token alla volta. Queste due fasi presentano profili di risorse, durate e sensibilità al carico differenti. Un sistema che non sa distinguerli non può ottimizzare nessuno dei due.

Il round robin è stato creato per carichi di lavoro in cui le richieste sono di breve durata, uniformi ed economiche. Uno strumento di pianificazione che non riesce a vedere all'interno della richiesta le tratta allo stesso modo.

Figura 1: L’approccio round robin distribuisce il numero di richieste, non il lavoro. Le stesse cinque richieste (di dimensioni e costi di elaborazione diversi) arrivano in modo non uniforme tra i pod. Un pod è blocccato da due lunghe richieste, mentre un altro rimane per lo più inattivo. Il routing basato sull'inferenza rileva forma, dimensioni e carico, bilanciando invece il lavoro effettivo.

Un riscontro nella cach sul pod sbagliato equivale a un mancato riscontro

vLLM è il motore di inferenza standard per gli LLM: tutti i principali acceleratori hardware sono ottimizzati per questo motore e i nuovi modelli vengono forniti con supporto vLLM immediato. Gestisce in modo eccezionale i meccanismi di inferenza su un singolo nodo.

vLLM ha introdotto il caching dei prefissi per risolvere una delle parti più costose dell'inferenza: la rielaborazione continua degli stessi prefissi dei prompt. Quando più richieste condividono un prefisso comune (un prompt di sistema, un documento o la cronologia delle conversazioni), vLLM può memorizzare nella cache lo stato Key-Value (KV) dal primo calcolo e riutilizzarlo per le richieste successive. In caso di riscontro nella cache, il passaggio di precompilazione viene completamente ignorato: il tempo necessario per il primo token (TTFT) diminuisce proporzionalmente alla quota del prompt già memorizzata nella cache, ma solo se la richiesta raggiunge la replica specifica che contiene quella cache.

Una richiesta che sarebbe quasi gratuita su una replica viene indirizzata a un'altra, dove inizia da zero. L'ottimizzazione esiste, ma il routing round robin la ignora.

Con poco traffico questa è un'opportunità persa. Su larga scala, paghi il doppio per lo stesso calcolo.

Dal nodo al cluster

Ogni pod vede solo se stesso, anche se ogni pod vLLM gestisce bene la propria quota di richieste: gestisce la memoria, esegue il batching in modo efficiente e distribuisce i token alla velocità massima consentita dall'hardware. Non sa cosa stiano elaborando gli altri pod, quali repliche siano sotto carico o quale sia lo stato della cache dei prefissi nel cluster. 

Il problema del coordinamento risiede al di sopra del nodo e Kubernetes è la piattaforma d'elezione per infrastruttura distribuita e orchestrazione scalabile, quindi llm-d è progettato per essere nativo di Kubernetes fin dall'inizio per risolvere esattamente questo problema. 

L'Inference Gateway (IGW) è l'applicazione pratica di questo concetto: un livello di traffico basato su Envoy e un'API Kubernetes Gateway che comprende i carichi di lavoro LLM, non solo HTTP. Dietro le quinte, l'Inference Scheduler controlla in tempo reale ogni pod nell'InferencePool (profondità della coda, stato della cache KV, carico) e indirizza ogni richiesta all'istanza corretta anziché alla successiva in rotazione.

Figura 2: l'Inference Gateway (IGW) riceve ogni richiesta e consulta l'Inference Scheduler (EPP) tramite ext_proc. Lo strumento di pianificazione assegna un punteggio a tutti i pod nell'InferencePool in base a due segnali in tempo reale (stato della cache KV e carico), restituisce l'endpoint selezionato all'IGW e quest'ultimo inoltra la richiesta. In caso di riscontro nella cache, la parte di precompilazione memorizzata nella cache viene riutilizzata e la decodifica inizia immediatamente. In caso di mancato riscontro, la precompilazione viene eseguita interamente.

Pianificazione dell'inferenza su larga scala: stesso hardware, capacità doppia

Lo strumento di pianificazione dell'inferenza (l'Inference Scheduler di llm-d, o EPP) rende concreto il coordinamento a livello di cluster. Anziché trattare tutti i pod come intercambiabili, indirizza ogni richiesta in base a segnali in tempo reale. Stato della cache KV, profondità della coda e carico. Ogni richiesta va all'istanza giusta, ogni volta.

I risultati del benchmark di llm-d v0.5 mostrano i vantaggi pratici che ne derivano.

Pianificazione dell'inferenza (Qwen3-32B, 8 pod vLLM, 16 NVIDIA H100):

• Incremento del rendimento fino al 109% rispetto a un servizio Kubernetes di base. Le stesse 16 GPU servono circa il doppio degli utenti simultaneamente rispettando l'obiettivo del livello di servizio (SLO).
• Tempo per il primo token (TTFT) ridotto fino al 99% con un carico equivalente. Il benchmark mostra che il TTFT di base sale fino a circa 80 secondi sotto carico elevato. La pianificazione intelligente lo mantiene a circa 150 ms. Questa è la differenza tra un prodotto malfunzionante e uno efficiente.
  • Il benchmark sostiene circa 11.000 token di output/sec su 16 GPU. Immaginando circa 1.000 token a risposta e circa tre richieste al minuto per utente attivo, si ottengono circa 200 utenti simultanei con SLO, su hardware che il servizio Kubernetes di base smette di servire in modo accettabile oltre i 20.

Ogni risultato è controllato in base alla versione e legato a una guida specifica e riproducibile.

Figura 3: pianificazione dell'inferenza llm-d rispetto a Kubernetes di base — TTFT medio e rendimento totale rispetto alle QPS. Topologia: 8 pod vLLM, 16 NVIDIA H100 (TP=2). Carico di lavoro: sintetico con prefisso condiviso, 150 gruppi × 5 prompt, lunghezza 6k/1,2k/1k sistema/domanda/output. Risultati: TTFT P50 136–157 ms, 4,5–11.000 tok/s di output, incremento del throughput fino al 109% e rendimento del TTFT del 99% rispetto al valore di base. Fonte: llm-d v0.5.

vLLM ottimizza il nodo, llm-d ottimizza il cluster

vLLM e llm-d sono progettati per lavorare insieme e il divario prestazionale tra l'esecuzione di uno senza l'altro è misurabile: il doppio degli utenti sullo stesso hardware, latenza migliorata del 99% sotto carico, un cluster in grado di gestire 250 o 20 utenti con la stessa efficienza.

Se esegui due o più repliche, la pianificazione dell'inferenza intelligente si applica al tuo carico di lavoro sin da oggi. Il divario nelle prestazioni non è incrementale: è la differenza tra un cluster scalabile e uno cluster meno efficiente. 

Qui inizia l'inferenza distribuita.

Tocca con mano la scalabilità

Le guide di llm-d e le configurazioni dei benchmark dietro ogni numero in questo post sono pubbliche e riproducibili. Un buon punto di partenza è la release llm-d v0.5.

Red Hat AI Enterprise include una versione di llm-d supportata, a livello enterprise, nella prova gratuita di Red Hat AI Enterprise della durata di 60 giorni. È un buon punto di partenza se vuoi eseguire la soluzione sulla tua infrastruttura.

Se vuoi vedere prima lo scheduler in azione, la Demo interattiva intitolata Introduction to llm-d illustra come vengono instradate le richieste.

Nota dell'autore: dati del benchmark tratti dalla release llm-d v0.5. Tutti i risultati sono riproducibili utilizzando le configurazioni controllate in base alla versione, pubblicate nelle guide llm-d.