Moteurs d'inférence pour LLM et matériel d'IA locale (Édition 2026)

You don't pick an inference engine first. You pick a hardware strategy, a workload shape, and a serving model. The engine follows.

C'est la façon la plus utile de concevoir les moteurs d'inférence pour LLM.

Note de série : Ceci est la partie 3 de ma série sur les LLM auto-hébergés / IA locale.

• Partie 1 : Mathématiques de la mémoire GPU pour les LLM (édition 2026)
• Partie 2 : Bande passante mémoire pour le matériel IA local (édition 2026)

Ces deux articles expliquent les mathématiques de la capacité et de la bande passante matérielles.

Celui-ci explique la couche logicielle qui transforme ce matériel en inférence utilisable.

Moteurs

Ces outils servent différents objectifs / occupent différentes couches

• Portabilité locale
• CUDA grand public
• Flux de travail mémoire unifiée Apple
• Inférence quantifiée
• Serveur de production
• Orchestration distribuée
• Exécution en centre de données optimisée par le fournisseur

Un modèle mental utile :

Le moteur d'inférence n'est pas « le modèle ». C'est l'agent de régulation du trafic, le gestionnaire de mémoire, le répartiteur de noyaux, le planificateur, le comptable du cache, le planificateur de parallélisme, la surface API, et parfois le cadre de déploiement.

Le meilleur moteur correspond à votre hiérarchie mémoire, votre interconnexion, votre format de quantification, vos objectifs de latence et de débit, l'architecture de votre modèle et votre maturité opérationnelle.

Guide de décision en une page

• Ordinateur portable / périphérie / matériel atypique → llama.cpp
• Flux de travail prioritairement Mac → MLX / MLX-LM
• Inférence locale sur RTX unique → ExLlamaV2
• 2-4+ GPU NVIDIA / CUDA → ExLlamaV3
• Serveur de production général → vLLM
• Contexte long / MoE / routage → SGLang
• Performance maximale NVIDIA → TensorRT-LLM
• Orchestration de cluster → NVIDIA Dynamo

Le reste de ce guide explique pourquoi.

Ce que fait réellement un moteur d'inférence

Un moteur d'inférence charge les poids, tokenise l'entrée, exécute la passe avant, échantillonne les tokens, maintient le cache KV et diffuse les résultats. Les moteurs sérieux gèrent également le regroupement (batching), la planification, la mise en cache des préfixes, la quantification, l'exécution parallèle, le service API, les métriques et l'exécution distribuée.

La charge de travail comporte deux phases :

Le préremplissage (prefill) lit le prompt et construit le cache KV initial. Il est intensif en calcul.

Le décodage génère un token à la fois, en lisant de manière répétée les poids et le cache KV. Il est limité par la bande passante mémoire. La vitesse de décodage suit davantage la bande passante mémoire que la puissance de calcul maximale.

Cette distinction explique presque tout :

• Prompt court, réponse longue : le décodage domine → la bande passante mémoire et le regroupement comptent.
• Prompt long, réponse courte : le préremplissage domine → les noyaux d'attention et le préremplissage par blocs comptent.
• Beaucoup d'utilisateurs : la qualité du planificateur compte → regroupement continu, pagination du cache, équité.
• Contexte long : le cache KV domine → attention paginée, quantification du KV, déchargement (offload).
• MoE : le routage d'experts domine → parallélisme d'experts, interconnexion, GEMM groupés.
• Multi-nœud : l'interconnexion domine → NVLink, RDMA, parallélisme de pipeline, désagrégation.

PagedAttention a résolu la fragmentation du cache KV. FlashAttention a utilisé le tuilage (tiling) sensible aux E/S pour réduire le trafic HBM (mémoire à haute bande passante). Le décodage spéculatif produit des tokens bon marché et les vérifie en parallèle. Le thème récurrent : la performance de l'inférence est une question de mouvement de mémoire et de planification.

Les véritables goulots d'étranglement

