Waarom groeit de KV-cache mee met de contextlengte van AI voor thuisgebruik?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Why Does KV Cache Grow With Home AI Context Length? - Zima Store Online

De KV-cache groeit mee met de contextlengte, omdat de runtime de attention-sleutels en -waarden voor elk behouden token in meerdere modellagen opslaat.

Een korte prompt voor een thuis-AI kan genoeg geheugen overlaten voor meerdere gebruikers, terwijl een lang document, een uitgebreide chatgeschiedenis of een agent-trace veel meer werkgeheugen kan verbruiken zonder dat het modelbestand zelf verandert. De cache begint tijdens het verwerken van de prompt en blijft groeien wanneer het model nieuwe tokens genereert. De omvang hangt ook af van het aantal lagen, de attentionarchitectuur, de numerieke precisie en het aantal gelijktijdige aanvragen. In de onderstaande secties volgen we die groei van één token tot aan de geheugenlimiet van de server.

Elk behouden token voegt attentionstatus toe

Tijdens inferentie met een transformer genereert elke laag key- en valuetensors op basis van de tokens die al zijn verwerkt. De runtime bewaart deze tensors, zodat het volgende token aandacht kan besteden aan eerdere context zonder de volledige reeks opnieuw te berekenen.

Het werk van vLLM identificeert KV-status per token als een belangrijke geheugenvereiste voor het aanbieden van modellen. Nieuwe tokens voegen nieuwe cache-items toe, terwijl eerder behouden items beschikbaar blijven voor latere attentionstappen.

De cache is daarom veranderlijke status van een aanvraag en geen onderdeel van de statische modelgewichten. Het laden van hetzelfde model met een langer actief gesprek leidt tot een groter geheugengebruik.

De cache groeit ongeveer lineair met de lengte van de behouden reeks

Bij een vaste modelarchitectuur en cacheprecisie verdubbelt het aantal KV-items dat voor een aanvraag wordt bijgehouden ongeveer wanneer het aantal behouden tokens verdubbelt. Zowel de prompt als het gegenereerde antwoord tellen mee voor de actieve reeks.

H2O beschrijft hoe de KV-cache schaalt met de reekslengte en batchgrootte. De relatie blijft ongeveer lineair, omdat elk extra token keys en values toevoegt aan elke laag die een cache produceert.

Daarom kan het verhogen van een runtime-instelling van een kleine context naar een veel groter maximum de praktische geheugengrens veranderen, ook wanneer het model identieke gewichten gebruikt.

De maximale instelling en het daadwerkelijke gebruik zijn niet hetzelfde. Sommige runtimes wijzen cacheblokken op aanvraag toe, terwijl andere al vroeg een groter gebied reserveren om toekomstige groei te garanderen.

De modelarchitectuur bepaalt het aantal bytes per token

Twee modellen met hetzelfde aantal parameters kunnen verschillende hoeveelheden KV-geheugen vereisen, omdat ze mogelijk een verschillend aantal lagen, verschillende headdimensies of aantallen attentionheads, grouped-query attention of multi-query attention gebruiken.

KIVI onderzoekt KV-cacheprecisie en laat zien dat het opslaan van keys en values met minder bits het piekgeheugen aanzienlijk kan verlagen. Dit voordeel geldt voor de status van aanvragen en verkleint niet de onderliggende modelgewichten.

Grouped-query- en multi-query-ontwerpen delen key-value-heads over meer queryheads, waardoor ze per token minder cachebytes kunnen gebruiken dan volledige multi-head attention. Het aantal lagen en de breedte van de heads vermenigvuldigen de behouden status nog steeds.

Een bruikbare schatting moet daarom de exacte modelarchitectuur en het cacheformaat van de runtime gebruiken, en niet alleen een algemene regel voor bytes per token die van een ander model is overgenomen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Gegenereerde tokens blijven de cache na het vooraf vullen uitbreiden

