Отсутствующая метрика между токенами и облачными расходами

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

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

Почему метрики токенов и облачные счета рассказывают разные истории?

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

The State of FinOps 2026 показывает, как быстро ИИ вошёл в обычные задачи FinOps: 98 % респондентов теперь управляют расходами на ИИ, против 63 % в 2025 году. Но более крупная строка бюджета всё равно не говорит, какой рабочий процесс сжёг деньги и почему.

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

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

Как выглядит полная цепочка затрат?

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

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

The OpenTelemetry conventions for GenAI agents предлагают формирующийся словарь для этого уровня. Они охватывают операции, провайдеров, запрашиваемые модели, агентов, беседы, использование токенов, выполнение инструментов, ошибки и рабочие процессы. Конвенции всё ещё помечены как находящиеся в разработке, поэтому команды не должны рассматривать их как окончательный универсальный стандарт. Они полезны, потому что делают проблему корреляции конкретной.

Then comes infrastructure. split cost allocation data for EKS может назначать общие затраты на вычисления и память pod‑ам Kubernetes и раскрывать детали, такие как кластер, пространство имён, развертывание, узел, имя и тип рабочей нагрузки. Для поддерживаемых ускоренных инстансов данные также охватывают резервации GPU, Trainium и Inferentia.

That’s the other half of the chain. Трассировка может объяснить, что приложение пыталось сделать; распределение ресурсов Kubernetes может показать, какие ресурсы несли работу. Руководство Unite.ai по развёртыванию и мониторингу LLM в Kubernetes предоставляет более широкий производственный контекст, включая распределение ресурсов, масштабирование и наблюдаемость.

The join won’t happen by accident. Командам нужен стабильный идентификатор, который сохраняется достаточно долго, чтобы связать телеметрию приложения с метками рабочих нагрузок, записями распределения или другим слоем сопоставления. Данные клиентов не должны находиться в тегах Kubernetes. Команды должны решить, какие идентификаторы низкой кардинальности могут безопасно соединять категорию рабочего процесса, сервис или функцию с использованными ресурсами.

Once that application context is in place, teams can start tracking Kubernetes costs by workload и соединять пространство имён, CPU, память и использование GPU с выполняемой работой. Это всё ещё не говорит, создал ли рабочий процесс бизнес‑ценность, но даёт инфраструктурной части расчёта конкретную привязку.

Какой показатель единицы должен доверять бизнес?

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

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

Успех меняет расчёты.

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

Agent systems make this harder because their paths can change from one run to the next. Unite.ai’s analysis of the economics of scaling agentic AI workloads охватывает маршрутизацию, вызовы инструментов, повторные попытки и атрибуцию на уровне рабочего процесса. Эти поведения должны учитываться в метрике единицы, когда они потребляют ресурсы, даже если конечный пользователь видит только один ответ.

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

Кому принадлежит цифра?

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

Ни одна команда не владеет полной цепочкой.

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

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

Этот обзор важнее, чем отполированная панель. Внезапный рост может быть вызван более длинными подсказками, новым резервным путём, недоиспользованием GPU, изменённой политикой автоскейлинга или продуктовым решением, которое отправляет больше работы через ИИ‑функцию. Каждая причина принадлежит разному владельцу.

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

Цепочка затрат должна быть общей

Контроль расходов ИИ останется фрагментированным, пока каждая команда оптимизирует только тот слой, который она видит. Токены, трассировки, pod‑ы, ускорители и счета — не конкурирующие измерения. Это части одной и той же цепочки затрат.

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