Pourquoi les latences moyennes semblent-elles bonnes alors que l’IA interactive paraît lente ?
Les moyennes de latence peuvent sembler bonnes alors que l’IA interactive paraît lente, car les rares attentes prolongées et les pauses en série dominent les échanges dont les utilisateurs se souviennent.
Neuf requêtes locales peuvent commencer en 300 millisecondes tandis que la dixième attend cinq secondes le chargement du modèle ou l’exécution d’un outil. La moyenne reste inférieure à une seconde, mais la conversation semble régulièrement interrompue. La qualité de l’interaction dépend de la distribution et de la séquence des délais, et non d’une seule valeur centrale calculée sur des types de requêtes sans rapport avec l’interaction dont la personne se souvient.
La moyenne masque la forme de la distribution des délais
Une moyenne arithmétique regroupe toutes les requêtes en un seul nombre. Quelques échanges très lents peuvent être dilués par de nombreux accès au cache ou des invites courtes. Les percentiles révèlent à quelle fréquence les utilisateurs dépassent un seuil de délai, même si le p95 peut masquer le pour cent le plus lent.
La traîne de latence explique qu’une petite fraction de composants lents peut dominer la latence de l’ensemble d’une requête dans les systèmes à exécution parallèle. L’IA interactive attend de la même manière son étape obligatoire la plus lente.
La composition de la charge compte également. Les vérifications d’état et les appels de statut mis en cache ne devraient pas être inclus dans la même moyenne de latence que les échanges vocaux, la récupération RAG ou les actions d’outils. Une valeur agrégée faible peut être mathématiquement correcte et opérationnellement insignifiante.
Les utilisateurs perçoivent des étapes et des blocages, pas seulement l’achèvement
Un échange de chat comporte plusieurs horloges : attente en file, récupération, premier jeton, cadence des jetons, attente d’un outil et réponse finale. Un temps total court avec un long silence initial peut sembler pire qu’une réponse légèrement plus longue qui commence rapidement et s’affiche de manière régulière.
Une analyse de la latence distingue le temps jusqu’au premier jeton du temps de réponse complet, car ces mesures représentent différentes facettes du comportement du modèle. Les deux sont nécessaires pour décrire un échange interactif.
Les pauses visibles ont également un ordre. Un blocage d’outil après plusieurs jetons interrompt l’attention différemment de la même attente avant le premier jeton. Une moyenne calculée sur toutes les phases efface cette structure d’interaction et oriente l’optimisation vers le mauvais composant.
Quand les percentiles restent trompeurs
Les percentiles deviennent trompeurs lorsque l’outil de mesure cesse d’émettre des requêtes pendant les blocages, échantillonne uniquement les requêtes terminées ou agrège des fenêtres temporelles sans rapport. Cette omission coordonnée peut sous-estimer précisément les délais rencontrés par les utilisateurs sous charge.
L’analyse de Gil Tene sur l’omission coordonnée montre pourquoi les tests de charge doivent respecter le calendrier prévu des requêtes au lieu de ralentir les soumissions lorsque le système ralentit. Sinon, les distributions de latence semblent artificiellement bonnes.
L’explication de la latence de queue cesse également de s’appliquer si chaque trace de phase est rapide, mais que les utilisateurs signalent toujours une lenteur. Le rendu de l’interface, la mise en tampon du réseau ou un retour retardé peuvent se situer en dehors de la limite du serveur mesurée. Ajouter des tableaux de bord de percentiles ne sert à rien lorsque l’horloge démarre trop tard ou s’arrête trop tôt.
Suivez les étapes que les utilisateurs attendent réellement
Instrumentez la mise en file, le début de l’exécution, la fin de la récupération, le premier jeton, chaque appel d’outil, le dernier jeton et le rendu côté client avec un identifiant de trace monotone unique. Indiquez p50, p95, p99, le maximum et le taux de dépassement des seuils par type d’interaction et selon qu’il s’agit d’un état à froid ou à chaud.
Utilisez les traces des démarrages à froid de l’IA pour distinguer le chargement à froid de l’inférence en régime stable. Conservez les échanges échoués et annulés dans l’ensemble de données au lieu d’exclure leurs temps d’attente.
Rejouez les requêtes selon un calendrier prévu fixe et comparez les étapes visibles côté client à celles visibles côté serveur. Optimisez la phase responsable du percentile lent. Si les traces serveur et client divergent, examinez le transport et le rendu ; si seuls les échanges à froid présentent un pic, corrigez le chargement plutôt que la génération en régime stable.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi la chaleur produite par l’IA locale semble-t-elle différente sur une étagère ouverte que dans une armoire fermée ?
Suivez la génération de chaleur, les échanges d’air et la recirculation dans des installations ouvertes et fermées, puis mesurez les variables qui les différencient.
Pourquoi un serveur domestique semble-t-il plus silencieux la nuit, même à la même vitesse de ventilation ?
Comprenez pourquoi une vitesse de ventilateur inchangée ne garantit pas un niveau sonore perçu inchangé, et comment distinguer le masquage, les conditions de la...
Pourquoi les sauvegardes dédupliquées paraissent-elles plus petites que leur empreinte de restauration ?
Découvrez comment la déduplication modifie le nombre d’octets stockés sans changer le sens des données restaurées, pourquoi les fichiers creux et compressés compliquent les...
