Токены и биллинг API — это способ считать стоимость работы модели по объёму обработанного ввода и вывода. На практике счёт обычно складывается из входных токенов, выходных токенов и, в зависимости от провайдера, отдельных тарифов на кеш, изображения, аудио или пакетную обработку. Такой подход прозрачен, но не подходит для грубого сравнения моделей только по строке «цена за 1M токенов»: реальная стоимость зависит от длины системного промпта, истории диалога, RAG-контекста, длины ответа, повторных вызовов и мультимодальности.
стоимость = input_tokens × ставка_ввода + output_tokens × ставка_вывода + прочие тарифицируемые единицы
Простыми словами
Токен — это не слово и не символ, а минимальная единица текста, с которой работает модель. Короткое слово может быть одним токеном, длинное — несколькими. Знаки препинания, пробелы и части слов тоже влияют на разбиение. Поэтому один и тот же текст на глаз может казаться маленьким, но по токенам оказаться дорогим.
Когда вы отправляете запрос в API, провайдер сначала превращает текст в токены. Затем модель обрабатывает эти токены и генерирует ответ, который тоже состоит из токенов. Биллинг опирается именно на это число, потому что оно напрямую связано с вычислительной нагрузкой.
Обычно отдельно тарифицируются:
- входные токены — всё, что вы отправили: системные инструкции, пользовательский текст, история диалога, извлечённые документы;
- выходные токены — всё, что сгенерировала модель;
- кешированные токены — если провайдер умеет учитывать повторяющийся префикс дешевле;
- нетекстовые единицы — изображения, аудио, видео или другие типы входа, если API мультимодальный.
Практический вывод простой: стоимость запроса растёт не только от размера пользовательского сообщения, но и от всего окружения вокруг него. В системах с длинным промптом, большим контекстом и многословным ответом основная цена часто скрыта не в одном сообщении пользователя, а в повторяемом служебном тексте.
Как это работает
У каждого провайдера есть своя токенизация и свои правила тарификации. Поэтому одинаковый абзац может дать разное количество токенов на разных моделях. Сравнивать стоимость нужно не по длине текста в символах, а по реальному счётчику usage в ответах API и по официальной странице pricing.
На уровне запроса логика обычно такая:
- Клиент отправляет данные в API.
- Провайдер токенизирует вход.
- Модель читает весь переданный контекст в пределах окна контекста.
- Модель генерирует выходные токены до достижения стоп-условия или лимита.
- API возвращает ответ и метаданные usage.
Названия полей usage зависят от API: это могут быть prompt_tokens и completion_tokens либо input_tokens и output_tokens. Для биллинга важен не формат названия, а факт, что именно эти поля дают фактический объём потребления на уровне запроса.
| Компонент | Что считается | Как влияет на счёт |
|---|---|---|
| Системный промпт | Повторяется в каждом запросе, если вы отправляете его заново | Часто даёт стабильную базовую стоимость каждого вызова |
| История диалога | Все предыдущие сообщения, если вы храните контекст в клиенте | Стоимость растёт от хода к ходу |
| RAG-документы | Извлечённые фрагменты из базы знаний | Могут стать главным источником входных токенов |
| Ответ модели | Сгенерированный текст | Длинные ответы увеличивают счёт и задержку |
| Кешированный префикс | Повторяющийся контекст, если провайдер поддерживает кеш | Может снижать стоимость повторного ввода, но правила зависят от провайдера |
| Мультимодальность | Изображения, аудио и другие типы данных | Часто тарифицируется отдельно и не сводится к текстовым токенам |
На практике биллинг ломается не на арифметике, а на архитектуре. Если вы на каждом запросе пересылаете длинную инструкцию, весь чат и десять фрагментов поиска, то даже дешёвая модель становится дорогой. И наоборот: короткий контекст, жёсткий формат ответа и ограничение максимального вывода обычно снижают расходы заметнее, чем разовая смена модели.
Для ориентиров по тарифам нужно смотреть официальные страницы провайдеров, например OpenAI API Pricing, Anthropic Pricing и Gemini API Pricing. Для оценки токенизации полезен официальный Tokenizer.
Зачем нужно
Понимание токенов и биллинга нужно не бухгалтерии, а разработчику и продакт-команде. Без этого невозможно нормально проектировать систему на LLM.
- Планирование бюджета. Вы можете прикинуть стоимость одного сценария, одного пользователя и всего трафика.
- Выбор модели. Сравнивать нужно не только цену на странице тарифа, но и фактическое число токенов в вашем кейсе.
- Контроль аномалий. Если usage внезапно растёт, это часто значит, что в проде распух промпт, зациклился агент или в RAG пошли слишком длинные документы.
- Оптимизация продукта. Иногда выгоднее сократить ответ вдвое, чем менять провайдера. Иногда выгоднее вынести часть логики из LLM в обычный код.
- Юнит-экономика. Стоимость на запрос, на диалог, на пользователя и на бизнес-операцию помогает понять, где система вообще окупается.
Ещё один важный момент: токены влияют не только на счёт, но и на задержку. Чем больше вход и выход, тем дольше модель читает контекст и генерирует ответ. Поэтому оптимизация токенов обычно одновременно улучшает стоимость и скорость.
Пример
Представим сервис, который делает краткие сводки входящих писем. Один запрос содержит:
- постоянную инструкцию и схему ответа — 900 входных токенов;
- текст конкретного письма — 300 входных токенов;
- ответ модели — в среднем 180 выходных токенов.
Итого один запрос даёт около 1200 входных и 180 выходных токенов. Если сервис обрабатывает 20 000 писем в день, то дневной объём составляет примерно 24 000 000 входных и 3 600 000 выходных токенов.
Теперь посмотрим, что можно сделать без смены модели:
| Шаг | Что меняем | Эффект по токенам |
|---|---|---|
| 1 | Сокращаем системную инструкцию | Меньше базовых входных токенов на каждый запрос |
| 2 | Делаем формат ответа строже | Меньше выходных токенов |
| 3 | Если провайдер поддерживает кеш, выносим стабильный префикс в повторяемую часть | Повторяющийся ввод может тарифицироваться мягче по правилам провайдера |
| 4 | Обрезаем слишком длинные письма или заранее чистим подписи и хвосты переписки | Меньше уникального входа |
После этого команда может считать уже не абстрактную цену «за миллион токенов», а конкретный сценарий: сколько стоит обработка одного письма, одного дня и одного месяца. Дальше достаточно подставить актуальные ставки нужной модели с официальной страницы тарифа.
Практическое правило: сначала измеряйте usage по реальным запросам, потом оптимизируйте промпт и формат ответа, и только после этого сравнивайте модели по цене.
Заблуждения и ограничения
Заблуждение 1: один токен — это примерно одно слово. Это грубое приближение, на которое нельзя опираться в расчётах. Русский, английский, код, JSON и таблицы ведут себя по-разному.
Заблуждение 2: самая дешёвая цена за 1M токенов даёт самый дешёвый продукт. Не обязательно. Более дешёвая модель может требовать больше попыток, давать более длинные ответы или хуже справляться с задачей, из-за чего растёт общее число вызовов.
Заблуждение 3: биллинг зависит только от сообщения пользователя. В длинных чатах и RAG-системах главный вклад часто вносит контекст, который пользователь даже не видит.
Ограничение 1: не всё выражается в текстовых токенах. Изображения, аудио, хранение данных, векторный поиск, внешние API и выполнение инструментов могут формировать отдельную часть расходов.
Ограничение 2: правила отличаются у провайдеров. Даже если все используют слово «токены», состав usage, цены на ввод и вывод, наличие кеша и способ тарификации мультимодальности различаются.
Ограничение 3: точную стоимость заранее посчитать сложно. До запуска вы строите оценку, а не факт. Фактический счёт надо подтверждать логами usage и сверкой с биллингом провайдера.
Поэтому метод не подходит как единственный критерий выбора в сложных системах с агентами, мультимодальностью и дорогими внешними инструментами. Там считать нужно полную стоимость сценария, а не только токены LLM.
Частые вопросы
Чем отличаются входные и выходные токены?
Входные токены — это всё, что модель читает. Выходные — всё, что она генерирует. У многих моделей ставки на ввод и вывод различаются, поэтому длинные ответы могут оказаться дорогими даже при коротком запросе.
Почему одинаковый текст может стоить по-разному на разных моделях?
Потому что различаются токенизаторы, тарифы на ввод и вывод, а также дополнительные механики вроде кеша или мультимодальности. Сравнение по символам или словам здесь бесполезно.
Можно ли заранее точно посчитать стоимость?
Точно — только постфактум по фактическому usage. До запуска можно сделать достаточно хорошую оценку: собрать типовые запросы, измерить токены, умножить на тарифы и добавить запас на длинные ответы и ретраи.
Что обычно сильнее всего снижает расходы?
Сокращение повторяющегося контекста, чистка истории диалога, уменьшение объёма RAG-фрагментов, жёсткий формат ответа и ограничение максимального вывода. Замена модели помогает не всегда.
Нужно ли экономить каждый токен?
Нет. Если чрезмерная экономия ломает качество, вырастет число повторных запросов и ручных проверок. Оптимизировать нужно до точки, где снижаются расходы без ухудшения целевого результата.
Связанные понятия
- Окно контекста — максимальный объём токенов, который модель может учитывать в одном запросе.
- Токенизация — разбиение текста на единицы, используемые моделью.
- Prompt caching — механизм учёта или переиспользования повторяющегося префикса, если он поддерживается провайдером.
- RAG — добавление внешнего контекста из базы знаний; часто увеличивает входные токены.
- Rate limits — ограничения по скорости и объёму запросов; это не биллинг, но они влияют на архитектуру и стоимость эксплуатации.
- Юнит-экономика — расчёт стоимости на один сценарий, пользователя или бизнес-операцию.
Если нужен рабочий минимум для команды, он такой: логируйте usage по каждому запросу, держите под контролем длину системного промпта и ответа, отдельно измеряйте стоимость RAG-контекста и не сравнивайте модели по одной цифре из прайс-листа без теста на реальном трафике.