Контекстное окно модели: сколько токенов нужно

Контекстное окно — самый заметный параметр в описании модели и самый бесполезный при выборе. Миллион токенов звучит внушительно, но задачи, которым он действительно нужен, можно пересчитать по пальцам, а платите вы не за размер окна, а за то, что реально отправили. Хуже того: качество работы модели на очень длинном вводе обычно падает задолго до заявленного предела, и предел этот описывает, где запрос будет отвергнут, а не где модель перестанет справляться. Разбираем, как считать окно честно, откуда берутся токены, которых вы не отправляли, и почему сокращение контекста улучшает не только счёт, но и результат.

Что такое окно и чем оно не является

Три разграничения, которые снимают большинство недоразумений.

Окно — это предел, а не рабочий режим. Оно говорит, при каком объёме запрос будет отклонён. Ничего не обещая о качестве по дороге к этому пределу.

Окно включает ответ. Заявленный размер обычно охватывает и вход, и генерируемый выход. Планируя длинный ответ, оставьте под него место.

Окно измеряется в токенах. Не в символах и не в словах. Для русского текста соотношение хуже, чем для английского: одно и то же содержание занимает заметно больше токенов. Поэтому переносить прикидки «столько-то страниц» между языками нельзя.

Отдельно стоит помнить, что модели одного семейства могут иметь разные окна, а публичное имя иногда указывает на обновляющуюся версию, у которой параметры менялись.

Сколько это в привычных единицах

Токены плохо ложатся на интуицию, поэтому полезны грубые ориентиры. Подчеркнём: именно грубые — точное соотношение зависит от языка, темы и токенизатора конкретной модели.

Для русского текста один токен обычно соответствует примерно двум-трём символам. Отсюда прикидка: страница обычного текста — это порядка тысячи токенов, а не сотни.

Что из этого получается для типичных объёмов:

Отдельно про код: он токенизируется хуже прозы из-за отступов, скобок и длинных идентификаторов. Файл на пятьсот строк легко даёт несколько тысяч токенов.

Важная оговорка: для английского текста то же содержание занимает заметно меньше токенов. Поэтому переносить чужие расчёты, сделанные на английском, к своим русским задачам нельзя — разница бывает полуторакратной и больше. Это же объясняет, почему один и тот же лимит ощущается по-разному в зависимости от языка работы.

И ещё одно, что меняет прикидки задним числом: токенизатор может смениться между поколениями моделей. Мы фиксировали случай, когда новая линейка стала считать тот же текст примерно на треть дороже при неизменной ставке. Сравнение поколений по прайсу в такой ситуации вводит в заблуждение.

Откуда берутся токены, которых вы не отправляли

Пункт, из-за которого расчёты не сходятся чаще всего.

В prompt_tokens попадает больше, чем вы послали. К вашему запросу добавляется служебный контекст маршрута, и его величина различается между семействами на порядок — подробный разбор отдельно.

Второй источник — изображения. Одна страница скана в исходном разрешении стоит сотни или тысячи токенов, и в мультимодальных сценариях окно кончается по картинкам, а не по буквам. Мы отмечали это, разбирая компактную зрительную модель, где заявленное окно в 128 тысяч сопровождается проверенным рабочим диапазоном до восьми тысяч для запросов с картинками.

Третий — описания подключённых инструментов. Они уходят в модель при каждом обращении независимо от того, воспользуется она хоть одним. Десяток серверов с подробными описаниями — постоянный довесок, подробности про MCP.

Почему длинный контекст ухудшает результат

Самая недооценённая часть, потому что она противоречит интуиции «дам побольше, разберётся сама».

Модели неравномерно внимательны к разным частям ввода. Начало и конец обрабатываются лучше, середина хуже — и чем длиннее ввод, тем заметнее провал. Нужный факт, оказавшийся в середине стотысячного контекста, модель может просто не найти, хотя формально он ей передан.

