LLM Prompt-caching: Skær API-omkostningerne med 90% (alle 3 udbydere)

LLM Prompt-caching: Skær API-omkostningerne med 90% (alle 3 udbydere)

LLM prompt-caching giver dig mulighed for at genbruge tidligere behandlede tokens på tværs af API-kald, hvilket skærer inputomkostningerne med op til 90% og reducerer tiden til første token (time-to-first-token) med op til 85%. Hvis du sender den samme systemprompt, værktøjsdefinitioner eller few-shot eksempler ved hver anmodning, betaler du fuld pris for arbejde, som GPU'en allerede har udført.

Denne guide dækker OpenAI, Anthropic og Gemini med den samme chatbot implementeret i alle tre SDK'er – noget ingen anden guide gør. Vi vil også se på Anthropic's automatiske caching-opdatering fra februar 2026, produktionsomkostningsscenarier med reelle dollarbeløb og de anti-mønstre, der stille og roligt ødelægger din cache-hitrate.

Hurtigt overblik: Alle tre udbydere ved et blik

Før vi dykker ned i implementeringsdetaljer, får du her den fulde sammenligning. Hvis du allerede ved, hvilken udbyder du bruger, kan du springe direkte til deres afsnit. Hvis du evaluerer mulighederne, fortæller denne tabel dig alt på 10 sekunder.

Vigtigste pointe: OpenAI er den enkleste (nul konfiguration, 50% rabat). Anthropic giver den dybeste rabat (90%) med mest kontrol. Gemini tilbyder konfigurerbar TTL og implicit caching på 2.5+ modeller med rabatter, der kan måle sig med Anthropic.

Hvordan fungerer LLM prompt-caching?

Du behøver ikke at forstå transformer-internals for at bruge prompt-caching effektivt. Men du skal forstå ét begreb: præfiks-matchning.

KV-cachen på 60 sekunder

Når en LLM behandler din prompt, beregner den attention-states (key-value-par) for hvert token. Disse KV-cache-poster er den dyre del; det er dem, der æder GPU-hukommelse og beregningstid. Prompt-caching gemmer disse beregnede states, så den næste anmodning med samme præfiks helt undgår genberegning.

Det afgørende ord er præfiks. Cachen matcher fra begyndelsen af din prompt og fremad. Hvis de første 2.000 tokens matcher en cachelagret post, men token 2.001 er anderledes, serveres de første 2.000 tokens fra cachen. Alt efter divergenspunktet beregnes friskt.

Det er derfor, rækkefølgen af prompts betyder noget. Strukturér dine prompts sådan her:

1. Værktøjsdefinitioner (mest statiske)
2. Systemprompt
3. Statiske few-shot eksempler
4. Hentet kontekst (semi-dynamisk)
5. Samtalehistorik (vokser per tur)
6. Brugerforespørgsel (altid forskellig)

Statisk indhold først, dynamisk indhold sidst. Jo flere tokens der matcher det cachelagrede præfiks, desto større bliver dine besparelser.

Prompt-caching vs. Semantisk caching vs. Respons-caching

Disse tre begreber bliver ofte forvekslet. Prompt-caching (som denne guide dækker) genbruger beregnede KV-states på GPU-niveau for identiske token-præfikser, uden tab af nøjagtighed og med samme output som uncached. Semantisk caching bruger embedding-lighed til at returnere tidligere genererede svar for "tilstrækkeligt lignende" forespørgsler; det er hurtigere, men kan returnere forkerte svar. Respons-caching gemmer eksakte input-output-par og returnerer det cachelagrede svar ordret; det virker kun for virkelig identiske anmodninger.

Prompt-caching er den eneste "gratis optimering"; det reducerer omkostninger og latens uden nogen trade-off i nøjagtighed. For den dybe transformer-matematik bag KV-caching målte Hugging Face's tekniske forklaring en hastighedsforøgelse på ~5,21x på T4-GPU'er.

Hvordan håndterer OpenAI prompt-caching?

OpenAI's prompt-caching er fuldt automatisk. Siden oktober 2024 drager ethvert API-kald med 1.024+ input-tokens automatisk fordel af caching. Du skal ikke tilmelde dig, du skal ikke tilføje headers, og du skal ikke ændre din kode.

