La latence LLM se réduit surtout en supprimant du travail inutile. Moins de tokens, moins d’appels, des modèles plus petits, du cache bien pensé. Je vois souvent le même piège chez les clients : le prototype marche, puis la prod expose tout ce qu’on n’a pas mesuré.
Que faut-il mesurer en premier ?
Il faut mesurer la latence LLM par morceaux, pas seulement avec un temps global. Le temps end-to-end est utile, oui, mais il mélange trop de choses. Il peut cacher un modèle lent, un prompt trop gros, un RAG qui ramène trop de contexte, un outil externe poussif, ou juste une file d’attente qui commence à gonfler.
Je découpe toujours la mesure. D’abord le temps en file d’attente, parce qu’il montre si votre infra suit la charge. Ensuite le time to first token, c’est le temps avant que le premier mot arrive. C’est souvent ce que l’utilisateur ressent le plus. Puis l’inter-token latency, le délai entre deux tokens générés. Un token, c’est un morceau de texte manipulé par le modèle, parfois un mot, parfois une partie de mot.
Comment structurer les sorties LLM avec Outlines ?
Je regarde aussi le nombre de tokens en entrée et en sortie. Si l’entrée explose, votre prompt ou votre RAG est probablement trop lourd. Si la sortie est trop longue, le modèle passe juste du temps à écrire. Le taux de cache compte aussi, parce qu’un cache bien utilisé évite de recalculer toujours les mêmes préfixes ou les mêmes réponses.
Pour les systèmes avec RAG ou agents, je mesure séparément la latence du retrieval, donc la recherche dans la base documentaire, et la latence des appels outils, comme une API CRM, une base SQL ou un service métier. J’ai déjà vu un agent accusé d’être lent alors que le vrai coupable était une API externe qui répondait en 4 secondes.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Et surtout, je ne regarde jamais seulement la moyenne. Sur le terrain, c’est là que les équipes se font piéger. La démo semble fluide, tout va bien à 2 utilisateurs. Puis la prod arrive, les files d’attente apparaissent, et le vrai problème se cache en P95 ou P99. P50, c’est l’utilisateur médian. P95 et P99, ce sont les cas lents, ceux qui créent les tickets support.
| Métrique | Ce qu’elle montre | Action possible |
| Temps en file d’attente | Pression sur l’infrastructure, batching mal réglé, saturation GPU ou mémoire. | Ajuster le batching, scaler, réduire la concurrence. |
| Time to first token | Temps avant la première réponse visible. | Alléger le prompt, utiliser un modèle plus rapide, activer le streaming. |
| Inter-token latency | Vitesse réelle de génération token par token. | Changer de modèle, réduire la sortie attendue, optimiser l’inférence. |
| Tokens en entrée | Prompt trop lourd ou RAG trop volumineux. | Compresser le contexte, filtrer les documents, nettoyer le prompt. |
| Tokens en sortie | Réponses trop longues et coûteuses. | Limiter la longueur, cadrer le format, demander une réponse plus concise. |
| Taux de cache | Réutilisation des calculs ou réponses. | Mettre en cache les préfixes, les résultats RAG ou les réponses fréquentes. |
| Latence retrieval | Lenteur de recherche documentaire. | Optimiser l’index, réduire le top-k, améliorer le reranking. |
| Latence appels outils | APIs externes ou bases métier trop lentes. | Ajouter timeout, cache, appels parallèles ou fallback. |
| P50, P95, P99 | Expérience normale et cas vraiment pénibles. | Piloter les optimisations sur les percentiles hauts, pas sur la moyenne. |
Pourquoi réduire les tokens générés ?
Comment fonctionnent les VLMs modernes en IA ?
Les tokens de sortie coûtent cher en temps et en argent parce que le modèle les génère un par un. Plus il écrit, plus vous attendez, et plus la facture monte. C’est bête, mais en prod, c’est souvent là que je vois le plus de gaspillage.
Beaucoup d’applications LLM perdent de la latence avec des réponses trop longues. Des résumés inutiles. Des disclaimers répétés. Des reformulations automatiques du type “Voici la réponse à votre question”. Des formats verbeux alors que le système derrière attend juste trois champs propres.
Le but n’est pas de rendre l’IA sèche ou désagréable. Le bon objectif, c’est de produire exactement ce dont l’utilisateur ou le système a besoin, pas plus.
- Limiter max_tokens pour éviter qu’une réponse parte en roman quand 80 mots suffisent.
- Demander explicitement une réponse concise, par exemple “Réponds en 3 phrases maximum”.
- Proposer un mode bref et un mode détaillé, parce que tout le monde n’a pas besoin du même niveau d’explication.
- Utiliser des séquences d’arrêt, c’est-à-dire des marqueurs qui disent au modèle où s’arrêter.
- Éviter les conclusions automatiques comme “N’hésitez pas si vous avez d’autres questions”. Ça consomme, et souvent ça ne sert à rien.
- Supprimer les phrases de remplissage qui donnent une impression de politesse mais n’ajoutent aucune information.
- Préférer un JSON compact quand la sortie est destinée à une machine. JSON, c’est un format structuré clé-valeur, très pratique pour envoyer le résultat à une API ou une base de données.
| Cas | Bonne sortie |
| Extraction de données | Uniquement les champs demandés, sans explication. |
| FAQ client | Deux ou trois phrases claires, pas un article complet. |
| Réponse JSON | Seulement les clés utiles, sans champs vides ou décoratifs. |
Quels algorithmes machine learning utiliser ?
Avant : “Rédige une réponse complète et détaillée à la question de l’utilisateur, avec une introduction, des explications et une conclusion.”
Après : “Réponds en 60 mots maximum. Donne uniquement la réponse utile. Pas d’introduction. Pas de conclusion. Format : problème, réponse, action.”
Chaque token évité est une petite économie. À l’échelle d’un appel, ça paraît minime. En production, avec des milliers ou des millions de requêtes, ça devient vite visible sur la latence et sur la facture.
Quel modèle choisir pour chaque demande ?
Quels frameworks Python pour agents IA locaux ?
Il faut envoyer chaque demande au plus petit modèle capable de répondre correctement. Tous les cas d’usage ne méritent pas le plus gros modèle disponible, surtout quand la tâche est répétitive, cadrée ou facilement vérifiable.
Je vois souvent le même réflexe en production : on branche le meilleur modèle partout “pour être tranquille”. Ça marche, oui. Mais on paie trop cher, et on ajoute de la latence là où ce n’est pas utile.
Les tâches simples peuvent souvent passer sur un modèle plus petit :
- Analyse de sentiment : positif, neutre, négatif.
- Extraction de champs : nom, date, montant, email, référence client.
- Modération simple : insulte, spam, contenu sensible évident.
- Réécriture de requête : reformuler une question pour une recherche interne.
- FAQ cadrée : répondre sur un périmètre bien défini.
- Génération de JSON structuré : produire un format attendu et validable.
- Summarisation basique : résumer un texte court sans interprétation fine.
Les grands modèles doivent rester disponibles pour les cas difficiles. Quand il y a du raisonnement, une forte ambiguïté, une demande longue, un contexte RAG incertain ou un enjeu qualité élevé, là oui, je préfère escalader. Le RAG, c’est quand on donne au modèle des documents récupérés depuis une base de connaissance. Si ces documents sont peu pertinents, le modèle doit souvent compenser, et ça demande plus de capacité.
Le pattern simple, c’est celui-ci : je qualifie d’abord la requête, j’envoie vers un modèle économique si la demande est simple, puis j’escalade vers un modèle plus puissant si la confiance est faible ou si la complexité augmente.
Les signaux utiles sont assez concrets :
- Longueur du prompt.
- Type de tâche demandé.
- Qualité du retrieval, donc la pertinence des documents retrouvés.
- Niveau utilisateur ou criticité du compte.
- Classifieur léger en amont.
- Score de confiance du modèle.
- Présence d’ambiguïtés ou de consignes contradictoires.
Je le dis franchement : le routage ne doit pas devenir une usine à gaz. Chez un client, on a gagné beaucoup juste avec trois règles simples. Pas besoin d’un système parfait dès le départ. Le vrai gain vient souvent de la première séparation propre entre “simple” et “complexe”.
| Type de tâche | Modèle recommandé | Critère d’escalade |
| Extraction de champs | Petit modèle | JSON invalide ou champ ambigu |
| Analyse de sentiment | Petit modèle | Texte ironique ou très contextuel |
| FAQ cadrée | Petit ou moyen modèle | Réponse absente dans la base |
| Résumé basique | Petit ou moyen modèle | Document long ou enjeu métier fort |
| Raisonnement complexe | Grand modèle | Déjà escaladé par défaut |
Comment éviter trop d’appels LLM ?
Il faut réduire les appels séquentiels et remplacer tout ce qui peut l’être par du code déterministe. Un LLM, donc un modèle de langage, doit rester là où il apporte vraiment de la valeur : comprendre, raisonner un peu, générer du texte utile. Pas pour faire le boulot d’un script.
Je vois souvent des workflows agents devenir lents parce qu’ils empilent les étapes : classification, réécriture, retrieval, c’est-à-dire recherche de contexte, summarisation, génération, critique, puis réécriture. Sur le papier, ça fait sérieux. En prod, chaque appel ajoute du coût, de la latence, et parfois de l’instabilité. Un appel peut mal interpréter, le suivant amplifie, et à la fin on debug une chaîne au lieu de debug une sortie.
Quand deux étapes sont proches, je préfère souvent les fusionner dans un seul prompt bien cadré. Extraction et génération courte peuvent vivre ensemble. Classification et justification minimale aussi. Reformulation et production finale pareil, si la consigne est claire et que le format de sortie est verrouillé.
| Cas | Approche |
| Extraire trois champs puis répondre en deux phrases | Un seul appel LLM avec sortie structurée |
| Classer une demande et donner une raison courte | Un seul prompt avec catégorie et justification |
| Reformuler puis produire le message final | Une seule génération avec ton, cible et contraintes |
Il y a aussi des cas où je n’utilise simplement pas de LLM. Formater une date, valider un email, vérifier des champs obligatoires, faire un calcul, remplir un template, chercher une ligne en base de données, appliquer une règle métier simple… C’est du code. C’est plus rapide, plus stable, moins cher, et surtout prévisible.
Le parallélisme aide aussi quand les tâches ne dépendent pas les unes des autres. Si le retrieval, la classification et un enrichissement CRM peuvent partir en même temps, je les lance en parallèle. Ce n’est pas forcément moins cher, parce que le nombre d’appels reste le même, mais l’utilisateur attend moins longtemps. Et parfois, c’est ça qui change toute la perception du produit.
Chez un client, le problème ne venait pas du modèle. Le modèle répondait correctement. Le vrai souci, c’était trois appels LLM inutiles placés avant la génération finale : une reformulation qui ne servait à rien, une classification déjà déductible par règle, et une critique automatique qui ralentissait tout sans améliorer la réponse.
Checklist d’audit d’un workflow LLM
- Quels appels sont vraiment nécessaires pour produire la réponse finale ?
- Quels appels peuvent être fusionnés dans un seul prompt plus précis ?
- Quels appels peuvent être remplacés par du code déterministe ?
- Quels appels font du formatage, de la validation, du calcul ou une règle simple ?
- Quels appels sont indépendants et peuvent tourner en parallèle ?
- Quels appels ajoutent de la qualité mesurable, et lesquels ajoutent juste de la complexité ?
Quand le cache change tout ?
Le cache change tout quand une partie du prompt revient souvent et peut être réutilisée. C’est là que le prefix caching, ou prompt caching, devient intéressant. L’idée est simple : si le début du prompt reste stable, le modèle ou le fournisseur peut éviter de refaire le même travail à chaque requête.
Dans un prompt LLM, le début contient souvent les instructions système, les règles métier, les consignes de format, une partie du contexte produit ou une documentation récurrente. Si cette zone ne bouge pas, elle peut être mise en cache. Ensuite, on ajoute la partie variable : la question utilisateur, les données du ticket, le message client, les derniers éléments récupérés par le RAG. Le RAG, c’est la technique qui consiste à récupérer des documents pertinents avant d’appeler le modèle.
J’ai vu ça changer pas mal de choses chez un client avec un assistant support. Le prompt contenait toujours les mêmes règles de réponse, les mêmes contraintes de ton, les mêmes politiques de remboursement et une doc produit assez stable. Avant, tout était reconstruit dans le désordre à chaque appel. Après restructuration, on a mis le bloc stable au début, puis les données variables à la fin. Même modèle, même usage, mais moins de latence et une facture plus propre.
Les bons candidats au cache sont généralement ceux-là :
- Les instructions système stables.
- Les consignes de format de sortie, comme JSON, ton, langue, longueur.
- Le contexte produit qui change peu.
- Les règles de modération ou de conformité.
- La documentation fréquemment utilisée.
- Les morceaux de contexte RAG qui reviennent souvent.
Le point important, c’est l’ordre du prompt. Si vous mélangez trop tôt des données variables, comme un ID client, une date, une question utilisateur ou un extrait unique, vous cassez souvent la réutilisation. Je préfère penser le prompt en deux zones : stable d’abord, variable ensuite. C’est bête, mais ça compte.
Le cache a aussi ses limites. Il ne corrige pas un mauvais prompt. Il ne supprime pas les tokens de sortie, donc si le modèle répond trop long, vous payez toujours. Il ne remplace pas le routage modèle, parce qu’un petit modèle bien choisi restera souvent moins cher. Et si chaque requête est totalement différente, le gain sera faible. Dans l’ordre, je mesure d’abord, je réduis les tokens, je route mieux, je réduis les appels inutiles, puis je structure le cache.
| Élément du prompt | Cache pertinent ou non | Raison |
| Instructions système | Oui | Elles changent rarement et sont souvent placées au début. |
| Question utilisateur | Non | Elle varie presque à chaque requête. |
| Consignes de format | Oui | Elles restent stables sur un même cas d’usage. |
| Documentation produit récurrente | Oui | Elle peut être réutilisée si elle est injectée dans le même ordre. |
| Contexte RAG unique | Parfois | Il est utile seulement si les mêmes extraits reviennent souvent. |
| Données client temps réel | Non | Elles changent trop souvent et doivent rester dans la partie variable. |
Et si le vrai gain venait surtout de ce qu’on évite ?
Réduire la latence LLM, ce n’est pas juste chercher plus de GPU ou changer de fournisseur. Je commence par mesurer proprement, puis je coupe les tokens inutiles, je route vers le bon modèle, je limite les appels LLM et je structure les prompts pour profiter du cache. C’est souvent là que les gains sont les plus propres. Pas dans une grosse refonte, plutôt dans une série de décisions simples et mesurables. Si votre application IA commence à coûter trop cher ou à répondre trop lentement, le bénéfice est clair : une expérience plus rapide, plus stable, et un coût de production mieux maîtrisé.
FAQ
- Qu’est-ce qui augmente le plus la latence LLM en production ?
Les causes les plus fréquentes sont les sorties trop longues, les prompts trop volumineux, les appels LLM séquentiels, les files d’attente, le retrieval lent et l’utilisation d’un modèle trop puissant pour une tâche simple. La première chose à faire, c’est mesurer séparément chaque morceau de la chaîne. - Pourquoi les tokens de sortie coûtent-ils autant ?
Parce que le modèle génère la réponse token par token. Plus la réponse est longue, plus l’utilisateur attend, et plus le coût augmente. Limiter les tokens de sortie, imposer un format court ou supprimer les phrases inutiles peut déjà réduire une bonne partie du problème. - Faut-il toujours utiliser le modèle LLM le plus puissant ?
Non. Beaucoup de tâches cadrées peuvent être traitées par un modèle plus petit : extraction, classification, FAQ simple, réécriture de requête ou JSON structuré. Le bon réflexe, c’est de router les demandes simples vers un modèle économique et d’escalader seulement quand la complexité le justifie. - Comment réduire le nombre d’appels LLM dans un workflow ?
Je regarde d’abord les appels séquentiels. Certains peuvent être fusionnés dans un seul prompt, d’autres remplacés par du code déterministe : validation, calcul, formatage, templates ou recherche en base. Quand des tâches sont indépendantes, elles peuvent aussi tourner en parallèle pour réduire l’attente. - À quoi sert le prompt caching pour un LLM ?
Le prompt caching sert à réutiliser une partie stable du prompt, comme les instructions système, les règles métier ou un contexte récurrent. Bien utilisé, il évite de recalculer la même chose à chaque requête. Il fonctionne mieux quand le prompt est structuré avec une partie stable au début et une partie variable ensuite.
A propos de l’auteur
Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des équipes sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA en entreprise et le SEO/GEO. J’ai travaillé avec des acteurs comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez industrialiser vos usages IA sans exploser vos coûts ni votre latence, vous pouvez me contacter.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.