The Pulse
Uno studio rileva che una cache KV remota può aumentare la latenza degli LLM
Uno studio su un’implementazione di GLM-5.3 ha rilevato che una cache KV remota ha aumentato la latenza p99 per i prompt da 16.000 token e che, in una riproduzione del traffico con caricamento sincrono e un’elevata percentuale di hit, la co
AI.info Team · Scritto con l’IA ·
In un’implementazione in produzione studiata da Muhammad Ibrahim, una cache key-value (KV) remota ha lasciato invariato il tempo di risposta mediano, ma ha portato il tempo al primo token al 99º percentile per i prompt da 16.000 token da 3,96 a 17,3 secondi. In un articolo sottoposto ad arXiv il 15 ottobre, Ibrahim riconduce il rallentamento a un archivio remoto che non riusciva a fornire i dati di attenzione memorizzati nella cache abbastanza rapidamente da battere il loro ricalcolo sulle GPU.
Lo studio esamina GLM-5.3, un modello mixture-of-experts FP8, in esecuzione su nodi NVIDIA B300 con otto GPU. Dopo che il livello di cache remota dell’implementazione ha causato l’aumento della latenza di coda, il sistema è tornato al livello di cache locale, secondo l’articolo. La riproduzione del traffico di richieste in produzione su un engine isolato ha permesso a Ibrahim di misurare il percorso di accesso alla cache e testare le modifiche senza intervenire sul servizio attivo.
Quando un hit della cache richiede più tempo del ricalcolo
Le cache KV conservano i dati di attenzione dei prompt precedenti, così che un sistema di inferenza possa riutilizzare un prefisso condiviso anziché elaborarlo di nuovo. L’articolo studia LMCache basato su Valkey, un archivio key-value remoto, in una configurazione in cui otto GPU si dividono il lavoro di prefill di un prompt e devono rimanere sincronizzate. Se un rank si blocca durante il caricamento dei dati, gli altri rank lo aspettano.
Nella riproduzione, un hit remoto per un prompt da 16.000 token ha richiesto 0,88 secondi; ricalcolare il prompt ne ha richiesti 0,31. Il modello dei costi di Ibrahim stima che, per questo modello e questo hardware, il livello remoto debba fornire più di 2,53 gigabyte al secondo perché il trasferimento dei dati sia più rapido del ricalcolo. Nel test di banda misurato, una singola istanza di Valkey ha raggiunto al massimo 1,71 GB/s.
L’articolo stima inoltre un costo fisso per hit di circa 0,33 secondi per la pianificazione, le ricerche e il coordinamento tra i rank delle GPU. In questa implementazione, tale sovraccarico significa che, per i prompt inferiori a circa 17.000 token, un hit remoto non può battere il ricalcolo in termini di latenza mediana, indipendentemente dalla banda disponibile. L’articolo presenta questa soglia come una previsione basata sul modello, non come un risultato misurato direttamente su prompt di diverse lunghezze.
Il caricamento sincrono ha trasformato il ritardo in una coda
In un test con 450 prompt e un’elevata percentuale di hit, il 98,5% dei token dei prompt proveniva dal livello remoto. Con una sola istanza di Valkey e il caricamento sincrono, la latenza p99 ha raggiunto 83,32 secondi, mentre l’utilizzo delle GPU era del 7%. La latenza mediana è salita da 3,52 secondi nel primo terzo della riproduzione a 52,30 secondi nell’ultimo, perché le richieste si accumulavano più rapidamente di quanto l’engine riuscisse a smaltirle.
Distribuire i dati KV memorizzati tra gli otto rank paralleli al contesto ha ripartito il lavoro della cache tra i server, uno per rank. La modifica ha aumentato di 6,3 volte la banda GET misurata, portandola a 10,76 GB/s. L’aggiunta del caricamento asincrono e la correzione di tre bug del client hanno portato la latenza p99 a 0,67 secondi sullo stesso insieme di richieste con un’elevata percentuale di hit, con il 98,5% dei token dei prompt ancora servito dal livello remoto.
«La lezione più generale è che, sulle GPU attuali, il ricalcolo è un termine di paragone impegnativo.»
Muhammad Ibrahim, autore dell’articolo
Una latenza di coda più bassa, ma con un compromesso sulla mediana
La configurazione migliorata della cache non ha reso più rapida ogni richiesta. La sua latenza mediana era di 0,40 secondi, contro gli 0,31 secondi del ricalcolo sugli stessi prompt, sebbene la sua latenza p99 fosse inferiore agli 1,28 secondi del ricalcolo. Riutilizzare la cache evita anche calcoli sulle GPU, un aspetto che può contare quando gli engine di prefill sono saturi; i risultati dello studio distinguono quindi la latenza dall’impiego di risorse di calcolo, anziché considerare un hit della cache un’accelerazione automatica.
Da sola, la distribuzione dell’archivio ha aumentato il throughput del prefill del 14% in un test separato con otto prompt simultanei di circa 200.000 token. Insieme a una correzione a monte di un kernel FlashInfer, il throughput è cresciuto del 34%; questo aumento maggiore non è attribuibile alla sola distribuzione della cache.
Un solo engine e un intervallo limitato di lunghezze dei prompt circoscrivono le conclusioni
I test di latenza dell’articolo si concentrano su prompt tra 14.715 e 17.889 token, e la riproduzione isolata usa un solo engine come client Valkey. Ibrahim riferisce che ogni condizione di test è stata eseguita una sola volta e che lo studio non misura la contesa tra più engine che condividono istanze dell’archivio remoto. I risultati descrivono una configurazione specifica di GLM-5.3, B300 e LMCache-Valkey, non tutte le cache KV remote.
Per quella configurazione, il risultato principale è preciso: il percorso di accesso alla cache originale, basato su un solo server, era più lento del ricalcolo e ha prodotto una coda crescente; la distribuzione basata sui rank, il caricamento asincrono e le correzioni del client hanno ridotto la latenza p99 del test con un’elevata percentuale di hit da 83,32 a 0,67 secondi, mentre la latenza mediana è rimasta superiore a quella del ricalcolo.