Het verwerken van de prompt creëert de eerste cache voor de invoercontext. Tijdens autoregressieve decoding wordt vervolgens voor elk geaccepteerd uitvoertoken status toegevoegd, zodat latere tokens aandacht kunnen besteden aan het volledige gesprek.

vAttention behandelt dynamische cachegroei als een toewijzingsprobleem, omdat de uiteindelijke uitvoerlengte onbekend is wanneer een aanvraag begint. Te veel reserveren verspilt geheugen, terwijl te weinig reserveren kan leiden tot onderbreking of extra uitbreidingswerk.

Een prompt die comfortabel past, kan tijdens een lang antwoord alsnog de geheugengrens overschrijden. Limieten voor de uitvoer beschermen daarom zowel het geheugen als de antwoordlengte en generatietijd.

Gelijktijdige gebruikers vermenigvuldigen de afzonderlijke contextstatus

Modelgewichten kunnen tussen aanvragen worden gedeeld, maar elke actieve conversatie heeft normaal gesproken een eigen tokenhistorie en KV-cache. Vijf gebruikers met lange contexten delen niet één universele cache alleen omdat ze hetzelfde model gebruiken.

Recent onderzoek naar KV-beheer beschouwt reserveringen per aanvraag als een centrale afweging tussen geheugenefficiëntie en het risico op onderbreking. Onbekende uitvoerlengtes maken de gecombineerde piek moeilijker te voorspellen dan een eenvoudig aantal gebruikers.

Gedeelde promptprefixen kunnen soms cachestatus hergebruiken wanneer de runtime exacte prefixmatching ondersteunt, maar privéchatgeschiedenis en afwijkende uitvoer creëren nog steeds afzonderlijke vertakkingen.

De hardwaregids van ZimaSpace beschouwt context en gelijktijdigheid als geheugenvereisten die verder gaan dan het modelbestand. Een test met één gebruiker kan daarom onderschatten hoeveel RAM of VRAM een huishoudassistent nodig heeft.

Paging, kwantisatie en verwijdering veranderen de limiet, niet de oorzaak

Toewijzing via paging vermindert fragmentatie door de cachestatus op te delen in kleinere blokken. Daardoor hoeft een runtime niet voor elke mogelijke reeks één te grote aaneengesloten reservering te maken.

PagedAttention biedt blokgebaseerde toewijzing, terwijl cachekwantisatie het aantal bytes per opgeslagen waarde vermindert en verwijderingsbeleid geselecteerde oude items weggooit. Elke methode verandert hoeveel context past, maar de behouden attentionstatus blijft groeien naarmate tokens zich opstapelen.

Verwijdering of schuivende vensters kunnen het geheugengebruik begrenzen door eerdere tokens te verwijderen, maar het model kan via het normale pad voor volledige context niet langer aandacht besteden aan de verwijderde status. Compressie en selectief behouden kunnen bovendien gevolgen hebben voor de kwaliteit of specifieke afwegingen met zich meebrengen.

Meet het cachegebruik met het echte model, de echte context, cacheprecisie, batchgrootte en het daadwerkelijke aantal gebruikers. De praktische limiet wordt bereikt wanneer een extra token of aanvraag niet kan worden toegelaten zonder verwijdering, offloading, herberekening of een fout.

Veelgestelde vragen

Wordt het modelbestand groter wanneer de contextlengte toeneemt?

‘Nee. De modelgewichten blijven hetzelfde. Het extra geheugen is runtime-status die wordt aangemaakt voor de actieve prompt en gegenereerde tokens.

Wordt bij het instellen van een grote maximale context al het KV-geheugen direct toegewezen?

Nee. Het toewijzingsgedrag hangt af van de runtime. Sommige runtimes reserveren vroeg capaciteit, terwijl systemen met paging blokken toewijzen wanneer tokens worden toegelaten.

Kan het systeem-RAM de KV-cache bevatten wanneer het VRAM vol is?

Sommige runtimes kunnen de cachestatus offloaden of verplaatsen, maar overdrachten voegen latentie toe en zijn afhankelijk van softwareondersteuning, bandbreedte en het actieve attentionpad.