Как управлять расходами на ИИ без жестких лимитов: инженерный подход к экономии токенов

Внедрение искусственного интеллекта в рабочие процессы компаний перестало быть экспериментом и превратилось в ощутимую статью расходов. Корпорации всё чаще сталкиваются с ситуацией, когда выделенный на год бюджет на нейросети исчерпывается за считанные месяцы. Известный пример из практики — решение Uber в 2026 году установить лимит в 1 500 долларов в месяц на одного сотрудника для каждого агентного инструмента написания кода. Как сообщает Bloomberg, без ограничений годовой лимит на ИИ-сервисы у них расходовался всего за четыре месяца.

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

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

Анатомия токенов: почему физический объем не равен оплачиваемому

Физические токены не равны оплачиваемым

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

• Физические токены — фактический объем символов, прошедший через токенизатор;
• Кэшированные токены — часть входного контекста, извлеченная провайдером из prompt cache;
• Оплачиваемые токены — итоговый объем, попадающий в финансовый расчет с учетом действующего тарифа и скидок.

Смешивание этих показателей в единую метрику приводит к искажению бюджетного контроля. Чтобы избежать ошибок, в рабочем контуре имеет смысл раздельно фиксировать несколько ключевых параметров на каждый запрос: EffectiveTokensIn (полный физический объем входа вместе с кэшем), CacheReadTokens (объем, прочитанный из кэша) и PaidTokensIn (конечная стоимость входа по применимой ставке).

Бюджетный гейт должен рассчитывать именно оплачиваемый вход и фактический выход. Это критически важно: хотя кэшированный контекст принимает полноценное участие в формировании ответа модели, его стоимость у большинства провайдеров существенно ниже обычного входа. Например, до корректировки алгоритмов учета некоторые модели OpenAI оценивали входящий промпт по абсолютному объему без учета кэширования. В результате лимиты расхода срабатывали в 1,5–3 раза быстрее, чем реально исчерпывался бюджет. Разделение метрик позволило гейту отражать реальные финансовые затраты. Главный принцип здесь — контролировать не абстрактные суррогатные показатели, а реальный дефицитный ресурс.

Токен одной модели не равен токену другой

В коммерческих прайс-листах цены традиционно указываются в долларах за миллион токенов, создавая иллюзию, что токен — это универсальная единица измерения, вроде киловатт-часа или грамма. Это заблуждение. Специалист OpenAI Тибо Сотто (Thibault Sottiaux) наглядно проиллюстрировал эту разницу на примере с пиццей: одну пиццу можно разрезать на 8 больших кусков по $2 за каждый, а другую — на 16 мелких по $1,25. Отдельный кусок во втором случае дешевле, но вся пицца целиком обойдется дороже.

В проведенных замерах одна нейросеть упаковала исходный текст в 766 токенов, в то время как другой модели для передачи того же объема информации потребовалось 1 170 токенов — разница составила более трети. И плотность токенизации — лишь первый видимый коэффициент. На практике проявляются и другие факторы:

• Внутренние рассуждения (reasoning): рассуждающие модели расходуют токены на скрытые размышления. На практике одна из таких моделей тратила в среднем 76,6 КБ контекста на внутренние мысли ради формирования итогового ответа размером всего 5,3 КБ, при этом оплачивается весь израсходованный объем;
• Многоходовость агентов: решение задачи автономным агентом требует разного количества шагов у разных моделей;
• Коэффициент кэширования: объем входа из кэша может считываться со скидкой или отсутствовать вовсе;
• Усиленные режимы (boosted): специальные режимы обработки могут вычитывать один и тот же запрос несколько раз по базовой цене за токен.

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

Оптимизация работы с кэшем и маршрутизация задач

Кэш начинается в промпте

Механизм Prompt Cache выступает одним из наиболее мощных рычагов снижения расходов. У провайдеров, поддерживающих кэширование, чтение сохраненного контекста обходится в 0,10–0,25 от базового тарифа на ввод. Однако кэш не формируется сам по себе — для его эффективной работы требуется строго зафиксированный повторяющийся префикс запроса.

Под стабильным префиксом понимается неизменяемая часть контекста, передаваемая от задачи к задаче:

• системные инструкции и роли;
• схемы вызова доступных инструментов (JSON schema и API);
• постоянные правила и ограничения;
• статические справочные данные.

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

В тестовых запусках с моделью deepseek-v4-flash показатель попадания в кэш (cache hit) достигал 98%: при общем физическом размере контекста в 23 000 токенов оплате подлежали всего 260–617 входных токенов. Разумеется, такой результат не гарантирован для любого сценария — некоторые модели не поддерживают кэширование вовсе или имеют короткое время жизни контекста.

