Cost tracking AI: чому витрата токенів зростає непомітно
Витрата токенів майже ніколи не зростає лінійно з кількістю запитів. Навантаження те саме, а споживання зросло в рази: промпт став важчим, до контексту додалися історія діалогу, результати пошуку й описи інструментів, частина трафіку перейшла на дорожчу модель.
Лічильник звернень цього не показує — він рахує виклики, а ми платимо за токени, і ці дві криві з часом розходяться дедалі сильніше.
Окрема проблема — атрибуція витрат. Поки облік запитів до моделей іде одним загальним підсумком за ключем, неможливо сказати, який продукт, сценарій або тип операції з'їв бюджет: діалоговий асистент, фоновий розбір документів чи нічний перерахунок ембеддингів.
Без розбивки за моделями, клієнтами й типом виклику рішення ухвалюються навмання — оптимізують те, що на слух здається дорогим, а не те, що справді тягне витрати.
Ліміти на виклики при цьому виставляють на око: за середнім споживанням за попередній період, без запасу на піки й повтори.
Ретраї, зациклювання агента, разовий імпорт великого корпусу — і поріг пробито, а аномалії споживання помічають лише постфактум, коли цифри вже накопичилися за тижні.
Нижче розбираємо, як це закривається: телеметрією на кожен виклик, атрибуцією за продуктом і моделлю, порогами й оповіщеннями до того, як витрати пішли вгору.
Що дає наскрізний облік витрат запитів до моделей
Коли всі звернення до моделей ідуть через один шлюз, кожен виклик позначається продуктом, командою й сценарієм.
Частка неврахованих викликів падає до нуля: у звіті видно не сумарну витрату, а внесок конкретного сервісу, і розбіжність із даними постачальника вкладається в частки відсотка.
Атрибуція витрат за продуктами й командами
Розбивка показує, що основний обсяг тягнуть один-два сценарії з десятка, решта витрачають одиниці відсотків. Команда бачить свою ділянку й править її сама: переписує шаблон запиту, скорочує переказ історії діалогу, переводить прості задачі на компактну модель.
Після такої правки частка зайвих викликів падає у 2-4 рази — причина видна в розрізі, а не в загальному рахунку.
Ліміти й передбачуваність споживання
Поріг на запит, сценарій і добу спрацьовує раніше, ніж витрата виходить за відведену смугу. Зациклювання, повтори при обриві зв'язку й сплеск від невідфільтрованого вводу впираються в ліміт і йдуть у чергу замість того, щоб з'їсти запас за ніч. Місячний обсяг відхиляється від плану на відсотки, без аварійного розширення.
Мітки скорочують час розбору інциденту: сплеск простежується за журналом за хвилини, а не за день листування між командами. Заодно зникає клас відмов — мовчазне перевищення квоти в постачальника, дублювальні повтори й виклики з виведеного з експлуатації сервісу.
Способи обліку AI-запитів: шлюз, інструментування, логи
Облік вартості запитів — cost tracking — будують на трьох рівнях: загальний шлюз перед провайдерами, інструментування всередині застосунку, постфактум-розбір логів провайдера.
Вони відрізняються точністю атрибуції та ціною супроводу, тому на практиці частіше сходяться до гібридної схеми.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Шлюз обліку | Кілька команд і сервісів ходять до моделей через спільну точку | Бачить лише виклики, що пройшли через нього |
| Інструментування застосунку | Потрібна розбивка за продуктом, командою або сценарієм | Правки в кожному сервісі та супровід при оновленнях |
| Вивантаження логів провайдера | Потрібна звірка фактичного списання | Надходить із затримкою, без розбивки за споживачами |
| Гібридна схема | Потрібні й атрибуція, і звірка | Дві моделі даних і правила їх зведення |
Точність атрибуції
Шлюз фіксує кожен виклик, включно з повторами й потоковими відповідями, і дає повну витрату на вході та виході — але не знає, який продукт стоїть за ключем, тому атрибуцію передають у заголовках запиту.
Інструментування точно називає споживача, зате лише там, де код справді розмічено. Логи провайдера слугують зовнішньою звіркою: показують фактичне списання й розбіжності з внутрішнім обліком.
Накладні витрати на прод
Шлюз додає затримку в кожен виклик і стає критичною точкою — його збій зупиняє звернення до моделей. Інструментування не впливає на швидкість відповіді, але потребує дисципліни в командах.
Вивантаження логів не навантажує систему взагалі, зате запізнюється, і обмежити витрату в моменті за ним не можна.
Як ми впроваджуємо моніторинг витрат токенів: етапи робіт
Cost tracking AI-запитів починається не з дашборда, а з інвентаризації: хто звертається до моделей і за якими ключами. Порядок робіт нижче дає розбивку вартості за командою, продуктом і сценарієм, а не одну суму в кінці місяця.
- Аудит викликів і джерел. Збираємо реєстр сервісів, ключів і моделей; окремо позначаємо фонові задачі, повторні спроби й потокові відповіді — вони найчастіше дають невраховану витрату.
- Схема тегування. Задаємо обов'язкові мітки: команда, продукт, середовище, сценарій. Виклик без мітки не проходить валідацію шлюзу, інакше зростає частка нерозпізнаної витрати.
- Налаштування збору метрик. Шлюз перед моделлю фіксує вхідні та вихідні токени, тип моделі, тривалість і ознаку потоку; агрегати лягають у сховище з кроком за часом.
- Перевірка на потокових і повторних викликах. При потоковій видачі лічильник надходить у кінці відповіді, при повторі — дублюється: тут ловимо подвійний облік і втрати при обриві з'єднання.
- Звірка зі звітом провайдера. Порівнюємо агрегати за однакові періоди: розбіжність у межах пари відсотків — округлення, більша — розбираємо за конкретними викликами.
- Передача регламентів. Віддаємо опис міток, пороги оповіщень, порядок розбору аномалій і правила додавання нових сценаріїв.
Перевірка збіжності з даними провайдера
Звірка йде постійно, а не раз на квартал: добові агрегати порівнюємо з виставленим рахунком і розкладаємо розбіжності за конкретними викликами.
Так випливають неправильний облік кешованих відповідей, втрачені при обриві й задвоєні при повторі — після цього цифра в дашборді збігається з рахунком, і на неї можна спиратися під час планування.
Що передаємо на руки: конфігурації, політики, регламенти
Передаємо не презентацію, а робочий контур: конфігурації, політики й регламенти лежать у репозиторії замовника, версіонуються й перевіряються на тестовому стенді перед викаткою.
Кожен артефакт описує не «що налаштовано», а чому вибрано саме так — щоб контур можна було змінювати без нас.
- Конфігурація шлюзу: правила маршрутизації запитів, ліміти на проєкт і команду, підрахунок токенів на вході та виході, режим деградації при вичерпанні квоти.
- Схема тегів і атрибуції: угода про іменування (проєкт, команда, середовище, тип задачі) і прив'язка витрати до власника — без цього витрату не розкласти за споживачами.
- Дашборди витрат: зведення за токенами й кількістю запитів, динаміка за днями, топ споживачів, частка повторних викликів і влучань у кеш.
- Політики доступу й ролі: матриця прав, окремі ключі на сервіс, журнал змін лімітів.
- Регламент ескалації: кому й у який строк надходить сигнал про відхилення, хто ухвалює рішення про обмеження.
- Документація й передача знань: схеми потоків, опис полів, інструкції з правки лімітів, розбір двох навчальних інцидентів.
Політики доступу й ролі
Матриця ролей розділяє тих, хто бачить агреговані показники, і тих, хто змінює ліміти та маршрути. Ключі видаються за сервісами, а не «одним на всіх»: при компрометації відкликається один доступ, решта продовжують працювати.
Рольова модель пов'язана із системою автентифікації замовника, тому звільнення співробітника автоматично закриває йому доступ до даних про витрату.
Регламент реакції на аномалії
Поріг задається не абсолютною цифрою, а відхиленням від базової лінії за минулі періоди — так правило не спрацьовує на плановому зростанні. Сигнал надходить із зазначенням проєкту, команди й типу задачі, а рішення про обмеження фіксується в журналі з причиною. Через місяць роботи пороги переглядаються за накопиченою статистикою.
Кейс: як скоротили витрату токенів утричі без втрати якості
Замовник — платформа з кількома командами продукту, кожна з яких зверталася до моделей напряму зі своїх сервісів. Навантаження зростало помірно, а витрата токенів — швидше за нього: зведених цифр за всіма викликами не було, частина трафіку взагалі не потрапляла у звітність.
Що показали заміри до впровадження
Ми зібрали розрізнені логи за місяць і звели їх за єдиними атрибутами: модель, команда, середовище, призначення виклику, ознака повторного запиту.
Картина виявилася неприємною — 23% викликів не враховувалися ніде: фонові задачі, автоматичні повтори після помилок, тестові середовища й обхідні шляхи повз загальний шлюз.
Розкид витрати між командами при порівнянному навантаженні відрізнявся вчетверо: частина різниці пояснювалася довжиною промпту й відсутністю кешування, частина — дублювальними викликами однієї й тієї самої задачі.
Зміни звелися до трьох речей: єдиний шлюз, через який ідуть усі виклики, атрибуція кожного запиту тегами команди й призначення, і ліміт з оповіщенням при відхиленні від базової лінії за вікно спостереження.
Атрибути збираємо в єдиному форматі — OpenTelemetry — так метрики зводяться між сервісами без ручних вивантажень.
Через два місяці після впровадження: частка неврахованих викликів — 1%, розкид витрати між командами скоротився з чотириразового до 1,3, час реакції на аномалію — з доби до 15 хвилин.
Сумарна витрата токенів упала втричі, при цьому оцінки якості на еталонному наборі задач залишилися на попередньому рівні.
Чим облік у шлюзі відрізняється від інструментування коду?
Шлюз рахує токени там, де бачить трафік цілком: він перехоплює запит і відповідь і бере фактичні значення зі службового блоку відповіді — системна підказка, історія діалогу, виклики інструментів.
Точність висока, але лише для контуру, який іде через нього; плата — зайвий мережевий хоп і єдина точка відмови.
Інструментування коду влаштовано інакше: замір ставиться навколо звернення до моделі всередині застосунку. Так видно бізнес-контекст — користувач, сценарій, гілка логіки, — але рахується лише те, що розробник явно обгорнув.
Динамічно зібрані підказки, фонові задачі та звернення з допоміжних сервісів залишаються поза обліком.
Обидва підходи втрачають точність на одному й тому самому. При потоковій видачі підсумкові значення надходять з останнім фрагментом і зникають, якщо з'єднання обірвалося раніше.
Повторні виклики після помилки або перемикання на резервну модель шлюз порахує як окремі запити, а застосунок — як один; рахунок розходиться в обидва боки.
Головне джерело розбіжностей — обхід шлюзу: прямі ключі в ноутбуках, скриптах і внутрішніх сервісах не видні ні шлюзу, ні коду із заміром.
Гібрид закриває це: шлюз залишається джерелом істини за токенами, а застосунок через заголовки передає мітки сценарію й користувача, і шлюзова метрика розкладається за продуктовими зрізами.
Якщо частина викликів уже йде повз контрольований контур, починаємо з інвентаризації точок виходу й паралельного рахунку: шлюз і код рахують одні сценарії, розбіжність розбираємо за групами.
Далі переводимо трафік частинами, а залишок поза шлюзом закриваємо інструментуванням і зводимо обидва джерела в загальну звірку.
Часті питання про облік викликів моделей і ліміти
Облік викликів моделей проєктується так, щоб не потрапляти в гарячий шлях відповіді: витрата знімається шлюзом викликів асинхронно, після віддачі результату, і пишеться батчами. Тому час відповіді визначається самою моделлю, а не телеметрією.
Спірні місця інші — потокова віддача, повторні спроби й виклики, що йдуть повз загальний шлюз. Розберемо кожне.
Лічильник токенів додає затримку до відповіді?
Ні, якщо облік винесено у шлюз і він не блокує стрім. Токени рахуються за вже отриманою відповіддю — або з фінальної події потоку, або локальним токенізатором, а запис у сховище метрик іде окремою чергою.
Клієнт отримує останній чанк точно тоді ж, як і без обліку; затримка можлива лише при синхронному записі в базу на кожен запит — цього в схемі немає.
Як розділити витрату, якщо кілька продуктів ходять через спільний сервіс викликів?
Кожному споживачу видається свій ключ до шлюзу, а в метадані запиту додається мітка продукту й сервісу-виклику. Агрегація будується за трьома розрізами: ключ доступу, ендпоінт, тип операції.
Тоді спільний сервіс залишається єдиною точкою входу, але рахунок за кожним напрямом сходиться окремо, без ручного рознесення витрат.
Що відбувається при потокових відповідях?
Витрата береться з фінальної події потоку, де провайдер віддає підсумкову статистику. Якщо провайдер її не надсилає, інкрементально рахується токенізація на боці шлюзу; розбіжність із білінгом провайдера залишається в межах кількох відсотків і видна у звіті звірки.
Чи враховуються повторні виклики й таймаути?
Так. Ретрай після таймауту — це новий фактичний виклик, і він тарифікується провайдером. Шлюз пише кожну спробу окремим записом, а ідемпотентний ключ пов'язує їх в одну логічну операцію: видно і підсумкову вартість задачі, і ціну нестабільності конкретного сценарію.
Чи можна обійти облік?
Лише пішовши повз шлюз — прямим викликом моделі з коду з ключем провайдера. Це закривається на рівні доступів: ключі провайдера не потрапляють у застосунки, вихідні з'єднання обмежені, а розбіжність між кількістю операцій у застосунку та в обліку піднімає алерт.
Обговоримо задачу: повернемося з оцінкою та планом обліку
Щоб оцінка була не «на око», а по суті, нам потрібні вихідні дані про те, як зараз влаштовані звернення до моделей. Збираємо їх в одному місці — від переліку моделей до відповідальних за доступи.
Далі рахуємо вартість токенів за кожним маршрутом і заздалегідь визначаємо точки контролю, де відхилення видно до того, як стало сюрпризом у звітності.
Що підготувати до розмови:
- Постановка задачі: який результат потрібен — разовий зріз витрат, регулярний звіт за командами або правило, що зупиняє запити при перевитраті.
- Схема викликів: які сервіси звертаються до моделей, через який шлюз, де маршрути дублюються і які з них обхідні.
- Перелік моделей і джерел: список моделей, режими роботи з контекстом, хто саме надсилає запити — сервіс, оператор чи пакетна обробка.
- Схема сервісів: карта компонентів і черг, щоб прив'язати токени до конкретного продукту або команди, а не до загального лічильника.
- Поточні ліміти: квоти, обмеження за швидкістю, усе, що вже налаштовано на боці постачальника моделей.
- Відповідальні за доступи: хто видає ключі, хто підтверджує зміни в конфігурації й куди надходить повідомлення.
- Точки контролю: де звіт потрапляє до людей і хто реагує на відхилення від звичайного профілю споживання.
За цими даними ми описуємо план впровадження за етапами — з перевіркою на кожному, а не одним великим перемиканням. Опишіть задачу й надішліть те, що вже є: повернемося з оцінкою та планом обліку.
