KV-cache-eviction kan dölja LLM-fel i produktion

Ja. KV-cache-eviction kan dölja LLM-fel eftersom en serveringspolicy kan kasta bort attention-tillstånd som var viktiga och sedan sakna tillräcklig information för att uppskatta skadan enbart från den cache som behållits.

En artikel som skickades in den 23 juli 2026 drar en tydlig gräns för problemet: deterministisk, värdeblind top-k-eviction kan inte konsekvent uppskatta det attention-output-fel som den själv orsakar utifrån det kvarhållna tillståndet. Det föreslagna alternativet behåller ett sannolikhetsurval av den bortkastade svansen och bygger ett statistiskt certifikat kring det uppskattade felet. Metoden förbättrade felattribueringen i de rapporterade experimenten, men prototypen är långsammare, experimenten stannar vid 16K context och 8B parametrar, och artikeln bevisar inte korrekthet för svar från början till slut.

Före utrullning ska varje kandidatbehandling av cachen jämföras med en full-cache-kontroll på samma frysta requests. Räkna fallen där full cache klarar sig men kandidaten misslyckas. Testa eviction, quantization, offload och reuse separat så att varje jämförelse isolerar en felkälla.

Läsarnivå: Avancerad. Den här guiden förutsätter att du förstår transformer-inferens, attention och grundläggande modelevaluering.

Innehåll

Varför KV-cache-eviction kan dölja fel

Attention-output beror på både kvarhållna poster och poster som policyn tar bort. När en deterministisk policy kastar bort svansen kan en monitor som bara ser den valda mängden inte inspektera de saknade värdena.

ArXiv:2607.21475 studerar detta observerbarhetsproblem. Det negativa resultatet gäller deterministisk, värdeblind top-k-eviction: det kvarhållna tillståndet räcker inte ensamt för att konsekvent uppskatta det attention-output-fel som eviction orsakar. Resultatet säger inte att varje deterministisk policy ger dåliga outputs. Det säger att denna policyklass inte på ett tillförlitligt sätt kan certifiera sitt inducerade fel med enbart det den behöll.

Den föreslagna metoden bevarar evidens om den bortkastade svansen. Den tar ett Poisson-urval av poster som annars skulle försvinna, tillämpar en Hájek-korrigering och kombinerar uppskattningen med ett varianscertifikat för den kvarhållna mängden.

Uppmätt: Felcertifikatet uppnådde 0,97 täckning över 12 096 attention-replayceller. En separat studie med verkliga arbetsbelastningar använde omkring 74 000 generationer för att testa felattribuering. I den studien nådde certifikatet AUC 0,73–0,75 för att skilja cacheorsakade fel från inneboende modellfel. Output confidence nådde 0,47–0,54 i samma attribueringsuppgift.

Uppmätt: Output confidence förutsade övergripande fel bättre. De två signalerna besvarar olika frågor:

Härlett: Låg output confidence kan inte fungera som den enda larmindikatorn för cacheregressioner. Den kan flagga ett svagt svar utan att identifiera orsaken, medan ett självsäkert svar fortfarande kan förändras efter att cachepolicyn tagit bort användbart tillstånd.

Artikeln rapporterar också negativa och operativa resultat. Tre av sju förregistrerade påståenden misslyckades. Prototypen tog 0,043 sekunder per token, jämfört med 0,023 för deterministisk eviction och 0,015 för full cache. Experimenten omfattade context upp till 16K, modeller upp till 8B och en single-turn-proxy. Författarna tillhandahåller inget teorem som kopplar certifikatet till korrekthet för uppgifter från början till slut.

Praktisk tolkning: Behandla certifikatet som en attribueringssignal under de studerade förhållandena. Det certifierar inte produktionsberedskap.

Fyra cachebehandlingar, fyra tillförlitlighetsfrågor

Team grupperar ofta flera interventioner under ”KV-cache-optimering”. Varje intervention förändrar en annan del av inferensen.

