Скільки коштує RAG при 50–100 тисячах запитів на місяць

Коротка відповідь: кількість запитів сама по собі ціни не визначає. Рахунок за RAG-систему — тобто систему, яка перед відповіддю шукає потрібні фрагменти у ваших документах і передає їх моделі, — залежить від того, скільки токенів іде в модель і з неї, скільки звернень до моделі робиться на одне питання, як часто бувають повтори і скільки коштує все, що працює навколо моделі. У навчальному прикладі нижче модельна частина для 100 тисяч запитів на місяць виходить від $100 до $2 000 залежно лише від обраної моделі, за тих самих розмірів запиту.

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

Що входить в одне питання користувача

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

1. Переписування запиту. Модель перетворює розмовне питання «а що там з поверненням, якщо я вже відкрив коробку?» на пошуковий запит. Це окремий виклик моделі, зазвичай короткий.
2. Перетворення запиту на вектор (embedding). Текст запиту перетворюється на числовий вектор для пошуку схожих фрагментів. Окремий тариф, окрема модель.
3. Пошук. Векторна база чи пошуковий сервіс знаходять кандидатів. Платите за сервіс або інфраструктуру, а не за токени.
4. Переранжування (reranking). Окрема модель упорядковує знайдені фрагменти за релевантністю. Ще один виклик або сервіс.
5. Генерація відповіді. Основний виклик: інструкція, знайдені фрагменти, історія діалогу і питання йдуть на вхід, відповідь — на вихід. Зазвичай найдорожчий крок.
6. Перевірка. Деякі системи окремим викликом перевіряють, чи спирається відповідь на знайдені документи, чи немає заборонених тем.
7. Повтори. Помилка мережі, перевищення ліміту, некоректний формат — і виклик повторюється.

Не кожна система використовує всі кроки. Проста RAG-система може обходитися пошуком і одним викликом генерації. Складніша — мати три-чотири виклики моделі на кожне питання. Тому перше, що потрібно знати для розрахунку, — це не «скільки запитів», а «скільки викликів моделі і якого розміру припадає на одне питання».

Прозора формула токенів

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

Вартість одного виклику:

вхідні токени ÷ 1 000 000 × ціна входу + вихідні токени ÷ 1 000 000 × ціна виходу

Вартість на місяць:

вартість виклику × кількість викликів на одне питання × кількість питань на місяць

Якщо постачальник підтримує кешування повторюваної частини запиту, вхід розділяється на три частини з різними ставками: звичайний вхід, токени, прочитані з кешу, і токени, записані в кеш. Наприклад, у тарифах API, перевірених 11.10.2026, для моделі gpt-6.1-sol у режимі Standard з коротким контекстом звичайний вхід коштує $2 за мільйон токенів, читання з кешу — $0,10, а запис у кеш — $2,50, тобто дорожче за звичайний вхід. Тому в розрахунку кешовані токени мають бути окремою колонкою з фактичними даними з журналу використання, а не припущенням «увесь вхід закешується».

Важливе застереження про тарифи. У постачальника може бути кілька режимів обслуговування — стандартний, пакетний, гнучкий, прискорений — і окремі ставки для короткого та довгого контексту. Не змішуйте їх: ціна з таблиці пакетної обробки не підходить для чат-бота, який має відповідати одразу, а ставка короткого контексту не діє, якщо ваші запити виходять за його межу. Наприклад, у тієї ж gpt-6.1-sol ставки довгого контексту в режимі Standard вищі: $4 за мільйон вхідних і $15 за мільйон вихідних токенів.

Розрахунок на 50 і 100 тисяч запитів

Нижче навчальний розрахунок для ілюстрації методу. Він не описує вашу систему і не є прайсом BotLabs.

Припущення: на одне питання — один виклик моделі; 6 000 вхідних токенів (інструкція, знайдені фрагменти, питання) і 800 вихідних; без кешу, повторів, податків. Тарифи API, режим Standard, короткий контекст, USD, стан на 11.10.2026: gpt-6.1-sol — $2 за мільйон вхідних і $10 за мільйон вихідних токенів; gpt-6-luna — $0,10 і $0,50.

Вартість одного виклику:

• gpt-6.1-sol: 6 000 ÷ 1 000 000 × $2 = $0,012; 800 ÷ 1 000 000 × $10 = $0,008; разом $0,02.
• gpt-6-luna: 6 000 ÷ 1 000 000 × $0,10 = $0,0006; 800 ÷ 1 000 000 × $0,50 = $0,0004; разом $0,001.

Різниця у 20 разів не означає, що дешевша модель — кращий вибір. Це різні моделі, і їхню якість у цьому розрахунку ніхто не порівнював. Порівнювати вартість має сенс лише тоді, коли обидві моделі на ваших запитах дають прийнятну якість.

Умовні додаткові витрати. Додамо до модельної частини три навчальні припущення: пошук і хостинг — $150 на місяць, моніторинг — $100, супровід — $600. Разом $850. Тоді:

Ці $850 — не ринкова норма і не комерційна пропозиція, а ілюстрація того, що для дешевої моделі постійні витрати можуть бути більшими за модельний рахунок.

Чутливість до архітектури. Тепер змінимо лише будову конвеєра, залишивши ті самі тарифи. Нехай система спочатку переписує запит (1 000 вхідних і 100 вихідних токенів), потім генерує відповідь із довшим контекстом (10 000 вхідних і 1 000 вихідних), а 5% викликів генерації повторюються.

