LMCache è un layer di gestione della KV cache per l'inferenza LLM. Non sostituisce vLLM o SGLang: si interpone tra l'engine e lo storage e tratta chiavi e valori dell'attenzione come dato persistente, non come stato usa-e-getta della GPU.
Il problema è concreto. In prefill il modello ricalcola K e V per ogni token del contesto. Su system prompt lunghi, chat multi-turno, documenti RAG e workflow agentici quel calcolo domina il TTFT e sottrae HBM al decode. La cache nativa in GPU aiuta solo finché il working set ci sta. Oltre quella soglia si ricomincia da zero.
Il paper LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference formalizza il layer e ne misura l'impatto. Il codice vive su GitHub LMCache/LMCache, licenza Apache 2.0. A fine agosto 2026 il progetto supera le 11,5k star, ha circa 1,8k fork e la release stabile è v0.5.4, installabile con pip install lmcache.
Cosa fa il layer e dove si posiziona
LMCache estrae i blocchi KV dagli engine a paging moderno, li serializza e li muove su una gerarchia a più livelli:
- GPU HBM: working set attivo
- CPU DRAM (memoria pinned): cache calda
- storage locale (SSD, NVMe, GDS): documenti lunghi e sessioni
- backend remoto: Redis/Valkey, Mooncake, InfiniStore, S3-compatible, NIXL
Il flusso è asimmetrico e pipelined. I nuovi chunk prodotti in GPU possono essere offloadati in batch verso CPU, scritti in asincrono su disco o rete con eviction LRU, prefetched quando tornano caldi e reiniettati in GPU on-demand. Il movimento è ottimizzato con operazioni batched, overlap compute/I/O e, dove possibile, zero-copy.
Due modi di deployment. In-process il layer vive accanto all'engine. In multiprocess (MP), percorso raccomandato, LMCache gira come daemon autonomo. L'engine calcola; il layer possiede la cache. Se l'engine crasha, i blocchi restano. Più worker e più istanze condividono lo stesso pool.
Benchmark dichiarati: throughput e TTFT
La valutazione del paper, combinata con vLLM, riporta fino a 15× di throughput su Q&A multi-turno e analisi documenti. Rispetto a vLLM base, vLLM con offload CPU interno e alcune API commerciali, LMCache mostra TTFT da 1,9× a 8,1× più basso e throughput da 2,3× a 14× più alto a parità di latenza, su più modelli.
Un secondo dato, più recente, riguarda la modalità MP su MoE. Su Qwen3-235B-A22B con otto H100, cache condivisa a livello host contro offload isolato per processo:
- TTFT medio: 0,29s contro 3,98s (circa 14×)
- TTFT p99: 1,30s contro 13,55s (circa 10×)
- decode medio: 37,47 tok/s contro 9,81 tok/s
La differenza non è il silicio. È il riuso cross-rank: senza un layer condiviso ogni data-parallel rank ricalcola un prefisso che un altro rank ha già materializzato.
Su Google Kubernetes Engine, un test con storage a tier ha mostrato TTFT medio in calo fino al 79% e throughput in input fino a +264% su prompt da 100k token quando HBM, RAM e SSD locale lavorano insieme rispetto al solo HBM.
Questi numeri dipendono da hit ratio, lunghezza del prefisso, backend e rete. Non sono una garanzia sul vostro traffico. Sono un segnale di direzione: se il contesto si ripete, il prefill è lavoro sprecato.
CacheGen, CacheBlend e disaggregazione PD
Il layer non si limita al prefix match esatto. CacheGen (SIGCOMM 2024) comprime la KV in bitstream per ridurne l'impronta e streamarla. CacheBlend (EuroSys 2025) consente il riuso di blocchi in posizioni arbitrarie del prompt, ricalcolando in modo selettivo i token necessari a recuperare qualità. Serve nel RAG, dove i chunk recuperati non coincidono con un prefisso fisso.
LMCache copre anche la disaggregazione prefill-decode: trasferisce la KV dai worker di prefill a quelli di decode su NVLink, RDMA o TCP, tramite transport come NIXL. Il connettore verso gli engine è modulare, proprio per non accoppiarsi alla velocità con cui evolvono vLLM e SGLang.
Il controller espone API di lookup, clear, compress/decompress, move, pin/unpin e health check. In pratica potete scaldare una cache, fissare un system prompt, migrare blocchi tra nodi o misurare hit a livello di richiesta e di token.
Vendor-neutrality e limiti reali
Il progetto è vendor-neutral per disegno. Integra vLLM e SGLang, con lavoro in corso su TensorRT-LLM. Lato hardware compaiono NVIDIA, AMD (incluso MI300X), Ascend e sperimentazioni XPU. È nel PyTorch Ecosystem. Il team di ricerca originario, University of Chicago, ha fondato Tensormesh, che sponsorizza lo sviluppo senza chiudere il codice.
I limiti vanno detti. Recuperare KV da storage remoto riduce il delay di prefill solo se la rete e il backend tengono. La truncation di contesto, tecnica diffusissima in produzione, può dimezzare l'hit ratio di prefisso: il layer non ripara un prompt che taglia proprio i token che avrebbero fatto hit. Su alcuni confronti, l'offload CPU nativo di SGLang è già competitivo; il vantaggio di LMCache è più netto dove serve riuso cross-engine, persistenza e osservabilità.
Per chi serve agenti, RAG e conversazioni lunghe, il punto non è “aggiungere cache”. È decidere se la KV è un sottoprodotto dell'engine o un dato di infrastruttura. LMCache scommette sulla seconda ipotesi, con codice, paper e integrazioni già in produzione.
Documentazione: docs.lmcache.ai. Sito: lmcache.ai.
Testo: assistito da AI · revisionato da Carlos H. P. Ross
