Відсутня метрика між токенами та хмарними витратами

Проблема не в тому, що командам ШІ не вистачає даних про витрати. Проблема в тому, що панель токенів і хмарний рахунок описують різні системи, які належать різним командам, і немає надійного способу їх з’єднати.

Агент підтримки може вирішити один запит після п’яти викликів моделі, кроку отримання даних, двох викликів інструменту та повторної спроби. Бізнес фіксує один завершений випадок. Інфраструктура реєструє розкидані запити, pod’и, пам’ять, час роботи прискорювачів і спільні сервіси. Поки ці записи не збігаються, оптимізація витрат є частково здогадкою.

Чому метрики токенів і хмарні рахунки розповідають різні історії?

Кількість токенів корисна. Вона показує, скільки тексту модель отримала і повернула, і допомагає командам порівнювати підказки, моделі або варіанти маршрутизації. Але вона не розповідає, що сталося навколо виклику моделі, скільки обчислювальних ресурсів було витрачено на отримання даних та використання інструментів, скільки невдалих спроб було спочатку, або чи був кінцевий результат корисним.

Звіт State of FinOps 2026 показує, наскільки швидко ШІ увійшов у звичайну роботу FinOps: 98 % респондентів тепер керують витратами на ШІ, порівняно з 63 % у 2025 році. Проте більша стаття бюджету все одно не підказує, який робочий процес витратив гроші і чому. 

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

Unite.ai вже дослідив, чому кількість токенів не автоматично відображає бізнес-цінність. Наступний крок – пов’язати ці підрахунки з робочими навантаженнями, які їх створили. Інакше команда може покращити вартість за токен, одночасно погіршуючи вартість за завершене завдання.

Як виглядає повний ланцюжок вартості?

Корисний ланцюжок вартості починається з результату, який важливий для бізнесу. Це може бути вирішений випадок підтримки, оброблений документ, прийнята зміна коду або завершений робочий процес агента. Усе нижче потребує ідентифікатора, який можна відстежити в системі.

Шар додатка забезпечує перше з’єднання. Ідентифікатор запиту, ідентифікатор трасування, назва робочого процесу або ідентифікатор розмови можуть пов’язати кілька операцій моделей і інструментів з однією роботою. Без цього зв’язку десять пов’язаних подій виглядає як десять незв’язаних витрат.

Конвенції OpenTelemetry для агентів GenAI пропонують нову термінологію для цього шару. Вони охоплюють операції, постачальників, запитані моделі, агентів, розмови, використання токенів, виконання інструментів, помилки та робочі процеси. Конвенції ще позначені як розробка, тому команди не повинні розглядати їх як завершений універсальний стандарт. Вони корисні, бо роблять проблему кореляції конкретною.

Далі йде інфраструктура. Розподіл витрат для EKS від AWS може призначати спільні витрати на обчислення та пам’ять pod’ам Kubernetes і розкривати деталі, такі як кластер, простір імен, розгортання, вузол, назва та тип робочого навантаження. Для підтримуваних прискорених інстансів дані також охоплюють резервування GPU, Trainium та Inferentia.

Це інша половина ланцюжка. Трасування може пояснити, що намагалося зробити додаток; розподіл Kubernetes може показати, які ресурси виконували роботу. Посібник Unite.ai щодо розгортання та моніторингу LLM на Kubernetes надає ширший виробничий контекст, включаючи розподіл ресурсів, масштабування та спостережливість.

З’єднання не відбудеться випадково. Командам потрібен стабільний ідентифікатор, який існує достатньо довго, щоб пов’язати телеметрію додатка з мітками робочих навантажень, записами розподілу чи іншим шаром мапінгу. Дані клієнтів не повинні потрапляти в теги Kubernetes. Команди мають визначити, які ідентифікатори низької кардинальності можуть безпечно зв’язати категорію робочого процесу, сервіс або функцію з використаними ресурсами.

Коли цей контекст додатка встановлено, команди можуть почати відстежувати витрати Kubernetes за робочим навантаженням і пов’язувати простір імен, CPU, пам’ять та використання GPU з виконуваною роботою. Це все ще не підказує, чи створив робочий процес бізнес-цінність, але дає інфраструктурній стороні розрахунку конкретну основу для прив’язки. 

Якій одиничній метриці слід довіряти бізнесу?

Не існує єдиної метрики вартості ШІ, яку б мала використовувати кожна команда. Вартість за токен відповідає на питання про споживання моделі. Вартість за pod відповідає на питання про розподіл інфраструктури. Жодна з них не підказує власнику продукту, чи виправдовує функція свої витрати.

Найкращий знаменник зазвичай – це найменший результат, який бізнес може чітко визначити, і який команда продукту може впливати. Операція підтримки може відстежувати вартість за вирішений випадок. Система документів може використовувати вартість за успішно оброблений файл, тоді як помічник кодування може розглядати вартість за прийняту зміну, а не за пропозицію.

Успіх змінює розрахунок.

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

Системи агентів ускладнюють це, бо їхні шляхи можуть змінюватися від запуску до запуску. Аналіз Unite.ai щодо економіки масштабування агентних навантажень ШІ охоплює маршрутизацію, виклики інструментів, повторні спроби та атрибуцію на рівні робочого процесу. Ці поведінки повинні входити до одиничної метрики, коли вони споживають ресурси, навіть якщо кінцевий користувач бачить лише одну відповідь.

Метрика все одно не буде ідеальною. Спільні сервіси, кешовані результати, пакетні завдання та затримана обробка можуть розмивати атрибуцію. Оцінка, корисна для прийняття рішень, краща за хибну точність, особливо коли вона підказує інженерам, який шар потребує дослідження.

Хто володіє цифрою?

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

Жодна команда не володіє повним ланцюжком.

Це створює передбачувану дискусію про те, чия панель правильна. Команда ML може вказувати на менше використання токенів, команда платформи – на зростання годин GPU, а команда продукту – на меншу кількість завершених завдань, ніж раніше. Усі три спостереження можуть бути одночасно правдивими. Спільна метрика повинна пояснити взаємозв’язок між ними.

Практичним стартовим пунктом є один виробничий робочий процес з чітким подією завершення. Надати йому стабільний ідентифікатор. Перенести цей контекст через трасування моделей і інструментів, зіставити його зі службою або навантаженням, що працює в Kubernetes, і обрати один бізнес-знаменник. Потім зібрати команди разом, коли цифра змінюється несподівано.

Цей огляд важливіший за відполіровану панель. Раптове зростання може бути викликане довшими підказками, новим шляхом резерву, недо використаною потужністю GPU, зміненою політикою автоскейлінгу або рішенням продукту, яке надсилає більше роботи через функцію ШІ. Кожна причина належить різному власнику.

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

Ланцюжок вартості має бути спільним

Контроль витрат ШІ залишатиметься фрагментованим, доки кожна команда оптимізує лише той шар, який бачить. Токени, трасування, pod’и, прискорювачі та рахунки не є конкурентними вимірюваннями. Це частини одного ланцюжка вартості.

Компанії, які їх з’єднають, не отримають ідеальну цифру в перший день. Важливо, чи зможе команда простежити високий рахунок до робочого процесу, який його спричинив, з’ясувати, що змінилося, і вирішити, чи виправдав результат витрати.