LLM Prompt Caching: Bespaar 90% op API-kosten (Alle 3 Providers)

LLM Prompt Caching: Bespaar 90% op API-kosten (Alle 3 Providers)

LLM prompt caching laat je eerder verwerkte tokens hergebruiken over API-aanroepen heen -- waardoor invoerkosten met maximaal 90% dalen en de tijd tot het eerste token met maximaal 85% afneemt. Als je bij elk verzoek dezelfde systeemprompt, tooldefiniëren of few-shot-voorbeelden verzendt, betaal je de volle prijs voor werk dat de GPU al gedaan heeft.

Deze gids behandelt OpenAI, Anthropic en Gemini met dezelfde chatbot geïmplementeerd in alle drie SDK's -- iets dat geen enkele andere gids doet. We behandelen ook de automatische caching-update van Anthropic van februari 2026, productie-kostenscenario's met echte bedragen, en de anti-patronen die je cache-trefferpercentage stil vernietigen.

Snelовerzicht -- Alle Drie Providers in één Oogopslag

Voordat we ingaan op implementatiedetails, hier de volledige vergelijking. Als je al weet welke provider je gebruikt, spring direct naar die sectie. Als je nog evalueert, vertelt deze tabel je alles in 10 seconden.

Kernboodschap: OpenAI is het eenvoudigst (nul configuratie, 50% korting). Anthropic biedt de diepste korting (90%) met de meeste controle. Gemini biedt configureerbare TTL en impliciete caching op 2.5+-modellen met vergelijkbare kortingen als Anthropic.

Hoe Werkt LLM Prompt Caching?

Je hoeft de interne werking van transformers niet te begrijpen om prompt caching effectief te gebruiken. Maar je moet één concept begrijpen: prefix-matching.

De KV-cache in 60 Seconden

Wanneer een LLM je prompt verwerkt, berekent het aandachtstoestanden (sleutel-waardeparen) voor elk token. Deze KV-cache-invoeren zijn het dure deel -- ze verbruiken GPU-geheugen en rekentijd. Prompt caching slaat deze berekende toestanden op zodat het volgende verzoek met hetzelfde prefix de herberekening volledig overslaat.

Het cruciale woord is prefix. De cache vergelijkt vanaf het begin van je prompt. Als de eerste 2.000 tokens overeenkomen met een gecachte invoer maar token 2.001 verschilt, worden die eerste 2.000 tokens vanuit de cache geserveerd. Alles na het divergentiepunt wordt vers berekend.

Daarom is de volgorde in de prompt belangrijk. Structureer je prompts zo:

1. Tooldefinities (meest statisch)
2. Systeemprompt
3. Statische few-shot-voorbeelden
4. Opgehaalde context (half-dynamisch)
5. Gespreksgeschiedenis (groeit per beurt)
6. Gebruikersvraag (altijd anders)

Statische inhoud eerst, dynamische inhoud als laatste. Hoe meer tokens overeenkomen met het gecachte prefix, hoe groter de besparingen.

Prompt Caching vs Semantische Caching vs Antwoord-caching

Deze drie termen worden voortdurend verward. Prompt caching (waar deze gids over gaat) hergebruikt berekende KV-toestanden op GPU-niveau voor identieke tokenprefiksen -- nul nauwkeurigheidsverlies, zelfde uitvoer als zonder cache. Semantische caching gebruikt inbeddingsovereenkomst om eerder gegenereerde antwoorden te retourneren voor "vergelijkbare" vragen -- sneller maar kan foute antwoorden geven. Antwoord-caching slaat exacte invoer-uitvoerparen op en retourneert het gecachte antwoord letterlijk -- werkt alleen voor volledig identieke verzoeken.

Prompt caching is de enige "gratis optimalisatie" -- het reduceert kosten en latentie zonder enig nauwkeurigheidsverlies. Voor de diepgaande transformerwiskunde achter KV-caching heeft Hugging Face's technische uitleg een ~5,21x versnelling gemeten op T4-GPU's.

Hoe Behandelt OpenAI Prompt Caching?

