Современный мейнстрим разработки корпоративного ИИ окончательно скатился в «token maxing» — порочную практику покупки системных возможностей за счет бездумного наращивания объема токенов. Согласно исследованию команды Writer, Inc. под руководством Муаяда Сайеда Али и Васима Альшиха, стремительное падение цен за токен лишь маскирует парадокс Джевонса: когда эффективность модели растет, бизнес начинает потреблять ресурсы в геометрической прогрессии. При переходе от прототипов к промышленной эксплуатации скрытый «налог на размышления» — многошаговые цепочки рассуждений (CoT), раздутые схемы инструментов и квадратичные повторы контекста — создает нелинейный рост затрат, который на корню съедает ценность выполненной задачи. Очевидно, что базовые модели перестали быть основным драйвером расходов; теперь деньги сжигает софт, который их окружает.
Анатомия «token maxing»
Агентская задача вроде сверки контрактов никогда не ограничивается одним вызовом модели. Как отмечают в Writer, Inc., процесс разворачивается в десятки итераций, включающих системные промпты, данные из поиска и промежуточные выводы. В наивных реализациях каждый предыдущий шаг пересчитывается заново, превращая бюджет в решето: количество токенов на задачу растет быстрее, чем полезность результата. Исследователи вводят понятие «упряжи» (harness) — слоя оркестрации, который управляет контекстным окном и определяет момент остановки. Без жесткой дисциплины в этом слое компании сталкиваются с лавинообразным ростом «пустых трат» (failure-spend) — стоимости цикличных ошибок агентов и извлечения мусорных данных без какого-либо контроля.
«Token maxing» незаметен в таблицах бенчмарков, измеряющих качество, но больно бьет по карману в облачных счетах за токены.
Чтобы доказать влияние архитектуры на экономику, команда Writer, Inc. провела эксперимент на 22 оценочных задачах с использованием шести моделей, включая Claude 3.5 Sonnet, Gemini 1.5 Pro, Gemini Flash 1.5, Qwen 2.5, GLM 4 и Palmyra X6. Сохранив модели неизменными и заменив лишь стандартный слой оркестрации на Writer Agent Harness, исследователи изолировали экономический эффект самого программного обеспечения. Данные подтвердили: выбор «упряжи» влияет на стоимость задачи сильнее, чем переход от самой дешевой модели к самой дорогой.
Рычаг управления «упряжью»
Результаты методологии показывают, что специализированная оркестрация позволяет отвязать производительность от расточительства. Внедрение Writer Agent Harness сократило среднюю стоимость задачи на 41% (с $0,21 до $0,12) и медианное время выполнения на 44% (с 48 до 27 секунд). Важно, что этот эффект универсален: каждая протестированная модель стала дешевле в эксплуатации на 33–61%. Исследователи также выявили феномен «рычага упряжи» (harness leverage): способность модели извлекать качество из архитектуры оркестрации почти идеально коррелирует с ее базовой мощностью (r=0,99).
Оркестрация — это единственный компонент, эффективность которого масштабируется на все модели, которые компания использует сегодня или внедрит завтра.
Для CTO это означает смену парадигмы: важно не то, какую LLM вы выберете, а какова «экономика токенов» вашего слоя оркестрации. Реализация механизмов контроля — от дисциплины кэширования до управления стоимостью отказов — позволяет увеличить количество завершенных задач на миллион токенов с 54,9 до 92,0. Вместо того чтобы покупать качество ценой бесконечного раздувания контекста, архитекторам пора сфокусироваться на том, как система выстраивает последовательность ходов и делегирует работу.
Это исследование смещает фокус ROI в области ИИ с чистых бенчмарков на архитектурную эффективность. Совокупная стоимость владения (TCO) автономными системами теперь определяется дизайном оркестрации в большей степени, чем прайс-листом провайдера LLM. Хотя оптимизированная «упряжь» и обещает рост качества на доллар в 82%, реальность такова, что текущие коробочные агентские решения экономически несостоятельны для индустриальных масштабов. Главный риск остается в расширении контекстных окон: если не вшить механизмы управления в саму «упряжь», это лишь подстегнет еще более расточительное поведение разработчиков в надежде решить проблемы грубой вычислительной силой.