Pay-per-inference білінг: де ламається облік викликів моделі
Рахувати виклики моделі простіше, ніж їх тарифікувати. Лічильник фіксує факт запиту, а вартість визначають вхідний контекст і довжина відповіді: один і той самий виклик за довгого входу й короткої відповіді відрізняється за споживанням у рази.
Коли ціна береться з кількості звернень, тарифікація інференсу перестає відображати навантаження — важкі сценарії списуються за ціною легких.
Облік викликів моделі ламається на повторних спробах і потоковій віддачі. Відповідь обірвалася на середині — звернення вже зараховано, клієнт повторив запит, і в журналі два записи там, де була одна операція.
Пакетна обробка й кешовані відповіді додають своє: один запит приносить кілька результатів, а тарифікується як одиниця.
Ліміти й квоти потребують резервування, а не підрахунку за фактом.
Поки споживання списується після відповіді моделі, паралельні запити одного клієнта проходять перевірку одночасно й виводять його за поріг; передплачений залишок обнуляється в мінус, а різницю доводиться списувати заднім числом або прощати.
Далі починаються спірні списання. Без журналу, де в кожного звернення є ідентифікатор, версія моделі, обсяг входу й виходу та ознака повторної спроби, розбіжності в рахунках нічим підтвердити — обидві сторони покладаються на слова. Розбираємо, як це закривається.
Вимірюваний ефект: точність списань і простої
Ефект від переробки білінгу вимірюється не відчуттями, а набором контрольних точок — ми знімаємо їх на стенді до запуску й на проді після. Нижче перелік, за яким приймаємо роботу: кожна позиція або виконана, або ні, і це видно у звітах.
- Точність списань — розрахунковий журнал звіряється з фактичними викликами моделі: розбіжність у межах часток відсотка, невраховані виклики залишаються поодинокими випадками, а не системною втратою.
- Частка спірних списань — операції, які не зіставляються з рахунком, тримаємо нижче 1% і розбираємо автоматичним правилом, без ручного перерахунку.
- Закриття періоду — замість вивантажень на кілька днів звіт закривається за години: агрегати рахуються в міру надходження подій.
- Пікове навантаження — кратне зростання потоку викликів не втрачає події: приймання й розрахунок розведені, тому сплеск розтягується, а не перетворюється на дірку в рахунку.
- Повторні виклики — ідемпотентність за ключем запиту: ретрай клієнта або обрив з'єднання не призводять до подвійного списання, дублі відсікаються на вході.
- Простій білінгу — у разі відмови вузла списання приймаються в буфер і доходять після відновлення, вікно втрати даних вимірюється хвилинами, а не годинами.
- Спостережуваність — відхилення й швидкість обробки подій бачимо в Grafana, алерт надходить раніше, ніж клієнт помітить розбіжність у рахунку.
Моделі тарифікації pay-per-inference: порівняння підходів
Будь-яка модель тарифікації спирається на один шар обліку: кожен виклик моделі пише подію — орендар, модель, обсяг спожитих токенів. Тариф — це правило, за яким події перетворюються на списання.
Тому режим вибирають не за зручністю білінгу, а за формою навантаження й за тим, скільки розбіжностей під час звірки готовий терпіти замовник.
Режими рідко живуть поодинці: підписка закриває базовий обсяг, а виклики понад ліміт ідуть в окремий тариф. Нижче — порівняння за навантаженням і звіркою: де режим поводиться передбачувано, а де починає заважати.
| Режим | Коли підходить | Обмеження за навантаженням і звіркою |
|---|---|---|
| Тарифікація за викликами | Нерівний потік, цінність виклику легко виміряти | Потребує точного журналу подій; за піків рахунок для клієнта непередбачуваний |
| Пакетні схеми | Стабільний обсяг, потрібно заздалегідь зафіксувати ліміт | Потрібна політика щодо невикористаного залишку: перенесення або згоряння |
| Підписка | Регулярне споживання, клієнту важливий рівний платіж | Жорстко обмежує обсяг; перевищення ліміту потребує окремого правила |
| Гібрид | Базовий обсяг стабільний, піки сезонні | Дві сутності обліку — звірка й звітність ускладнюються |
| Передплачений баланс | Разові проєкти, самообслуговування | У разі вичерпання балансу виклики відхиляються; потрібні поріг і повідомлення |
Спільне обмеження в усіх режимів одне: списання не точніше за журнал подій під ним. Повторна доставка, втрата відповіді, ретраї з боку клієнта — усе це або гаситься ідемпотентним ключем виклику, або перетворюється на розбіжності.
Етапи впровадження білінгового контуру
Білінг pay-per-inference ламається не на моделі, а на обліку: ретраї, скасовані стріми й частково віддані відповіді перетворюються на спірні рядки в рахунку. Тому починаємо з інвентаризації подій, а не з коду.
- Аудит обліку. Збираємо джерела подій — журнали шлюзу, метрики моделі, логи доступу — і фіксуємо, де губиться факт запиту й як ідентифікується клієнт. На виході карта обліку з переліком дір.
- Схема тарифікації. Вибираємо одиницю: токени, виклики або час інференсу; задаємо округлення, градації за моделями, ліміти й поведінку в разі їх перевищення. Схему узгоджуємо таблицею до написання коду.
- Налаштування контуру. Ставимо лічильники з ідемпотентністю за ідентифікатором запиту, агрегуємо в розрахункові періоди, прив'язуємо тариф до клієнта. Ретраї та скасування обробляємо так, щоб один виклик не потрапив у рахунок двічі.
- Тестові прогони. Ганяємо синтетику й тіньовий трафік, звіряємо суми білінгу із сирими логами. Граничні випадки: розрив стріму, скасування на середині, повторне надсилання, порожня відповідь.
- Акт звірки. Зводимо розрахунок з фактичним споживанням за період і розбираємо розбіжності за джерелами до нуля. Після підпису акта цифрам можна довіряти.
- Передача регламентів. Віддаємо опис схеми тарифікації, процедуру розбору розбіжностей, алерти на аномалії й доступи. Команда замовника закриває типові питання сама.
Схеми обліку, політики лімітів і документація
Робота над білінгом за моделлю pay-per-inference закінчується не запуском, а передачею контуру: замовник має сам змінювати ліміти, читати нарахування й пояснювати розбіжності. Тому все, що ми проєктуємо, залишається в артефактах — від схеми обліку до регламенту звірки.
- Схема обліку: що вважається викликом, де фіксуються вхід і вихід, як коректно закривається потокова відповідь у разі таймауту або обриву.
- Конфігурація тарифів: прив'язка моделі до ціни за одиницю, версійність тарифів, довідники моделей, правила округлення.
- Політики лімітів: пороги на ключ, команду й проєкт, поведінка в разі вичерпання — м'яка відмова або деградація, винятки для внутрішніх задач.
- Регламент звірки: як сходяться лічильники провайдера й наші, де зберігається журнал розбіжностей, хто і в який строк закриває інцидент.
- Панелі моніторингу й оповіщення: витрати за проєктами, частка відмов, відхилення фактичного споживання від очікуваного.
- Інструкції для підтримки: як знайти нарахування за ключем, перевипустити ключ, що робити за аномального зростання витрат.
- Матриця ролей і доступів: хто змінює ліміти, хто бачить фінанси, хто працює тільки з логами.
- Передача контуру: репозиторій, схеми даних, міграції, середовища й порядок викату змін.
Окремо передаємо журнал рішень — чому вибрано таку гранулярність обліку, які компроміси прийняли щодо ідемпотентності та потокових відповідей. Нова команда не відкриває ці суперечки заново, а правки в білінг вносить за документованими правилами.
Кейс: як прибрали розбіжності в списаннях
Що було
Платформа надавала доступ до кількох моделей: генерація тексту, розпізнавання, векторні представлення. Облік ішов за подіями від сервісів-виконавців, і під час повтору запиту після таймауту одне звернення потрапляло в рахунок двічі.
Розбіжності в списаннях сягали до 4% звернень, частка спірних рахунків — близько 5%, а звірку підтримка робила руками: два-три дні в кінці кожного розрахункового періоду.
Що змінили
Подія почала формуватися в одній точці — на шлюзі перед викликом моделі — і йшла в потік на Kafka. У кожного виклику з'явився ключ ідемпотентності, а обліковий сервіс пише журнал тільки на дозапис: повтор із тим самим ключем відкидається, а не підсумовується.
Тариф і обсяг токенів фіксуються в тій самій події, тому сума в рахунку відновлюється з первинних даних.
Що стало
Розбіжності в списаннях упали нижче 0,1% звернень, частка спірних рахунків — до 0,4%. Автозвірка йде щодня, займає 10-15 хвилин і піднімає алерт у разі відхилення вище порога: помилка видна наступного дня, а не під час закриття періоду.
Клас відмов «подвійне списання під час повтору» закрито схемою даних — обробник не може застосувати одну операцію двічі.
Перед зміною схеми розрахунок місяць ішов у тіньовому режимі: старий і новий рахувалися паралельно, розбіжності розбирали порядково. З підтримки зникла більша частина звернень про рахунок — типове питання розбирається за журналом виклику за пару хвилин.
Що робити, якщо білінг уже працює на самописному обліку?
Самописний облік майже не переписують з нуля — його добудовують до керованого контуру.
Зазвичай він уже збирає потік подій і агрегати, але в ньому немає стійкості до повторних запитів, чітких меж звітного періоду й можливості перерахувати закритий місяць — звідси й накопичені розбіжності. Перший крок — зафіксувати поточну логіку як еталон і зняти з неї поведінку на історичних даних.
Ключ — тримати журнал використання окремо від агрегатів: сирі події з ключем, моделлю, витратою на вході й виході, ознакою потрапляння в кеш і ознакою повтору дозволяють перерахувати будь-яку суму заново й пояснити її.
Тоді звірка розбіжностей іде не «за підсумком місяця», а за кожною позицією, і в кожної знаходиться причина: подвійний облік під час повтору, зсув межі періоду за часовим поясом, втрачена витрата за потокової відповіді, округлення на агрегації. Для білінгу pay-per-inference це і є джерело істини.
Міграція даних поділяється на довідкову й подієву. Довідкова — зіставлення клієнтів, акаунтів і ключів з історичними балансами та лімітами; подієва — перенесення сирих подій за період звірки, щоб новий контур відтворив ті самі цифри. Поки суми не збіглися, нарахування йдуть за старими правилами.
Поетапне впровадження будується так: спочатку тіньовий режим, де новий контур рахує паралельно й нічого не списує; потім списання переводиться на частину акаунтів, решта продовжують іти через старий облік.
На кожному кроці — звіт звірки й поріг розбіжності, за якого крок відкочується. Повний перехід можливий тільки після того, як розбіжності на живому потоці зведені до пояснюваних.
Так облік перестає бути чорним ящиком: будь-яку суму можна розкласти до події, а розбіжність — показати клієнту до того, як він її помітить.
Технічні сумніви: повторні виклики, ліміти, звірка
П'ять питань найчастіше звучать, коли вибирають підрядника з обліку споживання моделей. Усі вони про одне: як поводиться pay-per-inference, коли запити йдуть пачками, падають за таймаутом і розходяться з тим, що клієнт бачить у звіті.
Що відбувається за повторних викликів і ретраїв?
Запит із тим самим ідентифікатором операції потрапляє в дедуплікацію: у нарахування йде перший успішний виклик, решта позначаються як дублі. Якщо результат до клієнта не дійшов, подія списання не створюється взагалі — фіксується доставка відповіді, а не факт надсилання.
Як задаються ліміти й квоти?
Обмеження ставляться на рівні ключа, клієнта й моделі — окремо за кількістю викликів і за обсягом обробленого тексту за вікно часу. У разі вичерпання працює або м'який режим із чергою й зрозумілою відповіддю, або жорстка відмова; правило змінюється без перезапуску сервісу.
Як влаштовані повернення списань?
Помилкове нарахування відкочується компенсувальною операцією, а не видаленням запису, — залишається слід: хто, коли й з якої причини повернув. Масове повернення йде пакетом за вибіркою за період, з журналом за кожною позицією.
Як проходить звірка сум і що робити з розбіжностями?
Агрегати за клієнтом і моделлю сходяться з первинними подіями регулярно, розбіжності автоматично потрапляють у звіт для розбору. Підсумок у звіті завжди збирається з подій, а не із заздалегідь порахованого підсумку, тому будь-який рядок можна розгорнути до конкретного виклику.
Чи не ляже облік на навантаження основного контуру?
Події пишуться асинхронно, поза критичним шляхом відповіді моделі, — зростання кількості викликів не додає затримки генерації. Буфер переживає рестарт сервісу: під час оновлення жодна подія не губиться.
Обговоримо задачу: схема обліку й тарифікації
Щоб обговорення задачі йшло за фактами, а не за загальними міркуваннями, потрібен доступ до поточної схеми обліку: як фіксується звернення до моделі, у який момент з'являється подія тарифікації й як вона доходить до рахунку.
Розбір поточної схеми зазвичай виявляє головне швидше, ніж подальша звірка розбіжностей — подвійний облік повторних запитів, втрачені події за таймауту, розбіжність одиниць вимірювання.
Для предметного розбору достатньо надіслати:
- Схему потоку запиту: від вхідної точки до відповіді моделі, з позначкою, де саме фіксується факт обробки.
- Вивантаження журналів за період: ідентифікатор запиту, модель, тривалість, статус, ознака повторної спроби — за ними видно, де журнал розходиться з рахунками.
- Поточну логіку тарифікації: одиниця обліку (звернення, токени, час роботи), правила округлення, обробка відмов, таймаутів і частково виконаних запитів.
- Опис інтеграцій білінгу: як формуються ліміти й передоплата, куди йдуть події, хто і як робить звірку.
- Вимоги до звітності: розрізи за клієнтами, моделями й періодами, які мають сходитися без ручних правок.
- Обмеження контуру: пікові значення навантаження, вимоги до затримки обліку, політика зберігання й знеособлення даних.
Після цього повернемося з планом впровадження, оцінкою обсягу робіт і розбивкою за етапами — від схеми обліку та ідемпотентної обробки подій pay-per-inference до звірки й звітності.
Якщо даних поки мало, сформулюємо мінімальний набір перевірок на обмеженому контурі: опишіть задачу, і ми запропонуємо, з чого почати.
