Як зменшити витрати на токени без неперевіреної втрати якості

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

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

Спочатку розкласти рахунок

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

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

У деяких API кешовані токени повертаються в полі використання окремо від загального входу, а для нових моделей окремо показуються і токени, записані в кеш. Ці поля варто зберігати, а не лише загальну кількість токенів.

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

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

Зменшити зайвий контекст

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

• Дублі. Один і той самий фрагмент бази знань потрапляє в запит двічі з різних джерел пошуку.
• Уся історія діалогу. Двадцять попередніх повідомлень, з яких для відповіді потрібні два останні і суть першого.
• Цілі документи замість фрагментів. Договір на сорок сторінок, хоча питання стосується одного пункту.
• Застарілі інструкції. Правила, які додали «про всяк випадок» і які вже не впливають на результат.
• Надмірна відповідь. Модель пише п’ять абзаців там, де достатньо двох речень, і ви платите за вихідні токени, які зазвичай дорожчі за вхідні.

Способи скорочення: прибирати дублі перед відправкою; обирати лише найрелевантніші фрагменти; замість повної історії зберігати перевірене стисле резюме попередньої частини розмови; явно обмежувати формат і довжину відповіді.

Порядок величин легко оцінити. Навчальний приклад: якщо замість повної історії діалогу на 3 000 токенів передавати перевірене резюме на 800 токенів, вхід кожного виклику скорочується на 2 200 токенів. За ставки $2 за мільйон вхідних токенів це $0,0044 на виклик, або $440 на 100 000 викликів на місяць. Для дешевшої моделі зі ставкою $0,10 та сама зміна дасть лише $22 — і тоді, можливо, час інженерів краще витратити на іншу статтю витрат. Ось чому порядок оптимізації залежить від вашого рахунку, а не від загального списку порад.

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

Налаштувати кешування

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

Для окремих нових моделей умови кешування, перевірені 11.10.2026, працюють так. Кешування увімкнене за замовчуванням для підтримуваних моделей. Для повторного використання має збігатися весь відрендерений префікс, і система шукає найдовший збіг. Для моделей починаючи з GPT-5.6 мінімальна довжина запиту для кешування — 1 024 видимі вхідні токени, а закешований префікс лишається доступним 30 хвилин після останнього запису чи використання. Читання з кешу для цих моделей коштує 0,1 від звичайної ставки входу, для GPT-6.1 Sol — 0,05. Але запис у кеш коштує 1,25 від звичайної ставки. Для старіших моделей умови інші, тому перевіряйте документацію для конкретної моделі.

Звідси практичні правила:

• Стабільне — на початку. Інструкція, загальні правила, довідники — першими, у незмінному порядку і форматі.
• Змінне — в кінці. Питання користувача, дата, ім’я, знайдені фрагменти — після стабільної частини. Навіть поточний час на початку запиту зламає збіг префікса.
• Вимірювати фактичні попадання, а не розраховувати на них.

Навчальний розрахунок: дві колонки замість одної

Навчальний приклад на тарифах API, Standard, короткий контекст, 11.10.2026, модель gpt-6.1-sol: звичайний вхід $2 за мільйон токенів, читання з кешу $0,10, запис у кеш $2,50, вихід $10. Запит — 6 000 вхідних токенів, з них 4 000 стабільний префікс, плюс 800 вихідних.

Тепер припустімо, що кожен промах кешу означає новий запис префікса. При 90% попадань середня вартість: 0,9 × $0,0124 + 0,1 × $0,022 = $0,01336, на третину менше, ніж без кешу. При 50% попадань: $0,0172, економія лише 14%. А якщо запити приходять рідше, ніж раз на 30 хвилин, і кожен раз префікс записується заново, виклик коштує $0,022 — на 10% дорожче, ніж без кешу.

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

Вибрати пакетні задачі

Пакетна обробка — це асинхронний режим: ви надсилаєте файл із багатьма запитами, а результати отримуєте пізніше. Для одного з актуальних пакетних API такий режим дає знижку 50% порівняно із синхронними API, пакет виконується протягом 24-годинного вікна, а часто швидше. В одному пакеті може бути до 50 000 запитів, а файл — до 200 МБ. Ліміти пакетної обробки окремі від звичайних лімітів моделі.

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

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

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

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

Додати маршрутизацію

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

Навчальна схема для звернень у підтримку:

1. Відома категорія короткого звернення → дешевша модель класифікує і готує відповідь.
2. Перевірка правилами: чи належить категорія до списку дозволених для автоматичної відповіді, чи заповнені всі обов’язкові поля, чи немає ознак скарги чи юридичного питання.
3. Правила не виконано → звернення передається сильнішій моделі.
4. Підстав для відповіді все ще немає → звернення йде людині.

Сигнал ескалації має бути зовнішнім: правило, відсутнє поле, непокрита категорія. Оцінка моделлю власної впевненості — слабкий сигнал. І потрібен ліміт повторів, щоб одне звернення не ходило по колу між моделями.

Навчальний розрахунок маршрутизації

Ті самі тарифи і той самий розмір запиту (6 000 вхідних і 800 вихідних токенів): виклик gpt-6.1-sol — $0,02, виклик gpt-6-luna — $0,001. На 1 000 звернень:

• Усе через сильнішу модель: 1 000 × $0,02 = $20.
• Маршрутизація з 20% ескалацій: спочатку всі 1 000 через дешевшу модель — $1, потім 200 звернень ще раз через сильнішу — 200 × $0,02 = $4. Разом $5.
• Маршрутизація з 60% ескалацій: $1 + 600 × $0,02 = $13.

Зверніть увагу: при ескалації рахуються обидва виклики. Поріг, за якого маршрутизація перестає бути вигіднішою за модельним рахунком, — коли $1 + частка ескалацій × $20 = $20, тобто 95% ескалацій.

Але модельний рахунок — не вся картина. Додамо навчальне припущення: 1% відповідей дешевшої моделі неправильні і проходять перевірку правилами непоміченими, а виправлення кожної такої помилки коштує бізнесу $2 часу співробітника. При 20% ескалацій дешевша модель відповідає на 800 звернень, помилкових — 8, ціна помилок — $16. Разом $5 + $16 = $21 — дорожче, ніж усе через сильнішу модель. Цей приклад вигаданий, але логіка реальна: ціна непомічених помилок може переважити всю економію на токенах.

Захистити якість економії

Кожна оптимізація — це зміна системи, і перевіряти її треба як зміну системи.

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

П’ять показників разом:

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

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

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

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

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

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

1. Почати журналювати для кожного виклику вхідні, кешовані, записані й вихідні токени, тип задачі і результат.
2. Визначити найбільшу статтю витрат і почати з неї.
3. Зібрати незмінний контрольний набір задач з еталонами.
4. Перебудувати промпти: стабільна частина на початку, змінна в кінці; виміряти фактичну частку кешованих токенів.
5. Позначити задачі, які можуть чекати, і перевести їх у пакетний режим.
6. Для маршрутизації порахувати вартість успішної задачі з урахуванням обох викликів при ескалації і ціни непомічених помилок.
7. Вносити зміни по одній і порівнювати відмови, помилки, затримку і вартість успішної задачі.

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

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