Une application LLM lente est une application abandonnee. Les utilisateurs en 2026 attendent une experience reactive, comparable a celle des produits maitrises (Cursor, Claude Code, ChatGPT). Pourtant, beaucoup d'applications LLM construites en interne souffrent de latences a deux ou trois chiffres en secondes. Pour la majorite des cas, ce n'est pas une fatalite mais le resultat d'implementations naives. Trois techniques bien connues mais mal exploitees produisent des accelerations spectaculaires : streaming, parallelisation, batching. Bien combinées, elles divisent typiquement les latences ressenties par 3 a 5 fois sans changer ni les modeles ni l'infrastructure. Cet article detaille comment et quand les utiliser.
La latence percue n'est pas la latence reelle
La latence d'une application LLM se decompose en deux notions distinctes mais souvent confondues.
La latence reelle est le temps total entre la requete et la reponse complete. Pour une generation de 500 tokens a 80 tokens par seconde, c'est 6,25 secondes plus le time-to-first-token (latence d'attente avant le premier token), souvent 1 a 2 secondes. Total : 7-8 secondes.
La latence percue est le temps avant que l'utilisateur commence a voir une reponse. Avec streaming, c'est le time-to-first-token : 1-2 secondes. Sans streaming, c'est la latence reelle complete : 7-8 secondes.
Cette distinction est fondamentale. Un utilisateur percoit "quelque chose se passe" des le premier token streame. Il tolere une generation lente s'il voit le progression. Il ne tolere pas un ecran fige pendant 7 secondes meme si le resultat final est identique.
L'optimisation de la latence percue est generalement plus impactante que l'optimisation de la latence reelle pour les applications interactives.
Streaming : la technique la plus simple et la plus impactante
Le streaming consiste a renvoyer la reponse du modele token par token plutot qu'en bloc final. Tous les providers majeurs supportent cette technique.
L'implementation cote API est triviale : ajouter stream: true dans la requete. La difficulte est cote client, ou il faut traiter un flux Server-Sent Events ou un streaming HTTP plutot qu'une reponse JSON classique.
Le gain en latence percue est massif. Sur une generation de 1000 tokens a 80 tokens par seconde, l'utilisateur passe d'une attente de 12,5 secondes (sans streaming) a une attente de 1 seconde avant les premiers tokens (avec streaming). Le ressenti est radicalement different.
Les pieges du streaming sont au nombre de trois. Le premier est la gestion des tools calls : quand le modele decide d'appeler un outil au milieu de la generation, le streaming est interrompu. Une bonne implementation gere proprement ces transitions. Le deuxieme est le parsing JSON : si la reponse doit etre du JSON structure, le streaming complique le parsing partiel. Des bibliotheques comme partial-json ou les sorties structurees natives des SDK aident. Le troisieme est l'experience d'erreur : si l'API echoue au milieu du stream, l'utilisateur a deja vu un debut de reponse incomplete. Une gestion explicite des erreurs evite les corruptions visibles.
Pour les agents multi-etapes, le streaming s'applique a chaque etape. Le pattern qui fonctionne est de streamer en continu en montrant les transitions entre etapes ("Analyse de la requete...", "Recherche dans la documentation...", "Generation de la reponse...") plutot qu'un ecran fige pendant l'orchestration.
Parallelisation : multiplier les appels simultanes
La parallelisation tire parti du fait que beaucoup d'operations dans un agent peuvent etre executees en parallele plutot qu'en sequence.
Le pattern le plus evident est le fan-out dans une chain. Un agent qui doit consulter trois sources differentes (base de donnees, documentation, API externe) peut lancer les trois appels simultanement plutot qu'en sequence. Si chaque appel prend 1 seconde, la sequence prend 3 secondes, le parallele prend 1 seconde.
Le pattern multiple LLM calls est plus subtil. Quand un agent doit generer plusieurs sections d'une reponse (resume executif, details techniques, exemples), ces sections peuvent etre generees en parallele. Le compromis : chaque section est generee sans visibilite sur les autres, ce qui peut creer des incoherences. Pour des sections vraiment independantes, le gain est reel.
Le pattern multi-model lance la meme requete sur plusieurs modeles en parallele et garde la meilleure reponse. Cette technique est utile pour les requetes critiques ou la qualite prime, mais coute plus cher (chaque modele facture). Une variation utilise des modeles moins chers en premier et n'invoque les modeles puissants qu'en cas de qualite insuffisante.
L'implementation requiert une discipline d'asynchrone. Python asyncio.gather, JavaScript Promise.all, ou les abstractions des frameworks (LangChain RunnableParallel). Voir notre [comparatif LlamaIndex vs LangChain](/llamaindex-vs-langchain-framework-rag/) pour les patterns specifiques.
Les pieges de la parallelisation incluent les rate limits (multiplier les appels simultanes peut depasser les quotas), la complexite de gestion des erreurs (un appel echoue parmi N), et le surcout en cas d'echec d'un seul appel (les autres ont quand meme consomme des tokens).
Batching : grouper pour economiser
Le batching consiste a grouper plusieurs requetes independantes en une seule. Cette technique est specialement utile pour les traitements asynchrones a fort volume.
L'API batch d'OpenAI permet de soumettre des centaines ou milliers de requetes en un seul appel asynchrone. Le traitement prend jusqu'a 24 heures mais coute 50 % moins cher que les appels temps reel. Pour les usages non interactifs (analyses massives, generation de documentation, classification de gros datasets), c'est l'option la plus economique.
Anthropic a introduit son propre batch API en 2024. Le principe est similaire avec une remise de 50 % et un SLA de 24 heures. Google offre egalement cette capacite dans Gemini.
Le batching synchrone est moins utilisé mais peut etre pertinent. Plutot que d'envoyer chaque requete separement, l'application accumule les requetes pendant quelques centaines de millisecondes et les envoie en un appel groupé. Cette technique reduit le surcout reseau quand les requetes arrivent en burst.
Le pattern le plus avance est le batching dynamique. L'application classifie les requetes selon leur urgence : les requetes interactives passent en streaming temps reel, les requetes differables vont en batch async. Cette segmentation optimise le cout total tout en preservant l'experience utilisateur.
Notre [guide sur les couts d'API LLM](/prompt-caching-couts-api-llm/) detaille les economies cumulees possibles avec batching et caching.
Combiner les trois techniques
Les trois techniques ne sont pas exclusives. La meilleure performance combine les trois.
Sur un agent conversationnel typique : streaming pour la reponse principale (latence percue minimale), parallelisation des outils invoques (latence reelle reduite), batching pour les operations de fond non interactives (cout reduit).
Sur un pipeline RAG : parallelisation de la recuperation (recherche dans plusieurs sources simultanees), streaming de la generation finale, batching des reindexations periodiques.
Sur une application d'analyse documentaire : batching des analyses massives (traiter 1000 documents la nuit), parallelisation du chunking et des embeddings (acceleration du pipeline), streaming pour les requetes interactives utilisateur.
Cette combinaison demande discipline mais produit les meilleures applications LLM en 2026.
Mesurer pour optimiser
Sans mesure, l'optimisation est aveugle. Plusieurs metriques meritent d'etre instrumentees.
La time-to-first-token mesure la reactivite percue. C'est la metrique la plus importante pour les applications interactives. L'objectif typique est inferieur a 1 seconde pour une experience tres reactive, inferieur a 2 secondes pour une experience acceptable.
La latence end-to-end p95 mesure le pire des cas pour 95 % des utilisateurs. Cette mesure est plus revelatrice que la moyenne, qui cache les outliers.
Le throughput effectif mesure les tokens generes par seconde reels, en tenant compte des temps d'attente et des cycles de tools calls. Cette metrique guide les optimisations cote infrastructure.
Le taux d'utilisation du parallelisme mesure le pourcentage de temps ou plusieurs operations s'executent simultanement. Une application avec un taux bas a probablement de la sequentiation evitable a optimiser.
Notre [guide sur les metriques d'agents IA](/metriques-monitoring-agents-ia-production/) detaille les patterns d'instrumentation.
L'approche speculative pour aller plus loin
Une technique avancee qui se generalise en 2026 est la decoding speculatif. Le principe : un petit modele rapide genere un brouillon de plusieurs tokens, qu'un gros modele plus lent verifie en bloc plutot que token par token.
Si le brouillon est correct, le gros modele valide en parallele plusieurs tokens. Si le brouillon devie, le gros modele corrige et reprend. En moyenne, l'acceleration atteint 2 a 3 fois pour une qualite quasi identique.
Cette technique est integrée nativement dans plusieurs providers (OpenAI predicted outputs, Anthropic prompt caching avec mode speculatif). Pour les applications custom avec modeles self-hosted, l'implementation demande plus d'effort mais reste accessible.
L'autre technique avancee est la generation parallele structuree. Pour les sorties JSON ou XML, le modele peut generer plusieurs champs en parallele si leur dependance le permet. Les frameworks comme Guidance ou LMQL exploitent cette capacite.
Cas d'usage : agent de developpement
Un agent de codage typique illustre les gains combines.
Scenario : un developpeur demande a l'agent de refactorer une fonction et d'ajouter des tests. Sans optimisation, l'agent fait : analyse (3s) + lecture du fichier (1s) + refactoring (5s streaming) + lancement test (2s) + iteration en cas d'echec (5s). Total : 16 secondes minimum.
Avec optimisations : analyse en parallele de la lecture du fichier (les deux operations en 3s simultanees) + refactoring streame (5s avec premier token a 1s) + lancement test (2s). Total avec premier feedback : 4s, total complete : 10s.
L'experience est radicalement differente. Le developpeur voit l'analyse, voit le refactoring se construire ligne par ligne, voit les tests s'executer. Plutot qu'une attente fixe de 16 secondes, c'est une progression visible de 10 secondes ou il sait toujours ce qui se passe.
Cas d'usage : assistant documentaire
Un assistant qui cherche dans une documentation enterprise et synthetise une reponse beneficie particulierement de la parallelisation.
Sans optimisation : reformulation de la question (2s) + recuperation RAG (3s) + reranking (1s) + generation (5s streaming). Total : 11s, premier token a 6s.
Avec parallelisation : reformulation de la question lancee en parallele de la recuperation initiale (les deux en 3s simultanes), reranking, generation streamee. Total : 8s, premier token a 4s.
Le gain en latence percue est de 33 %. Sur l'experience d'usage repetee, cette acceleration est tres tangible.
Les pieges a connaitre
Trois pieges courants meritent attention en 2026.
Le premier piege est l'optimisation prematuree. Sur un prototype ou un POC, ajouter de la parallelisation peut compliquer le code sans benefice tangible. La discipline est de mesurer d'abord, optimiser ensuite. Les techniques presentees s'ajoutent generalement dans une seconde phase, apres validation du flow fonctionnel.
Le deuxieme piege est la gestion d'erreurs degradee. Un appel parallele qui echoue partiellement est plus complexe a gerer qu'une sequence lineaire. Si la gestion d'erreurs n'est pas robuste, l'optimisation produit des bugs intermittents difficiles a debugger.
Le troisieme piege est la perte de coherence. Le streaming de plusieurs sections en parallele peut produire des incoherences logiques (deux sections qui se contredisent par exemple). Pour les contenus qui exigent une coherence forte, la parallelisation est a manier avec precaution.
La culture de la performance
Au-dela des techniques, la performance d'une application LLM tient a une discipline culturelle. Trois habitudes distinguent les equipes serieuses.
La mesure systematique : chaque feature mesure ses performances avant et apres optimisation. Cette discipline evite les regressions et oriente les efforts vers les vrais goulots.
La culture du temps reel : penser chaque feature comme une experience interactive, meme quand elle est techniquement asynchrone. Cette mentalite pousse a utiliser le streaming et le feedback continu.
L'iteration sur les pires cas : optimiser le p95 plutot que la moyenne. Les utilisateurs frustrations viennent de leurs pires experiences, pas de leurs experiences moyennes. Cette focalisation sur les outliers transforme la perception generale.
Les applications LLM les plus reussies en 2026 ne sont pas celles qui utilisent les modeles les plus puissants. Ce sont celles qui exploitent intelligemment les modeles disponibles avec les techniques de performance qui maximisent l'experience. Streaming, parallelisation et batching sont la fondation de cette discipline. Les applications qui ne les utilisent pas en 2026 paient un cout en experience utilisateur qui se mesure en abandons et en frustration. Celles qui les maitrisent obtiennent des produits que les utilisateurs adoptent et recommandent.
