Token‑экономика: как контролировать стоимость LLM‑бота в продакшене

Помню, как мы запускали первого AI-ассистента для клиента — интернет-магазина электроники. Тесты прошли блестяще. Бот вежливый, понимает с полуслова, решает вопросы за секунды. Заказчик в восторге, мы довольны собой. Через неделю трафик вырос в три раза — сарафанное радио сработало. Ещё через три недели пришёл счёт от OpenAI.

Сумма была такой, что звонок от финдиректора начался без "здравствуйте". Это и есть тот самый "bill shock" — неприятный сюрприз, который настигает многих на пути к AI-автоматизации. Проблема в том, что LLM-сервисы устроены коварно: один вызов API кажется копеечным, но когда диалогов становится сто тысяч в месяц, каждый "лишний" токен превращается в реальные деньги.

После того случая мы перелопатили десятки проектов и набили немало шишек. Где-то переплачивали за "умные" ответы на банальные вопросы вроде "Привет" или "Спасибо". Где-то гоняли через модель километровую историю переписки, хотя достаточно было краткого резюме. Постепенно сформировался набор практик, которые позволяют держать расходы под контролем без ущерба для качества.

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

Токеномика на пальцах: за что мы платим?

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

Звучит безобидно, пока не вспомнишь одну особенность языковых моделей: у них нет памяти. Вообще. Каждый новый запрос для модели — как первое знакомство. Чтобы бот "вспомнил", что вас зовут Алексей и что вы уже обсудили проблему с доставкой, нужно отправить ему всю предыдущую переписку целиком. И заплатить за её "прочтение" снова.

На практике это означает следующее: если диалог длится 20 сообщений, то на последнем ходе модель "читает" все 19 предыдущих. А вы платите за каждый токен в этой истории. Вот почему длинные разговоры так дороги — контекст растёт квадратично.

Из чего складывается стоимость диалога

Когда мы считаем полную стоимость владения (TCO) одного разговора с ботом, нужно учитывать три компонента. Первый и самый весомый — это непосредственно вызовы языковой модели. Формула простая: количество входящих токенов умножаем на их цену, плюс количество исходящих токенов на их цену. Обычно это 70-90% всех затрат.

Второй компонент — RAG, то есть поиск по базе знаний. Когда бот ищет ответ в вашей документации, он сначала превращает вопрос в вектор (это эмбеддинг), потом ищет похожие фрагменты в базе. Каждая такая операция тоже стоит денег, хотя и существенно меньше, чем генерация. На больших объёмах, впрочем, набегает.

Третий — инфраструктура: серверы, базы данных, логирование, мониторинг. Это фиксированные расходы, которые "размазываются" по диалогам. Чем больше у вас трафика, тем меньше доля инфраструктуры в стоимости одного разговора.

Есть ещё один множитель, который многие упускают из виду — кэширование. Если 30% вопросов повторяются (а так обычно и бывает), то при наличии хорошего кэша вы платите только за 70% запросов. Итоговая формула: Стоимость = (LLM + RAG + Инфра) × (1 - % Кэширования). Запомните этот последний множитель — он станет вашим лучшим другом.

Пять главных "пожирателей" бюджета

Прежде чем что-то оптимизировать, нужно понять, куда утекают деньги. За годы работы с LLM-проектами мы выявили типичные "дыры", через которые бюджет уходит как вода в песок. Расскажу о каждой подробнее.

Бесконечная история диалога. Это самый распространённый грех. Разработчик просто отправляет модели всю переписку с первого "Привет". Кажется логичным — пусть бот знает контекст. Но к двадцатому сообщению в контексте уже несколько тысяч токенов, и каждый следующий ответ стоит как небольшой обед. Мы видели проекты, где 80% бюджета съедала именно история чата.

Раздутый системный промпт. "Ты — дружелюбный и полезный ассистент компании X. Пожалуйста, всегда будь вежливым, отвечай развёрнуто, но по существу..." — знакомо? Такие инструкции могут занимать тысячу токенов и отправляться с каждым сообщением. А ведь модель отлично понимает и краткие команды. Один наш клиент сократил промпт с 800 до 150 токенов без потери качества — экономия 15% на ровном месте.

Жадный RAG. Когда бот ищет ответ в базе знаний, он находит релевантные фрагменты и вставляет их в контекст. Проблема возникает, когда система подхватывает слишком много — десять страниц документации вместо двух абзацев, которые реально нужны. Модель честно "переваривает" весь этот массив, а вы честно за это платите. Умная настройка чанкинга и ранжирования может сократить этот расход в разы.

Топовая модель для простых задач. GPT-4o или Claude 3 Opus — мощные инструменты. Но использовать их для ответа на "Спасибо за помощь!" или "Какой у вас график работы?" — всё равно что возить хлеб на грузовике-двадцатитоннике. Для рутинных вопросов существуют модели попроще и подешевле, которые справляются ничуть не хуже.

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

Реальные цифры: как мы сократили расходы в шесть раз

Ладно, хватит абстракций — вот конкретные цифры. Возьмём типичного клиента: онлайн-сервис с ботом поддержки, 100 000 диалогов в месяц. Средняя длина разговора — 8 сообщений.

Когда этот проект пришёл к нам, архитектура была максимально простой: один запрос — один вызов GPT-4o со всей историей. Промпт красивый и подробный, на полторы тысячи токенов. RAG подтягивал по пять-семь документов на каждый вопрос. Работало отлично, клиенты были довольны... пока не пришёл счёт.

