Сократить затраты на ИИ на 80% можно не только сменой модели и уж точно не бесконечным торгом за цену токена. Именно к такому выводу пришёл Зохар Эйни в материале о собственной практике оптимизации, и для продуктовых команд это новость важнее очередного сравнения «кто дешевле на входе». Если тезис автора верен, то главная утечка бюджета прячется не в прайс-листе вендора, а в том, как компания вообще использует генеративный ИИ внутри продукта.
Об этом сообщает The New Stack в статье Zohar Einy под прямым заголовком: команда смогла урезать расходы на ИИ на 80%. Ключевая мысль звучит неприятно для рынка, который привык обсуждать только стоимость моделей: счета растут не по той причине, о которой обычно спорят в Slack и на созвонах с закупками. Да, модели становятся мощнее, и ценник на их использование остаётся важным фактором. Но в реальных системах деньги начинают сгорать там, где вокруг модели наращивается лишняя механика: слишком длинный контекст, повторяющиеся обращения, слабый контроль за тем, что именно и как часто отправляется в inference.
Это довольно болезненный разворот для команд, которые последние полтора года выбирали стратегию «найдём модель подешевле и победим юнит-экономику». На бумаге схема выглядит логично: сравнил цену за входные и выходные токены, переключился на более выгодного провайдера, показал CFO слайд с экономией. На практике этого хватает ненадолго. Как только ИИ-функции начинают жить в продукте, появляются агентские сценарии, многократные перезапросы, история диалога, системные промпты, служебные инструкции, отладочные вызовы и прочие вещи, которые не видны в демо, но отлично видны в счёте. В результате продукт может пользоваться «более дешёвой» моделью и всё равно тратить больше.
Судя по логике материала, автор предлагает смотреть на ИИ-расходы так же трезво, как зрелые команды давно смотрят на облачную инфраструктуру. Не как на магическую строку в бюджете «на эксперименты с AI», а как на полноценный инженерный контур, где у каждого запроса есть цена, полезность и срок жизни. Иначе происходит классическая для платформенных команд история: локально каждый вызов модели кажется недорогим, но в сумме организация получает неконтролируемый поток затрат. Особенно быстро это проявляется в продуктах, где ИИ стоит на пользовательском пути, а не в режиме внутренней игрушки для пары сотрудников.
Для разработчиков здесь неприятная, но полезная новость. Экономия в ИИ всё меньше похожа на выбор между «умной» и «бюджетной» моделью и всё больше на дисциплину проектирования. Если контекст передаётся без разбору, если система не отличает действительно важные запросы от рутинных, если одинаковые операции многократно прогоняются заново, то команда фактически масштабирует не ценность, а собственную небрежность. В такой схеме финансы начинают зависеть не от прорыва в машинном обучении, а от качества бэкенда, оркестрации и продуктовых ограничений. Это, кстати, хорошая новость для инженеров: проблема лежит в зоне, где можно навести порядок руками, а не ждать, пока рынок сам подарит чудо-дисконт.
Для бизнеса вывод ещё жёстче. Генеративный ИИ перестаёт быть строкой «инновации» и всё больше становится обычной операционной статьёй расходов. А значит, к нему начинают применяться взрослые вопросы: какой сценарий действительно приносит выручку, какие вызовы можно урезать без потери качества, где нужна дорогая модель, а где нет, кто вообще владелец этих затрат внутри компании. Пока на эти вопросы отвечает только команда разработки, руководитель почти гарантированно видит картину слишком поздно, когда месячный счёт уже приехал и внезапно оказался не похож на прогноз. Поэтому история про снижение затрат на ИИ на 80% интересна не как красивая цифра сама по себе, а как напоминание: без FinOps-подхода к ИИ даже успешный продукт может оказаться финансово тяжёлым.
На рынке это укладывается в более широкий тренд. Первая волна внедрения ИИ была почти полностью сосредоточена на качестве ответов, скорости релизов и демонстрационном эффекте для клиентов и инвесторов. Вторая волна, похоже, будет куда менее романтичной: кто сумеет держать качество при внятной себестоимости, тот и выиграет. И тут выясняется, что борьба идёт не только между OpenAI, Anthropic, Google или open source-моделями. Гораздо важнее конкуренция между самими командами по уровню инженерной зрелости. Одни продолжат мерить успех количеством интеграций с LLM, другие начнут считать стоимость полезного действия и выстраивать ограничения ещё на этапе архитектуры.
Для русскоязычной IT-аудитории в этом есть очень практичный смысл. Локальные команды тоже быстро приходят к тем же вопросам, даже если используют другой стек, собственные шлюзы к моделям или гибридные сценарии с open source. Паттерн везде один: как только ИИ выходит из пилота и попадает в production, стоимость начинает определяться не презентацией вендора, а глубиной вашей собственной дисциплины. Поэтому главный урок из заметки Эйни звучит почти обидно просто: срезать бюджет иногда можно не благодаря новой модели, а благодаря тому, что команда наконец-то перестала обращаться к модели как попало.
Следующий большой вопрос для отрасли уже виден: кто первым научится управлять ИИ-нагрузкой так же точно, как сегодня управляют облаком и observability. Потому что в ближайшие кварталы победят не те, кто громче всех говорит про агентность, а те, кто умеет объяснить, сколько именно стоит каждый «умный» сценарий и почему он вообще достоин своего места в продукте.