Колеги, які займаються бекендом та алгоритмами, ви, напевно, теж стикалися з такою контрінтуїтивною ситуацією: обсяг онлайн-бізнесу начебто майже не зріс, але наприкінці місяця дивишся на рахунок — і він просто подвоївся. Команда, яку я очолюю, два роки тому робила систему інтелектуальної служби підтримки для однієї компанії в сфері онлайн-освіти. За два місяці після запуску кількість викликів зросла лише з 120 тисяч на день до 168 тисяч на день, тобто на 40%, але щомісячний рахунок за API злетів з 8000 юанів до 23000 юанів, тобто на 187%. Різниця в грошах — це не підвищення ціни за одиницю, це чотири приховані чорні діри витрат, які тихо з'їдають бюджет.

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

Чорна діра перша: шторм повторних спроб, недійсні виклики подвоюються напряму

Наш початковий код викликів був дуже простим: при мережевих збоях або тайм-аутах просто catch і повторний виклик, без відступу, без ідемпотентності. На другому тижні після запуску ми зіткнулися з обмеженням частоти на боці постачальника: QPS раптово впав з 20 до 5, і клієнт протягом 3 секунд повторно викликав той самий запит користувача 7 разів. Тієї ночі частка недійсних викликів сягнула 41%. Ці гроші в рахунку не принесли жодної копійки бізнес-цінності.

Рішення дворівневе. Експоненційний відступ: перша невдача — чекаємо 500 мс, друга — 1 с, третя — 2 с, максимум 3 повторні спроби, після чого переходимо на резервний сценарій. Ключ ідемпотентності: кожен запит несе request_id, і сервер, і клієнт виконують дедуплікацію, той самий id протягом 60 секунд допускає лише один реальний виклик. Після змін недійсні виклики через повторні спроби скоротилися з 41% до менш ніж 6%. Цей пункт заощаджує близько 4200 юанів на місяць.

Чорна діра друга: довгий контекст не обрізається, історія діалогу повторно вставляється знову і знову

У сценаріях служби підтримки діалоги часто тягнуться до десятка з гаком раундів. Спочатку ми для простоти щоразу вставляли повну історію. Середній вхідний токен одного раунду діалогу зростав з 800 на 3-му раунді до 3400 на 12-му. Гірше те, що коли користувач питав «яка там була політика повернення коштів, про яку щойно йшлося», моделі насправді потрібні були лише останні 3 раунди плюс одне резюме, а ми вставляли всі 12.

Вирішили за допомогою ковзного вікна з компресією в резюме: зберігаємо оригінальний текст останніх 4 раундів, більш ранній діалог стискаємо одним легким викликом моделі до резюме не довше 150 символів, і резюме стає частиною system-контексту. Так вхідний токен 12-го раунду впав з 3400 до приблизно 1100, тобто на 67%. Тут є одна пастка: саме резюме теж витрачає токени, тому поріг спрацьовування компресії треба виставити правильно; ми на практиці виміряли, що компресія запускається лише після 6 раундів, і сукупна вартість найнижча.

Чорна діра третя: флагманська модель виконує роботу легкої моделі

Це найбільш прихований пункт. Усі запити в системі йшли через одну й ту саму флагманську модель, включно з привітаннями на кшталт «привіт», «на зв'язку», «зачекайте хвилинку». Я вивантажив логи викликів і зробив класифікацію — виявилося, що 62% запитів це розпізнавання намірів і прості запитання-відповіді, які зовсім не потребують флагманської моделі. Запуск їх на флагманській моделі коштує за один виклик у 8–12 разів дорожче, ніж на легкій моделі.

Рішення — маршрутизація за рівнями відповідно до завдання. Ми додали рівень правил у шлюзі моделей: класифікація намірів, привітання, влучання в FAQ ідуть на легку модель; лише складні завдання, як-от розрахунок повернення коштів, рекомендації курсів, ескалація скарг, маршрутизуються на флагманську модель. У нашому проєкті ми використовували token8341 для уніфікованого підключення кількох моделей: один Key дозволяє викликати GPT-4o, Claude, DeepSeek, Qwen та інші провідні моделі, автоматично обираючи оптимальну модель під завдання, без необхідності самому підтримувати кілька наборів SDK та автентифікації. Після розшарування частка викликів флагманської моделі впала зі 100% до 34%, а загальна вартість знизилася на 52%.

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

Чорна діра четверта: повторна оплата після переривання потокового виводу

Потоковий вивід (SSE) дуже поширений у сценаріях служби підтримки: користувачеві приємно бачити, як слова з'являються одне за одним. Але щойно мережа обривається і клієнт перепідключається, якщо сервер не робить відновлення з точки розриву, вже згенерований вміст генерується заново. Ми порахували: частка переривань потоку близько 3,7%, і кожне переривання в середньому повторно генерує 1200 токенів. За місяць ця повторна оплата становила 9% рахунку.

Рішення — компенсація обриву потоку: сервер записує зміщення (offset) уже згенерованих токенів для кожного потокового запиту, і коли клієнт перепідключається, він передає offset, а сервер продовжує з точки розриву, а не з початку. У поєднанні з ключем ідемпотентності повторна оплата падає до нуля. Цей пункт заощаджує близько 2000 юанів на місяць.

Контрольний список моніторингу витрат

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

1.Частка недійсних викликів: якщо перевищує 10%, перевіряйте повторні спроби та ідемпотентність;

2.Співвідношення середнього вхідного токена до середнього вихідного токена: якщо в сценарії служби підтримки перевищує 3:1, це означає, що контекст не обрізається;

3.Частка викликів флагманської моделі: якщо перевищує 40%, варто розглянути маршрутизацію за рівнями;

4.Частка переривань потоку: якщо перевищує 2%, треба робити відновлення з точки розриву;

5.Вартість одного ефективного діалогу: рахуйте за бізнес-метрикою, а не за метрикою API;

6.Частка влучань маршрутизації за завданням у шлюзі моделей: якщо нижче 60%, це означає, що правила погано налаштовані.

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

Автор: Чжоу Мінчже

Дата публікації: 23 жовтня 2026 року