Cachebewuste LLM-prompts ontwerpen voor OpenAI, Anthropic en Gemini

Prompt caching helpt alleen als dezelfde tokens lang genoeg op de juiste plaats worden hergebruikt, en volgens de semantiek van de provider die u feitelijk aanroept. Teams missen vaak het voordeel omdat ze caching als een modelfunctie beschouwen in plaats van als een verzoekarchitectuurprobleem. Ze plaatsen tijdstempels bovenaan elke prompt, voegen verzoekspecifieke ophaalresultaten af ​​met herbruikbare toolschema's, of optimaliseren voor de ene provider terwijl ze stilletjes de kosten voor een andere verhogen.

De praktische oplossing is om promptcaching onderdeel te maken van de gatewayverzoekcompiler. De gateway moet stabiel promptmateriaal scheiden van vluchtig verzoekmateriaal, providerspecifieke cache-instructies compileren en de kosten en latentie meten aan de hand van een cachebaar voorvoegsel. Dat is het belangrijkst in een omgeving met meerdere modellen, waar OpenAI, Anthropic en Gemini verschillend cachegedrag, boekhoudvelden, TTL's en installatiekosten blootleggen.

Begin met de cachebare eenheid, niet met de provider

De herbruikbare eenheid is meestal niet de hele prompt. Het is een voorvoegsel of contextobject gemaakt van promptmateriaal dat door veel verzoeken wordt gedeeld. In een productie-onderneming LLM API omvat dat materiaal vaak platformbeleid, organisatiebeleid, applicatie-instructies, tooldefinities, regels voor reactieformaten, instructies voor coderingsagenten of statische corpusbegeleiding.

Het vluchtige deel is het materiaal dat per verzoek verandert: de huidige taak van de gebruiker, verzoek-ID's, tijdstempels, gespreksstaart, nieuw opgehaalde RAG-passages, accountspecifieke gegevens en eenmalige gereedschap resultaten. Als vluchtige inhoud vóór stabiele inhoud verschijnt, kan dit het hergebruik van voorvoegsels verbreken of de provider dwingen een grote prompt als nieuw te behandelen.

Feit: implementaties van providers verschillen. OpenAI documenten vragen om caching als hergebruik van een gedeeld voorvoegsel, met token-accounting in de cache. In het openbare prompt-caching-artikel staat dat automatische caching begint bij een voorvoegsel van 1.024 tokens en groeit in stappen van 128 tokens, en dat cache-items doorgaans worden gewist na 5 tot 10 minuten inactiviteit en binnen een uur na het laatste gebruik. Anthropic documenteert expliciete cachebreekpunten en raadt aan om cache_control op het laatste gedeelde blok te plaatsen, zoals systeemprompts of tooldefinities. Gemini documentcontextcaching als een betaalde functie waarbij het aantal tokens in de cache wordt geretourneerd in gebruiksmetagegevens voor cachebewerkingen en generatieaanroepen die gebruikmaken van een cache.

Aanbeveling: ontwerp uw interne promptrepresentatie rond stabiele blokken en vluchtige blokken voordat u iets toewijst aan API's van de provider.

Compileer verzoeken van meest stabiel naar meest vluchtig

A cache-bewuste verzoekcompiler moet materiaal zo bestellen dat de grootste herbruikbare sectie vóór de verzoekspecifieke sectie verschijnt. Een praktische standaardvolgorde is:

1. Platformveiligheids- en compliancebeleid.
2. Organisatie- of tenantbeleid.
3. Applicatierol- en taakinstructies.
4. Toolschema's en regels voor toolgebruik.
5. Statische kennis of langdurige referentie materiaal.
6. Gespreksgeschiedenis die tussen beurten wordt hergebruikt.
7. Opgehaalde passages of andere verzoekspecifieke context.
8. De huidige gebruikerstaak.
9. Efemere metadata zijn alleen nodig voor deze oproep.

Deze volgorde is geen universele waarheid. Sommige aanbieders of modellen reageren mogelijk anders als instructies worden verplaatst. Beleidsprioriteit en gedragskwaliteit zijn nog steeds van belang.Beschouw cache-bewuste ordening als een gecontroleerde wijziging: voer promptregressietests uit voor en na het wijzigen van de lay-out.

Voorbeeld van interne promptblokken

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