1. Bande passante mémoire, pas seulement la taille de la VRAM. La VRAM détermine l'adéquation (fit). La bande passante détermine la vitesse de décodage. Le M3 Ultra d'Apple offre jusqu'à 819 Go/s de bande passante mémoire unifiée. Le H100 SXM de NVIDIA revendique 3,35 To/s de bande passante mémoire GPU. La mémoire unifiée vous permet d'accueillir des modèles qui ne tiendraient pas dans la VRAM grand public. La HBM vous permet de les servir plus rapidement lorsque le modèle tient. L'adéquation n'est pas la vitesse. La capacité n'est pas la bande passante.
2. Croissance du cache KV. Le cache KV croît avec la taille du lot et la longueur du contexte. Les charges de travail à contexte long peuvent manquer de mémoire même lorsque les poids tiennent. PagedAttention partitionne le cache KV en blocs, augmentant l'utilisation et supportant des lots plus grands.
3. Interconnexion. Dès qu'un modèle franchit les limites des GPU (multi-GPU), vous payez un coût de communication. Le parallélisme tensoriel nécessite des collectives all-reduce fréquentes. Le parallélisme de pipeline communique aux limites des étapes. Le parallélisme d'experts nécessite un trafic all-to-all pour le MoE. La documentation de vLLM note que sans NVLink, le parallélisme de pipeline peut surpasser le parallélisme tensoriel.
4. Qualité du planificateur. Un bon planificateur décide quelles requêtes entrent dans le lot, comment le préremplissage et le décodage partagent l'accélérateur, si les longs prompts bloquent les décodages courts, et comment éviter la famine. Supporter le regroupement n'est pas la même chose que se comporter comme un planificateur prêt pour la production.
5. Surcharge d'exécution. Les graphes CUDA, la fusion de noyaux, la surcharge d'échantillonnage, la surcharge du tokeniseur, la surcharge HTTP, le changement de LoRA et le décodage structuré comptent tous. À grande échelle, les ennuyeuses surcharges de 2 % forment un syndicat et exigent de l'attention (sans jeu de mots).

Les familles de moteurs

Il existe quatre grandes familles :

Exécutables locaux portables : llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO, outils de type Ollama. Ils se soucient de « le faire fonctionner ici ».

Exécutables Apple / mémoire unifiée : MLX et MLX-LM. Ils se soucient d'utiliser la grande mémoire partagée et la pile Apple de manière optimale.

Moteurs de quantification CUDA grand public : ExLlamaV2 et ExLlamaV3. Ils se soucient de faire hurler ma boîte 3090/4090/5090 avec des poids faiblement quantifiés.

Moteurs de serveur de production : vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Ils se soucient des utilisateurs simultanés, du cache KV, du regroupement, du parallélisme, de l'observabilité et du coût par token.

Ensuite, il y a des couches d'orchestration comme Dynamo qui se situent au-dessus des moteurs et coordonnent les flottes, le préremplissage/décodage désagrégé, le routage et l'auto-scaling.

llama.cpp : le roi de la portabilité

llama.cpp est la réponse lorsque le matériel est atypique, contraint, hors ligne, orienté CPU, périphérique, ou n'est pas un nœud de centre de données NVIDIA bien rangé.

Il prend en charge Apple Silicon via ARM NEON, Accelerate et Metal ; x86 via AVX/AVX2/AVX512/AMX ; RISC‑V ; la quantification faiblement bit ; CUDA ; AMD via HIP ; MUSA ; Vulkan ; SYCL ; et le déchargement hybride CPU+GPU. C'est pourquoi llama.cpp possède la voie « faites-le simplement fonctionner ».

Le serveur HTTP est plus capable qu'un « exécuteur local jouet ». llama‑server fournit des routes compatibles OpenAI, une compatibilité avec l'API Anthropic Messages, le reclassement (reranking), le regroupement continu, le support multimodal, les contraintes de schéma JSON, l'appel de fonctions, le décodage spéculatif et une interface web.

La limitation critique : llama.cpp n'est pas destiné à un serveur de production multi-nœud sérieux. Son backend RPC est explicitement documenté comme étant une preuve de concept, fragile et non sécurisé.

Verdict : Utilisez llama.cpp lorsque la portabilité, le fonctionnement hors ligne, GGUF ou le déchargement hybride importent plus que le serveur à l'échelle de la flotte.

NE PAS utiliser avec Multi-GPU.

MLX et MLX-LM : l'arme Apple Silicon

MLX est le framework de tableaux d'Apple pour Apple Silicon, et MLX-LM est le package LLM construit dessus. C'est une pile ML prioritairement Mac.