Hvordan OpenAI's automatiske caching fungerer

Når du sender en anmodning med mindst 1.024 tokens, tjekker OpenAI, om præfikset matcher en nylig anmodning fra din organisation. Cache-hits koster 50% af standardprisen for input-tokens. Efter den indledende tærskel på 1.024 tokens matcher cachen i intervaller på 128 tokens.

Cachen lever i 5-10 minutter under normal brug og kan persistere i op til 24 timer med udvidet opbevaring i perioder med lav belastning. Den er scoped per organisation, så forskellige projekter inden for samme org kan drage fordel af delte caches.

Understøttede modeller inkluderer GPT-4o, GPT-4o-mini, GPT-4.1, o1, o3-mini og alle nyere modeller.

Eksempel med OpenAI Python SDK

from openai import OpenAI

client = OpenAI()

# This system prompt is ~2,000 tokens -- well above the 1,024 minimum
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},
        ],
    )

    # Check if caching kicked in
    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

# First call: cache miss (full price)
chat("Review this async function for race conditions...")

# Second call within 5-10 min: cache hit (50% off on cached tokens)
chat("Now optimize the same function for throughput...")

Det første kald behandler alt til fuld pris og befolker cachen. Det andet kald genbruger de cachelagrede systemprompt-tokens til halv pris. Du vil se noget lignende Cached: 1920/2048 tokens (94%) i outputtet.

Konklusion: OpenAI er nemmest at komme i gang med, nul konfiguration, caching sker bare. De 50% rabat er den laveste af de tre udbydere, men du kan ikke slå enkelheden.

Hvordan håndterer Anthropic/Claude prompt-caching?

Anthropic tilbyder to tilstande: automatisk caching (aktiveret som standard siden februar 2026) og eksplicit caching med cache_control brydepunkter. Overskriftstallet er svært at ignorere: cachelagrede læsninger koster kun 10% af standard input-prisen, hvilket er en rabat på 90%.

Automatisk vs. eksplicit caching (2026-opdatering)

Pr. 5. februar 2026 aktiverer Anthropic automatisk caching som standard for alle berettigede prompts. Du behøver ikke længere den gamle beta-header. Systemet bestemmer optimale cache-brydepunkter automatisk.

Eksplicit caching er stadig tilgængelig, når du ønsker finmasket kontrol. Du placerer cache_control: {"type": "ephemeral"} på specifikke indholdsblokke for at markere præcis, hvor cachegrænsen skal være. Dette er nyttigt, når din prompt har en specifik struktur, og du vil garantere, at visse sektioner cachelagres.

Der findes to TTL-muligheder:

• 5-minutters cache (standard): skrivninger koster 1,25x basis input-pris, læsninger koster 0,1x. Betaler sig selv efter 1 cache-hit.
• 1-times cache: skrivninger koster 2x basis input-pris, læsninger koster 0,1x. Betaler sig selv efter 2 cache-hits. Tilgængelig på Claude 4.5+ modeller.

Cache-isoleringen ændredes fra organisationsniveau til workspace-niveau den 5. februar 2026. Det betyder, at forskellige workspaces inden for samme organisation vedligeholder separate caches.

Når du arbejder med Anthropic's caching, hjælper det at strukturere din prompt for optimal caching; at placere statisk indhold før dynamisk indhold er endnu vigtigere her, da du betaler en præmie for skrivning.

Eksempel med Anthropic Python SDK

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"},  # Explicit breakpoint
            }
        ],
        messages=[
            {"role": "user", "content": user_message},
        ],
    )

    # Read cache metrics from the response
    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

# First call: cache_creation_input_tokens = ~1920 (write at 1.25x)
chat("Review this async function for race conditions...")

# Second call: cache_read_input_tokens = ~1920 (read at 0.1x -- 90% off!)
chat("Now optimize the same function for throughput...")

Forståelse af prissætning for cache-skrivning vs. cache-læsning

Her bliver Anthropic's prissætning interessant. Ved brug af Claude Sonnet 4.5 ($3/MTok basis input) som eksempel:

