LLM-promptcachning kan göra ett premium-API billigare än en underutnyttjad lokal GPU för upprepad kontext. Den kan också ge inga besparingar alls. De avgörande variablerna är inte modellernas listpriser. Det är prefixåteranvändning, kostnad för cache-skrivning, läsrabatter, utgångstid, utträngning, utnyttjandegrad och kostnaden för misslyckat arbete.
Målgrupp: Avancerade praktiker med ansvar för kostnad, latens eller infrastruktur för LLM-plattformar.
Den praktiska regeln: mät cachade läsningar och ogiltigförklaringar på din verkliga arbetslast innan du köper GPU-kapacitet. En ny fallstudie om en enterprise-kodningsagent visar detta med ett slående cache-träffresultat på 99,3 %, men författarna studerade en utvecklare, två sekventiella 28-dagarsperioder, olika modellsfamiljer och en produktionskodbas. Se artikeln som en uppmaning till mätning, inte som ett avgörande mellan moln och lokalt.
Vad LLM-promptcachning förändrar
En LLM bearbetar indata i två breda faser:
På serveringslagret kan prefixcachning lagra återanvändbara attention- eller key-value-tillstånd för ett promptprefix. En senare begäran med samma kvalificerade prefix kan hoppa över en del av det upprepade prefill-arbetet. Det föränderliga suffixet måste fortfarande bearbetas, och modellen dekoder fortfarande ett nytt svar.
Den skillnaden är viktig. Promptcachning är inte svarscachning. Den returnerar inte ett lagrat svar, förkortar inte utdatan, reparerar inte en svag prompt och garanterar inte lägre latens från början till slut. Den riktar sig främst mot upprepad beräkning av indata och förbättrar ofta tiden till första token.
Den ursprungliga Prompt Cache-artikeln formaliserade återanvändbara promptmoduler och rapporterade förbättringar av tiden till första token på mellan 8× på GPU:er och 60× på CPU:er i en prototyp. Detta är resultat från artikelns testade modeller, hårdvara, promptar och implementation – inte en prognos för dagens kommersiella API:er.
Fallstudien med 99,3 %: användbara belägg med snäva gränser
Ett förtryck från juli 2026, *Inference Economics of Enterprise Coding Agents*, jämförde två sammanhängande 28-dagarsperioder på ett produktionsmonorepo:
Författarna analyserade LLM-telemetri och Git-historik. De rapporterade en prompt-cache-träffgrad på 99,3 % för API-perioden, en effektiv API-kostnad på 0,573 USD per miljon bearbetade tokens och en amorterad styckkostnad på 2,83 USD för den delade lokala allokeringen. API:t bearbetade 16,9 gånger fler tokens, medan den lokala hårdvaran hade låg utnyttjandegrad, så dessa normaliserade tokenpriser avgör inte infrastrukturfrågan.
Resultaten för totalkostnad pekar i olika riktningar beroende på allokering. Under artikelns antaganden om Taiwan-marknaden och arbetskraft minskade delad lokal kapacitet den uppskattade verkliga totalkostnaden för ägande med 40,1 %. Dedikerad lokal reservation kostade 43,8 % mer än det cachade API:t. Den lokala perioden var också förknippad med en högre andel fix-commits: 74,9 % jämfört med 45,9 %.
Vad författarna mätte
Vad de drog för slutsatser om
Vad studien inte kan fastställa
Designen var icke-randomiserad och sekventiell. Kodbasen, utvecklaren, uppgiftsmixen och arbetssätten kan ha förändrats mellan perioderna. Modellkapacitet, serveringsstack, harness och kvantisering förändrades samtidigt. Den första författaren kände till hypotesen. Etiketten för fix-commits är en proxy, inte en oberoende felrevision. Rå produktions-telemetri och den fullständiga replay-miljön publicerades inte.
Den hållbara slutsatsen är snävare än rubriksiffrorna: promptåteranvändning och GPU-utnyttjande kan dominera jämförelser av listpriser, medan reparationsarbete kan dominera tokenbesparingar.
Definiera mätkontraktet innan du beräknar en träffgrad
”Cache-träffgrad” är tvetydigt om nämnaren inte är uttrycklig. En dashboard kan dividera cachade tokens med kvalificerade prefix-tokens. En annan kan dividera begäranden med någon cacheläsning med alla begäranden. En tredje kan rapportera cachade tokens som andel av total indata, inklusive ett ocachat suffix.
Använd separata mätvärden:
Håll leverantörsrapporterade användningsfält åtskilda från mätvärden du härleder. Tokenantal kan också förändras med modellernas tokenizers och mallar; förklaringen av tokenizerskatten för LLM→ visar varför råa teckenantal är en svag ersättning.
Aktuellt API- och self-hosted-beteende är inte enhetligt
Följande ögonblicksbild kontrollerades den 30 juli 2026. Kontrollera den länkade dokumentationen igen innan du använder den för inköp eller fakturering.
| Plattform | Cachekontroll | Observerbar signal | Operativ begränsning |
|---|---|---|---|
| --- | --- | --- | --- |
| OpenAI API | GPT-5.6 stöder implicit och explicit promptcachning | `cached_tokens` och `cache_write_tokens` | Aktuell vägledning för GPT-5.6 prissätter explicita skrivningar till 1,25× ocachad indata; läsningar är rabatterade |
| Anthropic API | Automatisk cachning eller explicita brytpunkter för block | Separat användning för skapande och läsning av cache | Prefixordningen är verktyg, system och därefter meddelanden; standard-TTL är 5 minuter, med ett betalt alternativ på 1 timme |
| Gemini Interactions API | Implicit kontextcachning är aktiverad som standard för Gemini 2.5 och nyare modeller | `usage.total_cached_tokens` | Gemensamt innehåll bör ligga först; aktuella minimikrav varierar från 2 048 till 4 096 tokens beroende på modell |
| vLLM | Automatic Prefix Caching kan aktiveras i motorn | Motormätvärden och begärandetider | Ditt team ansvarar för kapacitet, utträngning, isolering, uppgraderingar och observerbarhet |
OpenAI:s aktuella modellvägledning uppmanar GPT-5.6-användare att övervaka cache-skrivningar och läsningar eftersom explicita skrivningar kostar mer än ocachad indata. Anthropics dokumentation om promptcachning dokumenterar 5-minutersskrivningar till 1,25× basindata, 1-timmeskrivningar till 2× och cacheläsningar till 0,1×. Googles guide för kontextcachning säger att implicit cachning är automatisk i dess Interactions API och rapporterar cachade tokens i användningen. vLLM:s exempel på Automatic Prefix Caching visar samma idé om delade prefix i en self-hosted-motor.
Dessa implementationer delar en princip, inte ett portabelt faktureringsavtal. Minsta prefixlängd, cachescope, lagringstid, lagringsavgifter, användningsfält och isolering kan skilja sig åt.
*Mät cachen innan du ändrar infrastrukturen: stabilisera prefixet, kör kalla och varma tester, tvinga fram ogiltigförklaring och jämför sedan totalkostnaden.*
En break-even-formel för det återanvändbara prefixet
Låt:
Om vi bortser från lagringsavgifter är den genomsnittliga avgiften per begäran för det återanvändbara prefixet:
`(W + (N - 1) × R) / N`
Cachning är billigare än att bearbeta prefixet ocachat när:
`N > (W - R) / (U - R)`
Denna ekvation isolerar det återanvändbara prefixet. Den utesluter det föränderliga suffixet, utdatatokens, minsta cachningsbara längd, lagringsavgifter, missar orsakade av utträngning, samtidighetseffekter, ingenjörsarbete och misslyckade uppgifter.
Som en daterad illustration var Anthropics 5-minutersmultiplikatorer den 30 juli 2026 `U = 1`, `W = 1.25` och `R = 0.1`. Tröskeln för enbart indata är `N > 1.28`, så den andra användningen inom cachens livslängd amorterar den högre skrivavgiften för det kvalificerade prefixet. Det betyder inte att två totala API-anrop gör cachning lönsam. Ett kort prefix, ett långt ocachat suffix, en cachemiss eller dyr utdata kan radera besparingen.
Använd ekvationen som ett enhetstest för din kostnadsmodell. Ersätt varje variabel med värden från det aktuella leverantörsavtalet och din uppmätta arbetslast.
Varför till synes stabila promptar missar cachen
De flesta missar börjar i promptkonstruktionen, inte i modellen.
Föränderlig data förekommer för tidigt
En tidsstämpel, ett begärande-ID, en slumpmässig nonce, ett användarnamn eller ett färskt retrieval-resultat nära början ändrar varje efterföljande token. Placera stabila verktyg, policyer, mallar och återanvändbara dokument först. Flytta begärandespecifik data efter det återanvändbara prefixet eller den explicita brytpunkten.
Serialiseringen förändras mellan begäranden
JSON-nycklars ordning, blanksteg, verktygsordning och dokumentordning kan förändra ett i övrigt likvärdigt prefix. Använd deterministisk serialisering. Sortera verktygsdefinitioner och hämtade dokument efter stabila identifierare där semantiken tillåter det.
Kontextansvarig förstör prefixkontinuiteten
Aggressiv beskärning kan spara indatatokens samtidigt som cachade prefix ogiltigförklaras. TokenPilot, ett pågående förtryck från juni 2026, behandlar detta som ett gemensamt optimeringsproblem. Författarna stabiliserar inläsningen och skjuter upp utträngning tills kontexten förlorar sitt uppgiftsvärde. De rapporterar kostnadsminskningar på 56 % till 87 % över två benchmark och två körlägen, samtidigt som konkurrenskraftig uppgiftsprestanda bibehölls. Dessa resultat kräver replikering utanför artikelns arbetslaster och LightMem2-integrering.
Cachen löper ut eller trängs ut under verklig belastning
Ett varmt lokalt test kan dölja TTL-gränser och kapacitetstryck. Self-hosted prefixcachning delar samma verklighet med begränsat minne som andra KV-cache-system. Den mer djupgående guiden om KV-cache-utträngning→ beskriver varför återanvändning kan kollapsa när samtidighet och sekvenslängd ökar.
Modellen eller mallen förändras
En modellversion, tokenizer, chattmall, bilddetaljinställning, verktygsschema eller säkerhetspreambel kan skapa ett nytt prefix. Behandla releaser och promptmigreringar som händelser som ogiltigförklarar cachen.
Aktuella vLLM-diskussioner inom engineering illustrerar trycket. Ett förslag om kontextmedveten kvarhållning hävdar att samtidiga agentarbetslaster kan tränga ut värdefulla prefix, medan ett förslag om semantisk KV-cache undersöker återanvändning bortom exakta matchningar. Detta är öppna designdiskussioner, inte produktionsgarantier eller mätningar av användning.
Ett reproducerbart promptcache-test
Använd samma uppsättning uppgifter som du skulle använda för att benchmarka AI-modeller för verkligt arbete→. Cachetestet lägger till kontrollerade prefixmutationer och infrastrukturredovisning.
1. Frys en representativ arbetslast
Välj 30 till 100 uppgifter från produktionstrafik eller en integritetssäker replay-uppsättning. Bevara den verkliga fördelningen av prefixlängd, suffixlängd, utdatalängd, verktyg, dokument och samtidighet. Definiera uppgiftsframgång innan testet körs.
Optimera inte på en enda lång demoprompt. Ett cachevänligt supportarbetsflöde och ett cachefientligt researcharbetsflöde kan ha motsatt ekonomi.
2. Dela upp stabilt och föränderligt innehåll
Märk varje promptsegment:
Bygg en deterministisk promptassemblerare. Registrera en ogenomskinlig prefixversion eller en nycklad hash så att varje begäran identifierar det prefix den försökte återanvända. Lägg inte hemligheter eller rått kundinnehåll i loggar.
3. Kör en kontrollerad matris
För varje uppgiftsklass, mät:
| Test | Ändring | Fråga som besvaras |
|---|---|---|
| --- | --- | --- |
| Kallt | Nytt prefix utan återanvändbart tillstånd | Vad är baslinjekostnaden för skrivning eller prefill? |
| Varmt | Identiskt kvalificerat prefix | Rapporterar leverantören eller motorn en läsning? |
| Tidig mutation | Ändra en token nära början | Hur mycket återanvändning försvinner? |
| Sen mutation | Ändra endast suffixet | Förblir det stabila prefixet återanvändbart? |
| TTL-gräns | Upprepa före och efter utgång | Hur ofta kommer produktionstrafik fram i tid? |
| Samtidighet | Öka parallella begäranden stegvis | Minskar utträngning eller schemaläggning återanvändningen? |
| Versionsändring | Ändra modell, verktyg eller mall | Vilka driftsättningar ogiltigförklarar cachen? |
Kör tillräckligt många upprepningar för att rapportera fördelningar i stället för ett enda latensvärde. Separera p50- och p95-tid till första token från latens från början till slut.
4. Registrera fakturering och kvalitet tillsammans
Samla in:
Återanvändning av tillstånd för exakta prefix bör undvika upprepad prefill-beräkning; det är inte ett skäl att hoppa över en kvalitetskontroll. En förändring av modell, kvantiseringsnivå, routingpolicy eller serveringsstack kan ändra utdatakvaliteten även när själva cachemekanismen fungerar korrekt.
5. Beräkna tre kostnadsperspektiv
Om det lokala alternativet bygger på varaktigt utnyttjande, testa antagandet om utnyttjandegrad. Ett GPU-köp blir inte ekonomiskt bara för att ett kalkylblad tilldelar varje tom timme till framtida efterfrågan.
Moln-API, lokal GPU eller hybrid routing?
Beslutet är sällan binärt.
Föredra ett cachat API när
Föredra delad lokal kapacitet när
Använd hybrid routing när
Gratis eller subventionerade endpoints kan hjälpa vid prototyper, men de eliminerar inte behovet av redovisning av arbetslasten. Fallstudien om API:er för gratis AI-modeller→ är en användbar utgångspunkt för att skilja åtkomstpris från produktionsmässig tillförlitlighet.
Promptcachesäkerhet behöver ett eget test
Cachning skapar databeroende timing: ett återanvänt prefix kan returnera sin första token snabbare än en miss. En granskning vid ICML 2025 använde tidsmätningar för att testa verkliga API:er och rapporterade belägg för cache-delning mellan användare hos sju leverantörer under studieperioden.
Det resultatet är historiskt och leverantörsspecifikt. Det fastställer inte hur dessa tjänster isolerar cacher i dag.
Fråga aktuella leverantörer och interna plattformsägare:
För self-hosted-system ska tester av timing och utträngning över tenants ingå. Logga inte återanvändbara känsliga prefix enbart för att felsöka cachen. Lagra hashvärden, tokenantal, versionsidentifierare och policysäker metadata.
Beslutschecklistan
Godkänn inte ett GPU-köp eller en API-migrering utifrån enbart listpriser. Kräv:
Promptcachning är värdefull eftersom upprepad kontext är vanlig. Den är farlig som genväg vid inköp eftersom återanvändning är specifik för arbetslasten. Mät prefixet, mät missarna och jämför sedan totalkostnaden.
Kontroll av påståenden
| Viktigt påstående | Evidenstyp | Kontroll och begränsning |
|---|---|---|
| --- | --- | --- |
| Studien av kodningsagenten rapporterade en prompt-cache-träffgrad på 99,3 % | Primärforskning, förtryck från juli 2026 | En utvecklare, en kodbas, två sekventiella perioder; resultatet är inte portabelt |
| Artikeln rapporterade 0,573 USD/M bearbetade API-tokens jämfört med 2,83 USD/M för delad lokal allokering | Primärforskning | API:t bearbetade 16,9× fler tokens och den lokala utnyttjandegraden var låg; total förbrukning och TCO är starkare jämförelser |
| Delad lokal kapacitet sparade 40,1 % TCO medan dedikerad kapacitet kostade 43,8 % mer | Primärforskning | Beror på artikelns antaganden om hårdvara, allokering, Taiwan-marknaden, arbetskraft och kvalitet |
| Prefixcachning återanvänder attention-tillstånd för upprepade promptsegment | Peer-reviewad primärforskning och officiell motordokumentation | Den minskar upprepat prefill-arbete; dekodning och arbete med föränderliga suffix kvarstår |
| Anthropics 5-minuters cache-skrivningar kostar 1,25× och läsningar 0,1× basindata | Officiell dokumentation kontrollerad den 30 juli 2026 | Priser och stödda modeller kan förändras; exemplet utesluter utdata, suffix och lagring |
| Geminis implicita cachning är standard för Gemini 2.5 och nyare i Interactions API | Officiell dokumentation uppdaterad den 7 juli 2026 | Tokenminimikrav och stöd för explicit cache skiljer sig åt mellan API och modell |
| TokenPilot rapporterade kostnadsminskningar på 56–87 % över sina testade inställningar | Primärforskning, pågående förtryck | Två benchmark och en specifik integrering; oberoende replikering behövs |
| Timing för promptcache kan exponera information när cachescope går över användargränser | Primärforskning vid ICML 2025 | Historisk granskning av testade leverantörer; dra inga slutsatser om aktuellt leverantörsbeteende |