Управление токенами в LLM-продукте: как контролировать расходы после запуска

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

Общий счёт отвечает на вопрос: «Сколько потратили?»

Управление начинается с другого вопроса: «На что именно?»

Управление токенами — это не сокращение промпта

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

Иногда это правильно. Если инструкция содержит повторы, устаревшие ограничения и примеры на все случаи жизни, её стоит пересмотреть.

Но сокращение промпта — это оптимизация одного элемента. Оно не заменяет управление расходами.

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

Это рабочая управленческая рамка, а не официальный отраслевой стандарт.

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

Нужен другой результат: предсказуемая стоимость при приемлемом качестве.

Чтобы дальше не путаться в терминах:

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

Одна функция может содержать несколько сценариев, а один сценарий — несколько вызовов.

Почему один запрос пользователя может стоить как десять

В простом интерфейсе всё выглядит линейно:

пользователь задал вопрос → модель ответила.

В работающем продукте между этими точками часто находится целый процесс.

Представим AI-ассистента службы поддержки. Пользователь спрашивает:

Можно ли вернуть товар после вскрытия упаковки?

Прежде чем показать ответ, система может:

1. Определить категорию обращения.
2. Найти правила возврата в базе знаний.
3. Отобрать наиболее релевантные фрагменты.
4. Сформировать ответ.
5. Проверить структуру и обязательные предупреждения.
6. Исправить результат или передать вопрос менеджеру.

Пользователь нажал одну кнопку. Внутри произошло несколько обращений к одной или разным моделям.

Пользовательский запрос → классификация → поиск → генерация → проверка → итоговый ответ

У каждого шага есть собственная стоимость, задержка и вероятность ошибки.

Агентные сценарии добавляют внутренние шаги

В обычном workflow последовательность действий заранее задаёт разработчик.

AI-агент может сам решать:

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

Такая гибкость полезна, но делает расходы менее предсказуемыми.

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

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

Неудачные вызовы тоже входят в стоимость сценария

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

Поэтому считать только последний ответ неправильно. Нужна полная трасса выполнения: от действия пользователя до результата или окончательной ошибки.

Граница темы

Токены — центральная, но не единственная часть себестоимости AI-функции. Дополнительно могут оплачиваться поиск, embeddings, хранение, внешние инструменты и инфраструктура. Здесь мы рассматриваем прежде всего стоимость LLM-вызовов.

Какие данные нужно собирать после каждого вызова LLM

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

Организационные API некоторых провайдеров дополнительно позволяют группировать потребление по моделям, проектам, ключам или рабочим пространствам. Это полезно для сверки счетов и общей аналитики. Но внутренние сценарии продукта провайдер всё равно не знает. [1][2][3][4]

Для него два вызова одной модели могут выглядеть одинаково.

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

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

Минимальный контроль для MVP

На первом этапе не нужна отдельная платформа наблюдаемости с двадцатью графиками.

Достаточно сохранять:

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

Такой набор уже позволяет понять:

• какая функция расходует больше всего;
• какие клиенты создают основную нагрузку;
• как изменилась стоимость после смены модели;
• сколько денег уходит на незавершённые операции.

Минимальное правило для MVP

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

Расширенный контроль для работающего продукта

В зрелом продукте к usage добавляют информацию, которая помогает восстановить всю цепочку:

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

Главное — не количество полей, а возможность восстановить причинно-следственную связь.

Например:

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

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

От стоимости вызова к стоимости полезного результата

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

Стоимость отдельного вызова

Эта метрика помогает:

• сравнивать модели;
• проверять влияние нового промпта;
• оценивать размер контекста;
• находить аномально длинные запросы;
• измерять эффект кэширования.

Но один вызов редко описывает всю пользовательскую задачу.

Стоимость сценария

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

Проверка договора, например, может состоять из определения типа документа, поиска правил, анализа текста, проверки результата и подготовки отчёта.

Если система сделала пять обращений к модели, стоимость сценария равна сумме всех пяти.

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

Стоимость успешного результата

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

Результатом может быть:

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

Рабочая операционная метрика:

Стоимость успешного результата = стоимость всех модельных вызовов / количество успешно завершённых задач

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

Допустим, 100 обращений к ассистенту обошлись в 2 000 рублей. Самостоятельно решить удалось 60 обращений. Остальные потребовали передачи менеджеру.

Стоимость одного успешно решённого обращения на уровне LLM составляет около 33 рублей, а не 20.

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

Среднее значение скрывает дорогие случаи

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

Допустим:

• большинство обращений стоят от 1 до 3 рублей;
• несколько длинных диалогов — по 50 рублей;
• один зацикленный агент потратил 500 рублей.

Среднее сгладит проблему.

Поэтому вместе с ним стоит смотреть медиану, максимум и верхние перцентили.

95-й перцентиль показывает стоимость, в которую укладываются 95% сценариев. Оставшиеся 5% — дорогие крайние случаи, которые нужно разбирать отдельно.

Расходы нужно связывать с релизами

После изменения модели, промпта или RAG-логики необходимо сравнивать показатели до и после релиза.

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

