Підрахунок токенів: де витрати на запити виходять з-під контролю
Будь-який запит до мовної моделі оплачується не за сенс відповіді, а за обсяг контексту: підрахунок токенів іде за вхідною інструкцією, історією діалогу та згенерованою відповіддю.
Поки сценарій один, а листування коротке, витрати на запити передбачувані й вкладаються в очікування. Як тільки з'являється довгий контекст діалогу, прикріплені документи й ланцюжки викликів, лічильник на стороні сервісу перестає збігатися з тим, що планувала команда.
Перша механіка витоку — накопичення історії. Кожен наступний хід у діалозі надсилає заново все попереднє листування разом із системною інструкцією, тому десята репліка коштує в рази дорожче за першу, хоча користувач написав один рядок. Без підрахунку токенів на кожному кроці це стає помітним лише за підсумками періоду.
Друга — повторні виклики моделі. Повтори через тайм-аут, розгалужені паралельні звернення, повторний запит на кожну дію в інтерфейсі: той самий фрагмент контексту оплачується кілька разів. Сюди ж незмінні системні блоки, які передаються на кожному кроці й не кешуються.
Третя — відсутність обліку за користувачами та сценаріями. Коли витрати на запити лежать однією загальною сумою, не можна відповісти, яка функція чи який акаунт забирає основну частку. Розбивка за сценаріями, клієнтами й типом операції перетворює облік на керовану величину.
Розбираємо, як це закривається: де ставити лічильники, як урізати контекст без втрати якості й як виставляти ліміти до того, як витрати підуть угору.
Що дає підрахунок токенів: контроль, ліміти, звітність
Кожне звернення до мовної моделі рахується в токенах: вхідні — промпт разом з історією діалогу, вихідні — відповідь. У OpenAI та інших постачальників моделей тарифікація побудована саме на цьому, тому витрати без обліку — похідна від того, хто і як часто запитував.
Ми знімаємо лічильник на кожному виклику й прив'язуємо його до користувача, сервісу та сесії — далі це не сирий лог, а метрика.
Облік витрат у розбивці за користувачами показує, де йде основний обсяг: окремий відділ дає важкі довгі промпти, а часті короткі запити довідника — майже нічого. Окремо видно частку влучень у кеш: повторюваний контекст не оплачується двічі, і це найшвидший важіль зниження витрат.
Аномалії — запит з історією в десятки тисяч токенів, циклічні повтори, забутий налагоджувальний скрипт — виявляються в перші дні, а не наприкінці періоду.
Ліміти на запити ставляться окремо за кількістю викликів і за обсягом токенів за хвилину — на користувача, команду та сервіс. М'який поріг переводить звернення в чергу або скорочує відповідь, жорсткий повертає відмову; вибір залежить від сценарію.
Пікові навантаження згладжують чергою, пакетною обробкою та кешем — витрати перестають зростати ступенями.
Звітність — це добовий зріз за сервісами та користувачами: обсяг токенів, динаміка, джерело сплеску. За ним видно, що змінювати: формулювання промпту, довжину переданого контексту чи саму модель.
Режими обліку: проксі-шар, обгортка викликів, журнали провайдера
Рахувати витрати можна в трьох точках: на мережевому посереднику, усередині коду застосунку або за журналами самого постачальника моделі.
Точки різняться тим, що кожна з них бачить: посередник — лише тіло запиту та відповіді, обгортка — ще й контекст виклику, а журнали містять уже пораховані значення.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Проксі-шар | Потрібен єдиний контроль над усіма сервісами одразу, включно з чужими застосунками, без правок коду | Термінує з'єднання й потребує довіри до вузла; не знає логічних меж операції — одне завдання дробиться на кілька викликів |
| Обгортка викликів | Облік потрібен за операціями та користувачами, з лімітами й оцінкою витрат до надсилання | Працює лише там, де її підключили; прямі звернення в обхід обгортки випадають з обліку |
| Журнали провайдера | Звірка й контроль: цифри надходять від постачальника, розбіжностей зі списанням немає | Затримка від хвилин до годин; немає розбивки за внутрішніми операціями; частина викликів може бути не розмічена |
Кешування відповідей додає розвилку. Влучення в кеш токенів не витрачає, але чи списувати його з ліміту користувача — питання політики: при списанні за фактом звернення кеш непомітно з'їдає бюджет, при повній відмові від списання з'являється стимул дробити однакові запити.
Практичніше поєднувати режими: обгортка дає оперативний ліміт і оцінку до надсилання, проксі закриває сервіси без правок коду, журнали слугують джерелом істини для звірки. Розбіжність між ними — сигнал, що частина трафіку йде повз облік.
Впровадження обліку витрат: від аудиту викликів до регламенту
Порядок робіт однаковий і для нового сервісу, і для вже працюючого: спочатку вимірюємо, потім обмежуємо. Починаємо з аудиту викликів — він показує, де витрати формуються насправді, а не там, де їх очікують. Далі схема обліку, ліміти, перевірка під навантаженням і передача разом із регламентом.
- Аудит викликів. Інвентаризація потоків: хто ініціює запит, скільки контексту йде в модель, які звернення дублюються, де повна відповідь генерується заради одного рядка. Результат — карта з часткою кожного сценарію в загальному обсязі.
- Схема обліку. Обираємо точку заміру: застосунок до надсилання або проксі-шар. Фіксуємо, що відносимо до запиту — контекст, історію діалогу, відповідь моделі, звернення до інструментів.
- Підрахунок токенів. Один токенізатор під цільову модель, інакше звіт розходиться з рахунком постачальника. Вхідні та вихідні рахуємо окремо, з розрізом за сценаріями.
- Налаштування лімітів. Три рівні: добовий на сценарій, на сесію користувача й аварійний стоп на весь сервіс. При вичерпанні — передбачувана деградація замість тихого перевищення.
- Перевірка під навантаженням. Профіль реальних звернень: як лічильники поводяться при паралельних запитах і обривах з'єднання, чи потрапляють потокові відповіді в облік. Розбіжність з даними постачальника в одиниці відсотків — норма, більше означає помилку в точці заміру.
- Регламент і передача. Віддаємо панель моніторингу, правила перегляду лімітів, порядок розбору розбіжностей і власника кожного сценарію. Далі правки промптів ідуть тим самим контуром: зміна → замір → ліміт.
Комплект передачі: схеми обліку, політики лімітів, регламенти
Впровадження закінчується не працюючим лічильником, а моментом, коли команда замовника сама змінює ліміти, розбирає перевищення й підключає новий сервіс без нас.
Тому передаємо не звіт про виконану роботу, а робочий комплект: конфігурації, схеми та регламенти, які лежать у тому самому сховищі коду й оновлюються разом із сервісом.
- Схема потоків даних: у якій точці рахується витрата в токенах, куди стікаються агрегати, як вони потрапляють у звітність, де точки відмови й хто відповідає за кожну ділянку.
- Політики лімітів: пороги на підрозділ, сервіс і окремого користувача плюс поведінка при вичерпанні — попередження, відмова або перехід на ощадливішу модель.
- Регламент ескалації: при якому відхиленні від звичайного профілю витрат піднімається тривога, хто і в який строк реагує, хто має право тимчасово підняти поріг.
- Передавальна документація: порядок розгортання, оновлення довідника ставок, підключення нової моделі та перевірка, що облік не розійшовся зі споживанням.
- Звіряльні сценарії: набір запитів із наперед відомою витратою, який проганяється після кожної зміни й ловить розбіжність до того, як вона дійде до звітності.
- Звітність і вивантаження: витрати за командами та сценаріями, частка повторних запитів, закритих без звернення до моделі, динаміка за довільний період.
Комплект залишається робочим без нас: правки політик проходять звичайне рев'ю, а новий інженер входить у контур за документацією, а не за розповідями колег.
Кейс: витрати на мовні моделі перестали зростати при зростанні навантаження
Що було
Асистент першого рівня вів діалоги в чаті та поштою: історія листування, витяги з бази знань і системні інструкції йшли в модель одним блоком. Звернення зросли втричі за сезон, і витрати на модель повторили цей графік майже лінійно.
Сплески додавали своє: при вичерпанні ліміту провайдера запит падав з помилкою й ішов на повтор, а повтор тарифікувався як новий.
Що змінили
Облік токенів винесли на шлюз перед моделлю — вхід і вихід рахували окремо, з розбивкою за сценарієм, користувачем і класом моделі; метрики знімали через Langfuse.
За ними стало видно, що 60% обсягу з'їдають три сценарії з дванадцяти, а більше половини переданої історії діалогу модель не використовує.
Далі — ліміти замість відмов: усічення історії до останніх повідомлень зі збереженням короткого резюме, маршрутизація коротких запитів на модель молодшого класу, кеш повторюваних промптів у межах вікна діалогу.
На кожен сценарій поставили поріг: попередження на 80% і плавна деградація замість помилки при вичерпанні.
Що стало
| Метрика | До | Після |
|---|---|---|
| Звернень на місяць | базовий рівень | утричі більше |
| Токенів на запит | повний контекст | утричі менше |
| Частка повторів після помилки | 18% | 4% |
| Відмови через ліміт провайдера | регулярні сплески | нульові |
Витрати перестали слідувати за навантаженням: звернень утричі більше, обсяг токенів виріс лише на п'яту частину й на цьому рівні тримається.
З'явився й другий ефект — за розбивкою видно заздалегідь, у скільки разів новий сценарій збільшить навантаження, ще до викочування в продакшен.
Що робити, якщо ліміти вже перевищені, а витрати продовжують зростати?
Перевищення лімітів майже ніколи не пов'язане зі зростанням тарифів — зростає споживання токенів в одному конкретному контурі: роздутий контекст, цикл в агенті, повтори після збоїв або фонова задача без стелі.
Тому порядок дій зворотний інтуїції: спочатку зупинити зростання, потім шукати причину. Діагностика на живому трафіку, який продовжує витрачати квоту, нічого не покаже.
Перший крок — зрізати низькопріоритетний трафік: пакетну обробку, переіндексацію, фонові збагачення. Це знімає помітну частку витрат за хвилини й не зачіпає користувацькі сценарії. Далі витрати розкладаються по осях: ключ доступу, модель, метод, орендар, година доби.
Журнали запитів провайдера — OpenAI та аналоги віддають таку розбивку — зіставляємо з базовою лінією минулого тижня й знаходимо точку, де графік пішов угору.
Аварійні пороги ставляться заздалегідь: 70–80% денної квоти — повідомлення відповідальному, 100% — автоматичне перемикання низькопріоритетних сценаріїв на ощадливішу модель або відмова в обслуговуванні.
Після стабілізації пороги переглядаються за фактичним профілем навантаження, інакше захист почне спрацьовувати на нормальному піку.
Часті технічні сумніви щодо обліку витрат і лімітів
Сумніви щодо обліку зазвичай стосуються не самої формули, а поведінки лічильника в реальному трафіку: чи сходиться він із виставленим рахунком, що відбувається на потоковій відповіді, скільки коштує сам контроль. Розбираємо питання, з якими інженерні команди приходять найчастіше.
Наскільки точний підрахунок токенів і де він розходиться з провайдером?
Рахуємо тим самим токенізатором, що й цільова модель, тому розбіжність виникає лише на службових обгортках і системних повідомленнях. У звіті зберігаємо обидва значення — своє та підтверджене відповіддю провайдера — і показуємо різницю окремою колонкою.
Якщо розбіжність виходить за заданий поріг, це сигнал, що модель оновили й розмітку потрібно переперевірити.
Як рахуються токени при потоковій видачі, коли відповідь надходить фрагментами?
Лічильник інкрементально накопичує фрагменти в міру надходження й фіксує підсумок у момент завершення потоку — проміжні значення не пишемо в історію, інакше отримаємо десятки хибних записів на один виклик.
Для обірваних з'єднань зберігаємо оцінку за промптом і вже наявним текстом з окремою ознакою, щоб такі записи не змішувалися з повними.
Наскільки підрахунок сповільнює відповідь — чи зростає затримка?
Контрольний шар стоїть на шляху запиту й додає до загального часу відповіді одиниці відсотків, а не фіксовану величину. При потоковій видачі перший фрагмент іде клієнту до того, як пораховано всю відповідь, тому користувач різниці не помічає.
Якщо шар стає вузьким місцем, його виносимо з основного шляху й рахуємо асинхронно, після завершення виклику.
Що саме зберігається в історії викликів і як вона не розростається?
Пишемо компактні записи: ідентифікатор запиту, модель, лічильники, ознака потоку, мітка часу й результат перевірки ліміту.
Тексти промптів і відповідей зберігаємо опційно, з налаштовуваним строком зберігання й очищенням за розкладом — тоді історія залишається придатною для розбору інцидентів, але обсяг не зростає нескінченно.
Обговоримо задачу: як поставити облік витрат під контроль
Щоб оцінка впровадження була не «на око», а за фактом, потрібні вихідні дані про те, як зараз витрачаються запити до моделей. Нижче — короткий перелік: якщо частина пунктів відсутня, це теж відповідь, вона показує обсяг підготовчої роботи в плані робіт.
- перелік сервісів і сценаріїв, які звертаються до моделей, із приблизною частотою викликів;
- знеособлені зразки запитів і відповідей — за ними видно, де контекст розростається без користі для результату;
- поточні правила лімітів і те, як зараз обробляються перевищення;
- вивантаження журналів звернень за типовий період: спокійний тиждень і пік навантаження;
- схема маршрутизації: які моделі та в яких режимах задіяні, де є запас для перемикання;
- вимоги до звітності — у якому розрізі витрати потрібно бачити: за продуктом, командою чи клієнтом;
- обмеження за інфраструктурою й доступами, якщо облік потрібно вбудувати в наявний контур.
З цим набором ми повертаємося з оцінкою впровадження та планом робіт: послідовність кроків, точки контролю, що і коли з'явиться у звітах. Опишіть задачу в зручному вигляді — обговоримо, що у вашому випадку дасть ефект одразу, а що можна не робити.