• Standard input: $3,00 per million tokens
• Cache-skrivning (5-min): $3,75 per million tokens (1,25x), du betaler mere første gang
• Cache-læsning: $0,30 per million tokens (0,1x) -- 90% billigere ved hvert efterfølgende hit

5-minutters cachen betaler sig selv efter blot 1 læsning. 1-times cachen ($6,00/MTok skrivning) betaler sig selv efter 2 læsninger. Hvis du laver mere end et par anmodninger i minuttet med samme præfiks, er matematikken overvældende til din fordel.

Konklusion: Anthropic giver den dybeste rabat (90%) og mest kontrol. Bedst til højt volumen, omkostningsfølsomme workload.

Hvordan håndterer Google Gemini prompt-caching?

Gemini tager en anden tilgang med to distinkte caching-mekanismer: eksplicit kontekstcaching (navngivne cache-objekter, du opretter og refererer til) og implicit caching (automatisk, nul-konfiguration, tilføjet i 2026 til Gemini 2.5+ modeller).

Eksplicit kontekstcaching (Navngivne caches)

I modsætning til OpenAI og Anthropic, hvor caching er transparent, kræver Gemini's eksplicitte caching, at du først opretter et navngivet cache-objekt og derefter refererer til det i efterfølgende anmodninger. Minimumstærsklen for tokens er 1.024 tokens for Gemini Flash-modeller og 4.096 tokens for Pro-modeller. TTL er konfigurerbar, standarden er 1 time, men du kan sætte den til, hvad du har brug for.

Cachelagrede tokens på Gemini 2.5 Pro prissættes til $0,125/MTok mod standard input-prisen på $1,25/MTok, hvilket er en rabat på 90%. Der er også en opbevaringsomkostning på $4,50 per million tokens per time for Pro og $1,00 for Flash.

Implicit caching i Gemini 2.5 (2026)

Startende med Gemini 2.5 Pro og Flash tilføjede Google implicit caching, automatisk caching, der fungerer ligesom OpenAI's tilgang. Ingen konfiguration nødvendig. Placer stort, fælles indhold i begyndelsen af din prompt og send anmodninger med lignende præfikser i hurtig succession. Systemet registrerer automatisk cache-berettiget indhold og videregiver besparelserne.