Что мы сделали? Во-первых, внедрили маршрутизацию: простые вопросы (около 60% трафика) пошли на GPT-4o-mini, который в десять раз дешевле. Во-вторых, настроили сжатие истории — вместо двадцати сообщений модель получает саммари на 200 токенов плюс последние три реплики. В-третьих, включили семантический кэш для частых вопросов — это ещё минус 25% вызовов.

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

Практические методы оптимизации

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

Маршрутизация моделей: не стреляйте из пушки по воробьям

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

На практике это работает так: лёгкие вопросы (приветствия, благодарности, простые факты вроде адреса или графика) идут на быструю и дешёвую модель типа GPT-4o-mini или Claude Haiku. Сложные кейсы — юридические вопросы, разбор конфликтных ситуаций, технические консультации — отправляются на "тяжёлую артиллерию" вроде GPT-4o или Claude Opus. Соотношение обычно получается 60/40 или даже 70/30 в пользу дешёвых вызовов.

Сжатие истории диалога: научитесь забывать ненужное

Тащить за собой всю переписку — дорогое удовольствие. Вместо этого мы делаем периодическое саммари. Каждые 5-7 сообщений отдельный вызов (можно на дешёвой модели) сжимает историю в короткое резюме: кто пользователь, какая проблема, что уже обсуждали, какие решения пробовали.

Выглядит это примерно так. Вместо двадцати сообщений на три тысячи токенов модель получает: "Клиент Иван, заказ #12345, проблема: товар не пришёл, курьер отмечает доставку как выполненную. Уже проверили: трек-номер корректный, адрес верный. Клиент расстроен, просит срочно разобраться." Плюс последние два-три сообщения для свежего контекста. Итого — 300 токенов вместо трёх тысяч. Модель понимает ситуацию, клиент получает релевантный ответ.

Семантический кэш: один раз сгенерировал — используй многократно

Обычный кэш работает по точному совпадению: если вопрос буква в букву такой же — отдаём готовый ответ. Но люди редко формулируют одинаково. "Сколько стоит доставка?" и "Какая цена доставки?" — один вопрос, а строки разные.

Семантический кэш решает эту проблему. Он сравнивает не буквы, а смысл — через эмбеддинги. Если новый вопрос достаточно похож на уже обработанный (обычно порог — 95% сходства), система отдаёт готовый ответ. Стоимость такого ответа стремится к нулю, задержка — миллисекунды вместо секунд. На частых вопросах это даёт колоссальную экономию.

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

Мониторинг: без метрик вы летите вслепую

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

Минимальный набор метрик, которые должны быть на дашборде: расходы за текущий час/день/неделю, средняя стоимость одного диалога (cost per conversation), распределение вызовов по моделям, процент попаданий в кэш. Этого достаточно, чтобы понимать общую картину и быстро замечать аномалии.

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

Чеклист перед запуском в продакшен

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

Промпт оптимизирован. Уберите лишние слова и дублирование. Если можно сказать в 50 токенов — не пишите 200. Протестируйте сокращённую версию на реальных диалогах, убедитесь, что качество не просело.

Настроен лимит токенов на ответ. Без ограничения модель может выдать эссе там, где нужно два предложения. Обычно 500-800 токенов — разумный потолок для большинства задач поддержки.

Работает семантический кэш. Проверьте, что он реально срабатывает на типовых вопросах. Посмотрите статистику попаданий — если меньше 15-20%, что-то настроено не так.

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

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

Вопросы, которые нам часто задают

Не станет ли бот "тупее" от сжатия истории?

Это первое, о чём беспокоятся клиенты, и понятно почему. Короткий ответ: при правильной настройке — нет. Длинный ответ: качество зависит от того, что именно вы сохраняете в саммари. Критически важны имена, номера (заказов, телефонов, документов), даты и суть проблемы. Мы используем подход Entity Extraction — перед сжатием отдельно вытаскиваем ключевые сущности и гарантируем их сохранность. Бот может забыть, что клиент упоминал погоду за окном, но никогда не забудет номер заказа.

Имеет ли смысл Fine-Tuning для экономии?

Зависит от ситуации. Fine-Tuning окупается, когда у вас очень специфическая доменная задача: например, классификация обращений в юридической компании или техподдержка сложного промышленного оборудования. Если GPT-4 справляется хорошо, а модели попроще — плохо, есть смысл "дотянуть" маленькую модель до нужного уровня через fine-tuning. Это разовые затраты на обучение, но потом каждый вызов обходится в разы дешевле. Для типовых задач вроде общей поддержки интернет-магазина fine-tuning обычно избыточен.

А можно вообще не платить за токены?

Технически — да. Можно развернуть open source модель (Llama, Mistral, Qwen) на своих серверах. Но "бесплатно" — это иллюзия. Вы будете платить за GPU (а хорошие карты стоят как автомобиль), электричество, инженеров для поддержки инфраструктуры. Для большинства проектов это экономически нецелесообразно, пока объёмы не достигают сотен тысяч долларов в месяц на API. Есть ещё гибридный вариант: простые вопросы на локальной модели, сложные — в облако. Но это уже отдельная большая тема.

Вместо заключения

Token-экономика — это не разовая задача, а постоянный процесс. Тарифы провайдеров меняются, появляются новые модели, растёт трафик — всё это влияет на расходы. Главное, что я хотел донести этой статьёй: контролировать бюджет LLM-бота вполне реально, и это не требует жертвовать качеством. Начните с мониторинга, определите главных "пожирателей" бюджета в вашем конкретном случае, и последовательно внедряйте оптимизации. Даже базовые меры — маршрутизация моделей и семантический кэш — обычно дают двух-трёхкратное снижение расходов. А дальше уже можно тонко настраивать под ваши задачи.