De compiler kan het stabiele voorvoegsel hashen nadat het is weergegeven. Die hash wordt de join-sleutel voor cacheanalyses: model, tenant, applicatie, hash met cachebaar voorvoegsel, promptversie, TTL-keuze, niet in de cache opgeslagen invoertokens, in de cache opgeslagen invoertokens, cacheschrijftokens waar beschikbaar, uitvoertokens, latentie en uiteindelijke kosten.

Gebruik provideradapters in plaats van één cache-aanname

Een enkele vlag 'cache inschakelen' is te vaag voor bewerkingen met meerdere providers. De gateway moet één intern cachebeleid beschikbaar stellen en dit compileren in providerspecifiek gedrag.

OpenAI Adapter

Voor OpenAI: optimaliseren voor herhaalde gedeelde voorvoegsels en gebruiksaccounting. De verzoekcompiler moet stabiel materiaal aan de voorkant houden en kleine verschillen binnen de eerste cachebare reeks vermijden. Volg in de cache opgeslagen invoertokens uit de gebruiksvelden van de provider. Houd, indien beschikbaar, ook cache-schrijftokens bij, zodat het kostenboek het maken en hergebruiken van caches kan vergelijken.

Omdat caching prefix-georiënteerd is, is het voorkomen van prefix-drift een belangrijke operationele taak. Twee prompts die er voor mensen hetzelfde uitzien, kunnen verschillen omdat een tijdstempel, build-ID, gerandomiseerde toolvolgorde of tenantpersonalisatie bovenaan werd weergegeven.

Anthropic Adapter

Voor Anthropic compileert u expliciete cache-breekpunten. Plaats cache_control op het laatste blok dat moet worden gedeeld met vervolgverzoeken. Goede kandidaten zijn grote systeeminstructies, tooldefinities of stabiele referentiecontext. Slechte kandidaten zijn eenmalige gebruikersberichten, huidige taakpayloads of verzoekspecifieke RAG-fragmenten.

Feit: Anthropic documenteert een standaard cacheduur van 5 minuten en een cacheduur van 1 uur, beschikbaar tegen extra kosten. Dat maakt TTL-selectie een economische beslissing. Een lange cache kan zinvol zijn voor interactieve codeeragenten, documentreview in meerdere stappen of ondersteuning van copiloten met pauzes tussen beurten. Het kan een verspilling zijn bij een eenmalige taak met weinig herhaling.

Gemini Adapter

Beschouw contextcaching voor Gemini als een resourcebeslissing. Maak inhoud in de cache wanneer het verwachte hergebruik de installatie- en opslagkosten rechtvaardigt, en verwijs vervolgens naar die cache vanuit generatieaanroepen. Dit is anders dan alleen vertrouwen op een automatische prefix-cache. De adapter moet eigenaar zijn van de cachelevenscyclus, TTL, metagegevens en opruimbeleid.

Gemini-stijl contextcaches zijn vaak het beste voor grote, stabiele context die veel verzoeken zullen hergebruiken: een lange beleidshandleiding, een statisch productcatalogusuittreksel, een vaste coderingstoolomgeving of een beoordelingsworkflow die herhaaldelijk vragen stelt over dezelfde documentenset.

Meet de cache-economie, niet alleen de hit Beoordeel

Cachehitpercentage is nuttig, maar niet voldoende. Een hoog trefferpercentage voor een klein voorvoegsel kan weinig besparen. Een lager trefferpercentage voor een zeer groot beleids-en-tools-voorvoegsel kan van groter belang zijn.Sommige providers brengen kosten voor schrijven in de cache of configuratiekosten met zich mee, en deze kosten kunnen de besparingen teniet doen als het hergebruik laag is.

Veg deze velden vast voor elk verzoek waar de provider ze openbaar maakt of de gateway ze kan schatten:

• Provider en model.
• Tenant, applicatie, omgeving en API sleutelidentiteit.
• Prompt sjabloonversie en cachebaar voorvoegsel hash.
• TTL-beleid of cacheduur.
• Niet in de cache opgeslagen invoertokens.
• Invoertokens in cache.
• Tokens voor schrijven in cache of cache maken, indien beschikbaar.
• Uitvoertokens.
• Tijd tot eerste token en totaal latentie.
• Lijstprijsversie van provider gebruikt voor kostenberekening.
• Of het verzoek deel uitmaakte van een interactieve sessie, batchtaak, agentlus of eenmalige oproep.