OpenAI's prompt caching is volledig automatisch. Sinds oktober 2024 profiteert elke API-aanroep met 1.024+ invoertokens automatisch van caching. Geen opt-in, geen headers, geen codewijzigingen.

Hoe OpenAI's Automatische Caching Werkt

Wanneer je een verzoek verzendt met minimaal 1.024 tokens, controleert OpenAI of het prefix overeenkomt met een recent verzoek van je organisatie. Cache-treffers kosten 50% van de standaard invoertokenprijs. Na de initiële drempel van 1.024 tokens matcht de cache in stappen van 128 tokens.

De cache is 5-10 minuten actief tijdens normaal gebruik en kan tot 24 uur aanhouden tijdens rustige periodes. De cache is per organisatie afgebakend, zodat verschillende projecten binnen dezelfde organisatie van gedeelde caches profiteren.

Ondersteunde modellen zijn GPT-4o, GPT-4o-mini, GPT-4.1, o1, o3-mini en alle nieuwere modellen.

OpenAI Python SDK Voorbeeld

from openai import OpenAI

client = OpenAI()

# Deze systeemprompt heeft ~2.000 tokens -- ruim boven het minimum van 1.024
SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": user_message},
        ],
    )

    # Controleer of caching is geactiveerd
    usage = response.usage
    cached = usage.prompt_tokens_details.cached_tokens
    total_input = usage.prompt_tokens
    print(f"Cached: {cached}/{total_input} tokens ({cached/total_input*100:.0f}%)")

    return response.choices[0].message.content

# Eerste aanroep: cache-miss (volle prijs)
chat("Review this async function for race conditions...")

# Tweede aanroep binnen 5-10 min: cache-treffer (50% korting op gecachte tokens)
chat("Now optimize the same function for throughput...")

De eerste aanroep verwerkt alles tegen de volle prijs en vult de cache. De tweede aanroep hergebruikt de gecachte systeemprompt-tokens voor de halve prijs. Je ziet dan zoiets als Cached: 1920/2048 tokens (94%) in de uitvoer.

Conclusie: OpenAI is het eenvoudigst om mee te beginnen -- nul configuratie, caching gebeurt gewoon. De korting van 50% is de laagste van de drie providers, maar de eenvoud is ongeëvenaard.

Hoe Behandelt Anthropic/Claude Prompt Caching?

Anthropic biedt twee modi: automatische caching (standaard ingeschakeld sinds februari 2026) en expliciete caching met cache_control-breekpunten. Het headlinecijfer is moeilijk te negeren -- gecachte lezingen kosten slechts 10% van de standaard invoerprijs, een korting van 90%.

Automatische vs Expliciete Caching (Update 2026)

Per 5 februari 2026 schakelt Anthropic automatische caching standaard in voor alle geschikte prompts. Je hebt de oude bèta-header niet meer nodig. Het systeem bepaalt automatisch optimale cache-breekpunten.

Expliciete caching is nog steeds beschikbaar wanneer je fijnmazige controle wilt. Je plaatst cache_control: {"type": "ephemeral"} op specifieke inhoudsblokken om precies aan te geven waar de cachegrens moet liggen. Dit is nuttig wanneer je prompt een specifieke structuur heeft en je wilt garanderen dat bepaalde secties worden gecacht.

Er zijn twee TTL-opties:

• 5-minuten-cache (standaard): schrijfkosten 1,25x basisinvoerprijs, leeskosten 0,1x. Terugverdient na 1 cache-treffer.
• 1-uur-cache: schrijfkosten 2x basisinvoerprijs, leeskosten 0,1x. Terugverdient na 2 cache-treffers. Beschikbaar op Claude 4.5+-modellen.

Cache-isolatie veranderde op 5 februari 2026 van organisatieniveau naar werkruimteniveau. Dit betekent dat verschillende werkruimten binnen dezelfde organisatie afzonderlijke caches bijhouden.

Wanneer je werkt met Anthropic's caching, helpt het om je prompt te structureren voor optimale caching -- statische inhoud vóór dynamische inhoud plaatsen is hier nog belangrijker omdat je een schrijftoeslag betaalt.

