Tout le monde est obsédé par le nombre de paramètres. Modèle plus grand, meilleures réponses — jusqu’à ce que les tokens rampe vers le bas à trois par seconde et le ventilateur de votre GPU ressemble à un souffleur de feuilles. La moitié des gains de vitesse que les gens recherchent en passant d’un modèle 7B à 70B proviendraient simplement du réglage du runtime qu’ils ont déjà.
L’inférence LLM locale en 2026 est une pile de décisions : schéma de quantification, dtype du cache KV, taille de batch, cache de prompt, décodage spéculatif, stratégie de déchargement. Nous avons testé huit applications de bureau pour optimiser l’inférence LLM locale, des runtimes bas niveau qui exposent chaque levier aux outils emballés qui choisissent des valeurs par défaut sensées pour vous. Choisissez celui qui correspond à votre profondeur d’implication.
Ce qu’il faut rechercher dans une application d’optimisation d’inférence LLM locale
Tous les runtimes n’optimisent pas la même chose. Avant de choisir, sachez lequel de ces éléments vous avez réellement besoin :
- Support de la quantification. Le runtime doit lire les formats GGUF, EXL2, AWQ ou MLC et vous permettre de choisir la largeur de bits par modèle. 4-bit est l’standard moderne ; certaines charges de travail vont bien à 3-bit.
- Contrôles du cache KV. Le dtype du cache (fp16 vs q8_0 vs q4_0) et la taille du cache modifient tous deux l’utilisation de VRAM de manière substantielle. Le runtime doit vous permettre de les configurer.
- Réutilisation du cache de prompt. Pour le chat et la RAG, réutiliser le cache KV du message précédent est la différence entre les suites instantanées et un remplissage complet.
- Décodage spéculatif. Associer un petit modèle brouillon à un grand modèle cible peut doubler le débit sur le même matériel pour les charges de travail de chat.
- Multi-GPU et déchargement. Le déchargement couche par couche vers la RAM CPU, la division de tenseurs entre GPU et l’allocation consciente de NUMA importent une fois que les modèles deviennent grands.
- Gestion du traitement par lots et des requêtes concurrentes. Si vous servez plus d’un client, le débit à la taille de batch 8 ou 16 importe plus que la latence au batch 1.
Comparaison rapide
| Application | Meilleure pour | Plateformes | Forfait gratuit | Caractéristique exceptionnelle |
|---|---|---|---|---|
| llama.cpp | Quantification profonde + contrôle du cache KV | Windows, macOS, Linux | Entièrement gratuit, open source | Écosystème GGUF, déchargement par couche |
| Ollama | Runtime sans configuration avec des paramètres par défaut sensés | Windows, macOS, Linux | Gratuit | Échange de modèles en une ligne |
| LM Studio | GUI pour le réglage sans terminal | Windows, macOS, Linux | Gratuit | Paramètres de runtime visuels pour GGUF |
| vLLM | Service par lot avec PagedAttention | Linux, Windows via WSL | Gratuit, open source | Traitement par lots continu pour de nombreux clients |
| MLC LLM | Inférence compilée sur GPU | Windows, macOS, Linux | Gratuit, open source | Noyaux compilés par TVM, Metal + Vulkan |
| KoboldCpp | Réglage du jeu de rôle et de l’écriture créative | Windows, macOS, Linux | Gratuit, open source | UI de réglage du cache KV par prompt |
| ExLlamaV2 | Inférence EXL2 rapide sur Nvidia | Windows, Linux | Gratuit, open source | Quant EXL2 + décodage spéculatif |
| TabbyAPI | Serveur ExLlamaV2 compatible OpenAI | Windows, Linux | Gratuit, open source | Se connecte derrière n’importe quel client OpenAI |
Les applications
1. llama.cpp — Meilleur pour la quantification profonde et le contrôle du cache KV
llama.cpp est le runtime sur lequel la majorité de l’écosystème est construit. Il lit les quantifications GGUF de 8 bits à 2 bits, décharge couche par couche vers le CPU lorsque le modèle ne rentre pas en VRAM, et expose les paramètres dtype du cache pour que vous puissiez échanger la qualité contre de l’espace.
La surface de réglage est où la vitesse se trouve. Définir correctement --n-gpu-layers pour votre GPU, faire correspondre le dtype du cache à la quantification, activer --flash-attn et utiliser les fichiers de cache de prompt peuvent doubler le débit sur le même matériel.
Où il faiblit : La CLI est dense et la liste des flags change rapidement. Le premier réglage prend un après-midi de lecture de documentation.
Prix :
- Gratuit, open source.
Plateformes : Windows, macOS, Linux — CPU, CUDA, Metal, Vulkan, ROCm.
Téléchargement : llama.cpp sur GitHub
Résumé : Le runtime à utiliser quand la vitesse importe plus que la commodité.
2. Ollama — Meilleur pour un runtime sans configuration avec des paramètres par défaut sensés
Ollama enveloppe llama.cpp et choisit des paramètres par défaut qui amènent la plupart des gens à un débit acceptable sans toucher aux flags. Tirez un modèle, exécutez-le, c’est fait. Le format Modelfile vous permet de définir les prompts système, les paramètres d’échantillonnage et la longueur du contexte par modèle.
Pour une station de travail qui exécute quelques modèles en rotation, c’est le chemin le plus rapide d’« installé » à « utilisable ». Le réglage avancé se fait via les paramètres Modelfile plutôt que les flags de ligne de commande.
Où il faiblit : L’abstraction cache certains leviers qui extraient les 30% finaux de débit. Les utilisateurs avancés finissent souvent avec Ollama pour un usage casual et llama.cpp pour les travaux lourds.
Prix :
- Gratuit.
Plateformes : Windows, macOS, Linux.
Téléchargement : Ollama pour le bureau
Résumé : Le choix par défaut pour quelqu’un de nouveau aux LLM locaux qui veut la vitesse sans manuel.
3. LM Studio — Meilleur pour le réglage sans terminal
LM Studio expose les boutons d’optimisation de llama.cpp via une véritable interface graphique. La sélection de quant, n_gpu_layers, la longueur du contexte, le dtype du cache et la taille du batch obtiennent tous des curseurs et des menus déroulants au lieu de flags.
Cela en fait le meilleur choix pour les personnes qui comprennent ce que font les boutons mais ne veulent pas mémoriser la syntaxe CLI. Le chat intégré et le serveur API fonctionnent comme un banc d’essai pendant que vous effectuez le réglage.
Où il faiblit : GUI uniquement signifie que les scripts sont limités. Pour les serveurs headless, retournez à llama.cpp ou Ollama.
Prix :
- Gratuit pour un usage personnel et de loisir.
- Payant : Plans d’équipe pour les déploiements commerciaux.
Plateformes : Windows, macOS, Linux.
Téléchargement : LM Studio pour le bureau
Résumé : L’interface de réglage qui rend enfin llama.cpp accessible.
4. vLLM — Meilleur pour le service par lot avec PagedAttention
vLLM brille quand vous servez plusieurs requêtes concurrentes. PagedAttention gère le cache KV comme un allocateur de mémoire, empaquetant de nombreuses séquences actives dans le même VRAM sans fragmentation. Le traitement par lots continu signifie que les nouvelles requêtes s’intercalent entre les générations de tokens au lieu d’attendre la fin de la requête actuelle.
Pour un laboratoire domestique qui exécute un point de terminaison compatible OpenAI pour plusieurs applications à la fois, la courbe de débit de vLLM au batch 8 écrase les runtimes à requête unique.
Où il faiblit : D’abord Nvidia, moins mature sur AMD et Metal. Le compromis est que vous voudrez probablement un vrai GPU pour ça de toute façon.
Prix :
- Gratuit, open source.
Plateformes : Linux nativement, Windows via WSL.
Téléchargement : vLLM sur GitHub
Résumé : Le runtime pour quiconque sert plus d’un client depuis la même boîte.
5. MLC LLM — Meilleur pour l’inférence compilée sur GPU
MLC LLM fait un pari différent : compiler les noyaux du modèle avec TVM pour le matériel cible exact. Cela lui confère un support solide de Metal, Vulkan et WebGPU, ce qui importe si votre bureau est un Mac Studio ou une boîte AMD où les runtimes CUDA-first peinent.
Le résultat est un prefill et decode rapides sur du matériel où llama.cpp va bien mais n’est pas rapide. La compilation ajoute une étape unique par modèle par cible.
Où il faiblit : Le zoo de modèles est plus petit que celui de GGUF, et le flux de travail est plus lourd pour les nouveaux utilisateurs.
Prix :
- Gratuit, open source.
Plateformes : Windows, macOS, Linux, plus WebGPU dans les navigateurs.
Téléchargement : MLC LLM sur GitHub
Résumé : Le meilleur choix si votre GPU principal n’est pas une carte Nvidia.
6. KoboldCpp — Meilleur pour le réglage des jeux de rôle et de l’écriture créative
KoboldCpp est llama.cpp en dessous avec une interface graphique destinée à l’écriture longue et aux jeux de rôle. Cette charge de travail s’appuie fortement sur le cache KV — long contexte, relecture répétée de la même histoire jusqu’à présent — ainsi KoboldCpp expose les contrôles de réutilisation du cache et du context-shift de manière proéminente.
Les outils de scénario, les informations du monde et les fonctionnalités de mémoire en font également un excellent choix en dehors de son public cible. Quiconque exécute des prompts de contexte long bénéficie du réglage du cache.
Où il faiblit : L’interface est fonctionnelle plutôt que polie. Le mode serveur va bien mais l’expérience principale est le chat intégré.
Prix :
- Gratuit, open source.
Plateformes : Windows, macOS, Linux.
Téléchargement : Versions de KoboldCpp sur GitHub
Résumé : L’interface la plus accordée pour le travail de contexte long.
7. ExLlamaV2 — Meilleur pour l’inférence EXL2 rapide sur Nvidia
ExLlamaV2 est un moteur d’inférence CUDA-first qui lit le format de quantification EXL2. Sur le même GPU Nvidia, il surpasse généralement llama.cpp en tokens par seconde pour le même budget de qualité de bit effectif. Le décodage spéculatif avec un petit modèle brouillon lui donne un autre saut.
Pour une station de travail avec 3090, 4090 ou 5090 comme seul accélérateur, c’est ici que réside la vitesse. Associez avec TabbyAPI pour obtenir un point de terminaison compatible OpenAI.
Où il faiblit : Nvidia uniquement. Pas de Metal, pas d’histoire ROCm.
Prix :
- Gratuit, open source.
Plateformes : Windows, Linux avec GPU Nvidia.
Téléchargement : ExLlamaV2 sur GitHub
Résumé : Le runtime pour tirer la plupart des tokens par seconde d’une GPU Nvidia.
8. TabbyAPI — Meilleur pour un serveur ExLlamaV2 compatible OpenAI
TabbyAPI enveloppe ExLlamaV2 dans une API REST compatible OpenAI, donc tout ce qui parle déjà à OpenAI — Cursor, Continue, Aider, LibreChat — peut le substituer avec un changement d’URL de base. Le streaming, l’appel de fonction et le décodage spéculatif fonctionnent tous via la même surface d’API.
Pour quelqu’un dont la pile suppose déjà un point de terminaison OpenAI, TabbyAPI est le chemin le plus court du « modèle local sur disque » à « tout lui parle ».
Où il faiblit : La configuration est constituée de fichiers TOML, pas d’interface graphique. Déboguer la première configuration nécessite de la patience.
Prix :
- Gratuit, open source.
Plateformes : Windows, Linux avec GPU Nvidia.
Téléchargement : TabbyAPI sur GitHub
Résumé : Le pont qui permet à vos outils existants d’utiliser ExLlamaV2 sans rien changer d’autre.
Comment choisir le bon
Choisissez llama.cpp quand vous voulez un contrôle maximal et êtes prêt à apprendre les flags. Tout sur cette liste soit l’utilise, soit est mesuré contre.
Choisissez Ollama quand vous voulez la vitesse sans fichier de configuration. Cela vous mène 80% du chemin en une commande.
Choisissez LM Studio quand les flags de llama.cpp ressemblent à du chinois et que vous voulez la même surface de réglage avec des curseurs.
Choisissez vLLM quand la charge de travail est de nombreuses requêtes concurrentes. Le traitement par lots gagne à l’échelle.
Choisissez MLC LLM quand le GPU principal est Apple Silicon ou AMD. Les runtimes CUDA-first ont des performances médiocres sur ce matériel.
Choisissez KoboldCpp quand les prompts sont longs et que l’histoire importe. La gestion du contexte est tout son jeu.
Choisissez ExLlamaV2 (avec TabbyAPI) quand la boîte est Nvidia et que chaque milliseconde compte.
Restez sur le cloud uniquement si les modèles dont vous avez besoin n’ont pas de poids locaux, ou le volume de requêtes est assez important pour qu’un A100 loué soit moins cher que l’électricité pour en exécuter un localement.
FAQ
La quantification rend-elle vraiment les LLM locaux plus rapides ?
Oui, et bien plus que ce que la plupart des gens s’y attendent. Passer de fp16 à Q5_K_M sur le même modèle réduit généralement de moitié l’utilisation de VRAM et améliore les tokens par seconde sur les charges de travail liées au GPU, la perte de qualité étant suffisamment petite pour que la plupart des utilisateurs ne puissent pas la détecter dans les tests en aveugle.
Qu’est-ce que le décodage spéculatif ?
Le décodage spéculatif exécute un petit modèle « brouillon » pour deviner plusieurs tokens à l’avance, puis les vérifie dans un seul passage de grand modèle. Quand le brouillon est correct, vous obtenez plusieurs tokens par appel de grand modèle. Sur les charges de travail de chat, cela peut presque doubler le débit.
Qu’est-ce que PagedAttention et pourquoi cela importe pour les LLM locaux ?
PagedAttention est la technique de gestion du cache KV de vLLM. Au lieu d’allouer des emplacements de cache de taille fixe par requête, il traite la mémoire de cache comme des pages qui peuvent être allouées dynamiquement. Sur un serveur occupé, cela signifie que beaucoup plus de requêtes concurrentes tiennent dans le même VRAM.
Quel runtime LLM local est le plus rapide sur Apple Silicon ?
Les noyaux Metal compilés de MLC LLM sont généralement l’option mono-utilisateur la plus rapide sur Mac. Le backend Metal de llama.cpp est proche et plus facile à exécuter — choisissez MLC si 10 à 20% supplémentaires importent, llama.cpp sinon.
Puis-je exécuter un LLM local sans GPU discret ?
Oui. llama.cpp et Ollama s’exécutent tous deux sur CPU avec n’importe quel modèle GGUF. Les vitesses sur les ordinateurs portables modernes vont de quelques tokens par seconde sur les modèles 7B à un défilement lent sur 70B — utilisable pour le chat, douloureux pour les générations longues.