Вартість токенів LLM: як її вимірювати та оптимізувати

Фірма запускає пілот з асистентом AI. Перші тести працюють чудово. Через місяць у продакшені бюджет на API перевищено на 280%. Причина не технічна, а проектне рішення на етапі пілоту: система надсилала до моделі повні PDF-файли замість фрагментів, видобутих за допомогою RAG, а кожен запит містив системну інструкцію довжиною 2400 токенів, яка копіювалася до кожного виклику.

Вартість токенів LLM не є лінійною щодо кількості запитів. Вона лінійна щодо кількості токенів. Різниця між цими двома реченнями — це різниця між бюджетом, який можна утримати, і бюджетом, який змушує вимкнути систему.

Token — це основна одиниця розрахунку для мовних моделей. Один токен — це зазвичай 3-4 символи в англійській мові, 2-3 символи в польській (польські діакритики, довші слова розпадаються на більше токенів). Для тексту українською припускай на 30-40% більше токенів, ніж для англійського еквівалента.

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

Ключове спостереження: преміум-моделі коштують у 10-30 разів дорожче, ніж моделі середнього класу. Але якщо модель середнього класу потребує вдвічі довшого промпту, щоб досягти того ж результату, реальна різниця буде іншою. Перед вибором моделі виміряй обидва параметри: ціну за токен і необхідну довжину контексту для отримання прийнятної якості.

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

У проєктах у продакшені, які ми аналізували, 70-80% витрат на токени походять із трьох джерел, про які рідко говорять під час пілоту.

Системний промпт, який копіюється до кожного запиту. Системна інструкція, що описує поведінку асистента, зазвичай містить 500-3000 токенів. При 10 000 запитів на день і промпті в 1500 токенів це дає 15 млн токенів на місяць лише на системний контекст, перш ніж модель прочитає хоча б одне запитання користувача. Більшість провайдерів API не кешує системні промпти між викликами автоматично, якщо не використовувати prompt caching.

Передача повних документів замість фрагментів. Агентові, якому передаєш рахунок PDF як повний текст (2000-8000 токенів), замість видобутих за допомогою RAG 3-5 фрагментів (150-400 токенів), може знадобитися в 10-30 разів більше токенів на операцію. Різниця драматична при великому обсязі документів.

Історія діалогу без обрізання. Чатові інтерфейси, які передають до моделі всю історію розмови, зростають лінійно з довжиною сесії. Розмова, що триває 20 обмінів, може мати 15 000 токенів контексту при останньому запиті, тоді як користувач питає про щось просте. Sliding window (останні N повідомлень) або підсумок старої історії зменшує ці витрати на 60-80%.

Більшість великих провайдерів API пропонують prompt caching, який зменшує вартість багаторазово використаного префіксу промпту (системний промпт, довідкові документи, інструкції) на 70-90%. Механізм полягає в тому, що провайдер хешує префікс і зберігає обчислення внутрішнього стану моделі. Друге та наступні виклики з тим самим префіксом сплачують частку ціни.

Умови, які мають бути виконані, щоб caching працював:

• Префікс має бути ідентичним байтово. Одна зміна символу анулює кеш.
• Префікс має перевищувати мінімальну довжину (зазвичай 1024-2048 токенів залежно від провайдера).
• Виклики мають відбуватися в часовому вікні (зазвичай кілька хвилин до години).

На практиці це означає: системний промпт та інструкції мають бути на початку контексту, перед динамічною частиною (запитання користувача, результати RAG). Динамічні елементи мають бути в кінці, щоб не анулювати префікс.

Для системи з 2000-токеновим системним промптом і 10 000 викликами на день prompt caching зменшує вартість вхідних токенів на 50-65% без жодних змін у логіці застосунку.

RAG часто описують як техніку покращення якості відповідей. Це правда, але в контексті вартості токенів RAG — це насамперед стратегія селекції контексту.

Різниця між системою з RAG і без нього:

• Без RAG: усі корпоративні документи (10-50 сторінок, 8000-40 000 токенів) потрапляють до кожного запиту.
• З RAG: семантичний пошук витягує 3-5 найбільш релевантних фрагментів (300-800 токенів), і лише вони потрапляють до моделі.

Хороший reranking після етапу пошуку додатково зменшує кількість фрагментів, що передаються до моделі, при збереженні високої релевантності. Патерн retrieve-rerank-trim (отримати 20 фрагментів, переранжувати, надіслати топ 3-5) дозволяє зменшити токени контексту на 70-80% порівняно з наївним retrieve-все.

Стаття корпоративний GPT на базі знань детально описує архітектуру RAG. Для пайплайнів з великим обсягом документів варто прочитати як підготувати корпоративні дані під AI, де обговорюються стратегії chunking, що безпосередньо впливають на кількість токенів на запит.

LLM router — це шар, який класифікує запит і спрямовує його до найдешевшої моделі, достатньої для завдання. У продакшен-системі обслуговування клієнтів типовий розподіл запитів виглядає так:

Роутинг на основі класифікації намірів (мала модель класифікує, велика виконує лише за потреби) зменшує витрати на 50-70% у системах з гетерогенним типом запитів. Вимагає A/B-тестування, щоб підтвердити, що якість відповідей при роутингу не падає нижче прийнятного порогу.

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

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

