Моніторинг витрат на LLM: як не спалити бюджет на AI

Рахунок за AI рідко вибухає з однієї причини. Зазвичай він зростає тихо: трохи довші контексти, кілька відсотків retry, ембедінги при кожному запиті, системний промпт, що додається до кожного виклику. Через квартал компанія платить удвічі більше і не може вказати, що саме поглинає бюджет. FinOps для LLM починається з одного припущення: неможливо оптимізувати те, що не вимірюється в розрізі.

Глобальний рахунок з хмари каже лише, що дорого — не каже, що насправді коштує. Розумний моніторинг розбиває витрати на три осі. Per token показує співвідношення вхідних і вихідних токенів та виявляє роздутий контекст. Per функція прив'язує вартість до конкретного завдання: класифікація, резюме, відповідь RAG, генерація звіту. Per користувач (або per клієнт, per команда) виявляє, що 5% акаунтів генерують 40% рахунку.

Лише ці три види разом дають рішення. Якщо одна функція з'їдає половину бюджету, оптимізуєш саме її, а не всю систему рівномірно. Це та сама логіка, яку застосовуємо при моніторингу якості агента AI — без атрибуції per завдання вимірювання — це прикраса, а не інструмент.

Більшість спаленого бюджету походить не з "занадто великої моделі", а з місць, на які ніхто не дивиться. Ось найпоширеніші.

Найпідступніші — довгі контексти та системні промпти, бо вони невидимі — виглядають як "звичайний" виклик, а тихо множать вхідні токени на кожен запит. Коротший системний промпт і контекст, обрізаний до необхідного, часто дає більшу економію, ніж зміна моделі.

Два важелі дають найшвидший результат. Перший — семантичний кеш: запитання зі схожим змістом обробляєш з буфера замість відправки до моделі. У сценаріях FAQ та обслуговування клієнтів повторюваність висока, тому показник влучень буває значним — замість повної інференції відповідаєш з буфера. Принцип простий: заплати один раз, відповідай багаторазово.

Другий — роутинг до дешевшої, достатньої моделі. Не кожне завдання потребує найбільшої моделі. Класифікація звернення, витяг поля з форми чи коротке резюме справляються на малій, дешевій моделі; потужну залишаєш для завдань, які її справді потребують. Це роль роутера LLM — одне рішення, яке часто знижує змінну вартість на 40-70% при непомітній зміні якості. Як обирати модель для завдання, розбираємо на фактори в окремому посібнику.

Оптимізація без обмежень — це половина справи. Друга половина — бюджети та алерти, які зупиняють рахунок, перш ніж він стане дорогим. На практиці впроваджуємо кілька простих механізмів:

• Денний та місячний бюджет per функція та per клієнт, з м'яким порогом (алерт) і жорстким (деградація до дешевшої моделі або тротлінг).
• Алерт на аномалію — раптовий стрибок вартості per користувач зазвичай означає петлю retry, зловживання або витік контексту.
• Тегування кожного виклику ідентифікатором функції та тенантом, щоб атрибуція була автоматичною, а не ручною.
• Kill-switch на рівні спостережливості, який відсікає дорогу функцію без зупинки всієї системи.

Ці механізми не замінюють оптимізацію — вони стежать, щоб одна помилка в коді чи нетиповий трафік не перетворили хороший місяць на спалений бюджет. Одиничну вартість рахуємо так само, як при оцінці агента AI: за одне виконане завдання, а не за абстрактний "місяць AI".

Питання "власний хостинг чи API з хмари" — це питання про обсяг, а не про ідеологію. При малому та нерегулярному трафіку хмара виграє — платиш за споживання, немає вхідних витрат, нуль обслуговування. При постійному, великому навантаженні self-hosting починає вигравати: амортизація обладнання та власна інференція дають нижчу і — що важливіше — передбачувану одиничну вартість.

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

З атрибуції: тегування кожного виклику функцією, тенантом та кількістю вхідних і вихідних токенів. Без цього бачиш лише глобальний рахунок і не знаєш, що оптимізувати. Лише коли є вартість per функція та per користувач, вибір важеля (кеш, роутинг, коротший контекст) стає очевидним.

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

З нашого досвіду роутинг до дешевшої, достатньої моделі знижує змінну вартість зазвичай на 40-70%, а семантичний кеш у сценаріях з повторюваними запитаннями здатен перехоплювати від кількох до понад 50% викликів. Сукупний ефект залежить від профілю трафіку, тому сприймай ці межі як орієнтир, а не обіцянку.

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

При постійному, великому обсязі та там, де важливі передбачуваність вартості та резидентність даних. При малому або нерегулярному трафіку хмара зазвичай виграє відсутністю вхідних витрат. Межу визначає твій обсяг — порахуй одиничну вартість в обох варіантах, перш ніж вирішувати.