FinOps AI-инфраструктуры: считать стоимость полезного результата

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

Выбрать единицу результата

FinOps Foundation описывает unit economics как способ связывать расходы с единицами ценности для бизнеса 1. Для AI это может быть корректно обработанный документ, решённое обращение или завершённый анализ. Токены и GPU-часы остаются важными техническими единицами, но не всегда отражают то, за что платит клиент.

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

Собрать полный числитель

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

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

Расход	Как учитывать
Постоянный узел и резерв	По принятому горизонту и владельцу мощности
Аренда по времени	По фактическим сессиям и правилам округления
Подготовка данных	По проекту и частоте обновления
Эксплуатация	По работе и обслуживаемым сервисам
Повторы и ошибки	Оставлять в расходах, объяснять причины
Нераспределённый ресурс	Показывать отдельно, не скрывать в успешных задачах

Пример для проверки формулы

Предположим, постоянные месячные расходы составляют 150 000 ₽, переменные — 30 000 ₽. Обработано 120 000 запросов, из них 90% прошли согласованный критерий полезности. Тогда полезных результатов 108 000, а стоимость одного равна 180 000 / 108 000 ≈ 1,67 ₽. Это условная модель, не рыночный ориентир.

Если считать все запросы успешными, получится 1,50 ₽ и экономика будет выглядеть лучше без фактического улучшения. Если дополнительно появились расходы на ручное исправление, их нужно прибавить. Поэтому рядом с ценой операции показывайте качество, задержку и состав нагрузки.

Разнести потребление по владельцам

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

FinOps for AI отдельно рассматривает особенности затрат AI-систем 2. В небольшом проекте достаточно регулярной таблицы фактических расходов и объёмов, если источники прозрачны. Сложная платформа учёта не нужна до появления нескольких владельцев и значимого распределяемого бюджета.

Оптимизировать с проверкой результата

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

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

Когда масштабировать

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

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