• gpt-6.1-sol: переписування — $0,002 + $0,001 = $0,003; генерація — $0,02 + $0,01 = $0,03; повтори — 5% × $0,03 = $0,0015. Разом $0,0345 на питання, або $3 450 на 100 000 питань замість $2 000.
• gpt-6-luna: переписування — $0,0001 + $0,00005 = $0,00015; генерація — $0,001 + $0,0005 = $0,0015; повтори — 5% × $0,0015 = $0,000075. Разом $0,001725, або $172,50 на 100 000 питань замість $100.

Той самий обсяг питань, та сама модель — і рахунок зростає на 72,5%. Саме тому без реального профілю запитів будь-яка оцінка «RAG коштує стільки-то» мало що означає.

Інші регулярні витрати

Модельний рахунок — лише частина щомісячних витрат. Інші статті, які варто внести в таблицю:

• Векторний пошук. Керований сервіс із платою за обсяг даних і запити або власна база на вашій інфраструктурі.
• Embedding нових документів. Кожен новий чи змінений документ треба перетворити на вектори. При частих оновленнях бази знань це регулярна стаття.
• Зберігання. Оригінали документів, фрагменти, вектори, журнали запитів і відповідей.
• Моніторинг. Збір журналів, метрики затримок і помилок, сповіщення.
• Резервування. Резервні копії індексу, запасний постачальник моделі чи режим деградації на випадок збою.
• Оцінювання якості. Регулярна перевірка відповідей. Система оцінювання може окремо показувати, чи знайшов пошук релевантний контекст, чи спирається відповідь на цей контекст і наскільки якісна сама відповідь. Автоматичні метрики потребують запусків моделі, а вибіркова ручна перевірка — часу людей.
• Супровід. Оновлення інструкцій, реакція на скарги, виправлення помилок пошуку, оновлення інтеграцій. Робота вашої команди чи підрядника — окрема стаття бюджету, рахунок за токени її не включає.

Разові витрати і ризики зростання

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

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

Інтеграції. Підключення до CRM, бази товарів, системи заявок, авторизації користувачів.

Очищення даних. Видалення персональних даних, де вони не потрібні, узгодження форматів.

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

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

Серед ризиків зростання витрат варто окремо порахувати:

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

Про піки — окремо. Місячний обсяг не описує, скільки запитів приходить одночасно. Навчальний розрахунок: 100 000 питань на місяць, 22 робочі дні — приблизно 4 545 питань на день. Якщо в пікову годину припадає 15% денного обсягу, це близько 682 питань на годину, або 11–12 на хвилину. Для API це питання лімітів швидкості вашого облікового запису. Для власного сервера — питання, чи витримає він таке навантаження із прийнятною затримкою. Такі параметри перевіряють навантажувальним тестуванням: наприклад, спеціалізовані засоби вимірюють час до першого токена, інтервал між токенами і пропускну здатність при заданій інтенсивності запитів і кількості одночасних з’єднань.

Як скласти свій бюджет

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

1. Зняти реальний профіль запитів. На пілоті або на вибірці історичних звернень виміряти середні й 90-й перцентиль вхідних і вихідних токенів на кожному кроці, кількість викликів на питання, частку повторів і частку кешованих токенів.
2. Визначити якість і рівень сервісу. Який відсоток правильних відповідей прийнятний, яка максимальна затримка, що робити, коли система не знає відповіді. Без цього неможливо чесно порівняти дешеву і дорогу модель.
3. Підставити чинні тарифи. Взяти потрібний режим обслуговування і довжину контексту, записати дату перевірки поруч із таблицею.
4. Порахувати три навантаження. Наприклад, 50, 100 і 150 тисяч питань, а також сценарій із довшими відповідями і більшою кількістю повторів.
5. Додати регулярні витрати поза моделлю і окремо — разові.
6. Призначити власника витрат. Людину, яка щомісяця звіряє фактичний рахунок із моделлю і має право змінювати налаштування.

Зручно звести все в одну таблицю, де кожен рядок — окремий крок або стаття витрат, а кожна колонка — значення, яке можна перевірити:

Порожні клітинки — це і є список того, що треба виміряти. Якщо значення поки оцінене, а не виміряне, позначте це прямо в таблиці, щоб через місяць було видно, які припущення підтвердилися. Добра практика — тримати поруч дві колонки «план» і «факт» і щомісяця дивитися на розбіжність: саме вона показує, яке припущення було найслабшим.

Підсумок і перші кроки

Ціна RAG на 50–100 тисяч запитів — це не одна цифра, а модель із кількома змінними. Тарифи на токени відомі й прозорі, але розмір запитів, кількість викликів і повтори можуть змінити модельний рахунок у кілька разів. А витрати навколо моделі — пошук, оцінювання якості, супровід — для дешевих моделей можуть переважати сам рахунок за API.

Що зробити на своєму проєкті:

1. Намалювати конвеєр однієї відповіді і позначити кожен виклик моделі та сервісу.
2. На реальних або тестових питаннях виміряти токени на кожному кроці.
3. Скласти таблицю «модельний рахунок» і окрему таблицю «повна вартість».
4. Порахувати мінімум три сценарії навантаження і сценарій із довшими відповідями.
5. Підготувати контрольний набір питань, щоб порівнювати моделі за якістю, а не лише за ціною.
6. Записати дату перевірки тарифів і перевіряти їх перед кожним бюджетним рішенням.

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

Часті запитання