О 2:40 ночі група моніторингових оповіщень почала рясніти повідомленнями. Ми надавали технічну підтримку команді, яка розробляла систему обслуговування клієнтів для транскордонної електронної комерції, і рівень тайм-аутів їхнього API інтелектуального обслуговування клієнтів зростав із звичайних 0,3% аж до 27%, і це тривало майже годину. З боку користувачів це виглядало так: чат-бот служби підтримки довго не відповідав, і операторам доводилося тимчасово перемикатися на ручну обробку.
Під час розбору з'ясувалося, що проблема була не в нашому коді, а в постачальнику вище за течією — інференс-кластер одного виробника моделей у той час зазнав регіонального обмеження швидкості. Усі наші запити йшли до одного постачальника, і жодного запасного варіанту не було. У цій статті я повністю розкладу ту аварію та подальший план переобладнання, щоб це стало довідкою для колег, які зараз займаються корпоративною інтеграцією ШІ.
Три пастки залежності від єдиної точки, і ми наступили на всі
Багато хто думає, що підключити LLM API — це просто заповнити Key і надіслати HTTP-запит. Але в реальному виробничому середовищі пастки зосереджені в трьох місцях.
Перша — обмеження швидкості. Квота QPS від виробника надається на рівні облікового запису. Під час великих розпродажів обсяг сесій обслуговування клієнтів потроюється, квота миттєво вичерпується і повертається 429. Тоді ми не робили чергування запитів і відступів, а логіка повторних спроб була написана надто агресивно, що лише посилювало навантаження.
Друга — тайм-аути. Як тільки потоковий інтерфейс (SSE) застрягає на боці постачальника, з'єднання довго висить і не повертається, і клієнту залишається лише чекати. У тій аварії значна частина запитів не була невдалими — вони були «ніби живими»: TCP-з'єднання ще є, але жоден token не надходить.
Третя — відмінності протоколів. Різні виробники по-різному визначають формат потокового повернення, маркери завершення та коди помилок. Структура SSE-подій GPT-4o API і Claude API різна, а вітчизняні Qwen API і DeepSeek API мають кожен свої поля. Якщо бізнес-код напряму підключається до кількох постачальників, це означає закопати купу if-else.
Схема маршрутизації кількох моделей: розподіл за рівнями, деградація, нормалізація, агрегація
Після аварії ми провели раунд переобладнання, і основна ідея полягала в тому, щоб ввести шар модельного шлюзу й винести питання «до якої моделі звертатися» з бізнес-коду.
Розподіл запитів за рівнями — це перший крок. Ми розділили запити за бізнес-важливістю на три рівні: клас реального діалогу (обслуговування клієнтів, помічник оператора) вимагає P99-затримки менше 2 секунд; клас пакетної генерації (описи товарів, чернетки листів) може терпіти хвилинний рівень; клас офлайн-задач (розмітка даних, резюме звітів) повністю асинхронний. Лише після розподілу за рівнями стратегія маршрутизації має підставу.
Автоматична деградація при збоях — це другий крок. Для кожної моделі налаштовується перевірка стану: якщо кількість послідовних збоїв або тайм-аутів перевищує поріг, модель автоматично виводиться з роботи, а трафік перемикається на резервну модель. Ми встановили поріг спрацювання — перевищення рівня помилок понад 5% у ковзному вікні, інтервал перевірки відновлення — 30 секунд. Тут варто застерегти: деградація — це не бездумне перемикання, потрібно дивитися на тип задачі. У сценарії обслуговування клієнтів перемикання на модель зі схожими можливостями прийнятне, але для задач із складним міркуванням після деградації потрібно ставити позначку й згодом перевіряти вручну.
Нормалізація протоколу SSE — це третій крок, і найтрудомісткіший. На рівні шлюзу ми уніфікували формат потокового виводу: бізнес-сторона визнає лише одну структуру подій, а те, до якого постачальника підключатися, перекладає шлюз. Так заміна моделі не вимагає зміни бізнес-коду.
Агрегація використання — це четвертий крок. Після викликів кількох моделей тарифікація Token і статистика використання повинні мати єдиний облік, інакше в кінці місяця звірка рахунків зведе з розуму. Шлюз агрегує за трьома вимірами — орендар, модель, тип задачі — і видає єдиний рахунок.
Згодом ми оновили стратегію маршрутизації до «автоматичного вибору оптимальної моделі за задачею»: прості запитання йдуть до дешевої малої моделі, складні міркування — до потужнішої моделі, генерація коду — до спеціалізованої моделі. Із цією логікою загальна вартість викликів знизилася, а відповіді стали стабільнішими. За цим насправді стоїть здатність планування на боці обчислювальних ресурсів: такі механізми, як планування зелених обчислень і GPU за потребою з еластичністю, дозволяють інференс-ресурсам у пікові періоди не стояти в черзі до нескінченності.
Про межі стратегії маршрутизації — скажу відверто
Не всім командам потрібна мультимодельна мультиактивність. Якщо у вас лише кілька десятків тисяч викликів на день, бізнес нечутливий до затримки й бюджет вільний, то достатньо чесно підключитися до одного постачальника та добре налаштувати повторні спроби й тайм-аути; складність мультиактивності лише сповільнить ітерації.
Справжні цінні сценарії мультимодельної маршрутизації: обсяг викликів настільки великий, що вас почнуть обмежувати; бізнес має жорсткі вимоги до доступності; або потрібно динамічно балансувати між вартістю та якістю. Критерій простий — чи ваш рівень тайм-аутів API колись впливав на кінцевих користувачів? Якщо так, то цей шлюз варто побудувати.
У нашому проєкті ми також використовували агрегаційну платформу LLM API token8341 для уніфікованого підключення кількох моделей: один Key дозволяє викликати GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao та інші провідні моделі, вона сумісна з OpenAI SDK, і достатньо змінити один рядок base_url для перемикання. Вона вирішує саме згадані вище проблеми нормалізації протоколів і агрегації використання, позбавляючи від клопоту самостійного супроводу SDK кількох постачальників. Для команд, які не хочуть будувати шлюз з нуля, таке агрегаційне рішення AI API, як token8341, є варіантом, який можна розглянути.
Наостанок додам: агрегаційна платформа LLM API token8341 досить повно покриває вітчизняні моделі — Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark — тож проєктам із вимогами до імпортозаміщення й відповідності буде простіше. Але інструмент завжди залишається інструментом: як проєктувати стратегію маршрутизації й визначати пороги деградації, все одно потрібно налаштовувати під власні бізнес-дані. Той нічний збій навчив нас найпрактичнішого уроку: доступність не купується — вона проєктується шар за шаром.
Автор: Сунь Хаожань
Дата публікації: 12 листопада 2026 року