Un tokenizer riutilizza la cronologia della chat per ridurre il ritardo al primo token

Quando una chiamata di un agente di programmazione aggiunge solo un breve aggiornamento a una conversazione molto lunga, perché la CPU dovrebbe trasformare di nuovo il testo precedente nelle unità numerate lette dal modello?

Un sistema di serving può evitare questo lavoro ripetuto e mantenere inalterate le unità ricevute dal modello?

Delta Tokenizer trasforma il testo in unità leggibili dal modello sulla CPU, riutilizza quelle verificate dai turni precedenti e suddivide in blocchi sicuri le richieste lunghe idonee al serving.

I ricercatori hanno confrontato Delta Tokenizer, un sistema CPU che riutilizza unità numerate del testo dopo averne verificato la corrispondenza, con il tokenizer di riferimento Hugging Face, il software standard che converte il testo in quelle unità.

Il confronto è avvenuto in SGLang con Qwen3-8B, su richieste di chat formattate con contesti da 100,000 token e aggiunte di 400 caratteri. Nei 60 turni con sessione già avviata, il ritardo mediano dall’arrivo programmato al primo token trasmesso in streaming è stato di 59.61 ms con Delta Tokenizer e di 144.80 ms con il tokenizer di riferimento.

Poiché queste richieste riutilizzavano la cronologia della sessione, il risultato supporta la conclusione che evitare una nuova codifica CPU completa può ridurre il ritardo quando la tokenizzazione rallenta il serving. Con contesti brevi il vantaggio è stato limitato.

I vantaggi dipendono dal carico di lavoro: con contesti brevi il beneficio è stato ridotto, perché il ritardo dipendeva dal lavoro del modello; quando ogni documento lungo era nuovo, invece, l’elaborazione sulla GPU determinava i ritardi più lunghi.

Alcune configurazioni del tokenizer e alcuni percorsi di elaborazione non sono stati verificati con la stessa copertura.