Без версии конфигурации такой эффект легко пропустить.

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

Как оценивать оптимизацию без самообмана

Допустим, команда сократила средний расход токенов на 30%.

Можно ли считать задачу выполненной?

Нет. Сначала нужно проверить, что произошло с результатом.

После изменения сравнивают:

• стоимость сценария;
• стоимость успешной задачи;
• точность и полноту;
• соблюдение формата;
• время выполнения;
• долю эскалаций;
• ручные исправления.

Критерий качества зависит от задачи.

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

Дешёвая модель может оказаться дороже

Более сильная модель может выполнить задачу с первой попытки.

Более дешёвая:

• нарушить формат;
• пропустить нужное поле;
• потребовать дополнительной проверки;
• чаще передавать задачу сотруднику.

Цена одного токена будет ниже. Стоимость результата — выше.

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

Сокращение контекста может ухудшить ответ

Удаление части истории или документов снижает входной расход.

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

На типовом запросе всё продолжит работать. На краевом сценарии система начнёт ошибаться.

Дополнительный вызов иногда дешевле ошибки

Не каждый лишний вызов нужно удалять.

Проверка может быть оправдана, если неправильный результат приведёт к финансовому риску, юридической ошибке или претензии клиента.

В критическом сценарии несколько тысяч дополнительных токенов могут стоить значительно меньше неправильного решения.

Меняйте один элемент за эксперимент

Не стоит одновременно:

• менять модель;
• сокращать промпт;
• перестраивать поиск;
• добавлять кэширование;
• ограничивать ответ.

Если стоимость или качество изменятся, команда не поймёт причину.

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

Как устанавливать бюджеты и ограничения

Мониторинг показывает, что уже произошло.

Управление должно ещё и ограничивать то, что может произойти.

Если система только записывает растущий расход, это хороший журнал наблюдений, но слабый финансовый контроль.

Бюджет продукта

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

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

Отдельные бюджеты полезны для функций с разной экономикой.

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

Квоты пользователей и клиентов

Квоту можно задавать по числу запросов, стоимости, объёму документов или количеству дорогих операций.

Это особенно важно в SaaS-продуктах.

Формулировка «безлимитный ИИ» хорошо выглядит на лендинге. В биллинге она выглядит менее романтично.

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

Например:

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

Мягкие и жёсткие ограничения

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

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

Жёсткое ограничение останавливает выполнение: блокирует операцию, завершает агентный цикл, отключает дорогую функцию или передаёт задачу человеку.

Например, при достижении 80% месячной квоты пользователь получает предупреждение.

После 100% обычные вопросы остаются доступны, а анализ больших документов блокируется до следующего периода или покупки дополнительного объёма.

Четыре разных лимита

1. Контекстное окно ограничивает объём данных, доступных модели.
2. Output limit ограничивает длину ответа.
3. Rate limit регулирует частоту обращений к API.
4. Финансовый лимит ограничивает допустимую стоимость.

Это разные механизмы. Объединять их одним словом удобно только до первой аварии.

Какие аномалии расходов нужно отслеживать

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

Задача мониторинга — не просто заметить рост, а связать его с конкретным изменением.

Повторные попытки после ошибок

Повторные вызовы часто выглядят как мелкая техническая деталь.

На большой нагрузке они становятся отдельной статьёй расходов.

Причинами могут быть:

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

Важно измерять не только количество повторов, но и их долю в стоимости сценария.

Если они создают 20% расходов, проблема находится не в цене токена. Нужно исправлять причину повторов.

Зацикливание AI-агента

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

Признаки:

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

Для защиты нужны:

• максимальное число шагов;
• лимит времени;
• предел стоимости;
• критерий завершения;
• передача управления человеку.

Каким должен быть полезный алерт

Слабый алерт: Расход API вырос. - Он сообщает очевидное и не помогает действовать.

Полезный алерт:

После выхода версии промпта 3.2 стоимость 95-го перцентиля сценария «анализ договора» выросла на 28%. Увеличились входной контекст и доля повторных попыток.

Команда сразу получает конкретные точки проверки.

Порог в 28% здесь приведён как пример внутреннего правила. Универсального допустимого процента не существует: он зависит от ценности сценария и стоимости ошибки.

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

Чек-лист контроля токенов и расходов LLM

Учёт

• Сохраняется ли usage каждого вызова?
• Учитывается ли полная цепочка сценария?
• Фиксируются ли незавершённые и повторные попытки?

Сегментация

• Привязан ли расход к сценарию и клиенту?
• Можно ли сравнить модели, промпты и релизы?
• Разделены ли production, тестирование и разработка?

Метрики

• Известна ли стоимость сценария?
• Рассчитывается ли стоимость успешного результата?
• Анализируются ли медиана и верхние перцентили?

Ограничения

• Заданы ли бюджеты и пользовательские квоты?
• Ограничены ли дорогие и агентные операции?
• Определено ли действие при превышении лимита?

Качество

• Проверяется ли качество после оптимизации?
• Учитывается ли стоимость ошибки?
• Сравниваются ли модели по стоимости результата, а не только по тарифу?