Токены и стоимость: как посчитать цену 100 000 запросов

Стоимость LLM-системы считается не «по цене модели», а по всему, что происходит за один запрос пользователя: сколько раз вызывается модель, сколько токенов уходит на вход и выход, что ещё платно — эмбеддинги, поиск, хранение, внешние API. Цена одного вызова почти всегда занижает реальную стоимость в разы, потому что вызовов больше одного.

Из чего складывается один запрос

Возьмём типичного ассистента по базе знаний. Пользователь задал вопрос — за кулисами произошло вот что:

• вопрос превратили в эмбеддинг для поиска;
• нашли кандидатов, отсортировали реранкером;
• собрали промпт: системные инструкции, история диалога, найденные фрагменты, сам вопрос;
• модель сгенерировала ответ;
• возможно, ещё один вызов проверил ответ или переформулировал вопрос.

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

Формула без магии

стоимость запроса = Σ по всем вызовам модели (токены_вход × цена_вход + токены_выход × цена_выход)
                  + эмбеддинги + реранкинг + внешние инструменты

стоимость 100 000 запросов = стоимость запроса × 100 000
                           + постоянные расходы (хранение индекса, сервер)
                           + переиндексация документов при обновлении

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

Пример в условных единицах, чтобы показать механику, — это не цены конкретного провайдера. Пусть промпт с найденными фрагментами — 2 000 токенов, ответ — 400, вход стоит 1 условную единицу за миллион токенов, выход — 5. Тогда один вызов: 2 000 × 1 / 1 000 000 + 400 × 5 / 1 000 000 = 0,002 + 0,002 = 0,004 у. е. На 100 000 запросов — 400 у. е. Добавили второй вызов на проверку ответа с тем же контекстом — почти вдвое больше.

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

Где деньги утекают незаметно

История диалога. Каждое новое сообщение отправляет модели весь предыдущий разговор. Двадцатый ход беседы дороже первого в разы, хотя пользователь спросил одну строчку.

Лишний контекст в RAG. «На всякий случай» положить в промпт двадцать фрагментов вместо пяти — значит платить за пятнадцать ненужных в каждом запросе. А модели к тому же хуже находят нужное в середине длинного контекста.

Ретраи. Повтор при ошибке сети или невалидном ответе — это ещё один полный вызов. Доля таких повторов тоже часть стоимости.

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

Проверка моделью-судьёй в продакшене. Если каждый ответ дополнительно оценивает большая модель, вы платите за два запроса вместо одного.

Как удешевить, не потеряв качество

• Кеш. Одинаковые запросы не отправлять в модель повторно. Семантический кеш идёт дальше — ловит похожие вопросы, но требует проверки, что «похожий» действительно означает «тот же ответ».
• Кеширование префикса. Длинные неизменные инструкции в начале промпта многие провайдеры позволяют кешировать дешевле.
• Короче контекст. Меньше фрагментов, но точнее: лучше поиск и реранкинг вместо «положить побольше».
• Маршрутизация моделей. Маленькая модель по умолчанию, эскалация на большую — только для сложных запросов.
• Пакетная обработка. Если ответ не нужен сразу, пакетные режимы обычно дешевле.

Главное правило: экономия засчитывается только с замером качества. Перевели запросы на маленькую модель и сэкономили — прогоните eval-набор и покажите, что качество не упало. Иначе «оптимизация» — это просто ухудшение, которое пока не заметили.

А если запустить модель у себя?

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

Частые вопросы

Как посчитать токены до запуска? Токенайзером той модели, которую будете использовать: у разных моделей одна и та же фраза разбивается по-разному, а русский текст обычно занимает больше токенов, чем английский того же смысла.

Зачем считать 100 000 запросов, если пока пользователей десять? Чтобы до запуска понять, не станет ли продукт убыточным при росте, и какая часть системы будет главной статьёй расходов.

Что входит в расчёт кроме токенов? Эмбеддинги при индексации и при каждом запросе, хранение индекса, внешние инструменты, ретраи, мониторинг. И время людей, если в цепочке есть ручная проверка.

Где это в программе

Стоимость одного запроса считается уже на L3, когда пишется первый надёжный клиент к API. На L5 — модуль о стоимости и маршрутизации: расчёт на 1 000 и 100 000 запросов с эмбеддингами, поиском, хранением и инструментами, кеши, маршрутизация между моделями и замер экономии без потери качества. На экзамене уровня стоимость 100 000 запросов нужно посчитать для своей системы. На L6 — TCO облачного, локального и гибридного вариантов.