Cost-aware архитектура ИИ-систем

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

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

Гипотеза: стоимость проектируется, а не оптимизируется потом

Стоимость ИИ-системы — не следствие цены модели, а следствие решений архитектора: сколько вызовов на один результат, какой контекст в каждом, какая модель на каком шаге. Эти решения принимаются на этапе проектирования. Оптимизация «по факту счёта» дороже и почти всегда означает временное отключение части функциональности.

Цена за токен упала в сотни раз — и счета всё равно взрываются. Значит, дело не в цене модели, а в архитектуре вокруг неё.

Проблема: стоимость считают постфактум

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

Почему обычные подходы не работают

«Подождём, модели дешевеют» не работает: дешевеет цена за токен, а не архитектурная привычка подкладывать в контекст всё подряд; объём растёт быстрее, чем падает цена.

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

«Возьмём модель подешевле везде» не работает: на дорогих по цене ошибки шагах слабая модель создаёт убытки больше экономии.

Инженерная модель: стоимость как проектная метрика

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

Бюджет контекста на шаг. Жёсткий потолок токенов на шаг не даёт длине тихо расти. Это одновременно про стоимость и про качество.

Шаги без модели. Логику, ветвления, работу с данными делают обычным кодом; модель вызывается только там, где действительно нужна. Самый дешёвый токен — невызванный.

Обрыв тихих циклов. Лимиты итераций, таймауты, ранний выход. Несходящийся цикл останавливается и эскалируется, а не жжёт токены.

Наблюдаемость стоимости по шагам. Каждый вызов помечен шагом; стоимость собирается по шагам. «Система дорогая» превращается в «шаг X дороже из-за Y» — задачу с решением.

Практический вывод для бизнеса

Требуйте два числа: стоимость разработки и стоимость работы в месяц при вашем объёме. Проект без второго числа не оценён по стоимости владения.

Спросите про cost-наблюдаемость до запуска. Если стоимость нельзя разложить по шагам, ею нельзя управлять — только урезать функции по факту счёта.

Закладывайте контроль стоимости в архитектуру, а не в дорожную карту «оптимизаций». Это несколько дней работы заранее против недель аврала потом — при том же конечном функционале.

Приложить это к вашим процессам — обсудить с инженером → .

Открытые вопросы

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

Если счёт за ИИ растёт быстрее, чем нагрузка, — проблема в архитектуре, и она находится по трассировке. Обсудить → — разложим стоимость по шагам и где она проектируется неверно.