Расходы на корпоративный ИИ: окупаемость не доказана

В декабре 2025 года компания Uber предоставила своим инженерам Claude Code и установила внутренние таблицы лидеров, отслеживающие потребление токенов и ранжирующие команды по объемам их использования. К апрелю весь бюджет на разработку с помощью ИИ на 2026 год был исчерпан.

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

Вся эта история породила термин для обозначения более масштабной проблемы: «токенмаксинг» (tokenmaxxing), то есть лавинообразный рост потребления токенов без оправдывающей его окупаемости инвестиций (ROI).

Компания Gartner ожидает, что расходы на программное обеспечение с ИИ-агентами приблизятся в этом году к $207 млрд, что на 139% больше по сравнению с $86,4 млрд в 2025 году. Однако ценообразование токенов не подчиняется законам затрат на ПО, моделированию которых финансовые директора посвятили десятилетия. Один и тот же инженер, использующий один и тот же инструмент в один и тот же день, может сформировать совершенно разные счета в зависимости от того, провел ли он утро за автозаполнением подсказок или запустил параллельные агенты для масштабной миграции базы данных.

Теперь Uber ограничивает расходы на уровне $1500 в месяц на каждого сотрудника, использующего инструменты агентского программирования. И компания не единственная, кто пересматривает свои взгляды.

Microsoft поставила под сомнение стоимость лицензий Claude Code, прежде чем окончательно отменить их в своем подразделении Experiences and Devices. Компания Duolingo отказалась от планов учитывать использование ИИ при оценке эффективности работы сотрудников после того, как те выразили недовольство призывами использовать эти инструменты ради самого процесса.

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

Этот разрыв теперь стал проблемой для бизнеса. И специалисты, пытающиеся его преодолеть, далеко не всегда сходятся в том, как именно его решить.

Проблема в людх или в инфраструктуре?

Ноэ Рамос, вице-президент по ИИ-операциям в Agiloft (платформе управления жизненным циклом корпоративных контрактов), считает, что термин «токенмаксинг» указывает не на того виновника.

«Команды тратят бюджеты не из-за любви к расточительству. Они делают это потому, что инфраструктура по умолчанию подталкивает их к этому», — рассказал Рамос изданию VentureBeat. — «Большинство компаний до сих пор перекладывают выбор моделей на того, кто пишет промпты. В итоге передовая модель выполняет задачи, с которыми дешевая модель с открытыми весами справилась бы ничуть не хуже. Это проблема не людей. Это проблема инфраструктурной начинки».

Дмитрий Палийчук, руководитель отдела разработки в компании по изучению языков Promova, видит причину в настройках по умолчанию, заданных большинством ИИ-инструментов.

«Оказалось, что в командных и корпоративных тарифах премиальные модели выбраны заранее; по умолчанию они работают с высоким уровнем логических рассуждений (reasoning effort), а в нашем тарифе сеансы Opus обновляются до контекстного окна в 1 млн токенов. Разумеется, никто не меняет это в своих личных настройках», — пояснил он.

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

Чтобы устранить эти пробелы, по словам Палийчука, компания Promova двидется к распределению запросов в пропорции 40/50/10 между моделями Opus, Sonnet и Хаiku. Тем не менее, он называет это скорее ориентиром, чем конечной целью, поскольку само соотношение не является главным.

«Нас сдерживает преимущественно поведенческая проблема. Даже если принудительно установить настройки организации по умолчанию на Sonnet, но не сформировать понимание того, что и когда использовать, люди возвращаются к старым привычкам», — отметил Палийчук. — «Самое главное — чтобы люди осознанно использовали модели, понимая, какую из них выбрать для конкретной задачи, и имели привычку проверять это перед началом нового разговора с языковой моделью».

Оптимизация использования не означает сокращение применения ИИ

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

«Первой реакцией не должно быть стремление «использовать меньше ИИ». Высокое потребление токенов может означать самые разные вещи. Если кто-то тратит $16 000 на токены, чтобы сэкономить нам $100 000, мы, конечно, хотим это поощрять», — рассказал VentureBeat Рик Спенсер, генеральный менеджер по технологиям и продуктам в SUSE. — «Все начинается с диагностики, а не с принудительных запретов».

В SUSE классифицируют использование ИИ по трем категориям, работу с которыми контролируют менеджеры: повседневная работа, автономные агенты и качественный рывок (Curve Jumping) для разовых стратегических инициатив.

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

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

