LLM auto hébergées · 9 November 2026

Batching continu, speculative decoding, offload : les trois leviers qui changent vraiment le débit d’un LLM local en 2026

Votre RTX 4090 à 24 Go génère plus lentement qu’un smartphone sur un modèle 70B, et ce n’est pas une panne : c’est de l’architecture. En 2026, la stack de serving open source a mûri au point que le débit d’un LLM auto-hébergé ne dépend plus seulement de votre GPU, mais de la façon dont vous empilez trois leviers — et dont vous acceptez d’arbitrer entre débit agrégé et latence perçue.

Le mur des 20 tokens/s : pourquoi votre GPU ronronne à vide

Il y a un paradoxe qui déroute quiconque installe son premier serveur d’inférence. Une RTX 4090, 24 Go de VRAM, plusieurs dizaines de téraflops en FP16 : sur le papier, une bête. En pratique, dès qu’on lui demande un modèle 70B en quantization 4 bits, elle crache ses tokens à un rythme qui ferait sourire un téléphone haut de gamme faisant tourner un 3B. Le GPU n’est pas à l’arrêt par accident : il attend. Il attend la mémoire.

C’est le diagnostic fondamental, et il structure tout le reste de ce dossier. Le décodage autorégressif d’un LLM est memory-bandwidth-bound : à chaque étape de génération, pour produire un seul token par séquence, le moteur doit relire l’intégralité des poids du modèle depuis la HBM. Sur un 70B quantifié, cela représente des dizaines de gigaoctets à faire transiter par la mémoire à chaque token. Les cœurs de calcul, eux, passent l’essentiel de leur temps à attendre des données. Le GPU ronronne à vide parce que le goulot n’est pas là où on l’imagine : il est dans le bus mémoire, pas dans les unités de calcul.

Cette réalité a une conséquence directe : les trois grands leviers d’optimisation n’attaquent pas le même maillon de la chaîne. Le batching continu amortit la lecture des poids sur plusieurs séquences simultanées — c’est un levier de débit agrégé. Le speculative decoding échange du compute disponible (qui ne sert à rien pendant l’attente mémoire) contre moins d’étapes séquentielles — c’est un levier de latence. L’offload déplace une partie des poids hors de la VRAM pour faire tenir un modèle trop gros — c’est un levier de capacité, au prix de la bande passante.

Le cadre mental à garder en tête avant d’entrer dans les mécanismes : ces trois leviers ne sont pas une liste de recettes à empiler, mais un arbitrage. Un utilisateur seul en chat et un serveur multi-agents derrière une API interne n’ont pas les mêmes besoins, et les réglages qui font briller l’un peuvent saboter l’autre. C’est cette tension que nous allons disséquer.

Orca, PagedAttention, vLLM V1 : la courte histoire du batching qui a tout changé

Pour comprendre pourquoi le batching continu est devenu la colonne vertébrale du serving moderne, il faut d’abord voir pourquoi le batching statique des débuts s’effondrait. Le batching naïf, celui qu’on faisait avec generate() de Hugging Face ou les premiers serveurs maison, regroupe des requêtes jusqu’à ce que toutes aient fini. Le problème : on ne connaît pas la longueur de sortie à l’avance, et elle varie énormément. Une requête qui produit 2 000 tokens bloque les slots du batch pendant que les autres, terminées depuis longtemps, laissent leurs places vides. C’est le head-of-line blocking : l’utilisation GPU s’effondre, les nouvelles requêtes attendent en file, et la latence de queue explose. Sur une charge réaliste, le GPU passe l’essentiel de son temps à faire tourner des slots fantômes.

La bascule conceptuelle arrive avec Orca (OSDI 2022), qui introduit l’iteration-level scheduling : le scheduler ne décide plus de la composition d’un batch une fois pour toutes, mais à chaque itération de décodage quelles séquences exécuter. Une séquence terminée libère son slot immédiatement, une nouvelle requête peut entrer au step suivant. Le batch devient une entité vivante, reconstituée en continu — d’où le nom.

Le second étage de la fusée est vLLM et son PagedAttention (SOSP 2023). Le batching continu résout le problème du scheduling, mais laisse entier celui du KV-cache : chaque séquence active stocke ses clés et valeurs en mémoire GPU, et cette allocation, faite naïvement de façon contiguë et surdimensionnée, gaspille massivement de la VRAM. PagedAttention applique au KV-cache le principe de la mémoire virtuelle des systèmes d’exploitation : des blocs de taille fixe, une table de pages, une allocation à la demande. C’est ce qui permet de faire tenir beaucoup plus de séquences simultanées dans la même VRAM — et donc de nourrir le batching continu.