Anthropic Python SDK Voorbeeld

import anthropic

client = anthropic.Anthropic()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

def chat(user_message: str) -> str:
    response = client.messages.create(
        model="claude-sonnet-4-5-20250514",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},  # Expliciet breekpunt
            }
        ],
        messages=[
            {"role": "user", "content": user_message},
        ],
    )

    # Lees cache-metriek uit de respons
    usage = response.usage
    created = usage.cache_creation_input_tokens
    read = usage.cache_read_input_tokens
    standard = usage.input_tokens
    print(f"Cache write: {created}, Cache read: {read}, Standard: {standard}")

    return response.content[0].text

# Eerste aanroep: cache_creation_input_tokens = ~1920 (schrijven bij 1,25x)
chat("Review this async function for race conditions...")

# Tweede aanroep: cache_read_input_tokens = ~1920 (lezen bij 0,1x -- 90% korting!)
chat("Now optimize the same function for throughput...")

Prijsstelling Cache-schrijven vs Cache-lezen Begrijpen

Hier wordt Anthropic's prijsstelling interessant. Met Claude Sonnet 4.5 ($3/MTok basisinvoer) als voorbeeld:

• Standaardinvoer: $3,00 per miljoen tokens
• Cache-schrijven (5 min): $3,75 per miljoen tokens (1,25x) -- je betaalt de eerste keer meer
• Cache-lezen: $0,30 per miljoen tokens (0,1x) -- 90% goedkoper bij elke volgende treffer

De 5-minuten-cache verdient zichzelf terug na slechts 1 lezing. De 1-uur-cache ($6,00/MTok schrijven) verdient zichzelf terug na 2 lezingen. Als je meer dan een paar verzoeken per minuut doet met hetzelfde prefix, staat de rekensommet overweldigend in jouw voordeel.

Conclusie: Anthropic biedt de diepste korting (90%) en de meeste controle. Ideaal voor grote volumes en kostengevoelige workloads.

Hoe Behandelt Google Gemini Prompt Caching?

Gemini neemt een andere aanpak met twee afzonderlijke caching-mechanismen: expliciete contextcaching (benoemde cache-objecten die je aanmaakt en raadpleegt) en impliciete caching (automatisch, nul configuratie, toegevoegd in 2026 voor Gemini 2.5+-modellen).

Expliciete Contextcaching (Benoemde Caches)

In tegenstelling tot OpenAI en Anthropic waar caching transparant is, vereist Gemini's expliciete caching dat je eerst een benoemd cache-object aanmaakt en het vervolgens in opvolgende verzoeken raadpleegt. De minimale tokendrempel is 1.024 tokens voor Gemini Flash-modellen en 4.096 tokens voor Pro-modellen. TTL is configureerbaar -- standaard is 1 uur, maar je kunt het instellen op wat je nodig hebt.

Gecachte tokens op Gemini 2.5 Pro zijn geprijsd op $0,125/MTok versus de standaard invoerprijs van $1,25/MTok -- een korting van 90%. Er zijn ook opslagkosten van $4,50 per miljoen tokens per uur voor Pro, en $1,00 voor Flash.

Impliciete Caching in Gemini 2.5 (2026)

Vanaf Gemini 2.5 Pro en Flash heeft Google impliciete caching toegevoegd -- automatische caching die werkt zoals OpenAI's aanpak. Geen configuratie nodig. Plaats grote, gemeenschappelijke inhoud aan het begin van je prompt en verstuur verzoeken met vergelijkbare prefiksen in snelle opeenvolging. Het systeem detecteert automatisch cache-geschikte inhoud en geeft de besparingen door.

Gemini Python SDK Voorbeeld

from google import genai
from google.genai import types

client = genai.Client()

SYSTEM_PROMPT = """You are a senior Python developer specializing in async programming.
You follow PEP 8, use type hints, and write comprehensive docstrings.
When reviewing code, check for: race conditions, resource leaks, error handling,
and performance bottlenecks. Always suggest specific fixes with code examples.
[... imagine 1,800 more tokens of coding guidelines, examples, and rules ...]"""