Второй эффект — разбавление. Чем больше постороннего в контексте, тем меньше вес относящегося к делу. Модель, получившая три релевантных абзаца и сто нерелевантных, отвечает хуже, чем получившая только три.

Отсюда практическое правило, которое стоит запомнить: лишний контекст не нейтрален. Он не «на всякий случай», он активно мешает. Класть в запрос всё подряд в надежде, что модель разберётся, — не бесплатная стратегия даже без учёта денег.

Как считать честно

Порядок, который даёт реальные числа вместо ощущений.

1. Замерьте, что уходит сейчас. Логируйте prompt_tokens по типам запросов. Почти всегда обнаруживается, что средний запрос вдвое-втрое больше, чем предполагали.
2. Разложите на составляющие. Системный промпт, история, документы, описания инструментов, служебный контекст. Обычно одна составляющая доминирует, и работать надо с ней.
3. Найдите свой девяносто пятый процентиль. Средний размер запроса бесполезен: важен верхний, потому что именно он определяет, упрётесь ли вы в предел.
4. Сравните с тем, что нужно по делу. Часто выясняется, что половина контекста — это история, которую можно обрезать без потерь.

Дальше выбор модели становится осмысленным: вам нужно окно с запасом над девяносто пятым процентилем, а не максимальное из доступных. Запас разумно брать двукратный — контекст имеет свойство расти вместе с продуктом.

Про пороги у вендоров

Отдельная причина следить за длиной запроса — деньги.

У ряда вендоров ставка растёт после порога длины, и растёт для всего запроса, а не для превышения. Переход границы на несколько тысяч токенов удваивает счёт целиком. Механику разбирали в материале про двухуровневые тарифы, а на конкретном примере считали, когда порог начинает работать против вас.

В нашем каталоге порогов по длине нет ни у одной позиции: ставка одна независимо от размера запроса. Это упрощает расчёт до умножения, но не отменяет пользы от короткого контекста — он всё равно дешевле и всё равно точнее.

Что делать с длинным контекстом

Четыре приёма вместо увеличения окна.

Обрезайте историю. В агентском цикле она растёт квадратично, и это главный источник раздувания — как считать.

Подставляйте только нужные фрагменты. Вместо всей документации — найденные по запросу куски. Это и дешевле, и точнее.

Разбивайте задачу. Три коротких обращения с проверкой после каждого работают надёжнее одного длинного.

Ставьте важное в начало и в конец. Раз середина обрабатывается хуже, размещайте инструкции и ключевые данные по краям. Приём бесплатный и работает на любой модели.

Пятый приём, о котором забывают: проверьте, не отправляете ли вы одно и то же дважды. Системный промпт, продублированный в первом сообщении диалога, встречается чаще, чем можно подумать, и стоит денег при каждом обращении.

Чего мы не утверждаем

Не приводим окна конкретных моделей. Они меняются, и смотреть их нужно в документации вендора и в живой выдаче.

Не утверждаем, что длинный контекст всегда плох. Есть задачи, где иначе нельзя: разбор большого документа целиком, работа с кодовой базой. Речь о том, чтобы не использовать длину без нужды.

Деградация на длине зависит от модели. Она есть у всех, но выражена по-разному, и мерить её нужно на своей задаче: положить нужный факт в середину длинного контекста и посмотреть, найдёт ли модель его.

Соотношение символов к токенам приблизительное. Оно зависит от языка, темы и токенизатора; для точного расчёта считайте фактические значения из ответа API.

Что держать в голове

Размер окна — это предел, а не рекомендация. Платите вы за отправленное, а качество начинает падать задолго до заявленной границы.

Правильный вопрос не «какое окно у модели», а «сколько контекста нужно моей задаче в верхнем случае». Ответ на него обычно оказывается в разы меньше, чем кажется до замера, — и уменьшить его выгоднее, чем искать модель с окном побольше.

Как мы проверяем факты и почему у каждого стоит источник — на странице о проекте. Замерить свои реальные запросы можно по ключу, который заводится за минуту: keydealer.ru/login.