Eksempel med Gemini Python SDK

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 ...]"""

# Step 1: Create a named cache object
cache = client.caches.create(
    model="gemini-2.5-flash",
    config=types.CreateCachedContentConfig(
        display_name="python-review-guidelines",
        system_instruction=SYSTEM_PROMPT,
        ttl="3600s",  # 1 hour
    ),
)

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

# Step 2: Use the cache in requests
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,
    ),
)

# Check cache usage in the response
metadata = response.usage_metadata
print(f"Cached tokens: {metadata.cached_content_token_count}")
print(f"Total input tokens: {metadata.prompt_token_count}")

Den eksplicitte tilgang har én stor fordel: du kontrollerer TTL'en præcist. Hvis du ved, at dit batch-job kører i 4 timer, kan du sætte en 4-timers TTL og undgå cache-udløb midt i behandlingen.

Konklusion: Gemini's konfigurerbare TTL og dobbelte caching-tilstande (eksplicit + implicit) gør det alsidigt. Minimumstærsklen er nu sammenlignelig med andre udbydere, og de 90% rabat på cachelagrede læsninger matcher Anthropic.

Kode-sammenligning side om side, samme use case, alle 3 udbydere

Her er den samme chatbot med en cachelagret systemprompt, implementeret i alle tre SDK'er. Sammenlign developer experience direkte.

# --- OpenAI: Zero config, just call the API ---
from openai import OpenAI
client = OpenAI()

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

# --- Anthropic: Explicit cache_control breakpoint ---
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"},  # Mark cache boundary
    }],
    messages=[{"role": "user", "content": user_message}],
)
cached = response.usage.cache_read_input_tokens

# --- Gemini: Named 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

Hvis du vil have besparelser uden indsats, skal du vælge OpenAI. Hvis du vil have den dybeste rabat og finmasket kontrol, skal du vælge Anthropic. Hvis du har brug for konfigurerbare cache-levetider, eller hvis du allerede er på Google Cloud, skal du vælge Gemini.

Produktionsomkostningsberegner, reelle besparelser i stor skala

Abstrakte procenter driver ikke beslutninger. Dollarbeløb gør. Her er tre produktionsscenarier med reelle omkostningsestimater ved brug af Claude Sonnet 4.5 ($3/MTok input), GPT-4o ($2,50/MTok input) og Gemini 2.5 Pro ($1,25/MTok input).

Priser verificeret marts 2026. Tjek Anthropic priser, OpenAI priser og Gemini priser for aktuelle satser.

Antagelser: 80% cache-hitrate (realistisk for velstrukturerede prompts), output-tokens ekskluderet, da caching kun påvirker inputomkostninger.

På Growth-niveauet sparer Anthropic caching $576/måned på trods af en højere basispris end OpenAI. På Enterprise-niveau ser du $7.200/måned i besparelser med Anthropic, eller $86.400 om året. Det svarer til lønnen for en senior ingeniør, sparet gennem en konfigurationsændring.

Mønsteret er klart: jo højere dit anmodningsvolumen og jo længere dit statiske præfiks er, desto mere sparer caching. Anthropic's 90% rabat dominerer i stor skala, men Gemini's lavere basispris gør det konkurrencedygtigt, når man ser på de samlede omkostninger.

Anti-mønstre for prompt-caching, hvornår man IKKE skal cache

Caching virker simpelt, indtil din cache-hitrate mystisk ligger på 0%. Her er fejlene, der stille og roligt ødelægger prompt-caching, og hvordan du retter dem.

Cache-ødelæggende fejl (med løsninger)

Tidsstempler i systemprompts, Den mest almindelige fejl. Hvis din systemprompt indeholder datetime.now(), ændres cache-nøglen hvert sekund.

# BAD: Cache misses every single request
system_prompt = f"""You are a helpful assistant.
Current time: {datetime.now().isoformat()}
Always be helpful and accurate."""

# GOOD: Move the timestamp to the user message
system_prompt = """You are a helpful assistant.
Always be helpful and accurate."""

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

Brugerspecifikt indhold før statisk indhold, Hvis du placerer session_id eller brugerpræferencer i starten, får hver bruger et unikt præfiks.

# BAD: Unique prefix per user = zero cache reuse
messages = [
    {"role": "system", "content": f"User ID: {user_id}\nPreferences: {prefs}\n{GUIDELINES}"},
    {"role": "user", "content": query},
]

# GOOD: Static content first, user context at the end
messages = [
    {"role": "system", "content": GUIDELINES},  # Same for all users -> cached
    {"role": "user", "content": f"Context: User {user_id}, prefs: {prefs}\n{query}"},
]

Hvornår prompt-caching genuint ikke hjælper

Nogle scenarier vil ikke drage fordel af caching, selvom du strukturerer dine prompts perfekt:

• Engangs-prompts: Hvis hver anmodning har en helt unik kontekst og intet delt præfiks, er der intet at cache.
• Meget korte prompts: Under 1.024 tokens (OpenAI/Anthropic) eller 4.096 tokens (Gemini Pro) aktiveres caching ikke.
• Sjældne anmodninger: Hvis anmodninger er timer fra hinanden, udløber cachen, før en anden anmodning ankommer. OpenAI's 5-10 minutters vindue og Anthropic's standard-TTL på 5 minutter betyder, at du har brug for konsistent trafik.

Virker prompt-caching med streaming?

Ja. Prompt-caching og streaming er uafhængige; caching opererer på input-tokens, streaming påvirker output-levering. De løser forskellige problemer på forskellige stadier af anmodningslivscyklussen.

Cachen håndterer prefill-fasen (behandling af din input-prompt). Streaming håndterer decode-fasen (generering og sending af output-tokens inkrementelt). Du får begge fordele samtidigt: hurtigere prefill fra cache-hittet plus progressiv output-levering fra streaming.

Her er et streaming-eksempel med caching aktiveret:

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)

    # After streaming completes, check cache metrics
    usage = stream.get_final_message().usage
    print(f"\nCache read: {usage.cache_read_input_tokens} tokens")

TTFT-forbedringen fra caching er faktisk mest mærkbar med streaming. Uden caching venter du på den fulde prefill, før det første token streames tilbage. Med caching er prefills næsten øjeblikkelig, så tokens begynder at flyde næsten med det samme.

Sådan overvåger du cache-hit-rates i produktion

At opsætte caching er halvdelen af kampen. At vide, om det faktisk virker, er den anden halvdel. Hvis din cache-hitrate falder under 50%, er der sket en ændring i din prompt-struktur, og du efterlader penge på bordet.

Udbyderspecifikke cache-metrics

En simpel logger for cache-hit-rate

Her er en hjælpefunktion, du kan droppe ind i ethvert projekt for at spore cache-hit-rates via API-svarfelter:

import logging

logger = logging.getLogger("cache_monitor")

def log_cache_metrics(provider: str, usage: dict) -> float:
    """Extract and log cache metrics from any provider's response. Returns hit rate."""

    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

