Un agent LLM en production : ce que personne ne dit sur la latence

En démo, l'agent répond vite. En production, sur un cas réel, la même requête traîne. L'écart n'est presque jamais dans le modèle lui-même : il est dans tout ce qui l'entoure. La démo montre le meilleur chemin ; la production emprunte tous les autres.

Décomposer la latence

La première erreur est de parler de « la latence » au singulier. Un appel réel est une somme : établissement de la connexion réseau, temps d'attente en file, appels d'outils intermédiaires, allers-retours de l'agent avec lui-même, sérialisation des réponses. Le modèle n'est qu'un terme de cette somme, souvent pas le plus gros.

Tant qu'on ne mesure pas chaque segment séparément, on optimise à l'aveugle. La première chose à instrumenter n'est pas le modèle, c'est le découpage du temps entre l'entrée de la requête et la sortie finale.

Les optimisations qui paient vraiment

Trois leviers ont un effet visible, dans cet ordre d'impact :

• Le streaming vers l'utilisateur. Afficher la réponse au fil de sa génération ne réduit pas le temps total, mais il effondre la latence perçue - celle qui compte pour l'usage. C'est le meilleur rapport effort/effet.
• La parallélisation des appels d'outils. Un agent qui interroge trois sources les enchaîne souvent en série par défaut. Les lancer en parallèle quand ils sont indépendants supprime les temps morts additionnés.
• Le cache. Prompts système stables, résultats d'outils déterministes, requêtes répétées : tout ce qui peut être mémorisé évite un aller-retour complet.

Les optimisations qui ne servent à rien

À l'inverse, beaucoup d'efforts se dissolvent sans effet mesurable : raccourcir le prompt de quelques mots, changer de modèle pour grappiller deux centièmes, micro-optimiser du code qui pèse pour 1 % du temps total. Ces chantiers rassurent parce qu'ils sont concrets, mais ils s'attaquent au mauvais terme de la somme.

Ce que je surveille en production

Une moyenne de latence ment. Ce qui compte, c'est la queue de distribution : le p95, le p99, ce que vit l'utilisateur malchanceux. À côté, je surveille le taux d'échec des appels d'outils - un outil qui échoue puis réessaie double silencieusement la latence - et le budget de tokens, parce qu'un prompt qui gonfle au fil des itérations finit par coûter du temps autant que de l'argent.

La conclusion tient en une image : une démo optimise le chemin heureux, une mise en production doit tenir sur tous les chemins. La latence n'est pas un chiffre, c'est une distribution - et c'est sa queue qu'on met en ligne.