LLM-Kontextfenster: Warum KI vergisst und was es kostet

Aktualisiert:
LLM-Kontextfenster: Warum KI vergisst und was es kostet

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.

LLM-Kontextfenster: Warum KI vergisst und was es kostet

🎯 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 для основної інформації + оптимізований довгий контекст для поточної розмови.

LLM-Kontextfenster: Warum KI vergisst und was es kostet

🎯 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

Останні статті

Читайте більше цікавих матеріалів

Як керувати контекстом AI агента: sliding window, summarization і compression з прикладами

Як керувати контекстом AI агента: sliding window, summarization і compression з прикладами

TL;DR Як ефективно керувати контекстом у довгоживучих AI-агентах: — Sliding Window + Pinning — Автоматична summarization з розумними тригерами — Compression та semantic memory З конкретними цифрами, кодом і архітектурними рішеннями, які значно підвищили стабільність агента. Ця стаття —...

Google Spam Policy 2026: маніпуляції з AI Overview тепер офіційно спам

Google Spam Policy 2026: маніпуляції з AI Overview тепер офіційно спам

15 травня 2026 року Google тихо оновив одне речення у своїй Spam Policy. Але це речення змінює правила гри для всіх хто займається контентом і SEO. Без гучних анонсів, без великої прес-конференції — просто нове формулювання на сторінці документації. Search Engine Roundtable...

Пам'ять AI агента: in-context, episodic, RAG і semantic — коли що використовувати

Пам'ять AI агента: in-context, episodic, RAG і semantic — коли що використовувати

Агент отримав запит — обробив — відповів. Наступний запит — і він не пам'ятає нічого з попереднього. Не тому що щось зламалось. А тому що так влаштована LLM за замовчуванням: кожен виклик — чистий аркуш. Якщо ви будуєте агента і не думали про пам'ять — ви будуєте амнезика з доступом до...

Grok Build від xAI: детальний технічний огляд

Grok Build від xAI: детальний технічний огляд

Grok Build — новий agentic CLI від xAI (early beta, 14 травня 2026). Головні фішки: Plan Mode з обов’язковим затвердженням плану, паралельні субагенти (до 8), контекстне вікно ~1–2M токенів та сучасний TUI на Rust. Працює на Grok 4.3, підтримує ACP, git worktree та MCP....

Ollama 0.24 + Codex App: як запустити локальний AI coding agent

Ollama 0.24 + Codex App: як запустити локальний AI coding agent

Оновлено: 15 травня 2026 14 травня 2026 вийшла Ollama 0.24 — і це не черговий патч з виправленням багів. Цей реліз додає офіційну підтримку Codex App від OpenAI: тепер десктопний AI coding agent можна запустити на будь-якій локальній або хмарній моделі через Ollama....

Tool RAG: що робити коли у агента забагато інструментів

Tool RAG: що робити коли у агента забагато інструментів

У вас 5 tools — все чудово. У вас 15 tools — починаються проблеми. У вас 50 tools — агент деградує. Але є рішення яке вирішує проблему масштабу елегантно — і ви вже знаєте як воно працює, бо використовуєте його для документів. Ця стаття — частина серії про AI агентів на Spring Boot. Якщо...