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

Эта история получила название «токенмаксинг» — резкий рост потребления токенов без подтверждённой отдачи.

Uber ограничил расходы на каждого сотрудника и каждый инструмент для агентного программирования суммой $1 500 в месяц. Компания оказалась не единственной, кто пересмотрел подход к затратам.

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

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

Для предприятий это становится проблемой. При этом специалисты предлагают разные способы её решить.

Люди или инфраструктура?

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

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

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

На корпоративных и командных тарифах премиальные модели обычно выбраны заранее, по умолчанию работают с высокой глубиной рассуждения, а в тарифе Promova сессии Opus автоматически получают контекстное окно на 1 млн токенов. Сотрудники редко меняют эти параметры в личных настройках.

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

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

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

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

Рост расходов на токены не обязательно означает, что компаниям нужно пользоваться ИИ реже.

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

SUSE делит использование ИИ на три категории, с которыми руководители работают по-разному:

Для автономного агента лучшей не обязательно будет самая новая передовая модель. SUSE пытается не подавлять использование ИИ, а связывать его с результатом.

Сейчас у SUSE нет автоматического слоя маршрутизации: решения принимают сами разработчики. Прокси-слой есть в планах компании.

Everlaw, которая создаёт ИИ-инструменты для судебных разбирательств и расследований, устанавливает индивидуальные ограничения на расход токенов, как Uber. Но технический директор Макс Кристофф считает эти ограничения не способом нормировать доступ, а механизмом обратной связи. Когда инженер достигает лимита, команда инструментов получает короткое письмо, после чего обычно в тот же день лимит удваивается.

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

В другом, ещё не выпущенном продукте, расходы на токены составили $27 000 и, вероятно, достигнут $40 000. При этом оценочное время разработки снизилось с 90–100 инженерных месяцев до 19.

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

Agiloft полностью отказалась от лимитов. По словам Рамоса, 74% сотрудников вообще не достигали прежних ограничений. Лимиты создавали препятствия для активных пользователей, но не устраняли настоящие причины расходов.

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

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

Как работают маршрутизаторы

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

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

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

Маршрутизатор выбирает не только модель. В Databricks обнаружили, что одна и та же модель может работать по-разному в зависимости от оболочки, через которую её используют, поэтому Smart Routing учитывает и этот параметр.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководители компаний расходятся в том, с чего начинать оптимизацию:

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