Le streaming ne rend pas votre modèle plus rapide. Il rend l'attente plus courte en apparence. Le temps total de génération d'une réponse est presque identique, que vous la diffusiez en streaming ou non. Ce que le streaming change, c'est le moment où l'utilisateur voit le premier token, et ce seul chiffre, le temps jusqu'au premier token, pilote toute la perception de vitesse. Traitez le streaming comme une décision d'UX, parce que c'est ce que c'est, et vous ferez de meilleurs choix sur quand l'utiliser et quand il nuit activement.

Le réflexe est de se tourner vers InvokeModelWithResponseStream ou ConverseStream parce que le streaming ressemble au choix performant. Mais le modèle produit les mêmes tokens dans le même temps total, dans un cas comme dans l'autre. Vous n'optimisez pas le débit. Vous décidez si un humain fixe un écran vide pendant six secondes ou regarde du texte apparaître après trois cents millisecondes.

Pourquoi le temps jusqu'au premier token est le chiffre qui compte

Une réponse non diffusée en streaming a une seule latence ressentie par l'utilisateur : toute la génération, du début à la fin. Demandez trois paragraphes et l'utilisateur attend tout avant que quoi que ce soit n'apparaisse. Cette attente se lit comme un système lent, même quand le temps total est correct.

Le streaming divise cela en deux chiffres. Le temps jusqu'au premier token est le délai avant que quelque chose n'apparaisse. Ensuite, les tokens arrivent en continu, et parce que les gens lisent plus lentement qu'un modèle ne génère, le texte a tendance à rester en avance sur le lecteur. L'expérience perçue est « instantanée et fluide » même si le temps total de génération n'a pas bougé. C'est la même psychologie qu'une barre de progression : le mouvement se lit comme un progrès, et un écran vide se lit comme un blocage. Pour tout ce qui est conversationnel, où une personne lit la sortie comme de la prose, le streaming est quasiment obligatoire pour cette seule raison.

Où le streaming aggrave silencieusement les choses

Le streaming est une option par défaut, pas une loi. Plusieurs cas courants sont mieux servis en attendant la réponse complète.

Une sortie structurée que le client doit parser

Si la réponse est du JSON que votre frontend désérialise, un flux partiel est inutile ou nuisible. Vous ne pouvez pas parser la moitié d'un objet JSON, et montrer à l'utilisateur une structure à moitié construite est pire que lui montrer un indicateur de chargement. Quand le consommateur de la sortie est du code, pas un lecteur, attendez le tout et parsez-le une fois. Le streaming ne vous apporte rien et ajoute le risque d'afficher un état partiel mal formé.

L'usage d'outils à l'intérieur d'un agent

Quand un modèle diffuse en streaming une décision d'appeler un outil, il n'y a rien à lire pour l'utilisateur : la « sortie » est un appel d'outil, pas de la prose. Diffuser en streaming les tokens d'un appel de fonction vers l'interface montre à l'utilisateur une mécanique qu'il n'a pas demandé à voir. Le bon schéma est de diffuser en streaming la réponse finale destinée à l'utilisateur et de garder le raisonnement intermédiaire d'appel d'outil hors de l'écran, ou de le représenter par un statut comme « vérification de votre commande », pas comme des tokens bruts diffusés.

Les réponses courtes

Si la réponse tient en une phrase, le streaming ajoute de la complexité de protocole pour un gain imperceptible. Le tout arrive en quelques centaines de millisecondes dans les deux cas. Réservez la plomberie de streaming aux réponses assez longues pour que l'attente serait autrement ressentie.

Le coût que vous assumez en diffusant en streaming

Le streaming n'est pas gratuit en ingénierie. Vous maintenez une connexion ouverte pendant toute la durée, ce qui change votre façon de penser les timeouts, les retries, et l'équilibrage de charge. La gestion des erreurs devient plus difficile : un échec à mi-chemin d'un flux laisse l'utilisateur avec une réponse tronquée que vous devez détecter et récupérer, contre un échec propre et complet sur un appel bufferisé. Et vous ne pouvez pas exécuter une vérification de sortie Guardrails ou une validation JSON sur une réponse que vous avez déjà montrée à l'utilisateur token par token. Si la validation compte, soit vous bufferisez, soit vous validez au fil du streaming et vous êtes prêt à rétracter, ce qui représente un vrai travail. Pesez cela contre le gain d'UX plutôt que de supposer que le streaming est strictement meilleur.

Baissez le chiffre plutôt, parfois

Si le problème est réellement que le premier token met trop de temps à arriver, le streaming le cache mais ne le corrige pas. Le cache de prompt, lui, le corrige : mettre en cache le préfixe stable d'un long prompt réduit le temps avant que la génération ne commence, ce qui abaisse directement le temps jusqu'au premier token. Sur un agent fortement promptifié, élaguer et mettre en cache le prompt peut faire davantage pour la vitesse perçue que le streaming, et cela aide aussi les cas non streamés et structurés.

Ce qu'il faut retenir

Le streaming ne change pas la vitesse à laquelle votre modèle tourne. Il change le temps jusqu'au premier token, ce qui change la vitesse ressentie du système, donc c'est une décision d'UX. Diffusez en streaming la prose conversationnelle qu'un humain lit. Ne diffusez pas en streaming une sortie structurée qu'un client doit parser, le raisonnement brut d'appel d'outil, ou des réponses d'une ligne. Et quand la latence du premier token est la vraie plainte, mettez le prompt en cache pour baisser le chiffre plutôt que de diffuser en streaming pour le masquer.

À lire ensuite

Pour l'infrastructure derrière les connexions longue durée et la latence en périphérie, les notes de terrain cloud sont sur ercan.cloud, et le hub est sur ercanermis.com.