Als Modellanbieter Kontextfenster im Millionen-Token-Bereich ankündigten, reagierten viele CTOs und leitende Ingenieure gleich: „Großartig — wir laden die gesamte Dokumentation hinein und müssen RAG nicht mehr lösen." Das ist eine verständliche Reaktion. Weniger Komponenten, weniger Infrastruktur, weniger Tuning. Die Realität im Produktionsbetrieb ist jedoch komplizierter.
Ein großes Context Window ist ein mächtiges Werkzeug — es hat aber seine physikalischen und wirtschaftlichen Grenzen. Dieser Artikel erklärt, wo diese Grenzen liegen, zeigt, wann 1 Million Tokens tatsächlich ein Problem löst, und wann ihr Einsatz unnötig teuer und mitunter sogar weniger präzise ist als eine gut konzipierte Pipeline mit agentic RAG.
Was „1 Million Tokens" tatsächlich bedeutet
Das Context Window ist die maximale Textlänge — Eingabe plus Ausgabe —, die das Modell bei einem einzigen Aufruf auf einmal sieht. Ein Token entspricht ungefähr 0,75 Wörtern im Englischen; bei deutschsprachigen und technischen Texten sind Tokens tendenziell etwas länger.
Eine Million Tokens entspricht rund 750 000 Wörtern — einem durchschnittlichen Roman, Hunderten von Seiten technischer Dokumentation oder dem vollständigen Quellcode eines mittelgroßen Projekts. Heute ist das keine Premium-Funktion mehr: Claude (höhere Tiers), Gemini 2.5/3.x und Llama 4 Maverick bieten 1M, Llama 4 Scout geht sogar auf 10M Tokens. Nicht jedes Modell ist jedoch so „lang" — DeepSeek V3 hat beispielsweise 128K. Dennoch gilt: 1M Kontext ist bereits kein Alleinstellungsmerkmal mehr, sondern ein etablierter Standard.
Das Problem ist nicht, ob das Modell langen Kontext verarbeiten kann. Das Problem ist, was es kostet und wie die Antwortqualität mit wachsendem Kontext abnimmt.
Wie die Kosten mit der Kontextlänge steigen
Die Rechenkosten bei der Inferenz wachsen nicht linear mit dem Kontext — die Situation ist in der Praxis komplexer, aber für praktische Entscheidungen genügt es, einen Mechanismus zu verstehen: den KV-Cache.
Jeder Token im Kontext erfordert die Speicherung sogenannter Key-Value-Vektoren im GPU-Speicher (VRAM). Bei jedem neu generierten Token greift das Modell auf den gesamten Cache zu. Bei einem 7B-Modell beträgt der KV-Cache bei 128K Tokens etwa 16 GB, bei 1M Tokens über 100 GB. Bei einem 70B-Modell umfasst der KV-Cache allein bei 128K Tokens rund 40 GB — noch ohne die Modellgewichte.
Das Ergebnis in der Praxis: Sollen mehrere parallele Anfragen mit langem Kontext bedient werden, ist entweder enorme Hardware nötig, oder Anfragen werden in eine Warteschlange eingereiht. Bei Cloud-APIs bedeutet das schlicht höhere Kosten pro Aufruf — Frontier-Modelle berechnen jeden Eingabe-Token, und langer Kontext schlägt sich direkt in höheren Ausgaben nieder. Bei On-Premises-Deployments bedeutet es mehr oder leistungsstärkere GPUs.
Eine wichtige Optimierung existiert: Prompt Caching. Wenn Ihr System-Prompt, Ihre Dokumentation oder andere statische Inhalte über mehrere Aufrufe hinweg gleich bleiben, speichert der Anbieter deren KV-Repräsentation, und bei wiederholtem Lesen zahlen Sie nur 10 % des Preises eines Eingabe-Tokens (bei Anthropic). Das Cache-Write ist dafür etwas teurer — 125 bis 200 % des regulären Preises. Die Ersparnis tritt nur dann ein, wenn dasselbe Präfix wiederholt innerhalb kurzer Zeit gelesen wird. Diese Strategie beleuchten wir ausführlicher im Artikel Prompt Caching und Kosten.
„Lost in the Middle" — wenn das Modell den Faden verliert
Die meisten Ingenieure kennen das technologische Limit des Context Windows. Weniger diskutiert wird eine andere, subtilere Grenze: Context Rot — die Verschlechterung der Antwortqualität mit wachsender Kontextlänge.
Die Forschung zeigt, dass Modelle dazu neigen, ihre Aufmerksamkeit auf den Anfang und das Ende des Kontexts zu konzentrieren. Informationen, die in der Mitte eines langen Dokuments gespeichert sind, werden in Antworten weniger präzise wiedergegeben — ein Phänomen, das als „Lost in the Middle" bezeichnet wird. Der Benchmark needle-in-a-haystack (Suche nach einem einzelnen Satz in einem langen Text) misst nur die Fähigkeit, einen isolierten Fakt zu finden. Reale Produktionsaufgaben sind komplexer — sie erfordern die Verknüpfung mehrerer Informationen aus verschiedenen Teilen des Dokuments und mehrschrittiges Schlussfolgern. Bei solchen Aufgaben tritt die Qualitätsdegradation früher und deutlicher auf.
Praktisch bedeutet das: Haben Sie ein 500-seitiges technisches Handbuch und fragen nach der Abhängigkeit zwischen Abschnitt 3 und Abschnitt 47, antwortet ein Modell, dem das gesamte Buch im Kontext vorliegt, nicht zwingend besser als eines, dem Sie über RAG nur die beiden relevanten Abschnitte übergeben haben. Und der zweite Fall ist erheblich günstiger.
Wann ein großer Kontext tatsächlich hilft
Trotz dieser Einschränkungen gibt es Szenarien, in denen ein langer Kontext objektiv die bessere Wahl ist. Die wichtigsten Kategorien:
Analyse eines vollständigen Dokuments mit sequentiellen Abhängigkeiten. Wenn Sie ein Protokoll einer dreistündigen Besprechung zusammenfassen, Entscheidungen aus einem langen Rechtsschriftsatz extrahieren oder einen langen technischen Report analysieren wollen, bei dem die Schlussfolgerung vom Kontext der Einleitung abhängt — das gesamte Dokument im Kontext ergibt Sinn. Hier ist die Linearität ein Vorteil, keine Schwäche.
Lange Konversationen mit vollständiger Historie. Multi-Turn-Chat-Systeme, bei denen jede Frage von der vorherigen Antwort abhängt — Kundensupport mit Verlauf, technische Assistenz, bei der eine Lösung über Dutzende Austausche hinweg verfeinert wird. Die gesamte Historie im Kontext zu speichern ist einfacher als eine ausgefeilte Speicherlösung zu implementieren.
Code-Review oder Refactoring eines gesamten Repositories. Wenn ein Modell eine Abhängigkeit über mehrere Dateien hinweg korrigieren soll, eliminiert der Kontext des gesamten Codes Inkonsistenzen. Genau so funktionieren moderne Coding-Agenten — Cursor, Claude Code und ähnliche.
Eine einzelne, seltene lange Anfrage. Wenn Sie einmal im Monat einen 300-seitigen Vertrag hochladen und nach Haftungsklauseln fragen, funktioniert die Wirtschaftlichkeit. Ein Aufruf, klares Ergebnis, geringe Frequenz — die Kosten sind akzeptabel.
Wann RAG günstiger und präziser ist
Die meisten produktiven LLM-Systeme in Unternehmen funktionieren anders: eine umfangreiche Wissensbasis (technische Dokumentation, ISO-Normen, interne Vorschriften, Serviceprotokoll-Historien), die täglich von Dutzenden oder Hunderten von Mitarbeitern abgefragt wird. Hier hört ein großer Kontext ohne RAG auf, wirtschaftlich sinnvoll zu sein.
Situationen, in denen RAG die richtigere Wahl ist:
- Hohe Aufrufzahl mit überlappenden Quellen. Wenn hundert Bediener täglich verschiedene Fragen zum selben Handbuch stellen, zieht RAG nur die relevanten Abschnitte heraus, und Sie zahlen für einen Bruchteil der Tokens.
- Die Wissensbasis wächst. Das Context Window ist fix — hat Ihre Dokumentation 10 Millionen Tokens, reicht auch ein 1M-Fenster nicht aus. RAG skaliert mit der Größe der Basis ohne Architekturänderung.
- Präzise Quellenangaben sind erforderlich. RAG liefert konkrete Chunks mit Verweisen. Ein langer Kontext liefert eine Antwort, aber ohne Zuordnung zu einem konkreten Absatz — wichtig in regulierten Umgebungen.
- Geringe Latenz ist entscheidend. Die Time to First Token (TTFT) wächst mit der Kontextlänge. Bei 128K Tokens ist die Latenz um Größenordnungen höher als bei einem 4K-Kontext mit relevanten RAG-Chunks.
Einen ausführlicheren Vergleich beider Ansätze finden Sie im Artikel RAG vs. Fine-tuning — Entscheidungsfindung, in dem wir auch kombinierte Szenarien besprechen.
Hybrider Ansatz: Kontext + RAG
In der Praxis kombinieren die besten Produktionssysteme nicht einfach „vollständiger Kontext" oder „reines RAG" — sie nutzen beides situationsabhängig. Eine typische Architektur:
- 1.System-Prompt und globale Anweisungen — statisch, per Prompt Caching gecacht, günstig bei wiederholtem Lesen.
- 2.Dynamisch abgerufene Chunks — relevante Abschnitte aus der Dokumentation, die anfragebasiert in den Kontext eingefügt werden. Typisch 5–20 Chunks, je 200–500 Tokens.
- 3.Konversationshistorie — die letzten N Austausche, eine Zusammenfassung älterer Historie falls nötig.
- 4.Vollständiges Dokument im Kontext — nur wenn das Dokument kurz ist (unter 50K Tokens) und die Aufgabe das Gesamtbild erfordert.
Diese Kombination hält die effektive Kontextgröße bei typischen Anfragen auf 8–32K Tokens, was um Größenordnungen günstiger ist als 500K+ beim naiven „alles laden".
Praktische Entscheidungsfindung: Fragen vor dem Deployment
Bevor Sie sich für eine Architektur entscheiden, beantworten Sie sich diese Fragen:
- Wie oft wird dieselbe Wissensbasis täglich genutzt? Bei mehr als 50 Mal rechnet sich RAG wirtschaftlich, auch bei höheren Setup-Kosten.
- Ist die Basis größer als 500K Tokens? Falls ja, reicht ein langer Kontext nicht aus, und RAG ist die einzige realistische Option.
- Hängt die Antwort vom sequentiellen Lesen des gesamten Dokuments ab? Falls ja, ist ein langer Kontext eine legitime Wahl.
- Wie hoch ist die Latenztoleranz? Echtzeit-Konversation mit einer Anforderung unter 2 Sekunden und langer Kontext lassen sich kaum kombinieren.
- Benötigen Sie zitierbare Quellen? RAG liefert Ihnen einen Chunk mit Verweis, ein großer Kontext nicht.
Antworten Sie auf die meisten Fragen mit „Nein, Nein, Ja, hoch, Nein" — dann kann ein langer Kontext die richtige Wahl sein. Überwiegt das Gegenteil, wird RAG oder eine hybride Architektur wirtschaftlich und qualitativ besser abschneiden.
Prompt Caching als Kompromiss
Ein Sonderfall ist die Situation, in der Sie einen relativ großen, aber statischen Kontext haben — etwa einen Unternehmens-Styleguide, einen umfangreichen System-Prompt mit Anweisungen oder Referenzdokumentation. Hier bietet Prompt Caching eine attraktive Mitte:
- Erster Aufruf: Sie zahlen den vollen Preis für das Cache-Write (125–200 % des regulären Eingabepreises).
- Jeder weitere Aufruf im TTL-Fenster (5 Minuten oder 1 Stunde bei Anthropic): Sie zahlen 10 % des Eingabe-Token-Preises für den gecachten Teil.
- Bei einem zehnfach wiederholten statischen Präfix sind die Gesamtkosten erheblich geringer als ohne Cache.
Typische Einsparungen im Produktionsbetrieb bei geeignetem Workload erreichen 50–70 % der Kosten für Eingabe-Tokens. Der Betonung auf „geeigneter Workload" kommt Bedeutung zu — wenn jeder Nutzer mit einem völlig anderen langen Prompt kommt, liegt die Cache-Hit-Rate nahe null, und das Cache-Write macht alles teurer.
Was das für die Hardware- und Serving-Framework-Wahl bedeutet
Wenn Sie sich für echte lange Kontexte im On-Premises-Deployment entscheiden, ist es wichtig, die Hardware-Konsequenzen zu verstehen.
Der KV-Cache für langen Kontext benötigt deutlich mehr VRAM zusätzlich zu den Modellgewichten. Bei einem 70B-Modell bei 128K Kontext beträgt allein der KV-Cache rund 40 GB — dazu kommen ~140–168 GB für die Modellgewichte in FP16 (oder ~35–40 GB bei Q4_K_M-Quantisierung). Das übersteigt schnell die Kapazität einer einzelnen GPU und erfordert ein Multi-GPU-Setup oder Tensor Parallelism.
Auf der Seite der Serving-Frameworks: vLLM und SGLang implementieren PagedAttention und RadixAttention — Techniken, die die KV-Cache-Fragmentierung reduzieren und ein effizienteres Sharing zwischen parallel verarbeiteten Anfragen ermöglichen. Ollama ist hervorragend für den Desktop-Einsatz und Experimente, aber für produktives Multi-User-Serving mit langen Kontexten ist die Leistung um Größenordnungen geringer. Mehr zum Vergleich der Frameworks finden Sie in vLLM vs. SGLang vs. Ollama.
Grouped Query Attention (GQA), das die meisten modernen Modelle implementieren, reduziert die KV-Cache-Größe gegenüber klassischer Multi-Head Attention erheblich — bei der Modellauswahl für langen Kontext ist es daher wichtig zu prüfen, ob GQA unterstützt wird.
Häufige Fragen
Ersetzt eine Million Tokens RAG vollständig?
Für die meisten Produktionssysteme: Nein. Die Wirtschaftlichkeit funktioniert nicht: 1M Tokens bei jedem Aufruf ist um Größenordnungen teurer als das Abrufen relevanter Chunks. Hinzu kommt die reale Qualitätsdegradation bei sehr langem Kontext. Ein großer Kontext ergibt Sinn für einmalige Analysen langer Dokumente, nicht für ein System, bei dem dieselbe Basis hundertmal täglich abgefragt wird.
Wie stark nimmt die Antwortqualität bei langem Kontext ab?
Das hängt von der Aufgabe ab. Bei einfacher Suche nach einem einzelnen Fakt (Needle-in-a-Haystack) sind moderne Modelle auch bei 1M Tokens zuverlässig. Bei komplexeren Aufgaben — Verknüpfung von Informationen aus mehreren Stellen, Multi-Hop-Reasoning — nimmt die Präzision mit steigender Länge deutlicher ab. Das Phänomen „Lost in the Middle" ist experimentell dokumentiert und muss beim Architekturdesign berücksichtigt werden.
Ist Prompt Caching immer vorteilhaft?
Nein. Es ist vorteilhaft bei einem statischen oder selten veränderten Präfix, das wiederholt innerhalb des TTL-Fensters (5 Minuten oder 1 Stunde) gelesen wird. Cache-Write-Tokens sind teurer als reguläre Eingabe-Tokens (1,25–2× bei Anthropic). Wenn jeder Nutzer einen einzigartigen langen Kontext mitbringt oder die Aufruffrequenz gering ist, wird die Cache-Hit-Rate niedrig sein, und die Gesamtkosten können höher ausfallen als ohne Caching.
Welche Hardware benötige ich für ein lokales Deployment mit langem Kontext?
Das hängt vom Modell und der Länge ab. Als Richtwert: Für ein 70B-Modell bei 32K Tokens benötigen Sie insgesamt rund 50–80 GB VRAM (Gewichte + KV-Cache bei Q4-Quantisierung). Bei 128K Tokens beträgt der KV-Cache allein rund 40 GB (für 70B, FP16 KV). Bei einem 7B-Modell ist die Situation günstiger — bei 128K Tokens kommen Sie mit einer High-End-GPU mit 40–80 GB VRAM aus. Apple M-Series mit Unified Memory (bis zu 128–192 GB beim M5 Ultra) ist eine interessante On-Premises-Alternative für 70B mit langem Kontext.
Gelten dieselben Prinzipien für Open-Weight-Modelle On-Premises und Cloud-APIs?
Die Wirtschaftlichkeit ist unterschiedlich, die Prinzipien sind gleich. Bei einer Cloud-API zahlen Sie direkt pro Token. On-Premises zahlen Sie für Hardware (CAPEX) und Energie (OPEX) — aber KV-Cache und damit GPU-Speicherbedarf wachsen auf dieselbe Weise. Die Entscheidung „langer Kontext vs. RAG" hängt also nicht nur vom Token-Preis ab, sondern von der gesamten Hardware-Architektur, Batch-Größe und Latenz.
*Wenn Sie die Architektur eines LLM-Systems planen und unsicher sind, wo für Sie die Grenze zwischen langem Kontext, Prompt Caching und RAG liegt, schauen wir uns Ihren konkreten Fall gerne bei MP Industrial Solutions an — wir bringen Erfahrung aus Industrie-Deployments mit, wo jeder Euro an Betriebskosten zählt.*