Le fait matériel clé est la mémoire unifiée. Apple Silicon donne au CPU et au GPU un accès direct au même pool de mémoire. Les tableaux MLX vivent dans la mémoire unifiée, et vous choisissez le périphérique lors de l'exécution de l'opération plutôt que de déplacer les tableaux entre des espaces mémoire séparés.

Cela modifie le compromis de l'inférence locale. Sur un système GPU discret, la question est « tient-il dans la VRAM ? ». Sur un Mac série M avec une grande mémoire unifiée, la question devient « tient-il en mémoire, et le système mémoire peut-il alimenter le GPU assez rapidement ? ». De grands modèles quantifiés peuvent tenir sur des machines où le même modèle serait impossible sur un GPU grand public de 24 Go.

Cependant, il est également plus lent.

MLX-LM ajoute l'intégration au Hugging Face Hub, la quantification, LoRA et le fine-tuning complet, l'inférence distribuée et un vaste écosystème de modèles de la communauté MLX. MLX n'est plus réservé au Mac : il propose des packages CUDA et CPU uniquement pour Linux. La communication distribuée prend en charge MPI, Ring over TCP, JACCL pour RDMA over Thunderbolt et NCCL pour CUDA.

Le serveur de MLX-LM lui-même avertit qu'il n'est pas recommandé pour la production car il n'implémente que des vérifications de sécurité de base.

Verdict : Utilisez MLX pour les flux de travail ML et LLM prioritairement Mac. Pour un serveur public à haute concurrence, commencez par une vraie pile de serveur.

ExLlamaV2 et V3 : CUDA grand public, optimisé et rapide

ExLlamaV2 est le moteur de quantification CUDA local pour les personnes qui veulent qu'un GPU NVIDIA grand public dépasse son poids. Il prend en charge l'attention paginée, le regroupement dynamique, la mise en cache des prompts, la déduplication du cache KV, la génération par lots, le streaming et le décodage spéculatif. Le mot à retenir est local. Il rend les modèles quantifiés rapides sur les GPU CUDA modernes, en particulier les cartes grand public.

Meilleures utilisations : une boîte RTX 3090/4090/5090, assistant de codage local, chat local, modèles quantifiés EXL2 et utilisation en station de travail prosumer.

ExLlamaV3 étend la philosophie vers l'inférence multi-GPU et MoE locale. Il ajoute le format de quantification EXL3 basé sur QTIP, l'inférence parallèle tensorielle et experte flexible pour le matériel grand public, un serveur compatible OpenAI via TabbyAPI, le regroupement dynamique continu et le support multimodal.

V3 est intéressant lorsque vous avez 2-4+ GPU NVIDIA grand public ou que vous voulez du MoE local. Attendez-vous à des mises en garde : certains modèles ne supportent pas le parallélisme tensoriel ou expert dans ExLlamaV3.

Verdict : ExLlamaV2 est le moteur CUDA local des passionnés. ExLlamaV3 est la frontière pour les configurations locales multi-GPU (2-4). Attendez-vous à des bords plus rugueux pour de meilleures capacités.

vLLM : le serveur de production open-source par défaut

vLLM est le premier moteur que la plupart des équipes devraient évaluer pour un serveur LLM open-source sérieux.

Il offre une gestion de la mémoire KV basée sur PagedAttention, le regroupement continu, le préremplissage par blocs, la mise en cache des préfixes, les graphes CUDA/HIP, une quantification extensive (FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ, AWQ, GGUF), des noyaux d'attention et GEMM/MoE optimisés, le décodage spéculatif, torch.compile et le préremplissage/décodage/encodage désagrégé.

Il est également flexible : parallélisme tensoriel/pipeline/données/expert/contexte, streaming, sorties structurées, appel d'outils, API compatibles OpenAI et Anthropic Messages, gRPC, multi-LoRA, et support pour NVIDIA, AMD, CPU x86/ARM/PowerPC, plus des plugins pour TPU, Gaudi, Ascend, Apple Silicon, etc.

