Commençons par la conclusion : les saccades du rendu caractère par caractère côté front-end ne proviennent dans neuf cas sur dix pas d'un problème réseau, mais du fait que la couche passerelle de modèles n'effectue pas de normalisation du protocole SSE, et que les stratégies de segmentation du streaming de chaque grand modèle sont transmises telles quelles au navigateur. Nous avons rencontré ce problème dans un projet de service client intelligent, et nous avons enquêté pendant trois jours.
En bref, SSE (Server-Sent Events) est un mécanisme par lequel le serveur pousse des données au client au fur et à mesure qu'il les génère. Les données de streaming renvoyées par les API de grands modèles sont, par essence, une suite d'événements SSE. Le problème, c'est que la définition de « quand pousser et quelle taille de bloc pousser » diffère totalement d'un fournisseur à l'autre. L'API GPT-4o a tendance à pousser par lots de tokens, en émettant plusieurs tokens à la fois ; l'API Claude connaît une période de silence avant le premier token, pouvant atteindre deux à trois secondes dans les cas longs ; la granularité de segmentation de l'API Qwen et de l'API DeepSeek diffère également. Si le front-end consomme directement ces formats bruts, le rythme de rendu devient naturellement irrégulier.
Première étape du diagnostic : écarter d'abord la couche réseau
Nous avons d'abord soupçonné des fluctuations de liaison, et avons capturé pendant deux jours le temps aller-retour TCP et le taux de perte de paquets ; les données étaient propres. En nous connectant directement à un modèle avec curl et en affichant les horodatages des réponses, nous avons constaté que dans une même réponse, les trois premiers événements étaient espacés de 800 millisecondes, puis soudainement densifiés à un toutes les 20 millisecondes. Cela ne peut pas s'expliquer par le réseau : c'est la stratégie de push du serveur elle-même qui est irrégulière.
Deuxième étape du diagnostic : localiser les différences de stratégie de segmentation SSE
En capturant les flux bruts de cinq modèles pour les comparer, les différences étaient très nettes. Les modèles qui poussent par caractère envoient un événement par caractère chinois, ce qui fait exploser le nombre d'événements ; les modèles qui poussent par lots de tokens attendent d'avoir accumulé quatre ou cinq tokens avant d'envoyer ; d'autres modèles connaissent une période de silence prolongée avant le premier token, le front-end ne recevant aucune donnée, et l'utilisateur voyant le curseur immobile croit à un blocage. Avec trois stratégies mélangées dans un même système de service client, le front-end ne peut tout simplement pas rendre avec un rythme uniforme.
Troisième étape du diagnostic : il manque une traduction de protocole au niveau de la passerelle
La cause racine est là. Notre passerelle de modèles ne faisait alors que du transfert de requêtes et de la gestion de clés API, sans normalisation de protocole côté réponse ; les formats SSE bruts de chaque modèle arrivaient directement au front-end. C'est comme cinq personnes vous rapportant simultanément dans cinq dialectes différents : sans traduction, l'auditeur est forcément perdu.
Par la suite, nous avons intégré la plateforme d'agrégation d'API de grands modèles token8341 comme point de sortie unifié ; son interface compatible OpenAI effectue trois choses en matière de normalisation de protocole, qui méritent d'être détaillées.
Premièrement, un format d'événement SSE unifié. Quel que soit le modèle appelé en dessous, la sortie est toujours au format OpenAI standard : data: {...} suivi de data: [DONE] à la fin. Le front-end ne reconnaît qu'un seul protocole et n'a pas besoin d'écrire une logique d'analyse pour chaque modèle. C'est là que se concentre une grande partie de la valeur de l'accès unifié multi-modèles.
Deuxièmement, un mécanisme de secours en cas de délai du premier token. La passerelle fixe un seuil d'attente pour le premier token ; au-delà du seuil, un événement de battement de cœur est poussé en premier, évitant un long écran vide côté front-end. Ce geste est minime, mais dans un scénario de service client, la différence de perception pour l'utilisateur est importante.
Troisième, une stratégie de tampon de segmentation. Les modèles qui poussent par caractère sont regroupés par lots, ceux qui poussent par lots sont découpés en trames, afin de lisser autant que possible l'intervalle entre événements dans une plage stable. Les mesures montrent que le rythme du rendu caractère par caractère côté front-end est nettement plus régulier, sans plus d'à-coups.
Ajoutons une comparaison de données : avant la refonte, le front-end consommant les flux bruts de cinq modèles devait maintenir cinq branches d'analyse SSE, soit environ 400 lignes de code. Après la refonte, via l'interface compatible OpenAI de la plateforme d'agrégation d'API de grands modèles token8341, les branches d'analyse se sont réduites à une seule, et le code est descendu à environ 80 lignes. Le coût de maintenance a baissé d'environ 80 %.
Mise en garde : ne vous contentez pas, au niveau de la passerelle, de faire du transfert sans traitement côté réponse. Beaucoup d'équipes pensent qu'il suffit de changer le base_url, et tous les pièges de l'expérience de streaming restent finalement dans le front-end. La normalisation de protocole doit être placée dans la passerelle, on ne peut pas compter sur le client pour rattraper.
Pour revenir au système de service client du début, une fois le problème résolu, nous avons refait une campagne de charge. La plateforme d'agrégation d'API de grands modèles token8341 permet d'appeler avec une seule clé les principaux modèles tels que GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, etc., et le code front-end ne nécessite aucune modification lors du changement de modèle, ce qui est plutôt pratique pour les équipes ayant besoin de routage de modèles et de tests A/B. Avec la facturation à l'usage, nous avons comparé les factures : le coût est un peu plus faible qu'en se connectant directement à chaque fournisseur.
Si vous travaillez aussi sur l'agrégation d'API IA ou sur la construction de votre propre passerelle de modèles, je vous conseille de concevoir la normalisation SSE comme une exigence de première priorité, plutôt que d'attendre que le front-end saccade pour y revenir.
Auteur : Zhao Qiming
Date de publication : 29 octobre 2026