🤖 machine learning

Depth-adaptive Inference of Looped Language Models via Continuous Depth Batching

Questo articolo introduce il Continuous Depth Batching (CDB), un nuovo framework di scheduling che consente un'inferenza adattiva alla profondità efficiente ed end-to-end per i modelli linguistici a loop, disaccoppiando le iterazioni del loop dagli stadi di confine e sovrapponendo lo scheduling con il calcolo della GPU, ottenendo così un throughput fino a 1,9 volte superiore e una latenza significativamente inferiore rispetto ai metodi standard.

Autori originali: Kristian Schwethelm, Daniel Rueckert, Georgios Kaissis

Pubblicato 2026-08-11

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Kristian Schwethelm, Daniel Rueckert, Georgios Kaissis

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di gestire una biblioteca enorme e velocissima dove un singolo bibliotecario può rispondere a migliaia di domande contemporaneamente. Nel mondo dell'Intelligenza Artificiale, questo bibliotecario è un "Large Language Model" (LLM), e le domande sono i prompt testuali degli utenti. Di solito, per risparmiare tempo e denaro, il bibliotecario elabora tutte le domande in una fila rigorosa, dedicando a ciascuna esattamente la stessa quantità di attenzione, indipendentemente dalla semplicità o complessità della domanda. Questo è efficiente, ma è uno spreco: rispondere a "Quanto fa 2+2?" richiede la stessa potenza cerebrale che risolvere un complesso problema di fisica, anche se il primo è un gioco da ragazzi.

Recentemente, gli scienziati hanno scoperto un trucco astuto chiamato modelli "a loop" (a ciclo). Invece di una linea retta, questi modelli hanno un "ciclo di pensiero". Possono controllare il proprio lavoro, far passare la risposta attraverso una speciale camera di pensiero e, se la risposta sembra buona, si fermano. Se sembra incerta, la fanno passare attraverso la camera di nuovo. Ciò significa che le domande facili ricevono un passaggio rapido, mentre quelle difficili ottengono cicli extra di pensiero profondo. È come uno studente che dà un'occhiata a un semplice problema di matematica e scrive subito la risposta, ma passa dieci minuti a scarabocchiare su una lavagna per un difficile problema di calcolo. Questo sembra perfetto, ma crea un incubo per il bibliotecario che cerca di gestire la fila. Se tutti nella fila hanno bisogno di un tempo diverso nella camera di pensiero, l'intera fila si blocca. Il bibliotecario non può elaborare il gruppo successivo finché il gruppo attuale non ha finito, e se alcuni stanno ancora pensando mentre altri hanno finito, il sistema si ferma. Questo articolo affronta esattamente questo ingorgo stradale.

Gli autori di questo articolo introducono un nuovo sistema chiamato Continuous Depth Batching (CDB) per risolvere il traffico causato da questi "cicli di pensiero". Si sono resi conto che il vecchio modo di gestire la fila (chiamato batching standard) era troppo rigido. Trattava ogni domanda come se avesse bisogno dello stesso numero di cicli, sprecando il vantaggio di velocità dei nuovi modelli. Per risolvere il problema, hanno costruito uno scheduler dinamico che agisce come un controllore del traffico super organizzato. Invece di aspettare che l'intero gruppo finisca, questo controllore permette alle domande concluse di lasciare la fila immediatamente e le sostituisce istantaneamente con nuove domande in attesa di iniziare.

Pensa a una cucina di un ristorante molto affollato. Nel vecchio sistema, se uno chef sta preparando un'insalata semplice (token facile) e un soufflé complesso (token difficile) contemporaneamente, l'intera cucina deve aspettare che il soufflé sia pronto prima di servire l'insalata o iniziare un nuovo ordine. Il nuovo sistema CDB è diverso. Non appena l'insalata è pronta, viene impiattata e inviata fuori, e lo chef afferra immediatamente un nuovo ordine per iniziare a tagliare le verdure, mantenendo la cucina costantemente occupata. Il documento mostra che, facendo così, il sistema può mantenere il "ciclo di pensiero" alla massima velocità senza mai lasciare le mani dello chef inattive.

