Hur minskar prefix-cachning upprepat promptarbete på en AI-server i hemmet?

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Prefixcachning minskar upprepat promptarbete genom att återanvända det nyckel-värdetillstånd som redan har beräknats för en identisk inledande tokenssekvens.

På en AI-server i hemmet kan det gemensamma prefixet vara en systempolicy, ett verktygsschema, ett långt dokument, en uppsättning hushållsinstruktioner eller en upprepad chatthistorik. Den första begäran måste fortfarande betala hela kostnaden för förifyllningen, men senare matchande begäranden kan hoppa över en stor del av den. Den främsta fördelen är en kortare förifyllningsväg och snabbare första token, inte kostnadsfri generering.

Upprepade promptar beräknar samma förifyllning på nytt utan cache

Innan ett svar genereras bearbetar en autoregressiv modell indata-token och bygger det nyckel-värdetillstånd som används vid senare avkodning. En lång systemprompt, ett verktygsschema, ett dokumenthuvud eller ett gemensamt instruktionsblock kan därför kräva samma förifyllningsarbete vid varje begäran.

Prompt Cache formaliserar denna möjlighet genom att återanvända uppmärksamhetstillstånd från överlappande promptsegment. På en AI-server i hemmet kan den upprepade delen bestå av tusentals token, även om användaren bara bidrar med en ny mening.

Utan återanvändning utför GPU:n eller CPU:n dessa matrisoperationer igen och läser samma modellvikter för samma prefix. Resultatet kan vara identiskt, men servern betalar fortfarande beräkningskostnaden för förberedelserna.

En prefixcache lagrar KV-tillstånd för ett redan bearbetat prefix

Efter den första kompatibla begäran kan runtime-miljön behålla KV-tillståndet som hör till det gemensamma prefixet. En senare begäran börjar med att kontrollera om dess inledande tokenssekvens matchar cachade block.

vLLM:s automatiska prefixcache identifierar block genom tokenen i blocket tillsammans med det föregående prefixet. Matchande begäranden kan hänvisa till samma fysiska cacheblock i stället för att allokera och beräkna duplicerade tillstånd.

Det som kan återanvändas är inte det slutliga svaret och inte heller en generell semantisk sammanfattning. Det är ett modellspecifikt uppmärksamhetstillstånd för ett exakt kompatibelt prefix.

En cacheträff hoppar över gemensam förifyllning men beräknar fortfarande det nya suffixet

När prefixet matchar kan runtime-miljön utgå från det lagrade uppmärksamhetstillståndet och bara utvärdera de nya token som kommer efter den cachade gränsen. En hushållsassistent med en stabil systemprompt kan därför undvika upprepat arbete före varje kort kommando.

LMCache beskriver återanvändning av KV-cache mellan LLM-begäranden som en optimering på serveringslagret, inte som en förändring av modellvikterna.

Det nya användarmeddelandet måste fortfarande förifyllas, och varje genererad output-token kräver fortfarande avkodningsberäkningar. Prefixcachning minskar främst överflödigt arbete innan genereringen börjar.

Långa stabila prefix ger störst förbättring av tiden till första token

En cache sparar arbete i proportion till den del som annars skulle ha beräknats på nytt. Att återanvända ett instruktions- och dokumentprefix på 2 000 token är viktigare än att återanvända en hälsningsfras på tio token.

SGLangs serveringsdesign använder strukturerad KV-återanvändning för att snabba upp arbetsbelastningar med gemensamma prefix. Motsvarigheten på en hemmaserver är en upprepad agentpolicy, en verktygskatalog, ett kunskapspaket för hushållet eller en dokumentmall.

Därför bör prefixcachning utvärderas med tiden till första token och förifyllningsgenomströmningen, inte enbart med token per sekund under genereringen. Avkodningsfasen kan förbli nästan oförändrad medan svaret börjar snabbare.

Små promptändringar kan bryta återanvändningen vid blockgränsen

En cache är vanligtvis exakt med avseende på token och modellens tillstånd. Om verktygsdefinitioner ordnas om, en tidsstämpel som ändras infogas nära början, adaptrar byts ut eller systemprompten ändras kan senare block bli obehöriga för återanvändning.

Hugging Faces serveringsvägledning skiljer mellan schemaläggning av förifyllning och avkodning. Genom att placera stabilt innehåll tidigt i prompten kan en större del av förifyllningen återanvändas.

Applikationer bör därför undvika att lägga in föränderlig data i början av ett annars stabilt prefix när samma information kan placeras längre bak.

Cachekapacitet och utkastning sätter gränsen för hemmaservrar

KV-block förbrukar minne, så servern kan inte behålla alla prefix för alltid. Samtidiga konversationer, långa kontexter och flera modeller konkurrerar om samma minnespool och kan göra att äldre återanvändbara tillstånd kastas ut.

ZimaSpaces förklaring av modellcachning och svarslatens med varma modeller beskriver den övergripande cachehierarkin. Prefixcachning är bara ett lager och ska inte förväxlas med att hålla modellvikter kvar i minnet.

Mät cacheträffsfrekvens, antal återanvända token, tid till första token, förifyllningsgenomströmning, KV-minnesanvändning och utkastningsfrekvens vid den verkliga samtidighetsnivån i hushållet.

NVIDIA:s dokumentation för TensorRT-LLM beskriver återanvändning av KV-cache som en serveringsoptimering med samma grundläggande begränsning: återanvändbara tillstånd hjälper bara så länge de matchande blocken finns tillgängliga.

Teknik- och AI-hubb

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.