Ті, хто займається бекендом і розробкою AI-застосунків, мабуть, усі переживали такий момент: відкриваєш наприкінці місяця рахунок за хмару й виявляєш, що витрати на API великих моделей утричі перевищують бюджет. Це не атака, не різке зростання бізнесу — просто той онлайн-сервіс діалогів тихенько спалює гроші. У цій статті я з інженерного погляду розберу, куди саме витікають гроші, і як закрити ці дірки технічними засобами.
Пастка перша: неконтрольоване розростання вікна контексту
Найлегше проігнороване джерело витрат у багатоходових діалогах — це повернення всієї історії повідомлень. Уявімо сценарій служби підтримки: у середньому 800 токенів контексту на хід, і коли користувач доходить до 20-го ходу, вхід одного запиту наближається до 16 000 токенів. За ціною входу GPT-4o $2.5/1M токенів, вартість входу одного запиту становить близько $0.04, а при 50 000 викликів на день це вже $2000. Найгірше те, що з цих 16 000 токенів, можливо, 70% — це балачки, які втратили актуальність ще три ходи тому.
Ідея оптимізації — ковзне вікно плюс стиснення через резюме. Зберігаємо оригінальний текст останніх N ходів, а раніші діалоги стискаємо легкою моделлю до резюме в межах 200 токенів. У нашому проєкті ми змінили вікно з «повного» на «останні 6 ходів + резюме», і вхідні токени одного запиту впали з 12 000 до приблизно 3500, а витрати на вхід скоротилися одразу на сімдесят відсотків. Зверніть увагу, що саме резюме теж має робитися дешевою моделлю — робити резюме флагманською моделлю означає не заощадити нічого.
Пастка друга: флагманські моделі виконують чорну роботу
Це найпоширеніше і найбезглуздіше марнотратство. Класифікація намірів, оцінка емоцій, стиснення контенту, конвертація форматів — ці завдання DeepSeek-V3 або Qwen-Max виконують з точністю понад 95%, але багато команд заради зручності пускають усе через Claude 4 Sonnet або GPT-4o. Яка різниця в ціні? Ціна входу флагманської моделі часто в 10–20 разів вища за легку модель.
Суть багаторівневого виклику моделей — це маршрутизація. Завдання надходить, автоматично визначається його складність, класифікація йде на легку модель, і лише складне міркування — на флагманську. SiCore TokenWorks підтримує автоматичний вибір оптимальної моделі за завданням, і в нашому проєкті після переведення завдань класифікації на легку модель витрати помітно впали. Цінність таких платформ-агрегаторів AI API саме в тому, що вам не потрібно окремо підтримувати SDK і Key для кожної моделі — достатньо одного OpenAI-сумісного інтерфейсу для перемикання. Ось приклад мінімальної зміни:
from openai import OpenAI
client = OpenAI(
api_key="your-token8341-key",
base_url="https://api.token8341.com/v1" # змініть один рядок, сумісно з OpenAI SDK
)
# легке завдання йде на дешеву модель
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role": "user", "content": "Визнач емоційне забарвлення цього відгуку: доставка швидка, але упаковка пошкоджена"}],
max_tokens=16
)
print(resp.choices[0].message.content)Стратегію маршрутизації можна спочатку будувати на правилах: позначаємо тип завдання, класифікація/резюме/витяг ідуть на легкі моделі, генерація коду/складне міркування — на флагманські. Попрацювавши так певний час, збираємо статистику фактичного влучання по кожній моделі й коригуємо — не варто одразу будувати складну семантичну маршрутизацію, витрати на її підтримку перевищать зекономлені гроші.
Пастка третя: втрата контролю над механізмом повторних спроб
Повторні спроби після тайм-ауту — це невидимий підсилювач. Багато SDK за замовчуванням роблять 2–3 повторні спроби; якщо поріг тайм-ауту встановлено занадто коротким (наприклад, 10 секунд), а фактична затримка P99 становить 25 секунд, то велика кількість запитів після тайм-ауту повторюється, і один виклик перетворюється на три. Гірше те, що самі повторні запити теж займають паралельні з'єднання, можуть спричинити обмеження швидкості, а обмеження своєю чергою знову провокує повторні спроби — утворюється лавина.
Ми одного разу наступили на ці граблі: затримка P99 деякого інтерфейсу 28 секунд, тайм-аут встановлено 15 секунд, 3 повторні спроби — і фактична кількість викликів у 2.4 раза перевищила обсяг бізнес-запитів. Згодом ми встановили поріг тайм-ауту на 30% вище за P99, а повторні спроби змінили на експоненційне відступання з максимум 1 спробою — і кількість викликів упала до 1.1 раза. Крім того, повторні спроби мають розрізняти типи помилок: повторювати лише 429 і 5xx, бо повторювати помилку параметрів 400 тисячу разів однаково марно.
Пастка четверта: відсутність агрегації витрат і сповіщень
Це найглибша проблема. Багато команд ведуть приблизний облік за проєктом або за Key, але не знають, яка саме функція, який користувач, який Prompt спалює гроші. І лише коли приходить рахунок, виявляється, що Key якогось тестового середовища не вимкнули, або що наддовга сесія якогось користувача з'їла весь бюджет.
Підхід — позначати за вимірами: кожен виклик супроводжується трьома тегами team, feature, user_id, які записуються в логи або в базу часових рядів. Перевага використання AI API-шлюзу як єдиної точки входу саме в цьому: усі виклики проходять через один проксі-шар, тегування й агрегація витрат виконуються на боці шлюзу, і не потрібно змінювати код кожного бізнес-підрозділу. Пороги сповіщень радимо встановлювати у два рівні: при досягненні 60% бюджету за денним обсягом — попередження, при 85% — спрацьовує деградація (наприклад, автоматичне переведення некритичних функцій на легкі моделі).
Порівняння витрат і орієнтири для вибору
Після впровадження всіх чотирьох пунктів ми порівняли три способи підключення: пряме офіційне підключення до однієї моделі, власна маршрутизація та платформа-агрегатор. Пряме офіційне підключення — найпростіше, але не дозволяє робити багаторівневість моделей, витрати жорстко фіксовані; власна маршрутизація гнучка, але вимагає підтримки кількох наборів Key, кількох SDK і кількох схем білінгу — це щонайменше два людино-місяці; платформа-агрегатор має готові можливості для перемикання моделей і агрегації витрат, оплата за фактичним споживанням, витрати вигідніші. При виборі звертайте увагу на три речі: чи сумісна з OpenAI SDK (витрати на міграцію), чи підтримує повне покриття вітчизняних моделей (відповідність вимогам і витрати), чи має інтерфейс агрегації витрат (спостережуваність).
Оптимізація витрат — це не разова дія, а процес постійного спостереження й коригування. Спершу налагодьте агрегацію витрат, побачте, куди витрачаються гроші, а вже потім оптимізуйте по черзі контекст, багаторівневість моделей і стратегію повторних спроб. Не міняйте порядок місцями, інакше ви оптимізуватимете пів дня, а виявиться, що оптимізували зовсім не те, що становить основну частину витрат.
Автор: Чень Цзінсін
Дата публікації: 3 жовтня 2026 року