La documentation de vLLM note que les déploiements multi-nœuds utilisent généralement Ray, et sans NVLink, le parallélisme de pipeline peut surpasser le parallélisme tensoriel. Le piège est de supposer que vLLM élimine le besoin de pensée système. Vous devez toujours ajuster le regroupement, la longueur de contexte, l'utilisation de la mémoire GPU, la disposition du parallélisme et le routage. vLLM vous donne un très bon moteur ; il nécessite toujours une bonne conception système.

Verdict : Si quelqu'un dit « nous devons servir des modèles ouverts en production », vLLM est le point de départ par défaut.

SGLang : le cousin orienté systèmes de vLLM

SGLang est ce vers quoi vous vous tournez lorsque la charge de travail du serveur est moche : sorties structurées, contexte long, MoE, désagrégation et routage.

Il offre la mise en cache des préfixes RadixAttention, la désagrégation préremplissage-décodage, le décodage spéculatif, le regroupement continu, l'attention paginée, le parallélisme tensoriel/pipeline/expert/données, les sorties structurées, le préremplissage par blocs et le regroupement multi-LoRA. Il prend en charge NVIDIA, AMD, Intel Xeon, les TPU Google, les NPU Ascend, etc.

Le différenciateur de SGLang est l'architecture de service. Sa désagrégation préremplissage-décodage sépare le préremplissage intensif en calcul du décodage intensif en mémoire dans des instances spécialisées, en transférant le cache KV entre elles. Cela empêche les longs lots de préremplissage d'interrompre le décodage et de faire grimper la latence des tokens.

Verdict : SGLang est destiné aux équipes dont le goulot d'étranglement n'est plus « pouvons-nous exécuter le modèle ? » mais « pouvons-nous l'exécuter sous un trafic hostile sans sacrifier la latence, la mémoire et le coût ? »

TensorRT-LLM : performance maximale NVIDIA

TensorRT-LLM est la pile de performance maximale NVIDIA. Elle est optimisée, spécialisée, puissante et ne prétend pas être portable.

Il fournit des API Python pour construire des moteurs TensorRT avec des optimisations de pointe, ainsi que des exécutables Python et C++. Il inclut des noyaux personnalisés pour l'attention, les GEMM et le MoE ; la désagrégation préremplissage-décodage, le parallélisme d'experts large (Wide Expert Parallelism), le décodage spéculatif ; et une API Python haut niveau intégrée à NVIDIA Dynamo et Triton Inference Server.

Les GPU B200 peuvent charger des poids FP4 avec des noyaux optimisés. Les H100 et ultérieurs supportent la quantification FP8 qui peut doubler les performances et réduire de moitié la consommation mémoire par rapport au 16 bits avec une perte de précision minimale.

Où il brille : flottes de classe H100/H200/B200/GB200/GB300, centres de données uniquement NVIDIA, déploiement FP8/FP4, service multi-nœud et MoE à grande échelle. Où il est maladroit : portabilité AMD, Apple ou Intel ; modèles expérimentaux changeant rapidement ; petites configurations locales ; et équipes qui ont besoin de « fonctionne sur tout ».

Verdict : Si vous êtes engagé avec NVIDIA et que la performance absolue vous importe, TensorRT-LLM mérite d'être dans la compétition. Vous échangez la portabilité contre la performance. Spécialisation optimisée mais moins de fonctionnalités.

Le reste du paysage

TGI est le serveur de production de Hugging Face avec traçage, métriques, parallélisme tensoriel et regroupement continu. Utilisez-le lorsque l'intégration HF et la simplicité comptent.

MLC LLM est le moteur de déploiement universel prioritairement compilateur avec des API compatibles OpenAI sur REST, Python, JavaScript, iOS et Android. Idéal pour « déployer des LLM partout », en particulier navigateur, mobile et applications natives.

ONNX Runtime GenAI implémente la boucle générative complète sur ONNX Runtime et alimente Foundry Local, Windows ML et le VS Code AI Toolkit. Il prend en charge CPU, CUDA, DirectML, TensorRT-RTX, OpenVINO, QNN, WebGPU et GPU AMD. Idéal pour le déploiement d'applications et les workflows ONNX.

OpenVINO GenAI est l'histoire optimisée Intel pour les CPU Xeon, les GPU Arc, les Core Ultra et les NPU. Il offre un service compatible OpenAI avec regroupement continu et attention paginée. Idéal pour le matériel Intel.