# Stap 1: Benoemd cache-object aanmaken
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        display_name="python-review-guidelines",
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",  # 1 uur
    ),
)

print(f"Cache created: {cache.name}, expires: {cache.expire_time}")

# Stap 2: Cache gebruiken in verzoeken
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Review this async function for race conditions...",
    config=types.GenerateContentConfig(
        cached_content=cache.name,
    ),
)

# Cache-gebruik in de respons controleren
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")

De expliciete aanpak heeft één groot voordeel: je beheert de TTL nauwkeurig. Als je weet dat je batchjob 4 uur duurt, stel dan een TTL van 4 uur in en voorkom cache-verlopen midden in de verwerking.

Conclusie: Gemini's configureerbare TTL en twee caching-modi (expliciet + impliciet) maken het veelzijdig. De minimale drempel is nu vergelijkbaar met andere providers, en de korting van 90% op gecachte lezingen komt overeen met Anthropic.

Code-vergelijking Naast Elkaar -- Hetzelfde Gebruik, Alle 3 Providers

Hier is dezelfde chatbot met een gecachte systeemprompt, geïmplementeerd in alle drie SDK's. Vergelijk de ontwikkelaarservaring direct.

# --- OpenAI: Nul configuratie, roep gewoon de API aan ---
from openai import OpenAI
client = OpenAI()

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},  # Automatisch gecacht
        {"role": "user", "content": user_message},
    ],
)
cached = response.usage.prompt_tokens_details.cached_tokens

# --- Anthropic: Expliciet cache_control breekpunt ---
import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},  # Cachegrens markeren
    }],
    messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens

# --- Gemini: Benoemd cache-object ---
from google import genai
from google.genai import types

client = genai.Client()
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",
    ),
)
response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=user_message,
    config=types.GenerateContentConfig(cached_content=cache.name),
)
cached = response.usage_metadata.cached_content_token_count

Als je moeiteloze besparingen wilt, kies OpenAI. Als je de diepste korting en fijnmazige controle wilt, kies Anthropic. Als je configureerbare cache-levensduren nodig hebt of al op Google Cloud werkt, kies Gemini.

Productiekostencalculator -- Echte Besparingen op Schaal

Abstracte percentages sturen geen beslissingen. Bedragen in euro's wel. Hier zijn drie productiescenario's met echte kostenschattingen met Claude Sonnet 4.5 ($3/MTok invoer), GPT-4o ($2,50/MTok invoer) en Gemini 2.5 Pro ($1,25/MTok invoer).

Prijzen geverifieerd maart 2026. Controleer Anthropic, OpenAI en Gemini voor actuele tarieven.

Aannames: 80% cache-trefferpercentage (realistisch voor goed gestructureerde prompts), uitvoertokens uitgesloten omdat caching alleen invoerkosten beïnvloedt.

Op Growth-niveau bespaart Anthropic-caching $576/maand ondanks een hogere basisprijs dan OpenAI. Op Enterprise-schaal kijk je naar $7.200/maand besparingen met Anthropic -- of $86.400 per jaar. Dat is het salaris van een senior-engineer dat bespaard wordt door een configuratiewijziging.

Het patroon is duidelijk: hoe hoger je verzoekvolume en hoe langer je statische prefix, hoe meer caching bespaart. Anthropic's korting van 90% domineert op schaal, maar Gemini's lagere basisprijs maakt het concurrerend als je de totale kosten meerekent.

Prompt Caching Anti-Patronen -- Wanneer NIET te Cachen

Caching lijkt eenvoudig totdat je cache-trefferpercentage mysterieus op 0% staat. Hier zijn de fouten die prompt caching stil vernietigen -- en hoe ze te verhelpen.

Cache-vernietigende Fouten (Met Oplossingen)

Tijdstempels in systeemprompts -- De meest voorkomende fout. Als je systeemprompt datetime.now() bevat, verandert de cachesleutel elke seconde.

# SLECHT: Cache-missers bij elk verzoek
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""

# GOED: Tijdstempel naar het gebruikersbericht verplaatsen
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""

