AI-инжиниринг

Токены и Context Window: почему LLM забывает и как с этим жить

Цели урока

Понять алгоритм BPE и почему разные языки требуют разного количества токенов
Научиться считать токены с помощью tiktoken и оценивать стоимость запросов
Разобраться в ограничениях context window и проблеме «Lost in the Middle»
Освоить стратегии работы с длинным контекстом: truncation, sliding window, summarization, RAG
Научиться планировать token budget для production-систем

Cursor IDE - IDE с AI-ассистентом за 10 USD/месяц. При наивном подходе (отправлять весь проект в каждый запрос) себестоимость была бы 100+ USD/месяц. Cursor решила задачу token management: sliding window, умный выбор контекста, агрессивное кэширование. Разница между прибыльным и убыточным продуктом - это понимание токенов.

Stripe оптимизировал промпты и сократил расходы на API на 40% - просто убрав избыточные токены
Notion AI работает с базами знаний на миллионы слов через RAG, а не через гигантский контекст
Cursor IDE использует sliding window + summarization для сохранения контекста в больших проектах - иначе продукт был бы убыточен при 10 USD/мес
Русские промпты на 30-50% дороже английских из-за особенностей BPE - это не опечатка, это математика

Sennrich и нейронный BPE

В 2016 году Rico Sennrich из Эдинбургского университета адаптировал алгоритм BPE (Byte Pair Encoding, предложенный в 1994 году для сжатия данных) для нейронного машинного перевода. Работа 'Neural Machine Translation of Rare Words with Subword Units' позволила системам перевода обрабатывать редкие и незнакомые слова - вместо '<UNK>' токена. GPT, BERT, Claude, LLaMA - все используют BPE или его вариации. Алгоритм для сжатия данных 1994 года стал основой токенизации в LLM.

Предварительные знания

How LLMs Work: Tokens, Embeddings, Attention

BPE: как модель разбивает текст на токены

**Разница между 50 USD/мес и 5000 USD/мес на одном и том же продукте** - это понимание того, как именно текст превращается в числа. 1 токен - это ~4 символа или ~0.75 слова. GPT-4o context window - 128K токенов. Это ~96K слов - весь «Властелин колец» умещается с запасом. Но стоит 32 цента если забить под завязку. Stripe, по имеющимся данным, сократил расходы на AI на 40% просто начав анализировать usage.

LLM не читает символы и не читает слова. Читает **токены** - фрагменты, которые получаются через **Byte Pair Encoding (BPE)**. Этот алгоритм лежит в основе токенизаторов GPT, Claude и большинства современных LLM. Он определяет, сколько будет стоить каждый запрос.

Токенизатор	Модель	Размер словаря
cl100k_base	GPT-4, GPT-4o	~100 000
o200k_base	GPT-4o-mini	~200 000
Claude tokenizer	Claude 3/3.5/4	~100 000
SentencePiece	LLaMA, Mistral	32 000 - 128 000

Практическое следствие BPE: **разные языки имеют разную «плотность»**. Английский, на котором обучалось большинство моделей, токенизируется компактно. Русский, китайский, арабский - требуют больше токенов для того же объёма информации. Русскоязычные промпты обходятся дороже - это не баг, это математика.

Почему слово "unhappiness" разбивается на 3 токена, а "cat" - на 1?

Подсчёт токенов: tiktoken и практические инструменты

KV-cache - причина почему контекст стоит деньги. Каждый токен в истории - это матрица, которая хранится в GPU-памяти всё время генерации. Отправить 100K токенов = занять 8-16 GB VRAM только на «оперативную память» диалога. Вот почему input-токены не бесплатны и почему считать их - инженерная обязанность, не опция.

Модель	Input (за 1M токенов)	Output (за 1M токенов)	Примерная стоимость 1 запроса
GPT-4o	2.50	10.00	0.01 USD - 0.05 USD
GPT-4o-mini	0.15	0.60	0.0005 USD - 0.003 USD
Claude 3.5 Sonnet	3.00	15.00	0.01 USD - 0.08 USD
Claude 3.5 Haiku	0.80	4.00	0.003 USD - 0.02 USD

**Output-токены всегда дороже input-токенов** (в 3-5 раз). Поэтому ограничение `max_tokens` в API - не только про длину ответа, но и про бюджет. Запрос «напиши эссе на 2000 слов» обойдётся в 10 раз дороже, чем «ответь одним словом».

API-запрос к GPT-4o использовал 500 prompt_tokens и 1000 completion_tokens. Какая часть стоимости приходится на output?

Context Window: граница памяти LLM

Context window - это **максимальное количество токенов** в одном вызове. Сюда входит всё: system prompt, история диалога, пользовательский запрос **и** ответ модели. Не «входящее» и «исходящее» отдельно - всё вместе, в одной корзине.

