LMCache: Slik slipper språkmodellen å lese den samme lange prompten om og om igjen

Problemet: samme arbeid, gang på gang

Når en språkmodell leser en prompt, regner den ut en mellomregning for hvert token – KV-cachen. Vi forklarte den i artikkelen om DeepSeek V4.1 Flash, som er bygget for å gjøre den mindre. Det er denne innlesingen som gjør at du må vente før de første ordene kommer.

I mange oppsett er store deler av prompten den samme hver gang: en lang systemprompt, et dokument du stiller flere spørsmål om, eller en agent som sender hele samtalehistorikken på nytt for hvert steg. vLLM har allerede innebygd gjenbruk av starten på prompten, men den holder cachen bare i grafikkortets minne. Når det fylles opp, eller serveren startes på nytt, forsvinner den – og modellen må regne alt fra bunnen igjen.

Hva LMCache gjør

LMCache er et lag mellom vLLM og lagringen som flytter KV-cachen ut av grafikkortet når det trengs: først til vanlig RAM, så til lokal SSD, og i større oppsett til delt lagring som Redis eller S3. Når den samme teksten dukker opp igjen, hentes mellomregningen fram i stedet for å regnes ut på nytt. Den kan også gjenbruke deler som ikke står først i prompten, gjennom en teknikk de kaller CacheBlend.

Prosjektet er åpen kildekode under Apache 2.0, har nesten 12 000 stjerner på GitHub og er i bruk hos blant andre IBM og CoreWeave. Det støtter grafikkort fra både Nvidia og AMD.

Hvor mye raskere?

Ifølge LMCache-teamets egen tekniske rapport får chat- og RAG-oppsett 3,7 til 6,8 ganger kortere tid før første token, og opptil 15 ganger høyere kapasitet. Med veldig lange prompter blir forskjellen størst: En systemprompt på 128 000 tokens kan gå fra rundt 11 sekunder til halvannet når mellomregningen allerede ligger klar.

Men det er en viktig forutsetning: Promptene må overlappe. Sender du helt unike forespørsler hver gang – klassifisering, embeddings, engangsspørsmål – får du ingen gevinst, og i verste fall litt ekstra arbeid.

Hvem bør bruke det?

LMCache gir mest mening hvis du kjører vLLM og har en av disse situasjonene:

• En agent eller kodeassistent som sender lang historikk ved hvert steg.
• RAG der mange spørsmål går mot de samme dokumentene.
• En lang, fast systemprompt som alle forespørsler deler.
• Flere vLLM-instanser som bør dele cache.

Bruker du Ollama eller LM Studio hjemme, er dette ikke for deg – de bygger på llama.cpp, som har sin egen prompt-cache. LMCache er laget for vLLM, og i noe grad SGLang.

Slik kommer du i gang

LMCache installeres med pip i samme miljø som vLLM:

pip install lmcache

Den enkleste varianten lagrer cachen i vanlig RAM. Du slår det på med miljøvariabler og et ekstra flagg til vLLM:

export LMCACHE_USE_EXPERIMENTAL=True
export LMCACHE_LOCAL_CPU=True
export LMCACHE_MAX_LOCAL_CPU_SIZE=20   # GB RAM til cache

vllm serve <modell> \
  --kv-transfer-config '{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_both"}'

Vil du også bruke disk, finnes tilsvarende variabler for en lokal mappe og maksstørrelse. En rask NVMe-disk gir mest igjen.

To råd fra dem som har brukt det i drift: Lås versjonene av vLLM og LMCache sammen, fordi koblingen mellom dem endrer seg mellom utgivelser. Og mål før og etter – med din egen arbeidsmengde – i stedet for å stole på andres tall.

Om råteksten

Denne artikkelen startet som en generell oppfordring om å utforske åpne prosjekter på GitHub, med LMCache og OpenCV som eksempler. OpenCV er et over 20 år gammelt bibliotek for bildeanalyse, og ingen nyhet. LMCache derimot løser et konkret problem mange som kjører egne modeller faktisk har – derfor fikk den hele plassen.

Ressurser

• LMCache på GitHub – kode og eksempler
• LMCache-dokumentasjon: lokal lagring – oppsett for RAM og disk
• LMCache: teknisk rapport – arkitektur og målinger
• andrew.ooo: LMCache Review – når det lønner seg og når ikke