AI FinOps: как обуздать скрытые расходы на ИИ-агентов и LLM

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

Один пользовательский запрос может закончиться одним обращением к модели. Другой потребует десять вызовов LLM, поиск по базе знаний, несколько обращений к внешним системам и повтор части цепочки после ошибки. Количество пользователей при этом может остаться прежним.

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

Поэтому общий счёт за API или GPU показывает слишком мало. Для управления нужна другая единица: сколько стоит успешно выполненная бизнес-задача — с этого начинается AI FinOps.

Все расчёты ниже, кроме отдельно обозначенного примера SVK.Digital, модельные. Они показывают механику расходов, конкретные значения зависят от тарифов, архитектуры и бизнес-процесса.

Почему стоимость ИИ плохо прогнозируется по количеству запросов

Возьмём агента для проверки договоров. Для пользователя всё выглядит просто: загрузить документ и нажать «Проверить».

Внутри один запуск может выглядеть так:

Проверка договора #18427

1. Извлечь текст

2. Найти реквизиты и существенные условия

3. Запросить внутренние правила компании

4. Проанализировать условия

5. Получить сведения о контрагенте

6. Проверить найденные риски

7. Сформировать заключение

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

Упрощённо стоимость запуска выглядит так:

Стоимость задачи = LLM + контекст + поиск + инструменты + внешние API + инфраструктура

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

Посмотрим на два запуска одного сценария:

Токены — техническая единица. А что насчет бизнеса

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

Службе поддержки нужен закрытый тикет. HR — обработанное резюме. Бухгалтерии — разобранный документ. Продажам — подготовленное коммерческое предложение. Разработке — проверенный pull request.

Поэтому хорошо, когда экономика поднимается от инфраструктуры к процессу.

FinOps Foundation разделяет resource efficiency metrics и business unit metrics именно для этого: стоимость технологии связывается с единицей деятельности, которая создаёт ценность для организации.

Ключевое слово здесь — успешного. Допустим, обработка документа обходится в среднем в 4 рубля. Из 10 000 документов 8 500 система обработала правильно, 1 000 потребовали повторного запуска, а 500 пришлось разобрать сотруднику вручную.

Метрика 4 ₽/документ скрывает значительную часть экономики.

Рабочая формула выглядит иначе:

Стоимость успешной задачи = полные затраты сценария / число задач, прошедших критерий качества

В полные затраты при необходимости включается и человеческая обработка исключений.

Как это выглядит на реальном процессе

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

Сейчас первая версия оценки появляется примерно за 20 минут. После обучения на накопленных данных система попадает в человеческие оценки с отклонением около 10–15%. Специалисты проверяют и корректируют готовую оценку.

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

Эти показатели отвечают на главный вопрос: стала ли оценка проекта дешевле и быстрее при приемлемом качестве.

Смотрим, за что именно платим

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

Для этого каждый серьёзный AI-сценарий должен оставлять трассу выполнения.

Проверка договора #18427

├── extract_data

│ └── model: small

├── retrieve_policy

│ └── vector search

├── analyze_terms

│ └── model: large

├── get_counterparty

│ └── external API

├── check_risks

│ └── model: large

└── prepare_summary

└── model: small

У каждого шага фиксируются модель, токены, время, вызовы инструментов, статус и стоимость. OpenTelemetry уже описывает семантические соглашения для GenAI: можно собирать модель, входные и выходные токены, workflow, tool calls и связанные параметры в обычных traces. Для содержимого сообщений и результатов инструментов предусмотрена отдельная осторожность, поскольку они могут содержать чувствительные данные.

Минимального набора полей обычно достаточно:

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

Это уже материал для инженерного решения.

Контекст может незаметно съесть половину бюджета

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

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

Если ничего не очищать, восемь вызовов получат:

10 + 12 + 14 + 16 + 18 + 20 + 22 + 24 = 136 тыс. входных токенов

Если после каждого шага сохранять только необходимое состояние и удерживать рабочий контекст около 10 тысяч токенов:

10 × 8 = 80 тыс. токенов

Разница — 56 тысяч входных токенов, или около 41%.

Агент выполнил ту же работу тем же количеством LLM-вызовов. Изменилась только работа с контекстом. На масштабе миллиона запусков такая разница превращается в инфраструктурный бюджет.

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

Практический принцип простой: каждый следующий вызов должен получать достаточный контекст, а не весь доступный.

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