Тем не менее, замер кэша позволяет диагностировать архитектурные проблемы. Низкий cache hit далеко не всегда указывает на ошибку тарификации. Часто это сигнал о том, что приложение формирует список инструментов динамически или помещает статические инструкции в конец промпта. В одном из исследованных контуров статическая инструкция для ревьюеров объемом 1157 байт располагалась после описания задачи. Перенос этого блока в начало промпта потенциально мог охватить кэшем от 28% до 36% медианного объема запроса. Подобные гипотезы требуют обязательной A/B-проверки, так как изменение порядка информации в контексте может отразиться на точности ответа.

Не каждой задаче нужна самая дорогая модель

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

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

• bulk — массовые простые операции, первичная классификация, экспресс-проверки (smoke tests);
• review — перекрестная проверка с выдачей структурированного вердикта;
• write — непосредственное генеративное написание или редактирование кода и текста;
• analyze — сложные исследовательские и аналитические задачи;
• scarce — редкие узкоспециализированные модели, вызываемые строго по прямому требованию.

Эффективность модели оценивается исключительно по метрикам соответствующей роли: для генераторов — по доле принятых правок, для ревьюеров — по проценту валидных структурированных отчетов. Анализ реальной нагрузки нередко выявляет сильные перекосы. В одном из замеров 61% запросов на простейшую оценку единичного ответа отправлялся в тяжелые каналы. Из 35,6 канало-часов, потраченных на легкие задачи, 11,2 часа были заняты избыточно мощными моделями.

Еще более показательный случай произошел с рассуждающей моделью: в 39% прогонов она прерывалась по таймауту. Нейросеть генерировала около 76,6 КБ внутренних рассуждений ради выдачи 5,3 КБ итогового текста. В роли обычного исполнителя дорогая модель показала непредсказуемость и высокую стоимость, в результате чего была исключена из регулярной ротации.

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

1. API-шлюз: отвечает за протоколы взаимодействия и конкретные маршруты к провайдерам;
2. Уровень приложения: управляет пулами моделей, весовыми коэффициентами и параметрами запроса (reasoning, top_p, seed, лимиты длины рассуждений);
3. Агентский конвейер: выбирает нужный пул под конкретную роль, учитывая ограничения по тарифам и таймауты.

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

Контроль качества и наблюдаемость процессов

Экономия имеет смысл только вместе с проверкой качества

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

Любые изменения в конфигурации моделей необходимо валидировать на контрольных датасетах. Для оценки роли ревьюеров применяется подход с независимыми «судьями» (LLM-as-a-judge): модель никогда не должна оценивать результаты собственной работы или нейросети того же провайдера. Дополнительно задействуется состязательная проверка (adversarial testing) сторонней моделью, а итоговый результат фиксируется через машиночитаемые вердикты.

Также важно помнить о скрытых механиках тарификации. В некоторых моделях предусмотрены «усиленные» режимы обработки: заявленная цена за токен остается прежней, но модель перечитывает входной промпт несколько раз, и каждое чтение заносится в счет. В наших тестах на абсолютно идентичном теле запроса стандартный режим потратил 20 296 оплачиваемых входных токенов, а усиленный — 74 365 токенов при одинаковой тарифной ставке.

Наблюдаемость важнее красивого отчёта

В комплексных агентных системах легко поддаться иллюзии благополучия, ориентируясь на текстовые отчеты о том, что задача «успешно выполнена». Для реального контроля необходимы строгие цифровые артефакты:

• детализированные логи расхода токенов и кэша;
• точная конфигурация параметров маршрутизации;
• результаты сплошных замеров задержки (latency);
• сравнительные метрики качества до и после изменений;
• полная история модификаций в пулах моделей.

Глубокий аудит метрик периодически заставляет пересматривать вроде бы успешные показатели. Например, первичная система учета показывала, что 96,5% задач успешно закрываются с первой попытки. Однако детальная проверка логики метрики выявила ошибку подсчета: реальная доля успешных первичных запусков составляла около 40%. Как и в разработке ПО, для любой метрики ИИ-расходов должен существовать прозрачный и воспроизводимый способ проверки.

Выводы: как построить управляемое потребление токенов

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

1. Какая структура расходов формирует итоговый биллинг провайдера?
2. Какая доля входного контекста реально попадает в кэш?
3. Какие типы задач действительно требуют привлечения флагманских моделей?
4. Подтверждена ли экономия объективными замерами качества, а не догадками?
5. Каковы архитектурные ограничения конкретного тарифа, модели и провайдера?

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

Источник: habr.com