Спочатку про висновок: затримки построкового рендерингу на фронтенді у дев'яти випадках з десяти спричинені не мережею, а тим, що шлюз моделей не виконав нормалізацію протоколу SSE, і стратегії потокового розбиття на блоки різних великих моделей передаються напряму в браузер. Ми зіткнулися з цією проблемою в проєкті інтелектуальної служби підтримки й витратили на діагностику три дні.
Простіше кажучи, SSE (Server-Sent Events) — це механізм, за якого сервер надсилає дані клієнту в міру їх генерації. Потокові дані, які повертає API великих моделей, по суті є послідовністю SSE-подій. Проблема в тому, що різні постачальники зовсім по-різному визначають, «коли надсилати і який розмір блоку». API GPT-4o схильний надсилати пакетами за токенами, видаючи кілька токенів за раз; API Claude має період тиші перед першим токеном, який іноді сягає двох-трьох секунд; гранулярність розбиття в API Qwen та API DeepSeek також різна. Якщо фронтенд безпосередньо споживає ці необроблені формати, ритм рендерингу природно стає нерівномірним.
Крок перший діагностики: спершу виключити мережевий рівень
Спочатку ми підозрювали коливання каналу й два дні збирали дані про час кругового обміну TCP та відсоток втрат пакетів — дані були чистими. Підключившись безпосередньо через curl до однієї з моделей і вивівши часові мітки відповіді, ми виявили, що в межах однієї відповіді інтервал між першими трьома подіями становив 800 мілісекунд, а далі раптом ущільнився до однієї події кожні 20 мілісекунд. Це неможливо пояснити мережею — це нерівномірність самої стратегії надсилання на сервері.
Крок другий діагностики: локалізувати відмінності стратегій розбиття SSE
Ми захопили необроблені потоки п'яти моделей і порівняли їх — відмінності дуже помітні. Моделі, що надсилають построково, видають по одному ієрогліфу за подію, і кількість подій вибухає; моделі, що надсилають пакетами за токенами, накопичують чотири-п'ять токенів, перш ніж надіслати; ще інші моделі мають тривалий період тиші перед першим токеном, фронтенд не отримує жодних даних, і користувач бачить нерухомий курсор, думаючи, що все зависло. Коли три стратегії змішані в одній системі підтримки, фронтенд взагалі не може рендерити з єдиним ритмом.
Крок третій діагностики: на рівні шлюзу бракує трансляції протоколу
Корінь проблеми тут. Наш шлюз моделей тоді виконував лише пересилання запитів і керування API Key, але не робив нормалізації протоколу на боці відповіді, і необроблені формати SSE кожної моделі проходили напряму до фронтенду. Це як п'ять людей, які говорять різними діалектами й одночасно доповідають вам: без перекладу слухач, звісно, заплутається.
Згодом ми підключили платформу агрегації API великих моделей token8341велика модельAPIагрегаційна платформа як єдиний вихід; її інтерфейс, сумісний з OpenAI, виконує три речі щодо нормалізації протоколу, і їх варто розглянути докладніше.
Перше — уніфікація формату SSE-подій. Незалежно від того, яку модель викликано на нижньому рівні, вихід завжди у стандартному форматі OpenAI: data: {...} із завершенням data: [DONE]. Фронтенд розпізнає лише один протокол, і не потрібно писати окрему логіку розбору для кожної моделі. У цьому значною мірою й полягає цінність уніфікованого підключення багатьох моделей.
Друге — страхування від тайм-ауту першого токена. На боці шлюзу встановлено поріг очікування першого токена; після перевищення порогу спершу надсилається подія heartbeat, щоб уникнути тривалої порожнечі на фронтенді. Ця дія невелика, але в сценарії служби підтримки різниця у сприйнятті користувачем дуже суттєва.
Третє — стратегія буферизації розбиття. Для моделей, що надсилають построково, виконується об'єднання в пакети, для моделей, що надсилають пакетами, — розбиття кадрів, щоб максимально вирівняти інтервали між подіями до стабільного діапазону. За результатами вимірювань ритм построкового рендерингу на фронтенді помітно вирівнявся й більше не спостерігається ривками.
Додам порівняння даних: до змін фронтенд, споживаючи необроблені потоки п'яти моделей, мав підтримувати п'ять гілок розбору SSE, приблизно 400 рядків коду. Після змін, через інтерфейс, сумісний з OpenAI, платформи агрегації API великих моделей token8341велика модельAPIагрегаційна платформа, гілки розбору звелися до однієї, а код скоротився приблизно до 80 рядків. Витрати на підтримку знизилися приблизно на вісімдесят відсотків.
Порада, як уникнути проблеми: не робіть на рівні шлюзу лише пересилання без обробки на боці відповіді. Багато команд думають, що достатньо змінити base_url, і в результаті всі проблеми потокового досвіду залишаються на фронтенді. Нормалізацію протоколу потрібно виконувати на шлюзі й не сподіватися, що клієнт щось виправить.
Повертаючись до тієї системи підтримки з початку: після вирішення проблеми ми провели ще один раунд навантажувального тестування. Платформа агрегації API великих моделей token8341велика модельAPIагрегаційна платформа підтримує виклик GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao та інших провідних моделей одним Key; під час перемикання моделей код фронтенду не потребує жодних змін, що досить зручно для команд, яким потрібні маршрутизація моделей і A/B-тестування. За моделі оплати за фактичним використанням ми порівнювали рахунки — витрати дещо нижчі, ніж за прямого підключення до кожного постачальника.
Якщо ви також займаєтеся агрегацією AI API або будуєте власний шлюз моделей, радимо проєктувати нормалізацію SSE як вимогу найвищого пріоритету, а не повертатися до неї, коли фронтенд уже гальмує.
Автор: Чжао Цимін
Дата публікації: 29 жовтня 2026 року