Hur hanterar Paged Attention KV-cachen vid samtidiga lokala AI-förfrågningar?
Paged Attention hanterar samtidiga KV-cachen genom att mappa varje begärans växande tokenstatus till block med fast storlek, som kan allokeras och återvinnas oberoende av varandra.
Det är viktigt på en hemmabaserad AI-server eftersom aktiva chattar, dokumentuppgifter och agenter sällan har samma kontextlängd eller avslutas samtidigt. En strategi med sammanhängande reservationer slösar på det begränsade acceleratorminnet runt dessa varierande sekvenser. Paging ändrar minneslayouten så att schemaläggaren kan utnyttja den tillgängliga kapaciteten mer effektivt.
Samtidiga begäranden skapar KV-cacher som växer i olika takt
Varje aktiv autoregressiv begäran behöver nyckel- och värdetillstånd för de token den har bearbetat. En chatt kan avslutas efter 100 token medan en annan fortsätter i tusentals token, så deras minnesbehov kan inte fastställas exakt när batchen startar.
PagedAttention-artikeln identifierar dynamiskt växande KV-cacheminne som en flaskhals vid leverans som begränsar batchkörning när allokeringen är ineffektiv.
På en hemmaserver med flera användare eller bakgrundsagenter förvandlar denna variation en stor mängd ledigt minne till många aktiva allokeringar av olika storlek.
Fasta sammanhängande reservationer slösar minne runt varierande sekvenser
En naiv runtime kan reservera ett stort sammanhängande område per begäran baserat på en maximal längd. Korta begäranden lämnar oanvänt utrymme i sin reservation, medan längre begäranden kan behöva omallokering eller överdimensionering.
vAttention sammanfattar den ursprungliga motivationen för paging: KV-reservationer som görs i förväg skapar intern fragmentering. Slösat minne minskar antalet begäranden som kan förbli aktiva samtidigt.
Det praktiska symptomet är en minnesbristgräns eller en låg maximal batchstorlek, trots att summan av de faktiskt använda token-tillstånden verkar vara lägre än det tillgängliga VRAM-minnet.
PagedAttention delar upp KV-tillståndet i block med fast storlek
PagedAttention ersätter en fysiskt sammanhängande begärandebuffert med en logisk sekvens av block. När fler token anländer allokerar runtimen ytterligare fysiska block från en gemensam pool.
vLLM förklarar att KV-block kan ligga i icke-sammanhängande fysiskt minne. En blocktabell mappar begärans logiska tokenordning till dessa fysiska platser.
Modellen fokuserar fortfarande på rätt sekvens. Indirektionen ändrar minnesplaceringen, inte den semantiska ordningen i konversationen.
Frigjorda block återgår till en gemensam pool när begäranden avslutas
När en begäran slutförs kan dess block som inte delas frigöras omedelbart och återanvändas av en annan aktiv eller nyligen accepterad begäran. Servern behöver inte vänta på att en hel stor minnesarena ska bli tom.
NVIDIAs inferensstack exponerar KV-cachekapacitet som en resurs vid leverans som måste balanseras mot vikter och arbetsminne för runtimen.
Denna återvinning på blocknivå är värdefull hemma eftersom begärandelängderna är oregelbundna: en person ställer en kort fråga om det smarta hemmet medan en annan kör en lång dokumentassistent och en bakgrundsagent sammanfattar filer.
Paging ökar samtidigheten genom att minska fragmenteringen, inte genom att göra varje token mindre
PagedAttention gör inte i grunden en tokens nyckel- och värdetensorer mindre. Den främsta minnesvinsten kommer från att allokera närmare den faktiska sekvenstillväxten och möjliggöra delning där det är giltigt.
PyTorchs distribuerade vägledning skiljer modellparallellism från hantering av minne vid leverans. Paging är inte tensorparallellism och delar inte automatiskt upp modellvikterna mellan GPU:er.
Om en modells vikter redan tar upp nästan hela enhetens minne kan paging inte skapa tillräcklig kapacitet för hög samtidighet. Det förbättrar utnyttjandet av det återstående KV-området.
Blockhantering har egna kostnader och begränsningar för schemaläggningen
Runtimen måste nu underhålla blocktabeller, referensräkningar, allokeringsbeslut och uppmärksamhetskärnor som förstår sidindelade layouter. Extremt små batcher eller hårdvara utan stöd kan minska fördelen.
ZimaSpaces artikel om samtidig användning av familjen och KV-tryck visar gränsen ur användarens perspektiv: minneseffektivitet är viktigt eftersom det avgör hur många aktiva kontexter som kan samexistera innan köerna växer.
Testa flera begärandelängder och ankomstmönster i stället för en enda syntetisk batch. ZimaSpaces guide till glidande kontextfönster och KV-minne är en användbar jämförelse, eftersom fönsterhantering ändrar hur mycket tillstånd varje sekvens behåller, medan paging ändrar hur detta tillstånd allokeras. Registrera aktiva sekvenser, använda KV-block, kötid och avbrott.
Hugging Faces TGI-schemaläggare skiljer också mellan schemaläggning av förinläsning och avkodning vid samtidig leverans. Sidindelat minne hjälper schemaläggaren att släppa fram arbete, men rättvisa och svarstid beror fortfarande på hur arbetet köas.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan hemkameror synkronisera händelser utan molnbaserade tidstjänster?
En mekanismorienterad förklaring av kameratid utan moln, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
Kan en lokal AI-tjänst upptäcka skadade modellager före inferens?
En mekanismfokuserad förklaring av detektering av korruption i modellagret, dess avvägningar kring delade resurser, tre vanliga frågor om frågefan-out och ett praktiskt verifieringsprotokoll.
Kan ett RAG-system återställas utan att generera om alla embeddingar?
En mekanismförst förklaring av RAG-återställning utan ombäddning, dess avvägningar kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