user_message = f"[Current time: {datetime.now().isoformat()}]\n{user_query}"

Gebruikersspecifieke inhoud vóór statische inhoud -- Als je session_id of gebruikersvoorkeuren aan het begin plaatst, krijgt elke gebruiker een uniek prefix.

# SLECHT: Uniek prefix per gebruiker = nul cache-hergebruik
messages = [
    {"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
    {"role": "user", "content": query},
]

# GOED: Statische inhoud eerst, gebruikerscontext aan het einde
messages = [
    {"role": "system", "content": GUIDELINES},  # Hetzelfde voor alle gebruikers -> gecacht
    {"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]

Wanneer Prompt Caching Werkelijk Niet Helpt

Sommige scenario's profiteren niet van caching zelfs als je je prompts perfect structureert:

• Eenmalige prompts: Als elk verzoek een volledig unieke context heeft zonder gedeeld prefix, valt er niets te cachen.
• Zeer korte prompts: Onder 1.024 tokens (OpenAI/Anthropic) of 4.096 tokens (Gemini Pro) activeer je geen caching.
• Onregelmatige verzoeken: Als verzoeken uren van elkaar liggen, verloopt de cache voordat een tweede verzoek aankomt. OpenAI's 5-10-minuten-venster en Anthropic's standaard-TTL van 5 minuten betekenen dat je consistent verkeer nodig hebt.

Werkt Prompt Caching Met Streaming?

Ja. Prompt caching en streaming zijn onafhankelijk -- caching werkt op invoertokens, streaming beïnvloedt de uitvoerlevering. Ze lossen verschillende problemen op in verschillende stadia van de aanvraaglevenscyclus.

De cache behandelt de prefill-fase (verwerking van je invoerprompt). Streaming behandelt de decode-fase (inkrementeel genereren en verzenden van uitvoertokens). Je profiteert van beide voordelen tegelijk: snellere prefill door de cache-treffer, plus progressieve uitvoerlevering door streaming.

Hier is een streaming-voorbeeld met ingeschakelde caching:

import anthropic

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system=[{
        "type": "text",
        "text": SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},
    }],
    messages=[{"role": "user", "content": "Explain Python's GIL..."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    # Na streaming, cache-metriek controleren
    usage = stream.get_final_message().usage
    print(f"\nCache read: {usage.cache_read_input_tokens} tokens")

De TTFT-verbetering door caching is eigenlijk het meest merkbaar met streaming. Zonder caching wacht je op de volledige prefill voordat het eerste token wordt teruggestreamd. Met caching is de prefill bijna onmiddellijk, waardoor tokens vrijwel direct beginnen te stromen.

Cache-trefferpercentages Monitoren in Productie

Caching instellen is de helft van het werk. Weten of het daadwerkelijk werkt is de andere helft. Als je cache-trefferpercentage onder 50% valt, is er iets veranderd in je promptstructuur en laat je geld op tafel liggen.

Provider-specifieke Cache-metriek

Een Eenvoudige Cache-trefferpercentage Logger

Hier is een hulpfunctie die je in elk project kunt gebruiken om cache-trefferpercentages via API-responsvelden bij te houden:

import logging

logger = logging.getLogger("cache_monitor")

def log_cache_metrics(provider: str, usage: dict) -> float:
    """Extraheert en logt cache-metriek uit de respons van een provider. Geeft trefferpercentage terug."""

    if provider == "openai":
        cached = getattr(usage.prompt_tokens_details, "cached_tokens", 0)
        total = usage.prompt_tokens
    elif provider == "anthropic":
        cached = usage.cache_read_input_tokens
        created = usage.cache_creation_input_tokens
        total = cached + created + usage.input_tokens
    elif provider == "gemini":
        cached = getattr(usage, "cached_content_token_count", 0)
        total = usage.prompt_token_count
    else:
        raise ValueError(f"Unknown provider: {provider}")

    hit_rate = (cached / total * 100) if total > 0 else 0
    logger.info(f"[{provider}] Cache hit rate: {hit_rate:.1f}% ({cached}/{total} tokens)")

    if hit_rate < 50:
        logger.warning(f"[{provider}] Low cache hit rate! Check prompt structure.")

    return hit_rate

Een gezond productiesysteem moet 70-90% cache-trefferpercentages aanhouden. Als je onder 50% zit, raadpleeg dan de anti-patronen-sectie opnieuw. Je kunt dit ook integreren met geautomatiseerde evaluatiemetriek om regressies in je promptpipeline te detecteren.

Prompt Caching in Echte Gebruikssituaties

De chatbot-voorbeelden hierboven illustreren de mechanismen, maar prompt caching blinkt echt uit in specifieke architectuurpatronen.

RAG-pipelines

In een RAG-setup zijn je systeemprompt en few-shot-voorbeelden statisch voor alle vragen. De opgehaalde documenten veranderen elke keer. Structureer je prompt om het gecachte prefix te maximaliseren:

1. Systeemprompt (gecacht)
2. Few-shot-voorbeelden (gecacht)
3. Opgehaalde documenten (dynamisch -- komt als laatste)
4. Gebruikersvraag (altijd uniek)

Met een systeemprompt van 5.000 tokens en 3.000 tokens few-shot-voorbeelden zijn dat 8.000 gecachte tokens bij elk verzoek. Bij 1.000 verzoeken/dag op Anthropic bespaar je ruwweg $6,50/dag alleen al op het gecachte prefix. Wanneer je contextblokken ophaalt en cachet, zorg ervoor dat de ophaaluitvoer na het statische prefix komt.

Multi-beurt Chatbots

Multi-beurt gesprekken zijn een goed geval voor prompt caching. Elke beurt voegt toe aan de gespreksgeschiedenis, maar het volledige vorige gesprek is al gecacht van eerdere beurten. Het cache-voordeel groeit -- bij beurt 10 heb je mogelijk 15.000 tokens gecachte geschiedenis met slechts 200 verse tokens van het laatste gebruikersbericht.

Agentische Systemen en MCP Tooldefinities

Als je agenten bouwt met toolgebruik, zijn je tooldefinities statische JSON-schema's die bij elke API-aanroep worden herhaald. Een typische agent kan 20+ tools hebben met in totaal 3.000-5.000 tokens aan definities. Dat is uitstekend materiaal voor caching.

Dit is bijzonder relevant voor MCP-gebaseerde architecturen waar servertooldefinities bij elke aanroep worden verzonden. Met Anthropic's expliciete cache_control kun je de tools-array markeren voor caching en garanderen dat die tokens worden hergebruikt.

Welke Provider Moet Je Kiezen?

Als je al een provider gebruikt, begin daar -- prompt caching vereist geen overstap. LiteLLM fungeert als proxy-laag die caching-parameters over providers heen normaliseert, wat handig is als je verzoeken naar meerdere modellen routeert.

FAQ -- LLM Prompt Caching

Wat is prompt caching in LLM's?

Prompt caching slaat de berekende aandachtstoestanden (KV-cache) op van eerder verwerkte promptprefiksen. Wanneer een volgend verzoek met dezelfde tokenreeks begint, hergebruikt de provider die opgeslagen toestanden in plaats van ze opnieuw te berekenen -- waardoor zowel kosten als latentie worden verminderd zonder impact op de uitvoerkwaliteit.

Hoeveel bespaart prompt caching op API-kosten?

Besparingen variëren van 50% tot 90% afhankelijk van de provider. OpenAI biedt 50% korting op gecachte invoertokens. Anthropic biedt tot 90% korting (gecachte lezingen tegen 0,1x basisprijs). Gemini biedt circa 90% korting op gecachte lezingen. Werkelijke besparingen zijn afhankelijk van je cache-trefferpercentage, promptlengte en verzoekfrequentie.

Gebeurt OpenAI prompt caching automatisch?

Ja, sinds oktober 2024. Elke API-aanroep met 1.024+ invoertokens profiteert automatisch van caching. Geen opt-in, geen headers, geen codewijzigingen vereist. De cache matcht tokenprefiksen vanaf het begin van de prompt.

Wat is het verschil tussen prompt caching en semantische caching?

Prompt caching matcht exacte tokenprefiksen op GPU-niveau -- er is geen nauwkeurigheidsverlies, en uitvoer is identiek aan niet-gecachte verzoeken. Semantische caching gebruikt inbeddingsovereenkomst om "dichtbij genoeg" eerdere vragen te vinden en gecachte antwoorden te retourneren -- het is sneller maar kan onjuiste of verouderde antwoorden teruggeven. Ze lossen fundamenteel verschillende problemen op.

Hoe lang duurt de promptcache?

Dit varieert per provider. OpenAI: 5-10 minuten (tot 24 uur met verlengde bewaring). Anthropic: 5 minuten (standaard) of 1 uur (beschikbaar op Claude 4.5+-modellen, kost 2x schrijven). Gemini: configureerbaar, standaard 1 uur voor expliciete caches. Impliciete caching-TTL wordt automatisch beheerd door Google.

Wat is de minimale tokenlengte voor prompt caching?

OpenAI: 1.024 tokens. Anthropic: 1.024 tokens voor de meeste huidige modellen. Gemini: 1.024 tokens voor Flash-modellen, 4.096 voor Pro-modellen. Prompts onder deze drempels activeren geen caching -- dit is de meest voorkomende "het werkt niet"-valkuil.

Werkt prompt caching met streaming-antwoorden?

Ja. Caching en streaming werken in verschillende fasen van het verzoek. Caching versnelt de invoer-prefill-fase; streaming levert uitvoertokens inkrementeel. Beide werken gelijktijdig, en je merkt de TTFT-verbetering feitelijk meer met ingeschakelde streaming.

Wanneer moet ik prompt caching NIET gebruiken?

Verlaat je niet op caching wanneer je prompts onder de minimale tokendrempel zitten, wanneer je tijdstempels of sessie-ID's in de systeemprompt opneemt, wanneer je few-shot-voorbeelden tussen aanroepen roteert, of wanneer verzoeken te onregelmatig zijn om de cache vóór zijn verlopen te treffen (5-10-minuten-venster voor OpenAI/Anthropic).

Kan ik prompt caching gebruiken met LangChain of LiteLLM?

Ja. LangChain geeft provider-specifieke caching-parameters door via zijn API-wrappers. LiteLLM biedt een uniforme caching-syntaxis die cache_control normaliseert voor Anthropic, OpenAI, Gemini, Vertex AI en Bedrock -- met name nuttig voor multi-provider-setups.

Wat is een cache-treffer versus cache-misser?

Een cache-treffer betekent dat de provider een overeenkomend prefix in het geheugen heeft gevonden en de opgeslagen KV-toestanden heeft hergebruikt -- je betaalt het verlaagde gecachte tokentarief en krijgt een snellere TTFT. Een cache-misser betekent dat er geen overeenkomst werd gevonden, waardoor de volledige prompt vanaf het begin wordt verwerkt tegen standaardprijzen. Controleer de velden cached_tokens (OpenAI), cache_read_input_tokens (Anthropic) of cachedContentTokenCount (Gemini) in de API-respons om te zien wat er is opgetreden.

Eindoordeel

Prompt caching is de minst-inspannende, hoogst-renderende optimalisatie in de LLM-API-stack. Je verandert je model niet, je offert geen kwaliteit op, en de implementatie varieert van "niets doen" (OpenAI) tot "één veld toevoegen" (Anthropic) tot "een cache-object aanmaken" (Gemini).

Begin met de automatische caching van je huidige provider. Meet je cache-trefferpercentage met het bovenstaande logging-hulpprogramma. Als je onder 70% zit, herstructureer dan je prompts (statisch eerst, dynamisch als laatste) en elimineer de anti-patronen. De meeste teams zien 50-80% kostenreductie binnen een dag na het implementeren van deze wijzigingen.

Bronnen

• Anthropic Prompt Caching Documentation
• OpenAI Prompt Caching Guide
• Gemini Context Caching Documentation
• Anthropic Model Pricing
• Gemini API Pricing
• KV Caching Explained -- Hugging Face Blog
• LiteLLM Prompt Caching Documentation