Скільки токенів іде на одну розмову в AI-боті — реальні заміри · Leadmlyn
Скільки токенів іде на розмову: реальні заміри і де можна оптимізувати
Реальні заміри токенів для трьох типів розмов в leisure-боті: від короткого запиту до складного бронювання. Що найбільше витрачає і як оптимізувати без втрати якості.
Павло Полюхович·4 квітня 2026 р.·6 хв читання
Продукт
Скільки токенів іде на розмову: реальні заміри і де можна оптимізувати
Типова розмова по бронюванню — приблизно 4500–6000 input-токенів і 800–1200 output-токенів сумарно за весь діалог. При ціні gpt-4o-mini $0.15/$0.60 за мільйон — це менше двох гривень за повну розмову. Але ця цифра може суттєво відрізнятись залежно від типу розмови і того, як налаштована KB.
Нижче — розбір того, що входить у цю суму, реальні заміри по трьох типах розмов і конкретні дії, які дають скорочення токенів без жодної втрати якості.
Що входить у токени однієї розмови
Кожна відповідь бота — це окремий виклик до мовної моделі. Модель не «пам'ятає» попередні розмови між сесіями, тому при кожному виклику їй передається весь контекст, необхідний для відповіді. Цей контекст складається з чотирьох компонентів.
Системний промпт — фіксована частина. Це інструкції боту: роль, тон, обмеження, правила збору лідів. Він передається з кожним викликом без змін. Типова довжина для leisure-бота: 800–2000 токенів. Якщо ти написав системний промпт розміром з невеликий есе — він щоразу займатиме левову частку input.
KB-витяжка — змінна частина. Це фрагменти з бази знань, знайдені через RAG для конкретного питання. Залежить від того, скільки релевантних чанків знайшов пошук і якого розміру ці чанки. Типово: 1000–2500 токенів. Якщо записи в KB довгі і розмиті — витяжка буде більшою.
Історія розмови — частина, що зростає. Чим довша розмова, тим більше попередніх повідомлень передається у контекст. На першому повідомленні — 0 токенів. На п'ятому — вже 500–800. На дванадцятому — 1500–2500, залежно від довжини відповідей.
Нове повідомлення клієнта — найменша частина. Зазвичай 20–80 токенів. Клієнти пишуть коротко.
Output-токени — це текст відповіді бота. Залежить від того, яку максимальну довжину відповіді встановлено (max_output_tokens у нас за замовчуванням 1024). Реальна середня відповідь leisure-бота — 100–250 токенів.
Реальні заміри: три типи розмов
Наведу три виміряні профілі. Всі числа — за gpt-4o-mini з середньостатистичним KB leisure-бота (150–200 записів, нормально заповнених).
Тип 1 — Коротка інформаційна: 3–4 повідомлення.
Клієнт запитує одну конкретну річ. Наприклад: «Працюєте у неділю?» — відповідь — «Дякую». Або: «Скільки коштує корт на годину?» — відповідь — «Зрозуміло».
Вартість при $0.15/$0.60 за мільйон: приблизно $0.00135 — менше 0.05 грн.
Тип 2 — Стандартне бронювання: 8–12 повідомлень.
Клієнт уточнює деталі, бот збирає дату, час, кількість людей, підтверджує. Найчастіший сценарій у leisure-боті.
Компонент
Один виклик
Сума за 10 обмінів
Системний промпт
~1200 токенів
~12 000
KB-витяжка
~1500 токенів
~12 000 (зменшується після пікових)
Зростаюча history
0→2000 токенів
~10 000
Повідомлення клієнта
~50 токенів
~500
Відповіді бота
—
~1500
Сумарно за розмову: ~34 500 input + ~1500 output.
Вартість: приблизно $0.006 — менше 25 копійок.
Тип 3 — Складний запит з уточненнями: 15+ повідомлень.
Групове бронювання з нестандартними умовами, кількома уточненнями, зміною дати. Або клієнт, який передумав і переформатував запит на середині.
Тут вступає ефект «зростаючої history». До 15-го обміну history-компонент може займати 3000–4000 токенів. Плюс системний промпт і KB — кожен виклик коштує 5000–6000 input-токенів.
Сумарно: ~70 000–90 000 input + ~3000 output.
Вартість: $0.012–0.016 — від 50 копійок до гривні.
Це максимальна вартість типового leisure-сценарію. Навіть складна розмова — менше гривні.
Що найбільше «їсть» токени і що можна оптимізувати
Три джерела токенних витрат, де є реальний важіль.
1. Надмірно довгий системний промпт.
Системний промпт передається з кожним викликом. Якщо він 3000 токенів — ти платиш за ці 3000 токенів при кожному з 10 повідомлень розмови. Тобто 30 000 токенів тільки на промпт, і жодного — на корисний контент.
Що оптимізувати: прибрати дублювання, видалити очевидні інструкції («відповідай ввічливо», «використовуй мову клієнта»), залишити лише специфічну логіку бізнесу.
Типовий результат скорочення промпту з 2000 до 800 токенів при 400 розмовах на місяць: економія ~480 000 input-токенів = ~$0.072/міс. Невелика сума, але системний ефект.
2. Розлогі KB-записи, що дають великі чанки.
Якщо в KB є запис розміром 600 слів, він розбивається на кілька чанків, і при пошуку може бути витягнутий один або два. Кожен такий чанк — 400–600 токенів. Три таких чанки — вже 1800 токенів тільки на KB-витяжку.
Що оптимізувати: розбити довгі записи на маленькі сфокусовані. Замість «Умови бронювання і скасування і трансфер і парковка» — чотири окремих записи. Кожен — 50–100 слів. RAG знайде точніше і передасть менше токенів.
3. Велика глибина history.
За замовчуванням history_limit = 15 повідомлень. Для простих сценаріїв це більше ніж потрібно — у більшості leisure-розмов питання вирішується за 5–7 обмінів.
Що оптимізувати: зменш history_limit до 8–10, якщо у тебе переважають короткі сесії. Параметр регулюється в playground через слайдер «Глибина історії». Кожна позиція — це скільки попередніх повідомлень бот «бачить» при відповіді. Менше — дешевше, але якщо клієнт повертається до теми з початку — бот може не «пам'ятати».
Не оптимізуй blindly: якщо у тебе є сценарії де клієнт уточнює умови кілька разів упродовж довгої розмови — обрізати history до 5 зіпсує досвід. Тестуй у playground.
Кожен виклик до моделі фіксується як UsageEvent з полями: model_slug, input_tokens, output_tokens, raw_cost_uah, charged_uah, markup_pct_applied. Ці дані агрегуються в дашборді.
Що бачиш в аналітиці:
Поточний баланс wallet — скільки залишилось
Витрати за день/тиждень/місяць — динаміка
Середня вартість розмови — ключова метрика для розуміння «нормального» рівня
Прогноз запасу — на скільки днів вистачить поточного балансу при поточному темпі
Середня вартість розмови — найважливіший показник. Якщо вона раптово зросла вдвічі — значить щось змінилось: можливо, клієнти стали писати довші запити, або в KB з'явились надто великі записи, або хтось випадково скинув history_limit на максимум.
Окрема секція, бо це найпрактичніший важіль з усіх.
Формула проста: менший чанк → менший KB-контекст → менше токенів → менша вартість. При цьому маленький сфокусований чанк ще й знаходиться точніше, бо його вектор не «розмитий» між кількома темами.
Конкретні кроки:
Записи FAQ — максимум 150–200 слів. Якщо більше — розбий.
Цінові записи — один рядок на позицію. Не «докладний опис послуги + умови + ціна» в одному полі.
Файли-документи — якщо вони великі і слабко структуровані, перепиши ключові факти вручну як FAQ і ціни. Авторозбиття файлів на чанки гірше, ніж ручні записи.
Після кожного оновлення KB — перевір у playground на типових питаннях чи вартість за одну відповідь знизилась.
# Що бачить аналітик по токенах у usage_events
SELECT
DATE_TRUNC('day', created_at) AS day,
model_slug,
SUM(input_tokens) AS total_input,
SUM(output_tokens) AS total_output,
SUM(charged_uah) AS total_cost_uah,
COUNT(*) AS calls
FROM usage_events
WHERE bot_id = '<твій-bot-id>'
GROUP BY 1, 2
ORDER BY 1 DESC;
Ця вибірка дасть розбивку по моделях і днях — якщо вартість раптово стрибнула в конкретний день, видно в яку дату і на якій моделі.
Токени — це не страшно. При нормально заповненій KB і розумному системному промпті типова розмова по бронюванню коштує 20–30 копійок, складна — до гривні. Місячна вартість токенів для активного бізнесу з 500 розмовами — 150–300 грн. Порядок цифр, де немає сенсу мікрооптимізувати в збиток якості відповідей.
Але якщо ти бачиш середню вартість розмови в 5–10 грн — щось точно не так: або системний промпт занадто великий, або KB з довжелезними записами, або history_limit занадто великий. Дивись дашборд і тестуй зміни в playground.