Модель	Context Window	≈ страниц текста	≈ строк кода
GPT-3.5	4K / 16K	6 - 24	200 - 800
GPT-4o	128K	190	6 400
Claude 3.5 Sonnet	200K	300	10 000
Gemini 1.5 Pro	1M / 2M	1 500 - 3 000	50 000 - 100 000

128K токенов звучит огромно. На практике context window заполняется быстрее, чем кажется - особенно когда пользователь начинает вставлять файлы и код. Один файл на 500 строк = ~3000 токенов = 2.3% контекста GPT-4o.

**«Lost in the Middle» problem.** Исследования (Liu et al., 2023) показывают: LLM хуже работает с информацией из **середины** длинного контекста. Начало и конец обрабатываются лучше. Просто увеличить context window - не серебряная пуля. Важнее правильно расположить критическую информацию.

Ещё одна ловушка: **стоимость растёт линейно** с размером контекста. Отправить 100K токенов в GPT-4o - 25 центов за один запрос. Если пользователь задаёт 50 вопросов в час - 12.50 USD/час только на одного человека. Cursor IDE и Copilot решают эту задачу через агрессивный token management.

Больше context window = умнее модель и лучше ответы

Context window - это объём рабочей памяти, не показатель интеллекта. Gemini с 2M токенов не умнее GPT-4o с 128K - просто держит больше текста за раз

«Lost in the Middle» problem доказывает обратное: слишком длинный контекст снижает качество на информации из середины. Умная архитектура с RAG и 8K токенов часто бьёт наивный «вали всё в контекст» с 200K.

System prompt занимает 1000 токенов, max_tokens = 4096, context window = 128K. Пользователь отправляет документ на 130 000 токенов. Что произойдёт?

Стратегии работы с длинным контекстом

Рано или поздно данные перестают помещаться. Netflix обрабатывает описания тысяч фильмов. Stripe анализирует длинные цепочки транзакций. Notion AI работает с базами знаний на миллионы слов. Ни один из них не «вываливает всё в контекст». Это дорого, медленно и работает хуже, чем кажется.

**В production обычно комбинируют подходы.** Например: sliding window для chat-истории + RAG для базы знаний + summarization для длинных диалогов. Cursor IDE делает именно это - и за счёт этого остаётся рентабельным при 10 USD в месяц.

Чат-бот для техподдержки использует базу знаний из 10 000 статей. Какая стратегия работы с контекстом подходит лучше всего?

Token Budgeting: контроль расходов в production

Token budgeting - практика распределения context window между компонентами запроса. Без чёткого бюджета система сама себя съедает: system prompt раздулся до 5000 токенов, RAG-контекст занял ещё 20000, на ответ осталось 200 токенов - модель генерирует обрезанную чепуху. Не потому что плохая. Просто кончилось место.

Мониторинг token usage - обязательная часть production-системы. Без него невозможно контролировать затраты и предсказывать масштабирование. Stripe, по имеющимся данным, сократил расходы на AI на 40% просто начав логировать и анализировать usage - без единого изменения в промптах.

**Три главных метрики для мониторинга:** 1. средняя стоимость запроса по модели и endpoint 2. процент запросов, достигающих token limit 3. соотношение input/output токенов. Аномалии в этих метриках - первый сигнал проблемы.

В production чат-боте с RAG история диалога растёт с каждым сообщением. Какая стратегия управления контекстом наиболее правильная?

Ключевые концепции

BPE (Byte Pair Encoding) - алгоритм, который итеративно объединяет частые пары символов. Частые слова = 1 токен, редкие разбиваются. tiktoken воспроизводит это точно
Русский текст на 30-50% дороже английского - KV-cache хранит каждый токен в GPU-памяти, поэтому это реальные деньги
Context window = system prompt + history + query + response. Всё вместе. Превышение = ошибка API, не «обрезка»
Output-токены в 3-5 раз дороже input-токенов. max_tokens - это рычаг бюджета, не только длины
«Lost in the Middle» - больше контекста не значит лучше. Информация из середины обрабатывается хуже
4 стратегии: truncation (просто), sliding window (умнее), summarization (дорого), RAG (масштабируется). В production - комбинация

Вопросы для размышления

Cursor IDE продаётся за 10 USD/месяц. Если бы они не решили задачу токенов - себестоимость одного пользователя была бы 100+ USD. Как именно token budgeting и RAG меняют эту математику? Что произошло бы с бизнес-моделью Cursor без этих техник?

Что дальше

Токены и context window - фундамент для всех дальнейших тем. Следующий шаг - применить эти знания при реальных вызовах API.

Интеграция с LLM API — Применение token budgeting при реальных вызовах OpenAI/Anthropic API
RAG: Retrieval-Augmented Generation — Главная стратегия работы с данными, не помещающимися в context window

Связанные уроки