En 2026, le paysage des moteurs est mature, et le choix dépend surtout de votre matériel et de votre usage.

Encadré sourcing — les limites de ce dossier. Les mécanismes décrits ci-dessus (inefficacité du batching statique, rôle d’Orca et de PagedAttention) sont cohérents entre plusieurs sources tierces, mais aucune source primaire — le papier Orca d’OSDI 2022, le papier vLLM de SOSP 2023 — n’a été consultée directement pour cet article. Les dates de sortie de vLLM V1, de SGLang et de TensorRT-LLM ne sont pas précisées dans notre matière. Les chiffres de débit proviennent de blogs, pour l’essentiel commerciaux, et ne sont pas recoupés par un benchmark indépendant. Nous le signalerons systématiquement.

Sous le capot du scheduler : prefill, decode et KV-cache sous tension

Pour régler un serveur sans le saboter, il faut distinguer deux phases que tout confond. Le prefill traite l’intégralité du prompt en un seul forward pass : c’est un matmul dense, compute-bound, et c’est lui qui détermine le TTFT (time to first token). Le decode génère les tokens un par un, memory-bound, et c’est lui qui détermine l’ITL (inter-token latency). Un serveur bien réglé pour le débit agrégé ne l’est pas forcément pour la latence perçue : ce sont deux régimes différents.

Le scheduler par itération, à chaque step, doit décider quelles séquences exécuter — et c’est là que le KV-cache entre en scène. Ce cache croît d’une entrée par couche par token généré. Chaque séquence active doit résider en mémoire GPU, et cette mémoire est finie. Le serveur devient donc un problème de bin-packing permanent : à chaque itération, il faut caser les séquences en cours dans l’espace KV disponible. Quand la pression monte, deux stratégies s’offrent au moteur : la préemption (on sort une séquence du batch, elle attend) et, pour la récupérer, soit le recompute (on recalcule son KV-cache plus tard, coûteux en compute), soit le swap (on l’écrit en mémoire CPU puis on le relit, coûteux en bande passante). Les deux se paient en latence de queue.

C’est ici que se joue le piège de configuration le plus classique — et le plus contre-intuitif. Les moteurs exposent des leviers comme max_num_seqs (nombre max de séquences simultanées), max_num_batched_tokens (tokens max par batch) et gpu_memory_utilization (fraction de VRAM allouée). Le réflexe du débutant est de pousser gpu_memory_utilization à 0,95 pour « profiter » de sa carte. Résultat : plus de place pour le KV-cache, donc plus de séquences admises… jusqu’au point où la moindre variation de longueur déclenche des préemptions en cascade, chaque préemption coûtant un recompute ou un swap, et la latence de queue s’envole alors que le débit agrégé, lui, ne progresse plus. Le bon réglage n’est pas le maximum, c’est celui qui laisse une marge pour absorber la variance des longueurs de sortie.

Speculative decoding : le pari du compute gratuit qui ne paie qu’en solo

Voici le levier le plus mal compris du lot. Le speculative decoding part d’une observation simple : pendant le décodage, le GPU attend la mémoire, ses unités de calcul tournent à vide. Autant les employer. Un modèle draft (plus petit, plus rapide) propose plusieurs tokens d’avance ; le modèle cible les vérifie en un seul forward pass et accepte la plus longue préfixe valide. Si le draft a vu juste sur k tokens, on a généré k tokens pour le prix d’un seul passage du gros modèle. Les variantes abondent : draft models classiques, EAGLE-2/3, Medusa (têtes de prédiction multiples), lookahead decoding, n-gram speculation.

Le point central, contre-intuitif, est que le speculative decoding est un levier de latence, pas de débit. Il brille à faible batch size, quand le GPU a effectivement du compute à revendre. À fort batch, ce compute est déjà employé à amortir la lecture des poids sur de nombreuses séquences : le speculative decoding devient alors une perte nette, puisqu’il ajoute du travail de vérification sans rien amortir. La documentation officielle de vLLM (v0.17.0) le confirme : les gains de latence inter-token s’observent sous charge « medium-to-low QPS, memory-bound », et les méthodes à base de modèle (EAGLE, draft models) donnent les meilleures réductions, tandis que le n-gram et le suffix donnent des gains « modestes » sans surcoût en trafic de pointe. En production, cela impose de le désactiver ou limiter dynamiquement quand la charge monte.