Хороший интерфейс инструмента фильтрует данные до передачи модели.

Дорогой хвост важнее средней стоимости

После появления трассировки команда обычно начинает смотреть на среднюю стоимость запуска — этого недостаточно.

Представим сервис, где p50 = 12 ₽, p95 = 44 ₽, а максимальный запуск за месяц стоил 260 ₽. Половина операций укладывается в 12 рублей, и большая часть системы выглядит вполне здоровой.

Затем открываем трассу запуска за 260 рублей:

Запрос пользователя -> LLM -> поиск -> LLM -> API вернул ошибку -> retry -> LLM -> поиск по другому источнику -> LLM -> API снова вернул ошибку -> retry -> fallback model -> повторная проверка -> финальный ответ

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

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

Поэтому для AI FinOps полезны как минимум:

• - p50 стоимости — обычное выполнение;
• - p95 стоимости — дорогой хвост;
• - максимум — потенциальная аварийная зона.

Далее можно рассмотреть введение лимитов в рамках финансового периметра.

Агенту нужен финансовый периметр

Для рабочего сценария лучше заранее определить предел автономности: максимальное число шагов, ретраев, вызовов инструментов, лимит токенов, время выполнения и максимальную стоимость запуска.

Допустим, после месяца наблюдений получилась такая картина: p50 — 12 ₽, p95 — 44 ₽, а задачи дороже 60 ₽ почти всегда связаны с ошибками или повторными циклами. Тогда 60 ₽ можно использовать как один из сигналов остановки.

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

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

Снижать стоимость лучше в определённом порядке

Когда расходы разложены по трассам, можно переходить к оптимизации.

1. Уберите работу, которую система выполняет зря

Сначала нужно посмотреть на сам процесс. Нужны ли три проверки ответа? Нужно ли каждый раз обращаться к поиску? Имеет ли смысл отправлять LLM проверку ИНН, даты или статуса, если это надёжно делает обычный код? Нужно ли второй раз запрашивать данные, уже полученные системой?

Один удалённый LLM-вызов даёт стопроцентную экономию на этом вызове.

2. Сократите контекст

Следующие кандидаты — полная история диалога, большие результаты RAG, повторяющиеся инструкции, ненужные tool results и документы, которые уже перестали влиять на решение.

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

3. Разберите дорогие трассы

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

Несколько десятков таких разборов обычно дают больше, чем долгое сравнение тарифов моделей.

4. Разведите операции по моделям

Большая модель на всех шагах удобна в прототипе. При большом объеме она становится дорогой архитектурной привычкой.

Возьмём модельный сервис со 100 тысячами операций в месяц. Допустим, 20% задач действительно сложные, а остальные 80% — классификация и извлечение данных.

Предположим:

• - сильная модель обходится в среднем в 10 ₽ на задачу;
• - небольшая модель — в 1,5 ₽;
• - в 8% простых задач небольшая модель не уверена в результате и передаёт их сильной.

Если отправлять все 100 тысяч задач сильной модели:

100 000 × 10 ₽ = 1 000 000 ₽

С маршрутизацией:

Простые задачи:

80 000 × (1,5 ₽ + 8% × 10 ₽) = 184 000 ₽

Сложные:

20 000 × 10 ₽ = 200 000 ₽

Итого:

384 000 ₽ вместо 1 000 000 ₽

Экономия — около 62%.

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

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

5. После этого оптимизируйте инфраструктуру

Когда лишние вызовы, контекст и маршрутизация уже разобраны, появляется смысл сравнивать поставщиков, пакетную обработку, зарезервированные мощности и собственное развертывание.

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

Модель в четыре раза дешевле может увеличить себестоимость

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

Представим обработку 100 тысяч документов.

Модель A:

• - ИИ-обработка — 12 ₽;
• - эскалация специалисту — 2% задач.

Модель B:

• - ИИ-обработка — 3 ₽;
• - эскалация специалисту — 10% задач.

Модель B в четыре раза дешевле.

Теперь добавим стоимость ручной проверки. Допустим, квалифицированному специалисту требуется 10 минут, а внутреннюю стоимость этого времени компания оценивает в 200 ₽.

Для модели A:

12 ₽ + 2% × 200 ₽ = 16 ₽ на документ

Для модели B:

3 ₽ + 10% × 200 ₽ = 23 ₽ на документ

