Haben Sie jemals bemerkt, dass ChatGPT oder Claude zu Beginn eines Gesprächs
alles perfekt im Gedächtnis behalten, aber nach einer Stunde anfangen, Details zu verwechseln oder
nachzufragen, was Sie bereits erklärt haben? Das ist kein Fehler – es ist eine grundlegende
Einschränkung, die bestimmt, wie viel eine KI gleichzeitig "im Kopf behalten" kann.
Sie wird als Kontextfenster bezeichnet – und genau davon
hängen die Qualität, Geschwindigkeit und Kosten jeder Antwort ab.
Wenn Sie noch nicht mit den Grundlagen von LLMs vertraut sind – beginnen Sie mit
unserem Leitartikel "Wie funktionieren ChatGPT, Claude und Gemini: Der vollständige Leitfaden 2026".
📌 TL;DR – Die wichtigsten Punkte in 30 Sekunden:
Das Kontextfenster ist die maximale Textmenge, die eine KI gleichzeitig sehen kann.
Bei Claude sind es 200.000 Token (~500 Seiten), bei GPT-5 – 400.000, bei Gemini – bis zu 1 Mio.+.
Aber mehr ist nicht immer besser: Eine Verdoppelung des Kontexts vervierfacht den Speicherbedarf
(quadratische Komplexität), die KI erinnert sich schlechter an Informationen aus der Mitte
des Textes (lost in the middle), und jedes zusätzliche Token kostet echtes Geld.
Deshalb ist RAG auch im Zeitalter von Millionen-Token-Kontextfenstern noch relevant.
📚 Inhaltsverzeichnis
🎯 Was ist ein Kontextfenster und warum ist es begrenzt?
Kurze Antwort:
Das Kontextfenster (context window) ist die maximale Anzahl von Token,
die ein Modell pro Anfrage verarbeiten kann. Dies umfasst sowohl das, was Sie geschrieben haben,
als auch das, was das Modell geantwortet hat, und die gesamte vorherige Chat-Historie.
Wenn das Fenster voll ist, "fallen" die ältesten Nachrichten heraus.
Stellen Sie sich einen Schreibtisch vor. Alles, was die KI gleichzeitig sehen kann,
liegt auf diesem Schreibtisch. Die Größe des Tisches ist das Kontextfenster.
Neue Dokumente werden oben abgelegt, alte fallen auf den Boden.
Wenn Sie eine Nachricht in ChatGPT oder Claude schreiben, wird Folgendes auf den "Tisch" gelegt:
Der System-Prompt (Anweisungen für das Modell) + die gesamte Konversationshistorie +
Ihre neue Anfrage. Das Modell "sieht" all dies gleichzeitig und generiert
eine Antwort.
Wichtiger Hinweis: Das Kontextfenster wird nicht in Wörtern, sondern in
Token gemessen. Ein Token ist ein Textfragment: ein Wort, ein Wortteil
oder sogar ein einzelnes Zeichen. Im Englischen entspricht ein Wort ≈ 1,3 Token.
Im Ukrainischen ist es komplizierter: Aufgrund der reichen Morphologie wird ein Wort
normalerweise in 2–4 Token zerlegt. Das bedeutet, dass ukrainischer Text
weniger in das Kontextfenster passt als englischer.
Mehr über Token und Tokenisierung –
im Artikel Was sind Token: Wie ChatGPT Ihren Text sieht.
Ich habe diese Einschränkung in der Praxis erlebt, als ich einen RAG-Chatbot für
WebsCraft entwickelte. Solange das Gespräch kurz ist –
antwortet der Bot schnell und präzise. Aber wenn der Benutzer 10-15 Fragen
hintereinander stellt, füllt sich der Kontext mit vorherigen Nachrichten, und die Qualität
der Antworten nimmt allmählich ab. Genau dann erkannte ich, wie sehr
das Kontextfenster alles beeinflusst – von der Geschwindigkeit bis zu den Kosten.
Warum kann das Fenster nicht unendlich sein?
Drei grundlegende Einschränkungen:
- ✔️ Speicher (RAM/VRAM): Jeder Token im Kontext erfordert die Speicherung eines KV-Caches (Key-Value Cache). Mehr Token = mehr GPU-Speicher. Bei einem Kontext von 200.000 Token kann der KV-Cache Dutzende von Gigabyte beanspruchen.
- ✔️ Geschwindigkeit: Jeder neue Token "sieht" alle vorherigen. Mehr Kontext = langsamere Generierung jedes folgenden Wortes.
- ✔️ Kosten: API-Anbieter berechnen für jeden Token. Längere Gespräche = teurere jede folgende Anfrage.
Aber der Hauptgrund ist mathematisch und verdient eine eigene Sektion.
Fazit: Das Kontextfenster ist kein technisches Detail,
sondern ein grundlegender Kompromiss zwischen Qualität, Geschwindigkeit und Kosten.
Jedes Modell löst diesen Kompromiss auf seine eigene Weise.
🎯 Quadratische Komplexität: Warum eine Verdoppelung des Kontexts = 4x teurer ist
Kurze Antwort:
Im Kern von LLMs liegt der Aufmerksamkeitsmechanismus, bei dem jeder Token
jeden anderen "betrachtet". Dies erzeugt eine quadratische Abhängigkeit: Eine Verdoppelung des Kontexts
erhöht die Berechnungen und den Speicherbedarf nicht um das 2-fache, sondern um das 4-fache. Dies ist die Hauptwand
auf dem Weg zu unendlichem Kontext.
1.000 Token = 1 Million Aufmerksamkeitsoperationen.
10.000 Token = 100 Millionen.
200.000 Token = 40 Milliarden.
Das Wachstum ist nicht linear – es ist quadratisch.
Analogie: Ein Raum voller Menschen
Stellen Sie sich einen Raum voller Menschen vor. Jeder Mensch ist ein Token. Damit jeder den
vollständigen Kontext des Gesprächs versteht, muss jeder Mensch mit jedem anderen sprechen.
Wenn 10 Personen im Raum sind – sind das 100 Gespräche (10 × 10). Wenn 100 Personen –
sind es bereits 10.000 Gespräche. Wenn 1.000 – eine Million. Die Anzahl der Personen verdoppelt –
die Anzahl der Gespräche vervierfacht sich. Das ist die quadratische Komplexität: O(n²).
Stellen Sie sich nun vor, jedes "Gespräch" ist eine Berechnung auf der GPU, die Zeit und Speicher beansprucht.
Es wird klar, warum die Erhöhung des Kontexts von 4K auf 200K
Token nicht nur "50-mal mehr", sondern 2.500-mal teurer in Bezug auf die Berechnungen ist.
Was passiert im Inneren: Self-Attention
In technischen Begriffen geschieht dies im Self-Attention-Mechanismus,
der das Herzstück der Transformer-Architektur bildet. Für jeden Token berechnet das Modell
drei Vektoren – Query (Anfrage), Key (Schlüssel) und Value (Wert).
Dann wird die Query jedes Tokens mit dem Key jedes anderen Tokens "verglichen",
um zu bestimmen, worauf zu achten ist. Das Ergebnis ist eine Aufmerksamkeits-Score-Matrix
der Größe n × n, wobei n die Anzahl der Token ist.
Diese Matrix wird im sogenannten KV-Cache
(Key-Value Cache) gespeichert – einem speziellen Bereich des GPU-Speichers.
Mit jedem neuen Token wächst der Cache, und er wird zum "Flaschenhals" in
Systemen mit begrenztem Speicher.
Mehr über den Aufmerksamkeitsmechanismus –
im Artikel Transformer und der Aufmerksamkeitsmechanismus: Warum KI Kontext versteht.
Was das in der Praxis bedeutet: Skalierungstabelle
| Kontext (Token) |
Aufmerksamkeitsoperationen |
~KV-Cache-Größe |
Relative Kosten |
| 4.000 (GPT-3, 2022) |
16 Millionen |
~100 MB |
1x |
| 32.000 |
1 Milliarde |
~800 MB |
64x |
| 200.000 (Claude) |
40 Milliarden |
~5 GB |
2.500x |
| 1.000.000 (Gemini) |
1 Billion |
~25+ GB |
62.500x |
Hinweis: Die KV-Cache-Größen sind Schätzungen und hängen von der spezifischen
Modellarchitektur, der Anzahl der Aufmerksamkeits-Layer und der Genauigkeit der Berechnungen ab.
Wie sich das auf echter Hardware anfühlt
Ich habe das in der Praxis erlebt, als ich mit Ollama auf meinem Mac M1 arbeitete.
Ich erhöhte das Kontextfenster von 2K auf 8K Token – und das Modell wurde merklich
langsamer, und der Aktivitätsmonitor zeigte einen Anstieg des Speichers um mehrere Gigabyte.
Als ich versuchte, einen 16K-Kontext auf einem 7B-Modell einzustellen, begann das System,
auf die Festplatte zu swappen – und die Antwort dauerte statt einer Sekunde 30+.
Das ist die gleiche quadratische Komplexität, nur im Maßstab
eines Laptops statt eines Google-Rechenzentrums. Mehr über
Speicherbeschränkungen auf schwacher Hardware –
im Artikel Ollama auf 8 GB RAM: Welche Modelle funktionieren wirklich.
Drei Mauern, die die Quadratizität erzeugt
- ✔️ Speichermauer: Der KV-Cache für 1 Million Token kann
mehr als 25 GB GPU-Speicher beanspruchen – mehr als die gesamte VRAM der meisten
Consumer-Grafikkarten. Selbst auf einer A100-GPU (80 GB) im Rechenzentrum
ist dies ein erheblicher Teil der Ressource.
- ✔️ Geschwindigkeitsmauer: Jeder neue Antwort-Token
erfordert die "Durchsicht" aller vorherigen Kontext-Token.
Bei 200.000 Kontext dauert die Generierung jedes Wortes merklich länger
als bei 4.000. Der Benutzer spürt dies als Verzögerung vor Beginn
der Antwort (Time to First Token).
- ✔️ Kostenmauer: Mehr Berechnungen = mehr
GPU-Zeit = höhere Kosten pro Anfrage. Deshalb berechnen API-Anbieter
für Eingabe-Token, und einige (z. B. Anthropic) verlangen
doppelte Kosten, wenn der Kontext einen bestimmten Schwellenwert überschreitet.
Fazit: Quadratische Komplexität ist kein Problem,
das einfach durch Hinzufügen von Servern gelöst werden kann. Es ist eine grundlegende
mathematische Eigenschaft der Transformer-Architektur, die sowohl auf einem Laptop mit 8 GB RAM
als auch in einem Google-Rechenzentrum mit Tausenden von GPUs gleichermaßen wirkt.
Deshalb investieren Unternehmen Millionen in die Erforschung alternativer Architekturen –
und deshalb bleibt RAG eine praktischere Lösung
als die endlose Erhöhung des Kontexts.
🎯 Lost in the middle: чому AI краще пам'ятає початок і кінець
Коротка відповідь:
Навіть якщо модель технічно може обробити 200K або 1M токенів,
інформація в середині контексту запам'ятовується гірше, ніж на початку
або в кінці. Дослідження показують падіння точності на 20–50%
для інформації з середини довгого контексту. Це не баг конкретної
моделі — це фундаментальна властивість архітектури трансформера.
Уявіть, що вам дали книгу на 500 сторінок і попросили
знайти одну конкретну фразу. Ви добре пам'ятаєте вступ і останній
розділ — але що було на сторінці 247? Те саме відбувається з AI.
Психологи називають це "ефектом серійної позиції" —
і виявляється, LLM страждають від нього так само, як і люди.
Це явище отримало назву "lost in the middle" після
фундаментального дослідження Стенфорда і Університету Вашингтона
(Liu et al., 2023).
Автори тестували моделі на двох задачах: пошук відповіді серед кількох
документів і витягування пар ключ-значення з довгого списку.
В обох випадках вони виявили U-подібну криву: точність найвища,
коли релевантна інформація знаходиться на початку або в кінці
контексту, і суттєво падає, коли вона опиняється посередині.
Причому ефект спостерігався у всіх протестованих моделях — від GPT-3.5
до GPT-4 і Claude.
Конкретні цифри: наскільки серйозна проблема
За даними
Chroma Research (2025),
яке тестувало 18 фронтірних моделей включаючи GPT-4.1, Claude Opus 4
і Gemini 2.5:
- ✔️ Інформація на початку і в кінці контексту: точність 85–95%
- ⚠️ Інформація в середині: точність падає до 76–82%
- ❌ При контексті 100K+ токенів: загальне падіння точності 20–50% порівняно з 10K
- ✔️ Claude-моделі деградують найповільніше, але жодна модель не є імунною
Окреме дослідження Du et al. (2025) довело ще тривожніший факт:
навіть коли нерелевантні токени замінювали порожніми пробілами і модель
змушували "дивитися" лише на релевантну інформацію — продуктивність
все одно падала на 13.9–85% зі збільшенням довжини контексту.
Це означає, що проблема не лише у "відволіканні" — сам обсяг
токенів заважає моделі мислити ефективно.
Чому це відбувається: архітектурні причини
Дослідники
MIT (2025)
знайшли конкретний механізм. Вони створили теоретичний фреймворк для
аналізу потоку інформації у трансформері і виявили дві причини:
- ✔️ Маски уваги (attention masking): каузальна маска
в трансформері дозволяє токенам "дивитися" лише на попередні.
Це створює природне упередження — останні токени мають доступ
до найбільшої кількості контексту, перші — отримують найбільше
уваги від наступних.
- ✔️ Позиційні кодування (positional encodings):
методи типу RoPE (Rotary Position Embedding) поступово
"згасають" з відстанню — чим далі два токени один від одного,
тим слабший їхній зв'язок. Токени в середині виявляються
достатньо далеко і від початку, і від кінця.
Результат — U-подібна крива уваги: сильний фокус на початку
(primacy bias), сильний фокус на кінці (recency bias),
і "сліпа зона" посередині.
Чому це важливо для практики
Коли ти ведеш довгу розмову з Claude або ChatGPT, твої ранні
повідомлення поступово "провалюються" в середину контексту.
Нові повідомлення завжди в кінці, системний промпт — на початку.
А от важливі деталі, які ти пояснив на 15-му повідомленні —
опиняються саме в тій зоні, де модель працює найгірше.
Я помітив це на власному досвіді: під час довгих сесій роботи
з Claude, коли ми обговорювали архітектуру Spring Boot проєкту,
модель починала "забувати" рішення, прийняті на початку розмови.
Допомагало одне — періодично повторювати ключові деталі
або починати нову розмову з резюме попередньої.
Практичні рекомендації
- ✔️ Для довгих розмов: періодично нагадуйте моделі
ключові деталі або починайте нову розмову з короткого резюме
- ✔️ Для RAG-систем: якщо завантажуєте кілька документів
у контекст, ставте найважливіші першими або останніми — ніколи
не в середину
- ✔️ Для промптів: основну інструкцію — на початку
(системний промпт), конкретне завдання — в кінці (user message).
Середину залишайте для допоміжного контексту, який менш критичний
- ✔️ Для розробників: використовуйте re-ranking
у RAG-пайплайні — переупорядковуйте документи за релевантністю
перед вставкою в контекст
Детальніше про різницю між підходами і коли що обирати —
у статті LLM vs RAG у 2026 році: чому це не одне й те саме і коли що використовувати.
Висновок: Рекламоване контекстне вікно і реальна
ефективність — це різні речі. Модель з 200K контексту, яка стабільно
працює на всьому діапазоні, на практиці цінніша за модель з 1M,
яка "губить" середину. А найкращий спосіб боротися з проблемою —
не збільшувати контекст, а зменшувати його через RAG і стиснення,
подаючи моделі лише те, що їй дійсно потрібно.
🎯 Порівняння: Claude vs GPT vs Gemini — хто скільки пам'ятає
Коротка відповідь:
Розміри контекстних вікон у 2026 році: Claude Opus 4.6 — 200K токенів
(1M у бета), GPT-5.4 — до 1M, Gemini 3 Pro — до 2M+.
Але рекламований розмір і реальна ефективність — різні речі.
Більше контекстне вікно — як більший рюкзак.
Ти можеш покласти більше речей, але знайти потрібну
стає все складніше.
| Модель |
Контекст |
Ефективний діапазон* |
Ціна (input/1M токенів) |
Сильна сторона |
| Claude Opus 4.6 |
200K |
~190K (стабільно) |
~$15 |
Найменша деградація якості |
| Claude Sonnet 4 |
200K (1M бета) |
~180K |
~$3 |
Баланс ціни і якості |
| GPT-5.4 |
1M (API) |
~400K |
~$1.50 |
Великий обсяг, доступна ціна |
| GPT-4.1 |
1M (API) |
~600K |
~$2 |
Кодинг, великі кодові бази |
| Gemini 2.5 Pro |
1M |
~700K |
~$1.25 |
Мультимодальність |
| Gemini 3 Pro |
2M+ |
~1M |
~$12 |
Максимальний обсяг |
| Llama 4 Scout |
10M |
залежить від інфраструктури |
безкоштовно (self-hosted) |
Open-source, data sovereignty |
* "Ефективний діапазон" — приблизний обсяг, на якому модель
зберігає стабільну якість без значної деградації. Базується на даних
Elvex,
AIMultiple
та Morph.
Реальна продуктивність залежить від задачі і типу контенту.
Важливий нюанс: прихована доплата за довгий контекст
Деякі провайдери стягують підвищену ціну, коли контекст перевищує
певний поріг. Наприклад, за даними
Morph,
Anthropic бере подвійну ціну за input-токени і 1.5x за output,
коли контекст Claude перевищує 200K у бета-режимі 1M.
Це логічно — довший контекст потребує більше обчислень.
Висновок: Обирай модель не за максимальним розміром
контексту, а за ефективним діапазоном і стабільністю на твоїх задачах.
200K стабільних токенів часто корисніші за 1M з деградацією якості.
🎯 Чотири способи обійти обмеження контексту
Коротка відповідь:
Замість того, щоб чекати нескінченного контексту, індустрія
розробила кілька підходів: RAG (зберігати інформацію зовні і
підтягувати за запитом), стиснення контексту, оптимізовані архітектури
attention і принципово нові архітектури без attention взагалі.
Кожен підхід має свої trade-off — і на практиці найкращий результат
дає їхня комбінація.
1. RAG (Retrieval-Augmented Generation) — зовнішня пам'ять
Ідея проста: замість того, щоб засовувати все в контекст,
інформація зберігається у векторній базі даних. Коли приходить
запит — з бази витягуються лише релевантні фрагменти і вставляються
в контекст. Вікно залишається маленьким, але модель "знає" потрібне.
Я реалізував саме такий підхід на
WebsCraft:
замість того, щоб завантажити всі 500 статей блогу в контекст моделі,
я зберігаю їх у pgvector і підтягую лише 3–5 найрелевантніших
фрагментів на кожен запит. Контекст залишається ~2000 токенів
замість мільйонів — і відповідь приходить за секунду, а не за хвилину.
Переваги: дешево (маленький контекст = менше токенів = менше грошей),
швидко (менше обчислень), точно (модель бачить лише релевантне,
немає "шуму" від нерелевантної інформації).
Обмеження: якість залежить від якості пошуку.
Якщо система витягне неправильні фрагменти — модель дасть неправильну
відповідь. Потрібна ретельна настройка чанкінгу, ембедінгів
і порогу релевантності.
Детальніше про різницю між підходами —
у статті LLM vs RAG у 2026 році: чому це не одне й те саме і коли що використовувати.
А про архітектуру production-ready RAG-систем —
у повному гайді по RAG.
2. Стиснення контексту (Context Compression)
Не всі токени в контексті однаково корисні. Слова типу "і", "в",
"також" несуть мінімум інформації, але займають місце в контекстному
вікні. Методи стиснення знаходять і видаляють такі неінформативні
токени, залишаючи лише суть.
Найвідоміший метод — LLMLingua від Microsoft.
Він використовує малу мовну модель (наприклад GPT-2) для оцінки
"сюрпризності" (perplexity) кожного токена. Токени з низькою
інформативністю видаляються. Результат — стиснення до 20x
з мінімальною втратою якості.
Для RAG-систем існує розширена версія — LongLLMLingua.
Вона додатково враховує запит користувача при стисненні і
переупорядковує документи в контексті — ставлячи найрелевантніші
на початок і кінець. Це безпосередньо допомагає з проблемою
"lost in the middle", про яку ми говорили у розділі 3.
За даними дослідників, точність зросла на 21.4%
при використанні в 4 рази меншої кількості токенів.
Переваги: працює з будь-якою моделлю без зміни архітектури,
суттєво зменшує витрати на API.
Обмеження: додає етап обробки перед кожним запитом,
є ризик видалити важливий токен, який виглядає "неважливим"
для малої моделі-компресора.
3. Оптимізований Attention (Flash Attention, Sparse Attention, Ring Attention)
Цей підхід не змінює архітектуру трансформера — він оптимізує
обчислення всередині неї. Три основних методи:
Flash Attention — перебудовує порядок обчислень attention,
щоб мінімізувати обмін даними між GPU-пам'яттю і кешем процесора.
На практиці це дає прискорення в 2–4 рази і значне зменшення
споживання пам'яті — без жодної зміни в якості відповідей.
Flash Attention вже вбудований у більшість сучасних моделей.
Sparse Attention — замість того, щоб кожен токен
"дивився" на кожен інший (повний attention), дозволяє дивитися
лише на підмножину: сусідні токени + кілька "глобальних" опорних
точок. Це знижує складність з O(n²) до O(n√n) або навіть O(n log n).
Компроміс: модель може пропустити далекі, але важливі зв'язки.
Ring Attention — розподіляє довгу послідовність
між кількома GPU, де кожен GPU обробляє свій фрагмент і передає
результати по кільцю. Це дозволяє масштабувати контекст пропорційно
до кількості GPU. Саме цей підхід стоїть за мільйонними контекстними
вікнами Gemini.
Переваги: не змінюють якість моделі, працюють з існуючими
архітектурами, дають суттєве прискорення.
Обмеження: не вирішують фундаментальну проблему
квадратичної складності — лише зсувають стіну далі. При достатньо
великому контексті O(n²) все одно переможе.
4. Нові архітектури без attention (Mamba, RWKV, State Space Models)
Найрадикальніший підхід — відмовитися від attention взагалі
і побудувати модель на іншій математичній основі.
Mamba (State Space Models) — обробляє послідовності
лінійно: O(n) замість O(n²). Кожен токен оброблюється один раз,
і модель підтримує "стан" (state), який акумулює інформацію
про попередні токени. Це схоже на те, як людина читає книгу —
не перечитуючи кожну сторінку при кожному новому абзаці,
а тримаючи "резюме прочитаного" в голові.
RWKV — рекурентна архітектура з продуктивністю
трансформера. Поєднує переваги RNN (лінійна складність) і
трансформерів (якість генерації). Модель може працювати навіть
на слабкому залізі завдяки низьким вимогам до пам'яті.
Переваги: теоретично необмежений контекст,
лінійне масштабування, значно менше споживання пам'яті.
Обмеження: поки поступаються трансформерам за якістю
на складних задачах — reasoning, аналіз довгих документів, кодинг.
Це активна область досліджень. Деякі нові моделі (Jamba від AI21)
комбінують Mamba з трансформерними шарами, намагаючись отримати
найкраще з обох світів.
Зведена таблиця підходів
| Підхід |
Складність |
Якість |
Зрілість |
Найкраще для |
| RAG |
Не залежить від контексту |
Висока (якщо добрий retrieval) |
Production-ready |
Великі бази знань, документи |
| Стиснення |
O(n) на стиснення |
Висока (до 20x стиснення) |
Production-ready |
Довгі розмови, оптимізація витрат |
| Flash/Sparse Attention |
O(n²) → O(n√n) |
Без втрат |
Вбудовано в моделі |
Загальне прискорення |
| Mamba/RWKV |
O(n) |
Нижча на складних задачах |
Дослідження / ранній production |
Потенційно — все |
Висновок: Жоден метод не є ідеальним.
RAG — найпрактичніший прямо зараз і перевірений у production.
Стиснення — ефективний доповнювач, який до того ж економить гроші.
Оптимізований attention — вже вбудований у моделі, які ти використовуєш.
Нові архітектури — потенційне майбутнє, яке може зробити все вищесказане
неактуальним. Найефективніший підхід у 2026 — комбінація:
RAG для основної інформації + оптимізований довгий контекст
для поточної розмови.
🎯 Wie viel kostet es: von einer Google-Anfrage bis zur Skalierung
Kurze Antwort:
Jeder Token im Kontext ist eine reale GPU-Berechnung, für die jemand
bezahlt. Eine Anfrage an ChatGPT kostet ca. 0,001–0,01 $. Multiplizieren Sie dies mit
Milliarden von Anfragen von Google AI Overviews – und Sie werden verstehen, warum Unternehmen
die Kontextgröße so sorgfältig optimieren.
Wenn Sie ChatGPT fragen: „Wie ist das Wetter?“ – das kostet
einen Bruchteil eines Cents. Wenn Sie ein 100-seitiges Dokument hochladen
und 20 Fragen stellen – das sind bereits Dutzende von Cents. Im Maßstab
von Google sind das Millionen von Dollar pro Tag.
Kosten einer einzelnen Anfrage
Eine typische Anfrage an einen KI-Chatbot besteht aus etwa 500–2000 Eingabe-Tokens
(Ihre Anfrage + System-Prompt + Kontext) und 200–500 Ausgabe-Tokens
(Antwort). Bei einem Preis von Claude Sonnet von ca. 3 $ pro 1 Mio. Eingabe-Tokens:
- ✔️ Einfache Anfrage (1K Tokens): ~$0.003
- ✔️ Anfrage mit Dokumentenkontext (10K Tokens): ~$0.03
- ✔️ Langes Gespräch (100K Tokens): ~$0.30
- ⚠️ Maximaler Kontext (200K Tokens): ~$0.60
Beachten Sie: Das gleiche Gespräch wird mit jeder Nachricht teurer,
da das Modell jedes Mal den gesamten vorherigen Kontext „erneut liest“.
Google AI Overviews: Skalierung der Kosten
Google verarbeitet täglich etwa 8,5 Milliarden Suchanfragen.
AI Overviews (KI-generierte Antworten am oberen Rand der Ergebnisse) werden
bei etwa 10–15 % der Anfragen angezeigt – das sind ~1 Milliarde KI-Generierungen pro Tag.
Selbst bei den internen Kosten von Google (eigene TPU-Chips, eigenes
Gemini-Modell) – bei 0,0001 $ pro Anfrage × 1 Milliarde = etwa
100.000 $ pro Tag oder ~36 Millionen $ pro Jahr allein für KI-Antworten in der Suche.
Zum Vergleich: Ich habe einen RAG-Bot für die Suche in Artikeln auf
WebsCraft erstellt –
bei 100 Anfragen pro Tag kostet er mich ~2 $ pro Monat.
Die gleiche Technologie wie bei Google AI Overviews – der Unterschied
liegt nur im Maßstab von 10 Millionen Mal.
Warum lokales KI drastisch günstiger ist
Wenn Sie ein Modell über
Ollama auf Ihrem Computer ausführen –
ist das Kontextfenster auf den RAM beschränkt, aber die Kosten jeder Anfrage = 0 $.
Keine API-Tarife, keine zu bezahlenden Tokens. Sie haben bereits für Ihre Hardware
„bezahlt“ – und können eine unbegrenzte Anzahl von Anfragen stellen.
Deshalb ist für regelmäßige Aufgaben mit vertraulichen Daten
lokales KI über Ollama – die optimale Wahl in Bezug auf die Kosten.
Mehr dazu – im Artikel Wie viel kostet KI: Tokens, GPUs und warum Google Millionen ausgibt.
Fazit: Das Kontextfenster ist nicht nur eine technische Einschränkung,
sondern ein finanzieller Multiplikator. Je länger das Gespräch und je größer der Kontext – desto
teurer ist jede nachfolgende Anfrage. Die Optimierung der Kontextgröße (durch
RAG, Komprimierung oder intelligentes Gesprächsmanagement) ist nicht nur
eine Verbesserung der Qualität, sondern auch eine direkte Geldeinsparung.
❓ Häufig gestellte Fragen (FAQ)
Was ist ein Kontextfenster in einfachen Worten?
Es ist die maximale Textmenge, die eine KI gleichzeitig „sehen“ kann.
Sie umfasst Ihre Anfrage, das gesamte vorherige Gespräch und Systemanweisungen.
Sie wird in Tokens gemessen – Textfragmenten, von denen jeder ungefähr
0,7 Wörtern im Englischen oder 0,3–0,5 Wörtern im Ukrainischen entspricht.
Warum vergisst ChatGPT, was ich vorher gesagt habe?
Wenn das Gespräch das Kontextfenster überschreitet – die ältesten Nachrichten
„fallen heraus“. Selbst innerhalb des Fensters erinnert sich das Modell schlechter an Informationen
aus der Mitte (Effekt „lost in the middle“). Für lange Gespräche hilft es,
wichtige Details gelegentlich zu wiederholen oder ein neues Gespräch
mit einer Zusammenfassung des vorherigen zu beginnen.
Welches Kontextfenster haben Claude, ChatGPT und Gemini?
Stand März 2026: Claude Opus 4.6 – 200K Tokens
(~500 Seiten), GPT-5.4 – bis zu 1M über API, Gemini 2.5 Pro – 1M,
Gemini 3 Pro – 2M+. Aber die beworbene Größe und der effektive Bereich –
sind unterschiedliche Dinge. Mehr dazu – in Abschnitt 4 dieses Artikels.
Warum ist RAG immer noch relevant, wenn es Millionen-Kontexte gibt?
Drei Gründe: Kosten (das Laden von einer Million Tokens für jede
Anfrage ist teuer), Qualität (lost in the middle reduziert die Genauigkeit), Geschwindigkeit
(längerer Kontext = langsamere Antwort). RAG liefert nur relevante
Fragmente – günstig, schnell, genau.
Mehr dazu – im Artikel
LLM vs RAG.
Kann man das Kontextfenster in Ollama erhöhen?
Ja, über den Parameter num_ctx in der Modelfile oder die Variable
OLLAMA_CTX_SIZE. Aber auf einem System mit 8 GB RAM kann eine Erhöhung
des Kontexts über 4096 Tokens hinaus zu einem Swap auf die Festplatte
und einer deutlichen Verlangsamung führen. Mehr dazu –
im Artikel Ollama auf 8 GB RAM.
Wie viel kostet ein langes Gespräch mit ChatGPT über die API?
Der Preis steigt mit jeder Nachricht, da das Modell den gesamten
vorherigen Kontext erneut liest. Ein Gespräch über 100K Tokens über Claude Sonnet
kostet ca. 0,30 $ pro Anfrage. Über GPT-5.4 – ca. 0,15 $.
Zur Kostenoptimierung verwenden Sie RAG oder Kontextkomprimierung.
✅ Schlussfolgerungen
Das Kontextfenster ist eine grundlegende Eigenschaft von LLMs,
die alles beeinflusst: die Qualität der Antworten, die Generierungsgeschwindigkeit und die Kosten
jeder Anfrage. Hier sind die wichtigsten Punkte:
- ✔️ Kontextfenster = „Schreibtisch“ der KI: alles, was das Modell gleichzeitig sehen kann. Wenn der Schreibtisch voll ist – fällt das Alte auf den Boden.
- ✔️ Quadratische Komplexität: eine Verdoppelung des Kontexts erhöht die Kosten um das 4-fache, nicht um das 2-fache. Dies ist eine grundlegende Einschränkung der Transformer-Architektur.
- ✔️ Lost in the middle: KI erinnert sich besser an den Anfang und das Ende des Textes. Informationen aus der Mitte können „verloren gehen“ – ein Genauigkeitsabfall von 20–50 %.
- ✔️ Mehr ≠ besser: 200K stabile Tokens (Claude) sind oft praktischer als 1M+ mit Degradation (Gemini).
- ✔️ RAG bleibt relevant: Selbst mit Millionen-Kontexten ist RAG günstiger, schneller und genauer für die Arbeit mit großen Datenmengen.
- ✔️ Jeder Token kostet Geld: längeres Gespräch = teurere jede nachfolgende Anfrage. Kontextoptimierung ist eine direkte Einsparung.
Ich selbst verwende einen kombinierten Ansatz: RAG für die Suche in Blog-Artikeln
(Kontext ~2000 Tokens) und einen langen Kontext für detaillierte
Gespräche mit Claude, wo eine tiefe Historie benötigt wird. Dies ist die effektivste
Strategie im Jahr 2026 – nicht auf unendlichen Kontext warten, sondern den
vorhandenen intelligent verwalten.
Wenn Sie andere Aspekte der LLM-Arbeit verstehen möchten –
wie KI Text durch Tokens sieht,
wie sie Antworten mithilfe des Attention-Mechanismus generiert,
und warum RAG immer noch relevanter als langer Kontext ist –
lesen Sie die entsprechenden Artikel des Clusters.
Und wenn Sie eine Website oder eine Webanwendung mit integrierter
KI-Funktionalität benötigen – RAG-Suche, Chatbot oder Analytik –
kontaktieren Sie uns bei WebsCraft,
wir helfen Ihnen bei der Umsetzung.
📖 Quellen