Et sundt produktionssystem bør opretholde 70-90% cache-hit-rates. Hvis du er under 50%, skal du genbesøge afsnittet om anti-mønstre. Du kan også integrere dette med automatiserede evalueringsmetrics for at fange regressioner i din prompt-pipeline.

Prompt-caching i virkelige use cases

Chatbot-eksemplerne ovenfor illustrerer mekanikken, men prompt-caching skinner virkelig i specifikke arkitekturmønstre.

RAG-pipelines

I en RAG-opstilling er din systemprompt og few-shot eksempler statiske på tværs af alle forespørgsler. De hentede dokumenter ændres hver gang. Strukturér din prompt for at maksimere det cachelagrede præfiks:

1. Systemprompt (cachelagret)
2. Few-shot eksempler (cachelagret)
3. Hentede dokumenter (dynamiske, placeres sidst)
4. Brugerforespørgsel (altid unik)

Med en systemprompt på 5.000 tokens og 3.000 tokens med few-shot eksempler er det 8.000 tokens, der cachelagres ved hver anmodning. Ved 1.000 anmodninger/dag på Anthropic ville du spare cirka $6,50/dag alene på det cachelagrede præfiks. Når du henter og cachelagrer kontekstblokke, skal du sørge for, at retrieval-outputtet kommer efter det statiske præfiks.

Multi-turn chatbots

Multi-turn samtaler er et sweet spot for prompt-caching. Hver tur tilføjer til samtalehistorikken, men hele den tidligere samtale er allerede cachelagret fra tidligere ture. Cache-fordelen akkumuleres; ved tur 10 har du måske 15.000 tokens med cachelagret historik med kun 200 friske tokens fra den seneste brugerbesked.

Agentiske systemer og MCP-værktøjsdefinitioner

Hvis du bygger agenter med værktøjsbrug, er dine værktøjsdefinitioner statiske JSON-skemaer, der gentages ved hvert enkelt API-kald. En typisk agent kan have 20+ værktøjer, der samlet set udgør 3.000-5.000 tokens af definitioner. Det er primært materiale til caching.

Dette er især relevant for MCP-baserede arkitekturer, hvor server-værktøjsdefinitioner sendes ved hvert kald. Med Anthropic's eksplicitte cache_control kan du markere tools-arrayet til caching og garantere, at disse tokens genbruges.

Hvilken udbyder skal du vælge?

Hvis du allerede bruger en udbyder, skal du starte der; prompt-caching kræver ikke skift. LiteLLM fungerer som et proxy-lag, der normaliserer caching-parametre på tværs af udbydere, hvilket er nyttigt, hvis du ruter anmodninger til flere modeller.

FAQ, LLM Prompt-caching

Hvad er prompt-caching i LLM'er?

Prompt-caching gemmer de beregnede attention-states (KV-cache) fra tidligere behandlede prompt-præfikser. Når en efterfølgende anmodning starter med den samme token-sekvens, genbruger udbyderen disse gemte states i stedet for at genberegne dem, hvilket reducerer både omkostninger og latens uden nogen indvirkning på outputkvaliteten.

Hvor meget sparer prompt-caching på API-omkostninger?

Besparelserne varierer fra 50% til 90% afhængigt af udbyderen. OpenAI tilbyder 50% rabat på cachelagrede input-tokens. Anthropic tilbyder op til 90% rabat (cachelagrede læsninger til 0,1x basispris). Gemini tilbyder cirka 90% rabat på cachelagrede læsninger. Faktiske besparelser afhænger af din cache-hitrate, prompt-længde og anmodningsfrekvens.