На 100 тысячах документов получаем:

Модель A: 1,6 млн ₽

Модель B: 2,3 млн ₽

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

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

Стоимость, качество и скорость оцениваются совместно

Допустим, после оптимизации расходы на обработку документа снизились на 40%. Результат выглядит приемлемым.

Затем выясняется, что точность упала с 97 до 89%. Сотрудники стали чаще перепроверять документы, часть операций возвращается на повторный запуск. Расходы просто переместились из API в ручной труд.

Поэтому у рабочего сценария нужны три группы показателей:

Для каждого типа системы критерии свои. RAG проверяется на корректность ответа и источников. Извлечение данных — на точность полей. Код-ревью — на полезность замечаний и пропущенные дефекты. Агент поддержки — на долю задач, действительно решённых без сотрудника.

Каждое существенное изменение модели, промпта, RAG или маршрутизации прогоняется через один и тот же набор контрольных задач. Тогда разговор об оптимизации выглядит предметно:

стоимость успешной операции снизилась на 22%, качество осталось в заданном диапазоне, p95 latency сократился на 14%.

Этим уже можно управлять.

Как выглядит рабочий AI FinOps

Отдельный FinOps-отдел для первого этапа не требуется. Для каждого существенного AI-сценария нужны девять вещей.

1. Владелец
Кто отвечает за результат и экономику процесса.

2. Единица результата
Документ, тикет, оценка, заявка, проверка или другое завершенное действие.

3. Критерий качества
Условие, при котором задача считается успешно выполненной.

4. Полная стоимость
Модели, инструменты, внешние API, инфраструктура и значимые ручные операции.

5. Трассировка
Возможность открыть конкретный запуск и восстановить цепочку расходов.

6. Распределение стоимости
Минимум p50 и p95 вместо одной средней цифры.

7. Лимиты
Количество шагов, ретраев, время и максимальный бюджет выполнения.

8. Eval-набор
Проверка влияния каждого изменения на качество.

9. Бизнес-эффект
Экономия времени, снижение себестоимости, увеличение пропускной способности, рост выручки или другой измеримый результат.

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

FinOps Foundation (международная некоммерческая организация развития и стандартизации дисциплины FinOps) предлагает тот же принцип на уровне юнит-экономики: технологические затраты нужно сопоставлять с бизнес-единицей и ценностью, которую система создает. Для ИИ-инициатив среди показателей отдельно рассматриваются финансовая отдача и время до получения бизнес-ценности.

Что можно сделать за неделю

Перестраивать всю AI-инфраструктуру не требуется. Подойдет один продакшн-сценарий с заметным расходом и проход его по короткому циклу.

День 1. Определите единицу результата. Например, успешно обработанный документ. Сразу зафиксируйте критерий успешности.

День 2. Соберите полную стоимость. Учтите LLM, RAG, инструменты, API, инфраструктуру и ручную обработку исключений.

День 3. Добавьте трассировку. Каждый проход должен раскладываться до отдельных вызовов моделей и обращений к инструментам.

День 4. Посчитайте p50 и p95. Откройте самые дорогие запуски и найдите первый момент, где их путь начинает отличаться от нормального.

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

День 6. Уберите один крупнейший источник расходов. Например, сократите контекст или исключите повторный LLM-вызов.

День 7. Запустите тот же оценочный набор. Сравните стоимость успешной задачи, качество и задержку до и после изменения.

После этого у компании появляется первая нормальная единица экономики ИИ.

ИИ должен окупать работу, которую выполняет

AI FinOps сокращает расходы на токены, а ещё делает экономику ИИ объяснимой. CTO должен видеть для каждого серьезного сценария три вещи:

• - сколько стоит успешно законченная задача;
• - из каких операций складывается эта стоимость;
• - какой экономический результат получает бизнес.

Тогда можно принимать осмысленные решения. Агент за 30 рублей может быть отличной инвестицией, если заменяет 20 минут работы специалиста. Агент за 3 рубля может оказаться дорогим, если каждый десятый результат сотрудник исправляет вручную.

Счёт за токены не способен ничего сказать об этом.

Когда стоимость связана с результатом, ИИ становится обычной производственной системой. Его можно измерять, ограничивать, оптимизировать и масштабировать. В этот момент вопрос «сколько мы тратим на LLM?» теряет смысл — полезнее узнать сколько стоит результат, ради которого вообще подключили ИИ.