Чому витрати на агентський ШІ стрімко зростають: модель витрат, орієнтована на архітектуру

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

«Яка ставка за мільйон токенів для цієї моделі?»

Це слушне запитання, але для систем Агентного ШІ промислового рівня воно ігнорує справжню проблему.

Одна заявка від користувача не означає один виклик мовної моделі.

Процес роботи агента зазвичай виглядає так:

User Request
     ↓
Router
     ↓
Planner
     ↓
Retrieval
     ↓
Tool Call
     ↓
Tool Result Interpretation
     ↓
Validator
     ↓
Final Response

Одна надійшла заявка може спричинити п’ять, шість, десять або навіть більше викликів моделей та інструментів перед тим, як вона буде оброблена.

Через це показник, який варто відстежувати, — це не просто:

Витрати за один виклик моделі

Це:

Витрати за завершену задачу.

Що насправді впливає на вартість агента

Загальні витрати на роботу агентного потоку значно перевищують просто кількість спожитих токенів:

Agent Cost
=
LLM inference
+ Embeddings
+ Reranking
+ Vector/Search infrastructure
+ Tool/API calls
+ Compute
+ Storage
+ Observability
+ Evaluations

Навіть у контексті процесу „інференсу LLM“ ви маєте справу з токенами вхідних даних, токенами результатів, кешованими токенами, а також, можливо, з кількома різними моделями, які працюють на різних етапах обробки.

Ця реальність змінює підхід до прийняття рішень щодо архітектури.

1. Надсилайте кожен запит до моделі правильного розміру

Не кожне завдання вимагає використання найпотужнішої моделі, до якої у вас є доступ.

Request
   ↓
Router
   ├── Simple extraction → Small model
   ├── Moderate reasoning → Mid-tier model
   └── Complex reasoning → Strong model

Ще одним корисним підходом є поступове поглиблення обробки.

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

Мета не в тому, щоб завжди обирати найдешевший варіант.

Мета — знайти найдешевшу архітектуру, яка все одно відповідає вашим вимогам щодо якості та надійності.

2. Припиніть витрачати ресурси на виклики моделей для детерміністичної логіки

Цей момент здається очевидним, але він має величезне значення під час роботи у масштабах.

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

Такі речі, як перевірка дозволів, арифметика, верифікація схеми, фільтрація, детерміністичні рішення щодо маршрутизації та більшість бізнес-правил, зазвичай не потребують використання LLM.

Корисне правило:

Ніколи не делегуйте LLM те, що детерміністичний програмний код вже може виконати краще.

Зберігайте ймовірнісне міркування для тих кроків у робочому процесі, де воно справді окупає свою вартість.

3. Розглядайте контекст як бюджет витрат

Агенти з довгим терміном існування постійно накопичують контекст під час своєї роботи.

Якщо не контролювати це, кожен додатковий крок може знову надіслати до моделі всю історію розмов, попередні результати роботи інструментів, отримані документи та попередні сліди міркувань.

Замість того, щоб дозволяти контексту рости без меж, треба підтримувати його обсяг у більш контрольованих межах:

Recent Context
      +
Compact Summary
      +
Relevant Memory
      +
Task-Specific Retrieved Context

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

Вони також виконують функцію контролю витрат.

4. Налаштування RAG Top-K — це інструмент керування витратами

Припустимо, ви отримуєте 20 фрагментів, кожен з яких має приблизно 700 токенів.

Це дає загалом близько 14 000 токенів отриманого матеріалу.

Проте, можливо, лише чотири з цих фрагментів справді мають значення для відповіді.

Краще спроектований механізм пошуку виглядає приблизно так:

Query
  ↓
Retrieve broader candidate set
  ↓
Rerank
  ↓
Select best 4–6 chunks
  ↓
LLM

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

Тому якість отримання даних та витрати на обробку є взаємопов’язаними архітектурними рішеннями, а не окремими проблемами.

5. Кешування на кількох рівнях

Кешування — це не єдина техніка; існує кілька видів, які можна поєднувати між собою.

Наприклад:

Exact Cache
Semantic Cache
Prompt/Context Cache
Tool Result Cache
Retrieval Cache

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

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

6. Встановлення суворих обмежень для автономних агентів

Агенти створюють власну небезпеку: вихідні з циклів.

LLM
 ↓
Tool
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
...

Одна помилка в оркестрації може одночасно призвести до проблем з надійністю та значного зростання витрат.

Через це агенти у продакшені потребують чітких механізмів контролю, які охоплюють такі аспекти:

Maximum agent steps
Maximum tool calls
Maximum tokens
Maximum wall-clock time
Maximum cost per run

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

7. Включіть витрати до вашої системи моніторингу

Кожен запис, створений у продакшені, має дозволяти відповідати на такі запитання:

Which application?
Which workflow?
Which agent?
Which model/provider?
How many input tokens?
How many output tokens?
How many tool calls?
How long did it take?
How much did it cost?
Did the task actually succeed?

На основі цього панелі керування можуть відображати такі метрики:

Cost / request
Cost / successful task
Cost / workflow
Cost / model
Cost / application
Cost / team
Cost / customer

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

Вартість та якість мають бути налаштовані разом

Найдешевший спосіб виконання завдання не є автоматично найкращим.

Якщо дешева модель часто зазнає невдач та вимагає повторних спроб, альтернативних шляхів чи ручного втручання, її справжня вартість може перевищити вартість більш потужної моделі, яка виконує завдання правильно з першої спроби.

Тож показник, який варто оптимізувати, ближчий до наступного:

Successful Tasks
Value = --------------------
        Cost + Latency + Risk

Це не є буквальним універсальним рівнянням — це інженерний підхід.

Для продакшн-систем з агентним ШІ необхідна така зміна мислення:

Припиніть оптимізувати токени окремо. Почніть оптимізувати економічну ефективність успішного виконання завдання.

Адже як тільки агенти зможуть міркувати, отримувати інформацію, викликати інструменти, повторювати спроби, перевіряти результати та виконувати цикли:

1 запит користувача більше не дорівнює 1 виклику моделі.

Саме тут витрати перестають бути просто деталлю ціноутворення та перетворюються на завдання проектування системи.