Toen modelproviders contextvensters van miljoenen tokens aankondigden, reageerden veel CTO's en hoofdingenieurs op dezelfde manier: "Uitstekend — we stoppen er de volledige documentatie in en hoeven RAG niet meer op te lossen." Dat is een begrijpelijke reactie. Minder componenten, minder infrastructuur, minder afstelling. De realiteit in productie is echter complexer.
Een groot contextvenster is een krachtig instrument — maar het heeft zijn fysieke en economische grenzen. Dit artikel legt uit waar die grenzen liggen, toont wanneer 1M tokens een probleem echt oplost en wanneer het gebruik ervan onnodig duur is — en soms minder nauwkeurig dan een goed ontworpen pipeline met agentic RAG.
Wat "1M tokens" eigenlijk betekent
Het contextvenster is de maximale tekstlengte — invoer plus uitvoer — die het model in één aanroep ziet. Een token komt overeen met ongeveer 0,75 woord in het Engels; in andere talen en technische teksten zijn tokens doorgaans iets langer.
Een miljoen tokens is ongeveer 750 000 woorden — een volledige roman, honderden pagina's technische documentatie of de volledige broncode van een middelgroot project. Tegenwoordig is dat geen premiumfunctie meer: Claude (hogere tiers), Gemini 2.5/3.x en Llama 4 Maverick bieden 1M tokens, Llama 4 Scout gaat zelfs tot 10M tokens. Niet elk model is echter zo "lang" — DeepSeek V3 heeft bijvoorbeeld 128K. Toch geldt: 1M context is geen uitzonderlijke eigenschap meer, maar een brede standaard.
Het probleem is niet of het model een lange context aankan. Het probleem is wat dat kost en hoe de antwoordkwaliteit daalt naarmate de context groeit.
Hoe de kosten stijgen met de contextlengte
De rekenkosten bij inferentie groeien niet lineair met de context — in werkelijkheid is de situatie complexer, maar voor praktische beslissingen volstaat het begrip van één mechanisme: de KV-cache.
Elke token in de context vereist de opslag van zogenaamde key-value-vectoren in het GPU-geheugen (VRAM). Bij elke nieuw gegenereerde token raadpleegt het model de volledige cache. Voor een 7B-model bedraagt de KV-cache bij 128K tokens ongeveer 16 GB; bij 1M tokens meer dan 100 GB. Voor een 70B-model bedraagt de KV-cache bij 128K tokens al zo'n 40 GB — nog zonder de modelgewichten.
Praktisch gevolg: als u meerdere parallelle verzoeken met lange context wilt afhandelen, hebt u óf enorme hardware nodig, óf verzoeken worden in de wachtrij geplaatst. Op een cloud-API betekent dat simpelweg hogere kosten per aanroep — frontiermodellen rekenen per invoertoken, en een lange context correspondeert rechtstreeks met hogere kosten. Bij on-premise implementatie betekent het meer of krachtigere GPU's.
Er bestaat een belangrijke optimalisatie: prompt caching. Als uw systeemprompt, documentatie of andere statische inhoud gelijk blijft over meerdere aanroepen, slaat de provider de KV-representatie op en betaalt u bij herhaald lezen slechts 10 % van de invoertokenprijs (bij Anthropic). Cache-writes zijn daarentegen iets duurder — 125 tot 200 % van de gebruikelijke prijs. De besparing treedt alleen op wanneer u hetzelfde prefix herhaaldelijk leest binnen een kort tijdvenster. In het artikel over prompt caching en kosten gaan we dieper op deze strategie in.
"Lost in the middle" — wanneer het model de draad kwijtraakt
De meeste ingenieurs kennen de technologische limiet van het contextvenster. Minder besproken is een andere, subtielere grens: context rot — de degradatie van antwoordkwaliteit naarmate de context groeit.
Onderzoek toont aan dat modellen de neiging hebben hun aandacht te richten op het begin en het einde van de context. Informatie die in het midden van een lang document staat, wordt in antwoorden minder nauwkeurig weergegeven — een fenomeen dat "lost in the middle" wordt genoemd. De benchmark needle-in-a-haystack (het zoeken naar één zin verborgen in een lange tekst) meet alleen het vermogen om een geïsoleerd feit te vinden. Echte productietaken zijn complexer — ze vereisen het leggen van verbanden tussen meerdere stukken informatie uit verschillende delen van een document, redeneren over meerdere stappen. Bij dergelijke taken treedt kwaliteitsdegradatie eerder en sterker op.
Praktisch betekent dit: als u een technische handleiding van 500 pagina's heeft en vraagt naar de afhankelijkheid tussen sectie 3 en sectie 47, hoeft een model met het hele boek in de context niet noodzakelijk beter te antwoorden dan een model dat via RAG alleen de twee relevante secties heeft gekregen. En dat tweede geval is aanzienlijk goedkoper.
Wanneer een groot context window echt helpt
Ondanks deze beperkingen zijn er scenario's waar een lange context objectief de betere keuze is. De belangrijkste categorieën:
Analyse van een volledig document met sequentiële afhankelijkheid. Als u een notulen van een vergadering van drie uur wilt samenvatten, beslissingen wilt extraheren uit een lang juridisch dossier, of een lang technisch rapport wilt analyseren waarbij de conclusie afhangt van de context in de inleiding — het volledige document in de context is zinvol. Hier is lineariteit een voordeel, geen zwakte.
Lange gesprekken met volledige geschiedenis. Multi-turn chatsystemen waarbij elke vraag afhangt van het vorige antwoord — klantenservice met geschiedenis, technische assistentie waarbij één oplossing over tientallen uitwisselingen wordt verfijnd. De volledige geschiedenis in de context opslaan is eenvoudiger dan het implementeren van een geavanceerd geheugenbeleid.
Code review of refactoring van een volledig repository. Wanneer u het model een afhankelijkheid over meerdere bestanden tegelijk wilt laten corrigeren, elimineert de context van de volledige code inconsistenties. Precies zo werken moderne coding agents — Cursor, Claude Code en vergelijkbare tools.
Één lange, incidentele vraag. Als u een contract van 300 pagina's eens per maand uploadt en vraagt naar aansprakelijkheidsclausules, werkt de economie. Één aanroep, duidelijke uitvoer, lage frequentie — de kosten zijn acceptabel.
Wanneer RAG goedkoper en nauwkeuriger is
De meeste productie-LLM-systemen in bedrijven werken anders: een uitgebreide knowledge base (technische documentatie, ISO-normen, interne voorschriften, servicelogboekhistorie), waarop tientallen of honderden medewerkers per dag vragen stellen. Hier houdt een grote context zonder RAG economisch geen stand.
Situaties waarin RAG de betere keuze is:
- Hoog aantal aanroepen met overlappende bronnen. Als honderd operators per dag verschillende vragen stellen over dezelfde handleiding, haalt RAG alleen de relevante passages op en betaalt u een fractie van de tokens.
- De database groeit. Het contextvenster is vast — als uw documentatie 10 miljoen tokens heeft, volstaat zelfs een 1M-venster niet. RAG schaalt mee met de omvang van de basis zonder architectuurwijziging.
- U hebt nauwkeurige bronverwijzingen nodig. RAG geeft u specifieke chunks met referenties terug. Lange context geeft u een antwoord, maar zonder attributie aan een specifieke alinea — belangrijk in gereguleerde omgevingen.
- Lage latency is cruciaal. De tijd tot de eerste token (TTFT) neemt toe met de contextlengte. Bij 128K tokens is de latency een orde van grootte hoger dan bij een 4K-context met relevante RAG-chunks.
Een uitgebreide vergelijking van beide benaderingen vindt u in het artikel RAG vs fine-tuning — beslissen, waar we ook gecombineerde scenario's bespreken.
Hybride aanpak: context + RAG
In de praktijk kiezen de beste productiesystemen niet tussen "volledige context" of "pure RAG" — ze combineren beide naar gelang de situatie. Een typische architectuur:
- 1.Systeemprompt en globale instructies — statisch, gecached via prompt caching, goedkoop bij herhaald lezen.
- 2.Dynamisch opgehaalde chunks — relevante passages uit de documentatie, op basis van de query aan de context toegevoegd. Doorgaans 5–20 chunks van elk 200–500 tokens.
- 3.Gespreksgeschiedenis — de laatste N uitwisselingen, een samenvatting van oudere geschiedenis indien nodig.
- 4.Volledig document in de context — alleen als het document kort is (onder 50K tokens) en de taak het geheel vereist.
Deze combinatie houdt de effectieve contextgrootte bij gewone vragen op 8–32K tokens, wat een orde van grootte goedkoper is dan de 500K+ bij een naïeve "laad alles"-aanpak.
Praktisch beslissen: vragen vóór implementatie
Beantwoord deze vragen voordat u een architectuur kiest:
- Hoe vaak per dag wordt dezelfde knowledge base gebruikt? Als meer dan 50×, is RAG ook bij hogere opzetkosten economisch rendabel.
- Is de basis groter dan 500K tokens? Zo ja, dan volstaat lange context niet en is RAG de enige realistische keuze.
- Hangt het antwoord af van het sequentieel lezen van het volledige document? Zo ja, dan is lange context een legitieme keuze.
- Wat is de latencytolerantie? Realtime gesprekken met een eis van onder de 2 seconden en lange context zijn moeilijk te combineren.
- Hebt u citeerbare bronnen nodig? RAG geeft u een chunk met referentie, grote context niet.
Als u op de meeste vragen "nee, nee, ja, hoog, nee" antwoordt — kan lange context de juiste keuze zijn. Als het omgekeerde overheerst, zal RAG of een hybride architectuur zowel economisch als kwalitatief beter presteren.
Prompt caching als compromis
Een speciaal geval is de situatie waarbij u een relatief grote maar statische context heeft — bijvoorbeeld een bedrijfsstijlgids, een uitgebreide systeemprompt met instructies of referentiedocumentatie. Hier biedt prompt caching een aantrekkelijk middenweg:
- Eerste aanroep: u betaalt de volledige prijs voor de cache-write (125–200 % van de gebruikelijke invoerprijs).
- Elke volgende aanroep binnen het TTL-venster (5 minuten of 1 uur bij Anthropic): u betaalt 10 % van de invoertokenprijs voor het gecachede deel.
- Bij een tienvoudig herhaald statisch prefix zijn de totale kosten aanzienlijk lager dan zonder cache.
Typische besparingen in productie bij een geschikt workload bedragen 50–70 % op invoertokenkosten. De nadruk ligt op "geschikt workload" — als elke gebruiker met een volledig ander lang prompt komt, nadert de cache-hitrate nul en worden cache-writes juist duurder.
Gevolgen voor hardware- en serving-frameworkkeuze
Als u besluit echte lange contexten te gebruiken in een on-premise implementatie, is het belangrijk de hardwareconsequenties te begrijpen.
De KV-cache voor lange context heeft veel extra VRAM nodig bovenop de modelgewichten zelf. Voor een 70B-model bij 128K context bedraagt de KV-cache alleen al zo'n 40 GB — daarbij opgeteld ~140–168 GB voor de modelgewichten in FP16 (of ~35–40 GB voor Q4_K_M-kwantisatie). Dit overschrijdt al snel de capaciteit van één GPU en vereist een multi-GPU-opstelling of tensor parallelism.
Aan de kant van serving-frameworks: vLLM en SGLang implementeren PagedAttention en RadixAttention — technieken die KV-cachefragmentatie verminderen en efficiënter delen mogelijk maken tussen parallelle verzoeken. Ollama is uitstekend voor desktop en experimenten, maar voor productie-multi-user serving met lange contexten is de prestatie een orde van grootte lager. Meer over de frameworkvergelijking leest u in vLLM vs SGLang vs Ollama.
Grouped Query Attention (GQA), dat door de meeste moderne modellen wordt geïmplementeerd, verlaagt de KV-cachegrootte aanzienlijk ten opzichte van klassieke multi-head attention — bij de modelkeuze voor lange context is het dus belangrijk te verifiëren of GQA wordt ondersteund.
Veelgestelde vragen
Vervangt een miljoen tokens RAG volledig?
Voor de meeste productiesystemen niet. De economie werkt niet: 1M tokens bij elke aanroep is een orde van grootte duurder dan het ophalen van relevante chunks. Bovendien is kwaliteitsdegradatie bij een zeer lange context reëel. Grote context is zinvol voor eenmalige analyses van lange documenten, niet voor een systeem waarbij dezelfde basis honderd keer per dag wordt bevraagd.
Hoezeer daalt de antwoordkwaliteit bij lange context?
Dat hangt af van de taak. Bij eenvoudig zoeken naar één feit (needle-in-a-haystack) zijn moderne modellen betrouwbaar ook bij 1M tokens. Bij complexere taken — verbanden leggen vanuit meerdere plaatsen, multi-hop redeneren — daalt de nauwkeurigheid merkbaar sterker naarmate de lengte toeneemt. Het fenomeen "lost in the middle" is experimenteel gedocumenteerd en moet worden meegenomen bij het ontwerpen van de architectuur.
Is prompt caching altijd voordelig?
Nee. Het is voordelig bij een statisch of weinig veranderend prefix dat herhaaldelijk wordt gelezen binnen het TTL-venster (5 minuten of 1 uur). Cache-write-tokens zijn duurder dan gewone invoertokens (1,25–2× bij Anthropic). Als elke gebruiker een unieke lange context meebrengt, of als de aanroepfrequentie laag is, zal de cache-hitrate laag zijn en kunnen de totale kosten hoger uitvallen dan zonder caching.
Welke hardware heb ik nodig voor lokale implementatie met lange context?
Dat hangt af van het model en de lengte. Als richtlijn: voor een 70B-model bij 32K tokens heeft u totaal zo'n 50–80 GB VRAM nodig (gewichten + KV-cache bij Q4-kwantisatie). Bij 128K tokens bedraagt de KV-cache alleen al ongeveer 40 GB (voor 70B, FP16 KV). Voor een 7B-model is de situatie gunstiger — bij 128K tokens redt u het met een high-end GPU van 40–80 GB VRAM. De Apple M-serie met unified memory (tot 128–192 GB op M5 Ultra) is een interessant on-premise alternatief voor 70B met lange context.
Gelden dezelfde principes voor open-weight modellen on-premise als voor cloud-API's?
De economie verschilt, de principes zijn gelijk. Op een cloud-API betaalt u rechtstreeks per token. On-premise betaalt u voor hardware (CAPEX) en energie (OPEX) — maar KV-cache en daarmee GPU-geheugenvereisten groeien op dezelfde manier. De beslissing "lange context vs RAG" draait dus niet alleen om tokenkosten, maar om de totale architectuur van hardware, batchgrootte en latency.
*Als u de architectuur van een LLM-systeem opzet en niet zeker weet waar voor u de grens ligt tussen lange context, prompt caching en RAG, kijken we graag naar uw concrete situatie bij MP Industrial Solutions — wij brengen ervaring mee uit implementaties in de industrie, waar elke euro aan operationele kosten telt.*