Varför växer KV-cachen med kontextlängden i lokal AI?

KV-cachen växer med kontextlängden eftersom körmiljön lagrar attention-nycklar och -värden för varje bevarad token i flera modellager.

En kort hem-AI-prompt kan lämna tillräckligt med minne för flera användare, medan ett långt dokument, en omfattande chatthistorik eller ett agentspår kan förbruka betydligt mer arbetsminne utan att själva modellfilen ändras. Cachen börjar byggas under promptbearbetningen och fortsätter att växa när modellen genererar nya tokens. Storleken beror också på antal lager, attention-arkitektur, numerisk precision och samtidiga förfrågningar. Avsnitten nedan följer denna tillväxt från en enda token till serverns totala minnesgräns.

Varje bevarad token lägger till attention-tillstånd

Under inferens med en transformer skapar varje lager nyckel- och värdetensorer från de tokens som redan har bearbetats. Körmiljön behåller dessa tensorer så att nästa token kan uppmärksamma tidigare kontext utan att hela sekvensen behöver beräknas på nytt.

vLLM-arbetet identifierar KV-tillstånd per token som ett viktigt minneskrav vid serverdrift. Nya tokens lägger till nya cacheposter, medan tidigare bevarade poster förblir tillgängliga för senare attention-steg.

Cachen är därför ett föränderligt tillstånd för förfrågan och inte en del av de statiska modellvikterna. När samma modell laddas med en längre aktiv konversation blir minnesavtrycket större.

Cachen växer ungefär linjärt med den bevarade sekvenslängden

För en fast modellarkitektur och cacheprecision innebär en fördubbling av antalet bevarade tokens ungefär en fördubbling av antalet KV-poster som hålls för den förfrågan. Både prompten och det genererade svaret räknas in i den aktiva sekvensen.

H2O beskriver hur KV-cachen skalas med sekvenslängd och batchstorlek. Sambandet förblir ungefär linjärt eftersom varje ytterligare token bidrar med nycklar och värden i varje lager som producerar cache.

Det är därför en ökning av en körmiljöinställning från en liten kontext till ett mycket större maximum kan förändra den praktiska minnesgränsen, även när modellen använder identiska vikter.

Maximal inställning och faktisk användning är inte samma sak. Vissa körmiljöer allokerar cacheblock vid behov, medan andra reserverar ett större område tidigt för att garantera framtida tillväxt.

Modellarkitekturen ändrar antalet byte per token

Två modeller med samma antal parametrar kan kräva olika mycket KV-minne eftersom de kan använda olika antal lager, huvuddimensioner, attention-huvuden, grouped-query attention eller multi-query attention.

KIVI undersöker KV-cacheprecision och visar att lagring av nycklar och värden med färre bitar kan minska toppminnet avsevärt. Fördelen gäller tillståndet för förfrågan och innebär inte att de underliggande modellvikterna blir mindre.

Grouped-query- och multi-query-arkitekturer delar nyckelvärdehuvuden mellan fler frågehuvuden, vilket kan minska antalet cachebyte per token jämfört med full multi-head attention. Antalet lager och huvudbredden multiplicerar fortfarande det bevarade tillståndet.

En användbar uppskattning måste därför baseras på den exakta modellarkitekturen och körmiljöns cacheformat, inte bara på en generell regel för byte per token som kopierats från en annan modell.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Genererade tokens fortsätter att utöka cachen efter förifyllningen

Promptbearbetningen skapar den initiala cachen för indatakontexten. Autoregressiv avkodning lägger sedan till tillstånd för varje accepterad ut-token, så att senare tokens kan uppmärksamma hela konversationen.

vAttention behandlar dynamisk cache-tillväxt som ett allokeringsproblem eftersom den slutliga utlängden är okänd när en förfrågan börjar. Om för mycket reserveras slösas minne, medan för lite kan tvinga fram undanträngning eller utökningsarbete.

En prompt som ryms utan problem kan ändå passera minnesgränsen under ett långt svar. Utdata- och längdgränser skyddar därför både minnet samt svarslängden och genereringstiden.

Samtidiga användare multiplicerar separat kontexttillstånd

Modellvikter kan delas mellan förfrågningar, men varje aktiv konversation har normalt sin egen tokenhistorik och KV-cache. Fem användare med långa kontexter delar inte på en enda universell cache bara för att de använder samma modell.

Ny forskning om KV-hantering beskriver reservationer per förfrågan som en central avvägning mellan minneseffektivitet och risk för undanträngning. Okända utlängder gör den sammanlagda toppbelastningen svårare att förutsäga än ett enkelt antal användare.

Delade promptprefix kan ibland återanvända cachetillstånd när körmiljön stöder exakt prefixmatchning, men privat chatthistorik och avvikande utdata skapar fortfarande separata grenar.

ZimaSpaces hårdvaruguide behandlar kontext och samtidighet som minneskrav utöver modellfilen. Ett test med en användare kan därför underskatta mängden RAM eller VRAM som behövs för en hushållsassistent.

Paging, kvantisering och utkastning ändrar gränsen, inte orsaken

Sidbaserad allokering minskar fragmentering genom att dela upp cachetillståndet i mindre block, så att en körmiljö inte behöver reservera ett enda överdimensionerat sammanhängande område för varje möjlig sekvens.

PagedAttention tillhandahåller blockbaserad allokering, medan cachekvantisering minskar antalet byte per lagrat värde och utkastningsstrategier tar bort utvalda äldre poster. Varje metod ändrar hur mycket kontext som får plats, men det bevarade attention-tillståndet fortsätter att växa när tokens samlas.

Utkastning eller glidande fönster kan begränsa minnesanvändningen genom att ta bort tidigare tokens, men modellen kan då inte längre uppmärksamma det borttagna tillståndet via den normala vägen för full kontext. Komprimering och selektivt bevarande kan också medföra avvägningar beroende på kvalitet och arbetsbelastning.

Mät cacheanvändningen med den verkliga modellen, kontexten, cacheprecisionen, batchstorleken och antalet användare. Den praktiska gränsen nås när ytterligare en token eller förfrågan inte kan släppas in utan utkastning, avlastning, omberäkning eller fel.

Vanliga frågor

Blir modellfilen större när kontextlängden ökar?

Nej. Modellvikterna förblir desamma. Det extra minnet är körningstillstånd som skapas för den aktiva prompten och de genererade tokens.

Allokeras alltid hela KV-minnet omedelbart när en stor maximal kontext ställs in?

Nej. Allokeringsbeteendet beror på körmiljön. Vissa reserverar kapacitet tidigt, medan sidbaserade system allokerar block när tokens släpps in.

Kan system-RAM lagra KV-cache när VRAM är fullt?

Vissa körmiljöer kan avlasta eller flytta cachetillstånd, men överföringar lägger till fördröjning och beror på programvarustöd, bandbredd och den aktiva attention-vägen.