I ricercatori hanno testato questo sistema su due diversi modelli di IA, chiamati Ouro e Huggin. Hanno scoperto che il CDB funziona incredibilmente bene. Per il modello Ouro, il nuovo sistema ha raggiunto fino al 99% del potenziale massimo teorico di accelerazione possibile. In parole povere, questo significa che il sistema è quasi veloce quanto potrebbe essere se si potesse magicamente rimuovere ogni singolo secondo di tempo sprecato. Nei test del mondo reale, ciò si è tradotto nel processare da 1,5 a 1,9 volte più richieste al secondo rispetto ai vecchi metodi. Quando il sistema era sotto carico pesante, come un sito web molto frequentato con migliaia di utenti, il tempo di attesa per le risposte è sceso del 45% - 90%.

Tuttamente, l'articolo sottolinea che questa magia non è automatica. Il sistema funziona meglio quando il "ciclo di pensiero" è la parte principale del lavoro. Se i passaggi prima del ciclo (come leggere la domanda) e dopo il ciclo (come scrivere la risposta finale) sono troppo lenti o pesanti, possono rallentare l'intero processo. Gli autori hanno scoperto che per i modelli in cui questi passaggi extra sono pesanti, l'accelerazione è comunque buona ma non così drammatica. Hanno anche scoperto un "punto di equilibrio" per quanti problemi elaborare contemporaneamente. Se si tenta di elaborare troppi pochi problemi, il sistema spreca tempo ricaricando il "cervello" (pesi) del modello per ogni singolo passaggio. Se se ne elaborano troppi, il sistema si intasa. Il CDB aiuta a trovare questo equilibrio perfetto fornendo costantemente nuovi problemi ogni volta che si apre uno slot.

Uno dei trucchi più astuti usati dagli autori è qualcosa chiamato "lookahead gate" (cancello di anteprima). Normalmente, il sistema deve aspettare che una domanda finisca il suo ciclo di pensiero prima di sapere se la risposta è abbastanza buona per uscire. Questo causa una piccola pausa in cui il computer resta lì in attesa. Il nuovo sistema prevede la risposta un passo prima, permettendo ai batch di domande successivi di essere preparati mentre quello attuale sta ancora finendo. È come un direttore d'orchestra che segnala la sezione successiva dell'orchestra proprio prima che la sezione attuale finisca, in modo che non ci sia silenzio tra le note. Questo piccolo cambiamento ha ridotto il "tempo di inattività" del computer a quasi zero, rendendo l'intero processo incredibilmente fluido.

In breve, questo articolo dimostra che possiamo rendere questi modelli di IA intelligenti e autocorrettivi effettivamente abbastanza veloci da essere utilizzati nel mondo reale. Trattando i "cicli di pensiero" come un programma flessibile piuttosto che come una fila rigida, e sostituendo costantemente i compiti completati con nuovi, gli autori hanno costruito un sistema che è non solo più intelligente, ma anche significativamente più veloce ed efficiente. Non si sono limitati a suggerire che potrebbe funzionare; l'hanno costruito, testato su hardware reale e dimostrato che offre enormi guadagni di velocità, trasformando un'idea teorica in uno strumento pratico per il futuro dell'IA.

Riepilogo Tecnico: Batching a Profondità Continua per Modelli di Linguaggio a Ciclo (Looped LMs)

Definizione del Problema

I Modelli di Linguaggio (LM) a ciclo offrono un'architettura promettente per l'inferenza a profondità adattiva, in cui un nucleo ricorrente condiviso viene iterato un numero variabile di volte per ogni token. Ciò consente al modello di allocare più calcolo ai token "difficili" e meno a quelli "facili", migliorando il compromesso tra calcolo e accuratezza. Tuttavia, questa adattività rompe fondamentalmente i meccanismi di batching standard utilizzati nei moderni framework di inferenza (ad esempio, vLLM).

