Управление токенами в LLM: где AI-продукты теряют деньги на API

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

Если говорить прямо, токены в LLM — это не просто единица текста. Это единица стоимости, ограничения и скорости. Через них проходят деньги, качество ответа и масштабируемость AI-функции. Пока команда не видит расход токенов, она не видит реальную себестоимость работы модели. А значит, управляет ей примерно по ощущениям — бодро, уверенно и местами вслепую.

Почему токены в LLM — это уже не мелочь, а статья расходов

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

Расход растет не только вместе с числом запросов. Он растет вместе с длиной системного промпта, объемом истории, количеством подтягиваемых документов, многословностью ответа, повтором одинаковых инструкций и устройством самого сценария. То есть стоимость начинает зависеть не от одной кнопки “вызвать модель”, а от всей конструкции вокруг нее.

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

Поэтому токены — это уже не техническая деталь “для разработчиков”. Это вопрос продукта, бюджета и управления. Чем активнее вы используете LLM, тем меньше у вас права не замечать эту тему.

Что такое токены на практике и почему текст не равен токенам один к одному

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

Одно слово может оказаться одним токеном, несколькими токенами или только частью токена. Пробелы, знаки препинания, форматирование, цифры, код, таблицы, JSON, смешение языков — все это влияет на то, как текст будет разрезан внутри модели. Поэтому “небольшой текст” с точки зрения человека и “небольшой запрос” с точки зрения API — не одно и то же.

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

Проблема тут не в том, что токенизация сложная. Проблема в том, что бизнес часто живет с ложной интуицией: “вопрос короткий, значит и расход копеечный”. А потом выясняется, что пользователь прислал одну строчку, а система довесила к ней еще половину внутреннего регламента.

Какие токены вообще участвуют в расходах

Фраза “мы потратили столько-то токенов” звучит удобно, но почти ничего не объясняет. Полезно сразу различать, из чего именно складывается расход.

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

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

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

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

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

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

Как токены превращаются в деньги

Самая вредная иллюзия в теме LLM — будто стоимость живет на уровне “один запрос = одна цена”. На уровне разговора это еще терпимо. На уровне продукта — уже нет.

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

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

Хорошая новость в том, что цена на LLM — это не только “прайс за модель”. Это еще и следствие архитектурных решений. А архитектурные решения, в отличие от рекламных обещаний, обычно можно поменять.

Где бизнес чаще всего теряет деньги на токенах

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

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

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

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

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

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

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

Три сценария, где токены незаметно раздувают бюджет

Проще всего увидеть проблему на типовых продуктах.

• Первый сценарий — чат-бот поддержки. Пользователь пишет: “Где посмотреть статус заказа?” Снаружи это одна фраза. Внутри система может отправить вместе с ней системную роль, правила общения, ограничения по безопасности, историю предыдущих сообщений, фрагмент внутренней справки, данные из карточки клиента, описание бизнес-логики, формат ответа и запрет на определенные формулировки. В итоге короткий вопрос оказывается дорогим не потому, что пользователь спросил что-то сложное, а потому, что вокруг него построили тяжелую рамку.
• Второй сценарий — AI-ассистент внутри CRM или внутренней системы. Такие инструменты любят быть “полезными по максимуму”, а значит тащат в запрос роли сотрудников, поля карточек, заметки, внутренние инструкции, статусы, права доступа, шаблоны и правила работы. Все это в теории оправдано. Но если никто не следит за тем, что реально влияет на ответ, запрос быстро начинает везти не полезный контекст, а архив корпоративной тревожности.
• Третий сценарий — RAG-поиск по базе знаний или документам. Пользователь задает узкий вопрос, а система подтягивает к нему пять-шесть фрагментов, иногда еще с пересечениями, дублями и соседними кусками текста “на случай, если вдруг модель лучше поймет общую картину”. Понять она, может, и поймет. Но заплатите за это тоже вы. И вот тут становится видно главное: в LLM часто дороже не сам запрос пользователя, а то, как старательно вы помогли модели перегрузиться.

Что такое управление токенами на практике

Управление токенами — это не искусство “резать текст, пока не станет дешево”. Это гораздо взрослее и скучнее, а значит полезнее. По сути, речь идет о дисциплине: видеть расход по частям, понимать, где он оправдан, где нет, и принимать решения не по ощущениям, а по данным.

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

И здесь возникает неприятный, но правильный вопрос: кто отвечает за расход токенов? Если ответ — “ну, наверное, разработчик”, значит система уже немного трещит по швам. Разработчик отвечает за реализацию. Продакт — за то, зачем сценарий вообще нужен и как он устроен. Техлид или CTO — за архитектуру и масштабируемость. Если никто не держит тему целиком, расходы почти всегда начинают жить своей отдельной жизнью.

Проблема в том, что компании часто пытаются “оптимизировать” токены раньше, чем начинают их нормально видеть. Это как худеть, не зная, что вы вообще едите. Много движений, мало смысла, результат случайный.

Что обычно делают, чтобы сократить расходы

Нормальная экономия начинается не с паники, а с разбора источника расхода.

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

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

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

Если раздут контекст, надо учиться фильтровать и выбирать фрагменты строже. “Больше текста” не всегда означает “лучше ответ”. Иногда это означает только “дороже и шумнее”.

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

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

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

С чего начать контроль расходов на токены

1. Первый шаг — вообще увидеть, где в продукте живет LLM. Не в абстрактном смысле “у нас есть AI”, а по-настоящему: в каких функциях, на каких шагах, в каких сценариях, для каких ролей и с какой бизнес-задачей.
2. Второй шаг — начать считать расход не общим ведром, а по сценариям. Пока у вас есть только цифра “за месяц потратили столько-то”, это не управление, а бухгалтерский осадок. Нужно видеть расход по функциям, типам запросов, ролям, продуктовым потокам, каналам — как позволяет архитектура.
3. Третий шаг — разделить расход хотя бы на три крупные зоны: вход, выход и повторяемая часть. Уже на этом уровне часто выясняется неприятная, но полезная правда: пользователь пишет немного, а платите вы в основном за собственный хвост из инструкций, истории и контекста.
4. Четвертый шаг — найти самые частые и самые дорогие сценарии. Иногда это разные вещи. Иногда один и тот же сценарий и частый, и дорогой, и вот это уже не просто техническая деталь, а кандидат на немедленный пересмотр.
5. Пятый шаг — только после этого решать, что именно менять. Где нужен кэш, где batch, где сжатие истории, где фильтрация контекста, где смена модели, где ограничение длины ответа, а где проблема вообще не в расходе, а в плохо поставленной задаче.

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