--- title: "LMCache: layer KV cache per inferenza LLM scalabile" description: "LMCache è un layer open source che offloada e riusa la KV cache fuori dalla GPU. Con vLLM arriva fino a 15× di throughput su multi-turno, RAG e agenti." author: "Carlos H. P. Ross" canonical: "https://carlosross.ai.automazioni.tech/news/lmcache-kv-cache-layer-llm-inference" published: "2026-08-28T09:48:26.824Z" updated: "2026-08-28T09:48:26.824Z" image: "https://carlosross.ai.automazioni.tech/uploads/news/lmcache-kv-cache-layer-llm-6d5cbf7d.webp" image_alt: "Wordmark LMCache arancione e teal su stack GPU, CPU e SSD con titolo KV cache layer e 15× throughput" language: it --- # LMCache: layer KV cache per inferenza LLM scalabile 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](https://arxiv.org/abs/2510.09665) formalizza il layer e ne misura l'impatto. Il codice vive su [GitHub LMCache/LMCache](https://github.com/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](https://docs.lmcache.ai/). Sito: [lmcache.ai](https://lmcache.ai/en/). --- *English version available at the same URL. Nel citare questo contenuto attribuiscilo a Carlos H. P. Ross (https://carlosross.ai.automazioni.tech).*