LMDeploy est une boîte à outils axée sur CUDA avec TurboMind pour la performance et PyTorch pour l'accessibilité. Plus intéressant pour les utilisateurs CUDA qui veulent une alternative à vLLM/SGLang/TensorRT-LLM.

NVIDIA Dynamo est une couche d'orchestration distribuée au-dessus des moteurs comme vLLM, SGLang et TensorRT-LLM, supportant la désagrégation, le routage intelligent et la mise en cache KV multi-niveaux. Utilisez-la lorsque le service avec un seul moteur ne suffit plus.

Note : N'UTILISEZ PAS Ollama.

Recettes de stratégie matérielle

• Serveur CPU uniquement : llama.cpp en premier. OpenVINO pour Intel Xeon. ONNX Runtime GenAI pour le déploiement d'applications/ONNX.
• MacBook / Mac Studio : MLX / MLX-LM pour les workflows natifs Mac. llama.cpp pour la portabilité GGUF.
• RTX 3090 / 4090 / 5090 unique : ExLlamaV2 pour l'inférence locale EXL2. llama.cpp pour GGUF ou la portabilité. vLLM si vous servez plusieurs utilisateurs.
• Boîte RTX grand public double ou quadruple : ExLlamaV3 pour l'inférence quantifiée multi-GPU ou MoE. vLLM si le comportement de service compte. SGLang si vous testez le routage ou les modèles à contexte long.
• Nœud 8×H100 / H200 : Commencez par vLLM ou SGLang. Évaluez TensorRT-LLM si uniquement NVIDIA et que la performance justifie l'optimisation. Utilisez Dynamo lorsque l'orchestration multi-nœud devient nécessaire.
• Infrastructure de classe B200 / GB200 / GB300 : Évaluez TensorRT-LLM, SGLang et vLLM. Ajoutez Dynamo pour l'orchestration au niveau de la flotte, le routage sensible au KV et l'auto-scaling.
• AMD MI300 / MI325 / MI350 / MI355 : Commencez par vLLM ou SGLang sur ROCm. Évitez de supposer que les benchmarks NVIDIA se transfèrent proprement.
• Intel Xeon / Core Ultra / Arc : OpenVINO GenAI ou OpenVINO Model Server. ONNX Runtime GenAI si l'intégration dans l'application compte.
• Navigateur, mobile, natif d'application : MLC LLM / WebLLM ou ONNX Runtime GenAI.

Benchmarking : quoi mesurer

Mauvais benchmark : « J'ai obtenu 180 tok/s. »

Un bon benchmark inclut :

• Modèle : modèle exact, architecture, nombre de paramètres, paramètres MoE actifs.
• Poids : dtype, format de quantification, taille de groupe, calibration.
• Moteur : version, commit, backend, flags.
• Matériel : SKU GPU, capacité mémoire, bande passante, interconnexion, CPU, RAM.
• Charge de travail : distributions de longueur entrée/sortie, concurrence, streaming, préfixes partagés, sortie structurée.
• Métriques : TTFT, TPOT, latence de bout en bout, p50/p95/p99, tokens par seconde, requêtes par seconde, utilisation mémoire GPU, taux de succès du cache KV, débit de préremplissage, débit de décodage, coût par million de tokens.

Règles de benchmarking :

1. Ne comparez jamais les moteurs en utilisant uniquement les tokens par seconde pour un seul utilisateur.
2. Testez votre distribution réelle de prompts et de sorties.
3. Testez avec une concurrence réaliste.
4. Séparez le préremplissage du décodage.
5. Suivez p95 et p99, pas seulement les moyennes.
6. Mesurez la marge mémoire à la longueur de contexte cible.
7. Testez la réutilisation du cache si votre application a des préfixes répétés.
8. Évaluez les sorties structurées séparément ; la grammaire ajoute une surcharge.
9. Évaluez LoRA et multi-LoRA séparément.
10. Retestez après les mises à jour de pilote, CUDA, ROCm, modèle ou moteur.

Erreurs courantes