Sur les taux d’acceptation, la prudence est de mise. Le débat public évoque souvent 60-80 % en théorie contre 40-60 % en pratique selon le domaine — mais ces chiffres ne sont pas sourcés dans notre matière, et aucun taux d’acceptation mesuré n’y figure. De même, le « 3× de throughput » attribué à AppScale dans un article de 2026 n’est pas vérifiable : le corps de l’article n’était pas disponible. Quant au passage de 20-30 à 80-150 tokens/s revendiqué par Tensoria, il mélange serveur d’inférence, speculative decoding et quantization sans détailler le protocole — à prendre avec des pincettes. Un point rassurant en revanche : vLLM garantit la losslessness algorithmique du speculative decoding (rejection sampler convergent, égalité du greedy sampling), avec des réserves sur la précision flottante et l’instabilité des logprobs.

Offload, MoE et quantization mixte : quand la mémoire est le vrai plafond

Troisième levier, et sans doute le plus déterminant pour le grand public : faire tenir un modèle trop gros pour la VRAM. Trois familles de stratégies coexistent. L’offload de couches place une partie des poids en RAM CPU et les fait transiter par PCIe au fil du décodage — chaque couche offloadée ajoute de la bande passante à consommer, donc de la latence. L’offload d’experts exploite l’architecture MoE (Mixtral, Qwen3-MoE, DeepSeek) : seuls quelques experts sont activés par token, ce qui permet de garder les experts froids hors VRAM et de ne charger que les actifs. La quantization mixte réduit l’empreinte elle-même : K-quants pour llama.cpp, AWQ/GPTQ pour vLLM.

Ce que chaque stratégie coûte dépend du maillon qu’elle sollicite. L’offload de couches tape la bande passante PCIe ; l’offload d’experts dépend du routage (un token peut activer des experts dispersés) ; la quantization joue sur la précision. C’est ici que les machines à mémoire unifiée changent la donne : sur un Mac ou un mini-PC à mémoire partagée CPU/GPU, il n’y a plus de frontière PCIe à traverser — le « offload » devient une simple allocation dans un pool commun. Les mini-PC 2026 à 128 Go de mémoire unifiée (Acer/AMD Ryzen AI Halo, annoncés jusqu’à 200 milliards de paramètres, à 3 999 $) ou les cibles AMD Gorgon Halo à 192 Go de mémoire unifiée pour des modèles 200B+ illustrent cette bascule. À l’inverse, une RTX 4090 à 24 Go reste le point de bascule pour le 70B : en dessous, il faut offloader ; au-dessus, on tient en VRAM et on peut se concentrer sur le batching.

Encadré — les speedups MoE revendiqués. Notre matière ne contient aucun chiffre de speedup offload MoE (Mixtral, Qwen3-MoE, DeepSeek), ni benchmark indépendant sur ces architectures. Les gains annoncés par les éditeurs ne sont pas recoupés. À traiter comme des promesses, pas des mesures.

Ce que disent vraiment les chiffres : débits, TTFT et taux d’acceptation sur matériel grand public

Il faut ici être honnête sur l’état des données disponibles en 2025-2026. Les chiffres les plus cités sont des ratios d’éditeurs sans protocole : le « 23× throughput » d’Anyscale attribué au continuous batching (cité en lien depuis la doc officielle vLLM, mais Anyscale est co-auteur de vLLM — acteur intéressé), le « 2 à 24× » d’Introl (fourchette très large, aucune méthodologie fournie), le « 73 % de réduction de coûts » de Stripe migrant de HF Transformers vers vLLM (repris d’un cas client). Ce sont des affirmations d’acteurs, pas des benchmarks reproductibles.

Les seuils de perception, eux, sont plus utiles pour raisonner : un TTFT supérieur à 1-2 s casse la fluidité ; un ITL d’environ 50 ms (soit ~20 tok/s) est perçu comme instantané ; au-delà de 100 ms par token, on perçoit le token par token. Ces seuils proviennent de Tensoria et ne sont pas recoupés — mais ils donnent un ordre de grandeur pour juger si un réglage « marche ».

La conclusion méthodologique est claire : les benchmarks indépendants sur matériel grand public manquent. On peut raisonner en ordres de grandeur, pas en promesses. Et sur une RTX 4090 ou une 3090, le débit réel dépendra tellement du modèle, de la quantization et du batch qu’aucun chiffre générique ne remplace une mesure chez soi.

Chat solo vs serveur multi-agents : choisir ses leviers selon l’usage

Maintenant qu’on a les mécanismes, le cadre mental promis en ouverture se déploie en deux configurations types — et un cas intermédiaire.