Nel batching continuo standard, un passaggio forward è un'operazione uniforme in cui tutti i token in un batch subiscono lo stesso numero di layer. Nei modelli a ciclo con profondità adattiva, i token escono dal nucleo ricorrente a profondità differenti. Di conseguenza, un singolo batch contiene token che richiedono operazioni diverse: alcuni necessitano di un altro passo ricorrente, mentre altri, che sono usciti, devono eseguire la "coda" non ciclica (LM head) per generare il token successivo. Gli esistenti scheduler a livello di token non possono gestire questa eterogeneità perché non possono instradare diversi token verso stadi differenti all'interno di un singolo passaggio forward. Inoltre, le architetture a ciclo introducono "stadi di confine" (preludio e coda) che vengono eseguiti una sola volta per token ma con frequenze diverse rispetto al ciclo, aggiungendo complessità allo scheduling. Nessun sistema di inferenza esistente supporta il serving end-to-end di questi modelli con profondità dinamica.

Metodologia: Batching a Profondità Continua (CDB)

Gli autori introducono il Continuous Depth Batching (CDB), un metodo di inferenza che pianifica alla granularità delle singole iterazioni del ciclo piuttosto che ai confini dei token. Il CDB affronta tre sfide primarie: l'eterogeneità degli stadi, l'uscita dal percorso critico e i cache KV (Key-Value) irregolari.

1. Scheduler di Decoding Basato su Code

Il CDB decompone il processo di generazione in quattro code distinte:

Prefill: Richieste in attesa.
Prelude: Token in attesa dell'embedding iniziale/pre-elaborazione.
Recurrent Core (Nucleo Ricorrente): Token pronti per il loro prossimo passo di ciclo.
Coda: Token che sono usciti dal nucleo e attendono la previsione finale.

Lo scheduler tratta questi stadi come operazioni separate, permettendo ordini di esecuzione flessibili. Il documento implementa due modalità:

No-Refill: Un ordine fisso (Prelude $\to$ Core $\to$ Coda). Quando i token escono, il batch si rimpicciolisce e nessun nuovo token entra fino al successivo round di decoding.
Refill: Gli stadi vengono eseguiti in qualsiasi ordine in base alla priorità. Quando un token esce, la sua posizione viene immediatamente riempita da un nuovo token dalla coda di prefill. Ciò massimizza la dimensione del batch e il throughput, sfruttando il fatto che il nucleo ricorrente riutilizza gli stessi pesi indipendentemente dal numero di iterazioni del ciclo.

2. Cache KV Consapevole della Profondità

Le cache KV standard sono indicizzate per profondità, creando lacune quando i token escono precocemente. Il CDB propone due layout:

Last-Exited Cache (Cache dell'ultimo uscito): Riempie le posizioni vuote per i passi saltati copiando lo stato finale del token uscito. Ciò preserva la semantica dell'attenzione ma spreca memoria e calcolo nella copia.
Shared Cache (Cache Condivisa): Ogni layer fisico mantiene un unico slot KV, che viene sovrascritto ad ogni passo del ciclo. Ciò riduce l'impronta di memoria di un fattore $r_{max}$ ma altera la semantica dell'attenzione (i token prestano attenzione allo stato più recente dei token precedenti indipendentemente dalla loro profondità di uscita). Gli autori notano che i moderni kernel di attenzione (ad esempio, PagedAttention, FlashAttention-3) sono compatibili con entrambi.

3. Esecuzione Asincrona e Lookahead

Per minimizzare l'overhead della sincronizzazione CPU-GPU, il CDB impiega l'esecuzione asincrona:

Overlapping (Sovrapposizione): La CPU prepara il batch successivo (basandosi sulle decisioni di uscita dal passo $N-1$ ) mentre la GPU esegue l'attuale passo ( $N$ ).
Lookahead Gate (Cancello di Previsione): Per eliminare il tempo di inattività della GPU causato dall'attesa delle decisioni di uscita, lo scheduler utilizza un "lookahead gate". Il segnale di uscita al passo $r$ determina la partecipazione al passo $r+2$ invece che al passo $r+1$ . Ciò fornisce alla CPU un intero passo di ciclo per preparare il batch successivo senza sprecare calcolo, riducendo il tempo di inattività della GPU a quasi zero (0,67% negli esperimenti).

Contributi Chiave

Implementazione End-to-End: La prima implementazione completa di CDB per modelli a ciclo con profondità adattiva, inclusi uno scheduler di serving, l'integrazione del gate di uscita e la gestione della cache KV.
Limiti Teorici: Derivazione di un limite superiore basato sui FLOP sulla velocità di incremento (speed-up) derivante dalla profondità adattiva e un modello roofline consapevole dell'hardware per identificare i regimi di dimensione del batch in cui la modalità "refill" è più vantaggiosa (specificamente nei regimi limitati dalla memoria).
Valutazione Empirica: Valutazione completa su due architetture (Ouro 1.4B e Huginn 3.5B) dimostrando l'impatto della struttura del modello, del numero di cicli e dei costi degli stadi di confine sull'efficienza dell'inferenza.

Risultati Sperimentali

Gli autori hanno valutato il CDB su Ouro 1.4B (completamente a ciclo, stadi di confine economici) e Huginn 3.5B (split 2-4-2, stadi di confine costosi) utilizzando carichi di lavoro Alpaca e ShareGPT.

Throughput: Il CDB raggiunge fino al 99% del limite teorico di speed-up basato sui FLOP.
- Ouro 1.4B: Il CDB (refill) ottiene un throughput offline da 1,5–1,58× superiore rispetto al batching continuo (CB) standard.
- Huginn 3.5B: Nonostante i costi più elevati degli stadi di confine, il CDB ottiene fino a 1,9× di throughput superiore.
Latenza: Sotto carichi di serving online dinamici, il CDB riduce la latenza normalizzata del 45–90% rispetto al CB standard.
Efficacia del Refill: La modalità "refill" è più efficace nel regime limitato dalla memoria (piccole dimensioni di batch), dove le uscite precoci lascerebbero altrimenti il calcolo della GPU inattivo. Nel regime limitato dal calcolo (grandi batch), il vantaggio diminuisce poiché il tempo di esecuzione scala con il lavoro totale indipendentemente dalle uscite precoci.
Accuratezza: Gli autori osservano che il lookahead gate (decidere l'uscita un passo prima) non degrada significativamente l'accuratezza rispetto agli standard gate di uscita. Tuttavia, notano che la condivisione della cache KV (specificamente il layout a slot singolo condiviso) può causare un crollo dell'accuratezza in Ouro a meno che il modello non sia addestrato per questo, mentre Huginn rimane robusto.

Significato e Rivendicazioni

Il documento sostiene che i modelli a ciclo serviti con CDB non sono solo efficienti nei parametri, ma anche efficienti nell'inferenza. Decomponendo il passaggio forward a profondità variabile in un problema di scheduling, il CDB consente all'hardware esistente di gestire la profondità adattiva senza l'enorme overhead precedentemente ritenuto rendere tali modelli impraticabili per il serving.

Gli autori sottolineano che i guadagni di efficienza dipendono fortemente dalla co-progettazione dell'architettura del modello e del sistema di inferenza. Nello specifico:

Stadi di Confine: I modelli con stadi di confine costosi (come Huginn) vedono ridotti gli speed-up perché i token devono attendere questi stadi prima di rientrare nella coda per il refill.
Memoria vs Calcolo: La strategia "refill" è fondamentale per superare la natura limitata dalla memoria dell'inferenza con piccoli batch, mascherando efficacementamente i costi di ricaricamento dei pesi del nucleo ricorrente.
Compromessi: Il lavoro evidenzia la tensione tra accuratezza ed efficienza; sebbene il decoding a profondità adattiva risparmi calcolo, la scelta delle soglie di uscita e delle policy della cache KV impatta direttamente sulle prestazioni del modello.

Il documento conclude che il CDB fornisce una via percorribile per servire modelli a profondità adattiva, realizzando i benefici teorici dell'inferenza a profondità variabile in scenari pratici ad alto throughput.