Bereken vervolgens de cachewaarde op basis van de werklast, niet globaal. Een ondersteunende copiloot, codeeragent, documentreviewer en eenmalige samenvatter hebben verschillende hergebruikpatronen. Samenvoegingen moeten de bespaarde dollars, de uitgegeven dollars in de cache, de verandering in de latentie en het hitpercentage per voorvoegsel-hash weergeven.

Een eenvoudig ROI-model is voldoende om te beginnen:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Dit model is opzettelijk eenvoudig gehouden. Het moet worden gebruikt als poort voordat langdurige of expliciete caches worden ingeschakeld, en niet als vervanging voor productiemetingen.

Voeg lintregels toe voor cachebrekers

De meeste cachefouten komen voort uit snelle constructiegewoonten, niet uit bugs van de provider. Voeg gateway-lintregels toe die worden uitgevoerd voordat verzoeken de provider bereiken.

Markeer tijdstempels bovenaan de prompts. Als het model de huidige tijd nodig heeft, plaats het dan na het herbruikbare voorvoegsel of geef het door als een laat verzoekblok.

Markeer willekeurige ID's in systeemberichten. Correlatie-ID's horen thuis in metadata of logboeken, niet in het stabiele promptvoorvoegsel.

Markeer dynamisch geordende toolschema's. Sorteer tools en schema-eigenschappen deterministisch voordat ze worden weergegeven. Een gereedschapslijst die bij elk verzoek van volgorde verandert, kan hergebruik vernietigen, zelfs als de gereedschapsset logisch identiek is.

Markeer verzoekspecifieke RAG vóór stabiele gereedschappen. Teruggevonden passages zijn vaak vluchtig. Zet eerst stabiele instructies en toolschema's en haal vervolgens de passages op, tenzij snelle tests uitwijzen dat een andere volgorde nodig is.

Markeer gebruikersspecifieke personalisatie in gedeeld beleid. Tenantbeleid kan in de cache van een tenant worden opgeslagen, maar gebruikersvoorkeuren en huidige accountstatus zijn dat meestal niet.

Verloop van sjabloonversie markeren. Als bij elke implementatie de witruimte, opmerkingen of ongebruikte instructietekst verandert, verandert de cachebare voorvoegsel-hash. Versieprompt bewust op sjablonen en vermijd onnodige bewerkingen van grote stabiele blokken.

Ga zorgvuldig om met RAG-workloads

RAG is de plek waar teams vaak te veel cachegeheugen gebruiken. Stabiele ophaalinstructies, citatieregels, toolschema's en corpusbeschrijvingen kunnen herbruikbaar zijn. De opgehaalde passages zelf zijn doorgaans verzoekspecifiek. Als u opgehaalde passages vóór de stalinstructies plaatst, vermindert u hergebruik. Als u de volledige context in de cache opslaat wanneer het onwaarschijnlijk is dat passages zich herhalen, betaalt u mogelijk schrijf- of instelkosten zonder voldoende toekomstige treffers.

Er zijn uitzonderingen. Een juridische beoordelingsstroom, ondersteuningsworkflow of productdocumentassistent kan in één sessie herhaaldelijk dezelfde documentbundel doorzoeken. In dat geval kan een cache met een langere levensduur voor de documentcontext nuttig zijn.De beslissing moet afhangen van het verwachte aantal hergebruiken, de cacheduur, de grootte van de documentcontext en of gebruikers de neiging hebben om meerdere vragen te stellen over hetzelfde materiaal.

Aanbeveling: classificeer RAG-context als een van de drie typen: statische corpusbegeleiding, herbruikbare sessiecontext of eenmalige opgehaalde fragmenten. Standaard worden alleen de eerste twee in het cachegeheugen opgeslagen.

Gedrag valideren voordat de kosten worden geoptimaliseerd

Het later verplaatsen van inhoud in een prompt kan het hergebruik van de cache verbeteren, maar kan ook het gedrag van het model veranderen. Het verplaatsen van toolregels na de gespreksgeschiedenis kan bijvoorbeeld hun invloed verminderen. Het verplaatsen van beleid onder opgehaalde inhoud kan de instructieprioriteit verzwakken. Het normaliseren van schema's kan de selectie van tools beïnvloeden als de beschrijvingen veranderen.

Gebruik regressietests voordat u cache-bewuste lay-outs uitrolt. Test minimaal het volgende:

• Instructieprioriteit voor veiligheids- en nalevingsbeleid.
• Toolselectie voor bekende taken.
• Gestructureerde uitvoervaliditeit waarbij schema's betrokken zijn.
• Antwoordkwaliteit voor representatieve RAG-voorbeelden.
• Latentie en kosten bij herhaling beurten.
• Provider-specifieke gebruiksaccounting.

Voor workflows met een hoog risico voert u een schaduwvergelijking uit: oorspronkelijke promptindeling versus cachebewuste indeling, hetzelfde model, dezelfde invoer, met menselijke of geautomatiseerde controles op onaanvaardbare uitvoerwijzigingen. Kostenbesparingen zijn niet nuttig als de verzoekcompiler het bedrijfsgedrag verandert op manieren die teams niet goedkeuren.

Kies werklasten selectief

Promptcaching is het sterkst wanneer prompts lang en herhaald zijn. Goede uitgangspunten zijn codeeragenten met grote toolschema's, ondersteuningscopilots met instructies die veel beleid vereisen, documentbeoordelingsstromen met herhaalde vragen over hetzelfde materiaal, agenten die veel tools gebruiken en bedrijfsassistenten met grote beheerblokken.

Zwakke kandidaten zijn onder meer korte one-shot-prompts, zeer gepersonaliseerde prompts waarbij de bovenkant van het verzoek elke keer verandert, onregelmatige beheertaken en workflows waarbij uitvoertokens de totale kosten domineren. In die gevallen kunnen andere optimalisaties belangrijker zijn: kortere prompts, beter ophalen, modelroutering, batchverwerking of strengere uitvoerlimieten.

Voorspelling: de caching-semantiek van providers zal blijven uiteenlopen. Automatische prefix-caching, expliciete breekpunten, betaalde contextbronnen, cache-write accounting en TTL-prijzen zullen waarschijnlijk ongelijk blijven tussen platforms.Teams die de compilatie van verzoeken en telemetrie bij de gateway centraliseren, kunnen zich sneller aanpassen dan teams die providerspecifieke cachinglogica in de applicatiecode insluiten.

Implementatiechecklist

• Maak een intern promptblokmodel met stabiliteitslabels: globaal, tenant, applicatie, workflow, sessie en verzoek.
• Geef blokken deterministisch weer, inclusief toolvolgorde en schema-eigenschap order.
• Verplaats vluchtige velden uit het stabiele voorvoegsel.
• Bereken een hash van het cachebare voorvoegsel na weergave.
• Voeg provideradapters toe voor OpenAI hergebruik van voorvoegsels, Anthropic cachebreekpunten en Gemini contextcachebronnen.
• Registreer niet-gecachte invoertokens, in het cachegeheugen opgeslagen invoertokens, cache-schrijven tokens waar beschikbaar, uitvoertokens, latentie, model, tenant, applicatie, voorvoegsel-hash en TTL.
• Bouw dashboards voor bespaarde netto dollars, schrijf-/instelkosten, hitrate en latentie per werklast.
• Voeg lintregels toe voor tijdstempels, willekeurige ID's, vluchtige RAG-plaatsing, dynamische toolvolgorde en personalisatie in gedeelde blokken.
• Promptgedrag uitvoeren regressietests voordat u de productie-indeling wijzigt.
• Schakel eerst caching in voor werklasten met veel herhaling en breid deze vervolgens uit op basis van de gemeten ROI.

Conclusie

Cachebewust promptontwerp is niet alleen maar promptopmaak. Het is een gateway-mogelijkheid: deterministische weergave, ontwerp met stabiele voorvoegsels, providerspecifieke compilatie, linting en kostentelemetrie. De teams die er het meest van profiteren, zijn degenen die voor elke werklast drie vragen kunnen beantwoorden: welk deel van het verzoek is echt herbruikbaar, hoe brengt deze provider kosten in rekening voor hergebruik, en heeft de cache de end-to-end-kosten of latentie verbeterd zonder het gedrag te veranderen?

Begin met één workflow met hoge herhalingen. Scheid stabiele blokken van vluchtige blokken, voeg providerspecifieke cache-afhandeling toe, meet de economie en generaliseer pas daarna. Op die manier wordt de gebruikelijke foutmodus vermeden: een cachefunctie inschakelen zonder te weten of dit geld bespaart, latentie toevoegt of eenvoudigweg de kosten naar een ander boekhoudveld verplaatst.

Gerelateerd lezen

• provider-neutrale LLM-observatie