Utilisateur unique en chat. Vous êtes seul, la latence perçue prime. Le batching continu n’apporte presque rien (vous n’avez qu’une séquence à la fois) : gardez un batch size de 1-2. Le levier roi est le speculative decoding — c’est exactement le régime à faible batch où il brille. L’offload devient pertinent uniquement si vous voulez un modèle trop gros pour votre VRAM, au prix de la latence. Piège : activer un speculative decoding agressif sur un modèle draft mal choisi, qui n’accepte pas assez de tokens et ajoute du travail pour rien.

Serveur multi-agents ou API interne. La donne s’inverse. Le batching continu et PagedAttention sont rois : c’est le débit agrégé qui compte, et chaque séquence supplémentaire amortit la lecture des poids. Le speculative decoding doit être désactivé ou limité — à fort batch, il coûte plus qu’il ne rapporte. L’offload devient un arbitrage coût/débit : garder plus de séquences en VRAM vaut souvent mieux que d’offloader pour un modèle plus gros. Piège : saturer gpu_memory_utilization et déclencher des préemptions en cascade.

Cas intermédiaire (petite équipe, charge en rafales). Activez le batching continu mais avec une marge mémoire confortable, et un speculative decoding conditionnel — désactivé au-delà d’un seuil de QPS. C’est le réglage le plus délicat, et celui qui exige le plus de mesure.

Ce qui change en 2026 : disaggregation prefill/decode, moteurs matures et prochain front

La stack de serving est décrite comme mature en 2026 : vLLM ou SGLang, paged attention avec continuous batching, speculative decoding, et désormais disaggregation prefill/decode. Cette dernière consiste à séparer physiquement les deux phases sur des machines différentes — le prefill, compute-bound, et le decode, memory-bound, n’ont pas les mêmes besoins matériels. Bien dimensionnée, elle permet d’allouer le compute là où il sert et la bande passante là où elle sert, au lieu de chercher un compromis sur une seule carte. Elle pourrait redistribuer les cartes entre batching et speculative decoding : si le decode tourne sur des nœuds dédiés à faible batch, le speculative decoding redevient intéressant là où il était relégué.

Les questions ouvertes restent nombreuses. Les benchmarks indépendants sur matériel grand public manquent toujours. Les taux d’acceptation réels par domaine ne sont pas documentés dans notre matière. Le coût énergétique de l’offload — faire transiter des dizaines de gigaoctets par PCIe à chaque token — n’est pas chiffré. Et les speedups MoE restent des promesses d’éditeurs.

Ce que le lecteur doit retenir pour ne pas se ruiner tient en deux principes. D’abord, investir dans la mémoire et la bande passante avant le compute : un GPU plus rapide ne sert à rien s’il attend la mémoire ; de la VRAM et de la bande passante, oui. Ensuite, mesurer avant de copier une recette : les chiffres qui circulent sont des ratios d’éditeurs, pas des mesures. Le seul benchmark qui vaille est celui que vous faites chez vous, sur votre modèle, avec votre charge. Les trois leviers sont là, ils sont réels, mais leur bon dosage dépend de vous — pas d’un tableau trouvé sur un blog.

Sources

• Chip Huyen on How to Optimize LLM Inference — P99 CONF
• Continuous Batching and Speculative Decoding: How Modern LLM Serving Engines Actually Work — Syslabs
• Optimisation latence LLM, speculative decoding, vLLM — Tensoria
• LLM Inference Optimization 2026: Serving, Batching, KV Cache — AI Learning Guides
• LLM Inference Acceleration — Inference Engineering
• Inference Optimization — Adaptive Recall
• vLLM documentation v0.9.0 (continuous batching)
• vLLM documentation v0.17.0 — Speculative Decoding
• vLLM Production Deployment & Inference Serving Architecture — Introl, 11 déc. 2025
• Continuous Batching vs Static Batching — SilentNode
• Local LLM Inference Engines Compared: The Definitive 2026 Guide — local-llm.net
• llm-d 1.0 Advances Open, Cost-Efficient AI Inference for Production Scale — PR Newswire, 20 oct. 2026
• Héberger son propre LLM pour réduire la facture IA : faire le calcul — Journal du Net, 14 oct. 2026
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API — 27 sept. 2026
• Windows ML: 2026 Updates for GGUF Models and Local AI — Techgenyz, 9 oct. 2026
• Best Hardware for Running Open-Source AI Models Locally in 2026 — Memeburn
• Local LLM Operation Guide 2026 — Running Securely on Your Own GPU — note.com

Article recherché et rédigé automatiquement · Magazine Electrosens