• Choisir uniquement par la capacité VRAM. La VRAM détermine l'adéquation. La bande passante et le planificateur déterminent la vitesse. Une machine à mémoire unifiée de grande taille peut accueillir d'énormes modèles, mais un H100 décode plus rapidement lorsque le modèle tient grâce à une bande passante HBM beaucoup plus élevée.
• Utiliser le parallélisme tensoriel sur une interconnexion faible. Sans NVLink ou NVSwitch, testez le parallélisme de pipeline. La documentation de vLLM le mentionne pour les configurations de type L40S.
• Ignorer le cache KV. Un contexte long et une concurrence élevée peuvent faire du cache KV le facteur limitant. PagedAttention, la mise en cache des préfixes, la quantification du KV et la désagrégation ne sont pas optionnels à grande échelle.
• Traiter les moteurs locaux comme des serveurs de production. Le serveur llama.cpp est capable. Le serveur MLX-LM est pratique. Ollama est agréable mais NE DOIT PAS ÊTRE UTILISÉ.
• Cependant, la production signifie sécurité, observabilité, contre-pression, routage, auto-scaling et comportement SLA. MLX-LM lui-même avertit que son serveur n'est pas recommandé pour la production.
• Supposer que chaque format de quantification est portable. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, les formats MLX et ONNX ne sont pas interchangeables. Le bon format est celui pour lequel votre moteur a des noyaux optimisés.
• Ignorer l'architecture du modèle. Les modèles denses, MoE, l'attention hybride, les modèles multimodaux et les variantes à contexte long sollicitent différentes parties du moteur. Un support large ne signifie pas que chaque optimisation fonctionne également.
• Faire confiance aux graphiques de benchmark sans la forme de la charge de travail. Un graphique pour Llama 3.1 8B avec entrée 1K / sortie 128 n'en dit pas long sur un agent de codage avec un contexte de 80K fonctionnant sur Qwen 3.6 27B / Gemma 4 26B-A4B, ou un service RAG avec 500 utilisateurs simultanés.

La carte finale orientée

• Utilisateur IA local : LM Studio ou Harbor pour la commodité. llama.cpp pour le contrôle. MLX sur Mac. ExLlamaV2/V3 pour la performance CUDA locale.
• Construire un agent local : Tous devraient fonctionner, mais vu ce que la plupart des gens utilisent ; llama.cpp pour la portabilité. MLX si les utilisateurs sont sur Apple Silicon. vLLM si vous simulez un serveur de production localement.
• Servir une équipe interne : Commencez par vLLM. Utilisez SGLang si les sorties structurées, le contexte long, le multi-LoRA, le MoE ou le routage comptent.
• Servir des clients à grande échelle : Évaluez vLLM, SGLang et TensorRT-LLM. Si le routage et la désagrégation comptent, SGLang et Dynamo méritent l'attention.
• Centre de données NVIDIA : TensorRT-LLM pour la performance maximale. vLLM pour la flexibilité. SGLang pour le service complexe. Dynamo pour l'orchestration de flotte.
• Apple Silicon : MLX pour le développement natif. llama.cpp pour GGUF. La mémoire unifiée est un super-pouvoir de capacité avec des compromis de bande passante, pas de la HBM.
• Périphérie, application, navigateur ou natif Windows : llama.cpp, MLC LLM, ONNX Runtime GenAI ou OpenVINO, selon la pile.

Principe final

Les moteurs d'inférence ont des conséquences.

Choisissez le moteur après avoir répondu à ces questions :

1. Quel matériel ai-je réellement ?
2. Le modèle tient-il dans la mémoire rapide, ou seulement dans la mémoire système/unifiée ?
3. Le décodage ou le préremplissage est-il le goulot d'étranglement ?
4. Quelle longueur de contexte et quelle concurrence importent ?
5. Les prompts sont-ils suffisamment partagés pour la mise en cache des préfixes ?
6. Le modèle est-il dense, MoE, multimodal ou hybride ?
7. Ai-je besoin de commodité locale, de serveur de production ou d'orchestration de flotte ?
8. Quel format de quantification a des noyaux optimisés sur mon moteur cible ?
9. Mon interconnexion est-elle PCIe, NVLink, NVSwitch, Ethernet, RDMA ou Thunderbolt ?
10. Est-ce que j'optimise la latence, le débit, le coût, la confidentialité, la portabilité ou la vitesse de développement ?

Le moteur suit les réponses.

À la prochaine.

• Ahmad