Fundamenten & Concepten

Waarom Zia overstapt op Prompt Caching voor lagere TTFT

Beau Jonkhout

Time To First Token (TTFT) is de grootste bottleneck bij grote context windows. Door over te stappen op Anthropic's prompt caching in Zia, verlagen we latency en kosten drastisch.

Waarom Zia overstapt op Prompt Caching voor lagere TTFT

Ik heb een hekel aan wachten op een LLM. Wanneer een gebruiker een vraag stelt aan Zia, ons AI-kennisplatform, en we een financieel prospectus van 150.000 tokens in de context window laden, interesseert het die gebruiker niet hoe indrukwekkend de onderliggende transformer-architectuur is. Het enige wat ze merken, is dat de Time To First Token (TTFT) oploopt tot 14 seconden. Dat is onacceptabel voor een productiesysteem. De illusie van de 'oneindige context window' crasht keihard op de realiteit van compute-kosten en latency. Daarom herschrijven we momenteel de retrieval-pipeline van Zia om volledig gebruik te maken van prompt caching, specifiek de recente implementaties van Anthropic en OpenAI. Dit is geen kleine optimalisatie; het is een fundamentele verschuiving in hoe we omgaan met state in LLM-infrastructuur.

De rekensom die traditionele RAG onwerkbaar maakte

Lange tijd was de standaardoplossing voor grote documenten het opknippen van tekst (chunking) en het ophalen van de meest relevante delen via vector search. Zoals ik eerder schreef in Verder dan Vector Search: Waarom wij overstappen op Hybrid Search, is vector search alleen simpelweg niet robuust genoeg voor complexe technische of juridische queries waarbij het antwoord verspreid ligt over tientallen pagina's. We moesten steeds grotere chunks naar het model sturen om de context te behouden.

Maar het meesturen van 100.000 tokens bij elke API-call heeft een enorme prijs. Het attention-mechanisme in een standaard transformer schaalt kwadratisch (of in het beste geval lineair bij nieuwere architecturen), wat betekent dat het model bij elke nieuwe vraag de Key-Value (KV) cache voor die hele 100.000 tokens opnieuw moet berekenen.

Stel je de workflow in Zia voor: een compliance officer uploadt een beleidsdocument van 300 pagina's en stelt in een half uur tijd 15 verschillende vragen over datzelfde document. In onze oude architectuur betaalden we 15 keer voor het verwerken van die 300 pagina's, en wachtte de gebruiker 15 keer 14 seconden voordat het eerste woord op het scherm verscheen. Dat is niet alleen een slechte user experience, het is mathematisch en economisch absurd.

De mechanica van Prompt Caching: Van stateless naar stateful

Prompt caching verandert de interactie met de LLM-API van volledig stateless naar pseudo-stateful. Zowel Anthropic (met Claude 3.5 Sonnet) als OpenAI hebben dit recent via hun API's blootgelegd. In plaats van de KV-cache na elke request weg te gooien, houdt de infrastructuur van de provider de berekende attention-states voor een specifieke prefix tijdelijk in het geheugen vast.

Bij Anthropic werkt dit expliciet. Je voegt een cache_control: {"type": "ephemeral"} block toe aan je API-payload bij het specifieke bericht of document dat je wilt cachen. OpenAI doet dit momenteel impliciet: als je een prompt stuurt die langer is dan 1.024 tokens en de prefix komt exact overeen met een recente request, krijg je automatisch een cache hit.

De impact op Zia is gigantisch. Bij een cache hit op een document van 100.000 tokens, dropt onze TTFT van ~14 seconden naar minder dan 500 milliseconden. De kosten voor input-tokens dalen bij Anthropic met 90% (van $3.00 per 1M tokens naar $0.30 per 1M tokens). Opeens is het inladen van een complete codebase of een heel wetboek niet langer een dure, trage operatie, maar een bliksemsnelle basis voor interactie.

Herschrijven van Zia: "Write-Once, Read-Many"