Мінімальні метрики для відстеження у продакшені:

• Вхідні та вихідні токени на endpoint або feature (не лише загалом).
• Вартість на сесію користувача або на бізнес-транзакцію.
• Відсоткова частка системного промпту у вхідних токенах.
• Cache hit rate для prompt caching (якщо використовуєш).
• Розподіл довжини відповідей моделі (довгі відповіді можуть сигналізувати зайву балакучість).

Алерти мають працювати на двох рівнях: попередження при 70% денного бюджету та жорсткий ліміт при 90% з автоматичним throttling або деградацією до дешевшої моделі. Моніторинг якості агента AI описує ширший контекст обсервабельності, включаючи метрики observability для шару AI.

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

Точні інструкції формату. «Відповідай максимум у 3 реченнях» працює, але краще: «Перелічи максимум 3 пункти як список, без вступу та підсумку». Модель без інструкцій схильна генерувати церемоніальні вступи та закінчення, які не додають цінності.

Structured output. Коли очікуєш дані для обробки кодом, structured output (JSON schema) усуває наративне оформлення. Екстракція 5 полів з документа як JSON — це 80-120 вихідних токенів, а та сама екстракція як наратив — 300-600 токенів.

Температура та довжина. Вища температура не подовжує відповіді, але temperature=0 з явним зазначенням довжини в промпті дає більш передбачувані, коротші відповіді для детермінованих завдань.

Stop sequences. Визнач токен зупинки для моделі (наприклад, ### або певний роздільник JSON), щоб модель не продовжувала після завершення основної відповіді. Особливо корисно при генерації списку з обмеженою кількістю елементів.

При обсязі понад 5-10 млн токенів на день self-hosting локальної моделі може бути дешевшим за API, навіть з урахуванням витрат на інфраструктуру. Межа доцільності залежить від моделі, обладнання та профілю запитів.

Для завдань, які не потребують frontier-моделі (класифікація, екстракція даних, FAQ, прості резюме), локальні моделі класу 7B-34B досягають прийнятної якості при вартості, близькій до нуля за токен. Стаття вартість local vs API LLM описує калькулятор порогу доцільності та типові профілі використання.

Рішення про self-hosting — це не лише вартість. Це також data residency (дані не залишають інфраструктури), відповідність RODO для чутливих даних та усунення залежності від зовнішнього провайдера. Стаття self-hosted LLM та RODO детально розглядає ці аспекти.

Опиши архітектуру своєї системи AI (скільки запитів на день, яка довжина системного промпту, чи використовуєш RAG), і модель вкаже, де найбільший потенціал оптимізації токенів (playground: PII маскуються, zero retencji):

Не завжди. Дешевша модель часто потребує довшого, більш точного промпту, щоб досягти того ж результату, що й преміум-модель. Якщо вартість за токен у 5 разів нижча, але промпт має бути в 3 рази довшим, а модель генерує вдвічі більше вихідних токенів, щоб уникнути помилок, реальна економія буде малою або відсутньою. Перед зміною моделі виміряй загальну вартість на завдання (не за токен) на репрезентативному тестовому наборі з щонайменше 200 прикладів.

Prompt caching — це механізм, за якого провайдер API зберігає внутрішній стан моделі для багаторазово використаного префіксу промпту. Кожен наступний виклик з ідентичним префіксом сплачує за токени кешу замість повних вхідних токенів, що зазвичай на 70-90% дешевше. Умова: префікс має бути байтово ідентичним між викликами та перевищувати мінімальний поріг довжини (зазвичай 1024 токени). Зміна хоча б одного символу анулює кеш. На практиці працює чудово для постійного системного промпту та контекстних інструкцій, які не змінюються між запитами користувача.

RAG замінює дорогий повнодокументний контекст на дешевий фрагментарний. Замість надсилання цілого документа (2000-40 000 токенів) до кожного запиту, RAG використовує семантичний пошук, щоб вибрати 3-5 релевантних фрагментів (150-600 токенів загалом). При 10 000 запитах на день з документом у 5000 токенів різниця становить 50 млн проти 2-3 млн токенів на місяць. Вартість ембедінгів та пошуку мізерна порівняно з економією на токенах моделі. Детальніше про побудову пайплайну RAG у статті семантичний пошук та ембедінги у компанії.

Self-hosting усуває вартість за токен, але має власні витрати: обладнання GPU або орендований сервер, обслуговування, оновлення моделі та час інженерів. При малому обсязі (менше 1 млн токенів на день) API зазвичай дешевше з урахуванням операційних витрат. Self-hosting стає доцільним при сталому, великому обсязі та завданнях, які не потребують frontier-моделі. Використай калькулятор ROI, щоб порівняти обидва сценарії для свого профілю використання.

Відстежуй токени на рівні виклику, а не сесії. У кожному виклику моделі фіксуй: feature або endpoint, який його викликав, кількість вхідних та вихідних токенів, а також чи використовувався кеш. Агрегуй за feature у дашборді (наприклад, Grafana з метриками Prometheus). Завдяки цьому видно, який feature відповідає за 60% витрат, що дозволяє визначити пріоритети оптимізації. Патерн реалізації описано в моніторингу якості агента AI у розділі, присвяченому телеметрії викликів LLM.