Sker OpenAI prompt-caching automatisk?

Ja, siden oktober 2024. Ethvert API-kald med 1.024+ input-tokens drager automatisk fordel af caching. Ingen tilmelding, ingen headers, ingen kodeændringer kræves. Cachen matcher token-præfikser fra begyndelsen af prompten.

Hvad er forskellen mellem prompt-caching og semantisk caching?

Prompt-caching matcher eksakte token-præfikser på GPU-niveau; der er intet tab af nøjagtighed, og outputs er identiske med uncached anmodninger. Semantisk caching bruger embedding-lighed til at finde "tilstrækkeligt tæt på" tidligere forespørgsler og returnerer cachelagrede svar; det er hurtigere, men kan returnere forkerte eller forældede svar. De løser fundamentalt forskellige problemer.

Hvor længe varer prompt-cachen?

Det varierer efter udbyder. OpenAI: 5-10 minutter (op til 24 timer med udvidet opbevaring). Anthropic: 5 minutter (standard) eller 1 time (tilgængelig på Claude 4.5+ modeller, koster 2x skrivning). Gemini: konfigurerbar, standard er 1 time for eksplicitte caches. TTL for implicit caching administreres automatisk af Google.

Hvad er den minimale token-længde for prompt-caching?

OpenAI: 1.024 tokens. Anthropic: 1.024 tokens for de fleste aktuelle modeller. Gemini: 1.024 tokens for Flash-modeller, 4.096 for Pro-modeller. Prompts under disse tærskler vil ikke aktivere caching; dette er den mest almindelige "det virker ikke"-fælde.

Virker prompt-caching med streaming-svar?

Ja. Caching og streaming opererer på forskellige faser af anmodningen. Caching fremskynder input-prefill-fasen; streaming leverer output-tokens inkrementelt. Begge dele fungerer samtidigt, og du vil faktisk bemærke TTFT-forbedringen mere med streaming aktiveret.

Hvornår bør jeg IKKE bruge prompt-caching?

Undgå at stole på caching, når dine prompts er under minimumstærsklen for tokens, når du inkluderer tidsstempler eller session-ID'er i systemprompten, når du roterer few-shot eksempler mellem kald, eller når anmodninger er for sjældne til at ramme cachen, før den udløber (5-10 minutters vindue for OpenAI/Anthropic).

Kan jeg bruge prompt-caching med LangChain eller LiteLLM?

Ja. LangChain sender udbyderspecifikke caching-parametre gennem sine API-wrappers. LiteLLM giver en unificeret caching-syntaks, der normaliserer cache_control på tværs af Anthropic, OpenAI, Gemini, Vertex AI og Bedrock, hvilket er særligt nyttigt til opsætninger med flere udbydere.

Hvad er et cache-hit vs. et cache-miss?

Et cache-hit betyder, at udbyderen fandt et matchende præfiks i hukommelsen og genbrugte de gemte KV-states; du betaler den rabatterede pris for cachelagrede tokens og får hurtigere TTFT. Et cache-miss betyder, at der ikke blev fundet noget match, så hele prompten behandles fra bunden til standardpris. Tjek felterne cached_tokens (OpenAI), cache_read_input_tokens (Anthropic) eller cachedContentTokenCount (Gemini) i API-svaret for at se, hvad der skete.

Endelig dom

Prompt-caching er den optimering i LLM API-stacken, der kræver mindst indsats og giver størst afkast. Du ændrer ikke din model, du ofrer ikke kvalitet, og implementeringen spænder fra "gør ingenting" (OpenAI) til "tilføj ét felt" (Anthropic) til "opret et cache-objekt" (Gemini).

Start med din nuværende udbyders automatiske caching. Mål din cache-hitrate med loggingsværktøjet ovenfor. Hvis du er under 70%, skal du omstrukturere dine prompts (statisk først, dynamisk sidst) og eliminere anti-mønstrene. De fleste teams ser 50-80% omkostningsreduktion inden for en dag efter implementering af disse ændringer.

Kilder

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