Den systemmedvetna översikten i arXiv:2607.08057 klassificerar området genom temporal schemaläggning, spatial placering och migrering samt strukturell representation och retention. Den taxonomin fungerar också som en utvärderingsgräns. En full-cache-BF16-kontroll jämförd med en evicted-FP8-kandidat ändrar två strukturella variabler samtidigt. Ett misslyckat kandidatförsök kan inte avgöra om eviction, quantization eller deras samspel orsakade regressionen.

Praktisk tolkning: Testa varje cacheintervention som ett eget experiment. Kombinera dem först efter att de individuella behandlingarna har klarat sig.

Policies som bevarar mer användbart tillstånd

Två andra artiklar visar att policyutformning kan bevara mer kvalitet vid samma minnesbudget. Ingen av dem tillhandahåller en universell produktionströskel.

VaSE, arXiv:2606.03928, skyddar value-tillstånd med hög magnitud samtidigt som den behåller stokastisk mångfald. På Qwen3-4B och Qwen3-14B över sex reasoning-uppgifter uppnådde den ungefär 4× cachekomprimering och förbättrade resultaten med 4,4 respektive 4,9 poäng jämfört med den starkaste eviction-baslinjen. En 16K-konfiguration med en enda A100 nådde 3,1× tokens per second.

Dessa mätningar omfattar endast decode, Qwen3-modeller och ingen produktionsbatchning. De fastställer inte samma vinst för en annan modelfamilj, serving engine, samtidighetsnivå eller arbetsbelastning.

K-VEC, arXiv:2606.29563, samordnar retention coverage över attention heads och layers. På Llama 3.1 8B över 16 LongBench-subset förbättrade den poängen med så mycket som 10,35 poäng och med 1,61 poäng i genomsnitt vid en budget på `B=128`. Utvärderingen använder en modelfamilj och en benchmarksvit, och metoden lägger till prefill-arbete.

Praktisk tolkning: Värdemedvetna, stokastiska och täckningsmedvetna policies förtjänar kandidatplatser i en utvärdering. Din full-cache-körning förblir den lokala sanningskällan.

Varför quantization behöver en separat kontroll

FP8 KV cache quantization minskar precisionen i stället för att ta bort tokens. Dess fel kan fortfarande nå applikationen utan ett engine-fel.

En officiell vLLM FP8-utredning, publicerad den 22 april 2026, rapporterade att needle accuracy för long-context föll från 91 % med BF16-cache till 13 % med FP8 innan en fix för two-level accumulation. Fixen återställde noggrannheten till 89 %. I den bästa rapporterade FP8-konfigurationen var decode slope 54 % av BF16.

Uppmätt: En numerisk väg gav en allvarlig regression, och en korrigering på kernel-nivå återställde merparten av den förlorade noggrannheten.

Inte fastställt: FP8-cache orsakar inte universellt den regressionen eller ger den hastighetsökningen. Resultatet beror på implementation, modell, hårdvara, attention-väg och benchmark.

vLLM issue #37554 ger en avgränsad varning: en rapportör hittade tyst korrupt FP8 KV-skalning i en hybridmodell. Denna buggrapport kan inte stödja ett generellt påstående om FP8 eller hybridarkitekturer.

En LocalLLaMA-diskussion från den 7 april innehåller motstridiga rapporter från praktiker om cacheformat och kvalitet. Rapporterna kan föreslå testfall, men en kontrollerad utvärdering måste avgöra en utrullning.

vLLM v0.26.0-release, daterad den 25 juli, innehåller 411 commits från 212 bidragsgivare och utökar insynen i KV-tiering, offload-mått och cache reuse. Releaseaktivitet och nya observability-funktioner bevisar inte bred produktionsanvändning eller korrekthet.

Ett parat valideringsflöde med full cache

Definiera ”full cache” som modellens inbyggda attention-beteende utan tillagd eviction eller cache quantization. Håll modellvikter, tokenizer, runtime-version, attention-backend, sampling-inställningar, prompttokens och output-validator fasta inom varje par.

1. Kör en ablationsmatris

Använd minst fyra behandlingar:

Att endast jämföra A med D kan avslöja en kombinerad regression, men kan inte fördela orsaken. Körningarna B och C tillhandahåller de saknade kontrollerna.

