Когда корпоративные AI-приложения выходят из режима демо и начинают работать под реальной нагрузкой, быстро выясняется неприятная вещь: оптимизация токенов перестаёт быть косметикой для промптов и превращается в инфраструктурную задачу. Именно об этом пишет The New Stack: по мере масштабирования команды упираются в стену затрат, задержек и нестабильного поведения, которую сначала легко принять за «проблему модели», хотя на деле речь часто идёт о всей системе вокруг неё.
Материал The New Stack под заголовком The systems guide to production token optimization разбирает эту смену оптики: токены в продакшене нужно считать не только на уровне одного запроса, но и на уровне архитектуры, маршрутизации, памяти, контекста и цепочек вызовов. Для русскоязычной IT-аудитории это важный сигнал: если компания уже внедряет LLM в саппорт, внутренний поиск, аналитические интерфейсы или AI-ассистентов для сотрудников, то рост расходов почти наверняка придёт раньше, чем хочется бюджету и SRE-команде.
Главная мысль здесь довольно трезвая. На раннем этапе команда обычно видит понятную картину: есть промпт, есть ответ модели, есть более-менее приемлемая цена одного запроса. Но в продакшене всё ломается о масштаб. Контекст разрастается, в запросы начинают добавлять историю диалога, системные инструкции, результаты поиска, служебные метаданные, промежуточные шаги агентов и защитные обвязки. В итоге приложение платит не за «один умный ответ», а за длинную и часто плохо контролируемую токенную цепочку. Если таких вызовов тысячи или миллионы, даже небольшой перерасход на один запрос превращается в системную проблему.
Отсюда и важный разворот, на котором настаивает источник: смотреть нужно не только на саму модель. Типичная инженерная ошибка состоит в том, что команда видит рост latency или счета от провайдера и сразу начинает обсуждать, не пора ли менять модель на более дешёвую или более быструю. Это иногда помогает, но не всегда бьёт в корень. Если приложение постоянно пересылает в модель лишний контекст, дублирует инструкции, повторно прогоняет одни и те же данные через несколько шагов пайплайна или без разбору хранит длинную историю взаимодействия, проблема останется и после замены модели. Просто счёт станет другим, а архитектурный долг никуда не денется.
Для разработчиков это означает, что оптимизация токенов надо рассматривать как часть обычной production-инженерии, а не как ремесло prompt engineer из презентаций. Нужны измерения, ограничения и понятная экономика каждого сценария. Сколько токенов уходит на системные инструкции? Сколько добавляет retrieval? Сколько стоит многошаговый агент по сравнению с более простым линейным сценарием? Где история диалога реально повышает качество, а где лишь раздувает запрос? Эти вопросы уже ближе к backend, observability и platform engineering, чем к магии формулировок в одном-единственном prompt box.
В более широком контексте это хорошо ложится на зреление всего AI-рынка. Первый цикл внедрения больших языковых моделей строился вокруг самого факта, что модель умеет «почти по-человечески» отвечать на вопросы, суммаризировать документы и писать код. Второй цикл куда менее романтичен: компании считают unit-экономику, ловят деградации качества под нагрузкой и разбираются, почему красивый прототип не переживает встречу с несколькими бизнес-подразделениями сразу. Поэтому разговор об оптимизации токенов звучит не как узкая тема для infra-энтузиастов, а как вполне деловой вопрос: можно ли масштабировать AI-функцию без того, чтобы она начала съедать бюджет и тормозить критические процессы.
Для продуктовых команд здесь тоже есть неприятный, но полезный вывод. Чем охотнее продукт добавляет «умные» возможности во все экраны подряд, тем важнее дисциплина на уровне сценариев. Не каждый кейс требует длинного контекста, постоянной памяти и многошагового рассуждения. Иногда пользователю нужен короткий классификатор, иногда извлечение факта, иногда сжатое резюме без лишних проходов. Если проектировать AI-функции без такой сегментации, стоимость владения начинает расти быстрее, чем реальная польза для пользователя. И тогда разговор о «масштабировании AI» заканчивается скучной встречей с финансистами, которые внезапно задают очень рациональные вопросы.
Для IT-директоров и фаундеров сигнал тоже предельно практичный. Внедрение LLM сегодня уже нельзя оценивать только по качеству демо или по тому, насколько эффектно модель отвечает на тестовом наборе вопросов. Нужны требования к предсказуемости стоимости, лимитам контекста, стратегиям деградации, кэшированию, отсечению лишней истории и прозрачности маршрута каждого запроса. Иначе AI-платформа начинает жить по законам чёрного ящика: бизнес видит растущие расходы, команда разработки жалуется на сложность, а понять, где именно утекают токены, можно только постфактум.
На этом фоне заметно меняется и роль AI-инфраструктуры внутри компаний. Если раньше она часто сводилась к выбору провайдера и обвязке API, то теперь становится ближе к полноценной платформенной дисциплине: наблюдаемость, контроль затрат, оркестрация цепочек, политика работы с контекстом и повторным использованием данных. И в этом смысле материал The New Stack интересен именно своей оптикой: он возвращает разговор с уровня «какой промпт лучше» на уровень «какая система вообще получилась и можно ли её безопасно масштабировать».
Похоже, следующий этап конкуренции в enterprise AI будет идти не только между моделями, но и между командами, которые умеют держать токенный бюджет под контролем. У кого AI-сервисы останутся полезными и предсказуемыми под нагрузкой, тот и выиграет. Остальным придётся признать, что главная проблема была не в интеллекте модели, а в собственной архитектуре вокруг неё.