Как считать токены и не ошибиться в бюджете

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

Что такое токен

Модель не читает текст буквами. Перед обработкой текст разбивается на куски — токены, — и каждый получает свой номер в словаре.

Разбиение неравномерное. Частое слово может занять один токен целиком. Редкое — развалиться на три-четыре куска. Знаки препинания, пробелы и переводы строк тоже считаются.

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

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

Почему русский дороже

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

Словари токенизаторов строятся на корпусах, где английского значительно больше. Английские слова и их части попадают в словарь целиком, русские — заметно реже. В результате русское слово чаще разбивается на несколько токенов там, где английское занимает один.

Порядок величин, полезный для прикидки: для русского текста один токен — это примерно два-три символа. Для английского соотношение заметно выгоднее.

Что из этого следует:

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

Смена языка меняет счёт. Если продукт работает и с русским, и с английским, это две разные экономики.

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

Ориентиры для прикидки

Грубые величины для русского текста, с оговоркой, что это именно грубые.

Пользоваться этим стоит только для предварительной оценки — «влезет ли вообще» и «какой порядок расхода». Для бюджета нужны фактические цифры.

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

Самая частая причина расхождения между расчётом и счётом.

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

Изображения. В мультимодальных запросах картинка тратит токены щедро: страница скана в исходном разрешении — это сотни или тысячи токенов. Окно контекста в таких сценариях кончается по картинкам, а не по буквам.

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

Системный промпт. Тоже уходит каждый раз. Промпт на тысячу токенов при десяти тысячах запросов в день — это десять миллионов входных токенов в сутки.

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

Последний пункт особенно коварен: видимый ответ в три предложения мог стоить как страница текста.

Как считать правильно

Единственный надёжный способ — брать фактические цифры из ответа API. Они возвращаются с каждым запросом, отдельно для входа и для выхода.

Порядок, который даёт настоящий бюджет.

1. Возьмите десяток типичных задач из своих логов. Не придуманных.
2. Прогоните и запишите фактические токены — вход и выход раздельно.
3. Посчитайте средний расход на задачу и девяносто пятый процентиль. Второе важнее: по нему видно, что происходит на тяжёлых случаях.
4. Умножьте на ожидаемое число задач в месяц.
5. Добавьте запас на повторы. В реальной эксплуатации часть обращений уходит впустую.

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

Пример расчёта до конца

Соберём всё вместе на сквозном примере, чтобы был ориентир.

Задача: бот отвечает на вопросы по базе знаний. На каждый вопрос уходит системный промпт, три подставленных фрагмента и сам вопрос; ответ короткий.

Вход. Системный промпт 400 токенов, три фрагмента по 500 — это 1500, вопрос пользователя 50. Плюс служебный контекст маршрута, скажем 2000. Итого около 3950 входных токенов.

Выход. Ответ на 200 токенов.

На модели за 3 ₽ за миллион в обе стороны получаем: (3950 + 200) × 3 / 1 000 000 — доли копейки за вопрос. Тысяча вопросов в день — единицы рублей в сутки.

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

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

И обратный пример для контраста. Задача генерации: промпт 300 токенов, ответ на 3000. Здесь всё наоборот — 90% счёта в выходе, и единственный рычаг это ограничение длины ответа.

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

Как уменьшить расход

Четыре рычага, по убыванию отдачи.

Обрезайте историю диалога. В агентских сценариях она растёт квадратично: удвоение числа шагов учетверяет расход на историю — механика с числами.

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

Сокращайте подставляемые документы. Три уверенных фрагмента лучше десяти на всякий случай — и дешевле, и точнее.

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

Чего делать не стоит: оптимизировать промпт на асимметричной модели, где счёт определяет выход. Там работает только ограничение ответа.

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

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

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

Мы не публикуем формулу подсчёта. Её нет: разбиение задаёт словарь конкретной модели, и единственный способ узнать точное число — отправить запрос и прочитать ответ.

Величина служебного контекста в примере условная. Она различается между семействами на порядок; своё значение смотрите в поле каталога и проверяйте фактическим запросом.

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

Токен — не символ и не слово, а для русского текста это примерно два-три символа. Прикидка по символам годится только чтобы понять порядок; бюджет считается по фактическим цифрам из ответа API.

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

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