Om hier gebruik van te maken, moesten we de architectuur van Zia flink omgooien. Voorheen was onze pipeline geoptimaliseerd om de context window zo klein mogelijk te houden om kosten en latency te besparen. Nu optimaliseren we voor een "Write-Once, Read-Many" (WORM) patroon.

Wanneer een document nu in Zia wordt geladen (vaak getriggerd door Vera, onze compliance-engine, of doorgestuurd door Alex, ons agent-platform), plaatsen we het volledige document als een statische prefix in de system prompt, gelabeld voor caching. Zolang de gebruiker of agent vragen blijft stellen over dit document, betalen we alleen de fractie van de kosten voor de cache read en genereren we antwoorden in real-time.

Dit is cruciaal voor de adoptie van AI in enterprise-omgevingen. Bedrijven willen niet betalen voor inefficiëntie. Dit sluit direct aan bij wat we zien in de markt, zoals we analyseerden in AI-ROI in 2026: van experiment naar meetbare waarde. Als je infrastructuurkosten lineair meestijgen met het aantal vragen dat een gebruiker stelt over hetzelfde document, is je businessmodel op termijn onhoudbaar.

De valkuilen: Eviction, Prefix Matching en Error Codes

Natuurlijk is het geen pure magie. We zijn tijdens de implementatie tegen een aantal harde muren aangelopen. Het grootste probleem is de strikte eis van prefix matching.

Prompt caching werkt alleen als de opbouw van je prompt exact byte-voor-byte identiek is aan de gecachte versie, vanaf het allereerste token. In onze eerste iteratie hadden we een dynamische session_id en een current_timestamp bovenaan onze system prompt gezet, bedoeld voor logging en context. Het resultaat? Een cache hit rate van 0%. Omdat de timestamp bij elke request veranderde, zag de API elke prompt als volledig nieuw. We moesten de opbouw omkeren: eerst de statische, zware documenten (gecacht), en pas helemaal aan het einde van de prompt de dynamische variabelen en de daadwerkelijke user query.

Daarnaast heb je te maken met cache eviction. Anthropic hanteert een Time-To-Live (TTL) van 5 minuten. Als een gebruiker een vraag stelt, vervolgens een kop koffie gaat halen en na 6 minuten een vervolgvraag stelt, is de cache weggespoeld. Je betaalt dan weer de volle mep voor de cache write en de gebruiker zit weer 14 seconden te wachten. We experimenteren nu met asynchrone 'keep-alive' pings vanuit Alex om de cache warm te houden voor actieve sessies, hoewel je hierbij goed moet rekenen of de kosten van de ping opwegen tegen de kosten van een cache miss.

Wat dit betekent voor de Agentic Fleet en CEA

De implicaties van prompt caching gaan veel verder dan alleen snellere antwoorden in een chat-interface. Voor PrudAI's visie op autonome systemen is dit een fundamentele enabler.

Onze Chief Executive Agent (CEA) moet constant de state van tientallen sub-agents overzien. Tot nu toe was het delen van grote hoeveelheden context tussen agents traag. Met prompt caching kunnen we een gedeelde "working memory" creëren. Een analyse-agent kan een gigantisch dataset in de cache laden, en CEA kan vervolgens razendsnel, tegen 10% van de kosten, queries afvuren op diezelfde gecachte state zonder de data opnieuw in te hoeven laden.

We verschuiven van een wereld waarin we constant data naar compute verplaatsen, naar een model waar de data (in de vorm van een KV-cache) tijdelijk op de compute-node blijft wachten op onze instructies. Voor Zia is dit de stap die het verwerken van 100k+ token kennisbanken eindelijk volwassen maakt.

Bronnen

Wil je sparren over latency-optimalisatie en LLM-architectuur? Neem contact op.

LLMRAGPrudAIAI kennisbank

Beau Jonkhout

Technisch Directeur

Beau is medeoprichter en technisch directeur van PrudAl. Hij is de drijvende kracht achter de technische architectuur van het PrudAl-platform. Hij leidt de ontwikkeling van de multi-agent frameworks, stuurt de developers aan en is verantwoordelijk voor de integratiekwaliteit, security en privacy by design van alle oplossingen.