Testa varje modell, runtime, kernel och hårdvaruväg som stöds separat. FP8-resultatet från vLLM visar varför en etikett som ”FP8 enabled” saknar tillräckligt med detaljer för ett tillförlitlighetsbeslut.

*Bildtext: Parad validering med full cache isolerar kandidatens egna fel innan eviction eller quantization når produktion.*

2. Frys en arbetsbelastningsmatris

Bygg matrisen från verkliga request-former och inkludera gränsfall:

Long-context-arbetsbelastningar behöver mer än ett syntetiskt needle-test. Om produkten kör code agents eller utökade workflows ska du inkludera representativa traces. Tokenvolym och workflow-form påverkar ekonomin som beskrivs i More Tokens, Better AI — and the Compute Bill och Code Agents, 21 Billion Activity Tokens, and the Fable of GPT-5.6.

3. Para requests och isolera cachens tillstånd

Använd denna utvärderingslogik:

text for each frozen_case: full = run(frozen_case, treatment=A, isolated_cache=true) candidate = run(frozen_case, treatment=candidate, isolated_cache=true)

full_pass = validate(full, frozen_case.expected_behavior) candidate_pass = validate(candidate, frozen_case.expected_behavior)

record(full_pass, candidate_pass, context_length, task_type, model, runtime, hardware, treatment)

Det här blocket är pseudokod, inte ett enginespecifikt API. Använd en task validator i stället för textjämförelse när flera svar kan vara korrekta. Lämpliga validatorer omfattar unit tests för genererad kod, schemakontroller för strukturerad output, exakta kontroller av verktyg och argument, retrieval assertions eller en förregistrerad rubric.

Håll cachenamespaces isolerade. Prefix state som återanvänds mellan behandlingar kan kontaminera jämförelsen.

4. Mät kandidatens egna fel

Använd detta primära mått:

text cache_induced_failure_rate = count(full passes and candidate fails) / count(full passes)

Nämnaren villkorar frekvensen på framgång med full cache. Ett par där båda körningarna misslyckas visar inte att cachekomprimering orsakade felet.

Rapportera det råa täljare- och nämnarvärdet för varje kritiskt segment. Ett enda aggregat kan dölja en regression vid maximal context, på en modell eller under en attention-backend. Följ den totala felfrekvensen bredvid det parade måttet eftersom output confidence och cache-attribueringssignaler täcker olika felmoder.

5. Förregistrera beslutsregeln

Välj den högsta acceptabla frekvensen, `τ`, innan du ser kandidatresultaten. Sätt striktare regler för kritiska uppgifter. Ett reproducerbart kandidatfel kan motivera avslag på en tool-, safety- eller transaction-väg även när aggregatet ligger under `τ`.

Cachekonfiguration hör hemma i exekveringspolicyn. Registrera och verkställ den med samma disciplin som används för deterministiska AI-agentbehörigheter: explicit konfiguration, observerbara beslut och en reparationsväg när verkställigheten misslyckas.

Beslut om utrullning

Release notes-aktivitet, anekdotiska rapporter och genomsnittliga benchmarkvinster kan inte ersätta en parad utrullningsgrind.

Begränsningar i den nuvarande evidensen

Det starkaste certifikatresultatet omfattar attention-output-fel under en single-turn-proxy, inte applikationskorrekthet från början till slut. Experimenten stannar vid 16K och 8B, medan produktionssystem kan köra större modeller, längre context, flera turns, verktyg och batcher. Den uppmätta prototypen kostar dessutom mer tid per token än deterministisk eviction och full cache i den rapporterade konfigurationen.

VaSE och K-VEC är fortfarande bundna till specifika modeller, uppgifter, budgetar och serving-konfigurationer. vLLM-evidensen visar att implementationsdetaljer kan dominera ett resultat för ett cacheformat. Ingen av dessa källor tillhandahåller ett universellt säkert komprimeringsförhållande.

Praktisk tolkning: Använd forskningen för att välja kandidatpolicies och övervakningssignaler. Använd parad validering med full cache för att avgöra om din implementation uppfyller tillförlitlighetsgränserna för din arbetsbelastning.

Kontroll av påståenden

Källor