Hoe beheert Paged Attention de KV-cache bij gelijktijdige lokale AI-verzoeken?
Paged Attention beheert gelijktijdige KV-caches door de groeiende tokenstatus van elk verzoek toe te wijzen aan blokken met een vaste grootte, die onafhankelijk kunnen worden toegewezen en hergebruikt.
Dat is belangrijk op een thuis-AI-server, omdat actieve chats, documenttaken en agents zelden dezelfde contextlengte hebben of op hetzelfde moment klaar zijn. Een strategie met aaneengesloten reserveringen verspilt schaarse acceleratorgeheugenruimte rond reeksen met variabele lengte. Paging verandert de geheugenindeling, zodat de scheduler de beschikbare capaciteit dichter kan benutten.
Gelijktijdige verzoeken creรซren KV-caches die in verschillend tempo groeien
Elk actief autoregressief verzoek heeft key- en value-status nodig voor de tokens die het heeft verwerkt. Eรฉn chat kan na 100 tokens eindigen, terwijl een andere duizenden tokens doorgaat. Daarom kan de geheugenvraag niet exact worden vastgesteld wanneer de batch begint.
Het PagedAttention-artikel beschrijft dynamisch groeiend KV-cachegeheugen als een knelpunt bij het aanbieden van modellen, dat batching beperkt wanneer toewijzing inefficiรซnt verloopt.
Op een thuisserver met meerdere gebruikers of achtergrondagents verandert deze variatie een grote hoeveelheid vrij geheugen in veel actieve toewijzingen van verschillende grootte.
Vaste aaneengesloten reserveringen verspillen geheugen rond reeksen met variabele lengte
Een eenvoudige runtime kan per verzoek รฉรฉn groot aaneengesloten gebied reserveren op basis van een maximale lengte. Korte verzoeken laten ongebruikte ruimte binnen hun reservering achter, terwijl langere verzoeken mogelijk opnieuw moeten worden toegewezen of overprovisioning vereisen.
vAttention vat de oorspronkelijke motivatie voor paging samen: KV-reserveringen vooraf veroorzaken interne fragmentatie. Verspild geheugen vermindert het aantal verzoeken dat gelijktijdig actief kan blijven.
Het praktische symptoom is een out-of-memory-limiet of een kleine maximale batch, ook al lijkt de som van de daadwerkelijk gebruikte tokenstatussen lager dan het beschikbare VRAM.
PagedAttention verdeelt de KV-status in blokken met een vaste grootte
PagedAttention vervangt รฉรฉn fysiek aaneengesloten verzoekbuffer door een logische reeks blokken. Naarmate er meer tokens binnenkomen, wijst de runtime extra fysieke blokken toe vanuit een gedeelde pool.
vLLM legt uit dat KV-blokken in niet-aaneengesloten fysiek geheugen kunnen staan. Een bloktabel koppelt de logische tokenvolgorde van het verzoek aan die fysieke locaties.
Het model besteedt nog steeds aandacht aan de juiste reeks. De indirecte adressering verandert de geheugenplaatsing, niet de semantische volgorde van het gesprek.
Vrijgegeven blokken keren terug naar een gedeelde pool wanneer verzoeken worden voltooid
Wanneer een verzoek wordt voltooid, kunnen de niet-gedeelde blokken ervan onmiddellijk worden vrijgegeven en hergebruikt door een ander actief of nieuw toegelaten verzoek. De server hoeft niet te wachten tot een volledige grote geheugenarena leeg is.
De inferentiestack van NVIDIA stelt KV-cachecapaciteit beschikbaar als een bron voor het aanbieden van modellen die moet worden afgewogen tegen gewichten en werkgeheugen van de runtime.
Deze recycling op blokniveau is thuis waardevol omdat verzoeklengtes onregelmatig zijn: de ene persoon stelt een korte vraag over het slimme huis, terwijl een andere een lange documentassistent gebruikt en een achtergrondagent bestanden samenvat.
Paging verhoogt de gelijktijdigheid door fragmentatie te verminderen, niet door elke token kleiner te maken
PagedAttention maakt de key- en valuetensors van รฉรฉn token niet fundamenteel kleiner. De belangrijkste geheug winst komt door toewijzing die beter aansluit bij de werkelijke groei van reeksen en door delen mogelijk te maken waar dat geldig is.
De gedistribueerde documentatie van PyTorch maakt onderscheid tussen modelparallelisme en geheugenbeheer voor het aanbieden van modellen. Paging is geen tensorparallelisme en splitst de modelgewichten op zichzelf niet over meerdere GPU's.
Als de modelgewichten al bijna al het apparaatgeheugen innemen, kan paging niet zomaar voldoende capaciteit creรซren voor een hoge mate van gelijktijdigheid. Het verbetert het gebruik van het resterende KV-gebied.
Blokbeheer brengt eigen overhead en beperkingen voor de planning met zich mee
De runtime beheert nu bloktabellen, referentietellingen, toewijzingsbeslissingen en attention-kernels die gepagineerde indelingen begrijpen. Extreem kleine batches of niet-ondersteunde hardware kunnen het voordeel beperken.
Het artikel van ZimaSpace over gelijktijdig gebruik door een gezin en KV-druk laat de grens vanuit gebruikersperspectief zien: geheugenefficiรซntie is belangrijk omdat die bepaalt hoeveel actieve contexten naast elkaar kunnen bestaan voordat de wachtrij langer wordt.
Test verschillende verzoeklengtes en aankomstpatronen in plaats van รฉรฉn synthetische batch. ZimaSpace's gids over schuivende contextvensters en KV-geheugen is een nuttige vergelijking, omdat vensterbeheer bepaalt hoeveel status elke reeks behoudt, terwijl paging bepaalt hoe die status wordt toegewezen. Leg het aantal actieve reeksen, gebruikte KV-blokken, wachtrijtijd en preรซmpties vast.
De TGI-scheduler van Hugging Face maakt ook onderscheid tussen prefill- en decodeplanning bij gelijktijdig aanbieden van modellen. Gepagineerd geheugen helpt de scheduler werk toe te laten, maar eerlijkheid en latentie blijven afhankelijk van de manier waarop dat werk in de wachtrij wordt geplaatst.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kunnen thuiscamera's gebeurtenissen synchroniseren zonder cloudtijdservices?
Een mechanismegerichte uitleg van cameratiijd zonder cloud, de afwegingen bij gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een lokale AI-service beschadigde modellagen detecteren vรณรณr de inferentie?
Een mechanismegerichte uitleg van detectie van beschadigingen in modellagen, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een RAG-systeem worden hersteld zonder elke embedding opnieuw te genereren?
Een mechanismegerichte uitleg van RAG-herstel zonder opnieuw te embedden, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