В компании Everlaw, которая предоставляет ИИ для судебных разбирательств и расследований, действуют лимиты на токены для каждого сотрудника (подобно Uber), но технический директор Макс Кристофф называет их полной противоположностью нормированию. Достижение лимита приводит к отправке короткого письма в инструментальную команду, и инженеру обычно удваивают лимит в тот же день.

Everlaw также оказалась единственной компанией, которая смогла поделиться точными цифрами о возврате инвестиций в ИИ. Один из проектов, связанных с базовой инфраструктурой Java, потребил токены на $3,500 и сократил время реализации с 9,5 до 2,5 человеко-месяцев разработки.

«Это реальные цифры; окупаемость в $3 500 ради экономии семи месяцев инженерного времени — это абсолютный очевидный выбор», — заявил Кристофф. Другой, более крупный продукт, который еще не запущен, потребовал токенов на $27 000 (и, вероятно, достигнет $40 000), при этом затраты времени на разработку сократились с прогнозируемых 90–100 человеко-месяцев до 19.

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

Что касается Agiloft, то компания вообще полностью отказалась от лимитов: «74% людей и раньше никогда не выбирали старые лимиты. Ограничения были ложным потолком, который создавал трудности для активных пользователей, никак не решая реальные проблемы с затратами», — пояснил Рамос.

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

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

Внутри маршрутизаторов

Любопытно, что сегодня многие вендоры, включая Merge, Databricks, AWS Bedrock и Azure AI Foundry, решают эту проблему с помощью автоматических маршрутизаторов. Они оценивают сложность задачи и направляют ее на модель, которая лучше всего подходит для ее решения и одновременно является экономичной.

Компания Databricks представила функцию умной маршрутизации (Smart Routing) в составе Unity Gateway на своем саммите Data + AI Summit в июне, наряду с жесткими лимитами расходов и распределением затрат по размещенным моделям, агентам программирования и кастомным агентам. Функция находится в стадии бета-тестирования и работает в режимах рекомендаций и автоматической маршрутизации.

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

Маршрутизатор занимается не только выбором модели. «Мы обнаружили, что одна и та же модель ведет себя по-разному при использовании с разными обертками (harness), поэтому мы создали Smart Routing с учетом этой гибкости», — рассказал Наси изданию VentureBeat.

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

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

Проблема окупаемости (ROI)

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

Палийчук, который стремится к распределению моделей 40/50/10 с осознанным выбором инструментов сотрудниками под конкретные задачи, не привел цифры «до и после» для Promova, поскольку это изменение внедрялось одновременно с другими рабочими процессами. Тем не менее, его телеметрия показала, что модель Opus с окном в 1 млн токенов составляла примерно треть от месячных расходов.

В SUSE, где использование ИИ распределено по категориям и готовится внедрение прокси-сервера, также нет точных метрик — только отдельные примеры. Один из проектов избавился от сотен уязвимостей (CVE) в своих зависимостях, сведя их к нулю, а его агенты с мая классифицировали около 10 000 уязвимостей в базе данных VEX.

Тем временем компания Databricks поделилась видением того, куда движутся команды.

«Ранние паттерны использования демонстрируют четкий сдвиг: команды, которые раньше пропускали весь трафик через передовые модели, начинают переносить рутинные задачи (такие как генерация шаблонного кода, простые исправления багов или мелкие правки) на более дешевые модели без какого-либо измеримого снижения показателей успешности решений», — отметил Наси.

Чтобы гарантировать, что команды получают четкое представление об этой оптимизации затрат и вовремя замечают ухудшение качества после изменения маршрутизации, Databricks поставляет Unity Gateway со средствами унифицированной трассировки, фреймворками оценки LLM-as-a-judge, а также наборами данных для оценки, аналитикой трассировок и автоматическими циклами обратной связи.

Однако проверка точности для конкретной бизнес-доменной области ложится на плечи клиента, что Палийчук назвал непростой задачей. Он отметил, что «вы применяете детерминированные проверки к недетерминированному выводу, а модели выпускаются примерно ежеквартально — система оценки, настроенная под одну модель, некорректно переносится на следующую».

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

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

Что будет дальше

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

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

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

«Мой прогноз заключается в том, что в ближайшие один-два года мы начнем относиться к расходам на токены скорее как к затратам на ежегодный штат сотрудников или производственным издержкам, а не как к расходам на IT или стандартное ПО», — заявил он, добавив, что руководители подразделений скоро будут приходить на ежегодное планирование с четкими позициями как по численности персонала, так и по токенам, подкрепляя обе статьи бизнес-планом.

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

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

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

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