LLM auto hébergées · 24 October 2026

Le moteur local en 2026 : anatomie comparée des runtimes d’inférence qui font tourner vos LLM open source

Faire tourner un LLM open source chez soi n’est plus un exploit de bidouilleur : c’est devenu une infrastructure personnelle, et parfois d’entreprise. Mais entre llama.cpp, Ollama, vLLM, SGLang, MLX, Windows ML et les stacks distribuées comme llm-d 1.0, le vrai poste de coût caché n’est plus le matériel — c’est le choix du moteur. Panorama d’un écosystème fragmenté où le diable se cache dans les formats, les noyaux et le KV cache.

Le moteur local n’est plus un bricolage : pourquoi 2026 rebat les cartes

Il y a trois ans, faire tourner un modèle de langage sur sa propre machine relevait du tour de force. En 2026, la question n’est plus « est-ce possible ? » mais « avec quel moteur, et à quel prix réel ? ». La promesse d’un LLM open source chez soi sans se ruiner est devenue crédible — à condition de comprendre que le runtime, ce logiciel qui transforme des poids de plusieurs gigaoctets en tokens sortants, est devenu le véritable poste de coût caché.

Trois forces ont fait basculer l’inférence locale du statut de bidouille à celui d’infrastructure. D’abord, la maturation des formats de quantification : le GGUF, porté par llama.cpp, a rendu possible l’exécution de modèles volumineux sur du matériel grand public, avec des variantes comme Q4_K_M ou Q8_0 qui arbitrent finement taille et qualité. Ensuite, l’arrivée de machines à mémoire unifiée change la donne : les mini-PC à 128 Go de mémoire unifiée — qu’il s’agisse de l’AMD Ryzen AI Halo à 3 999 $, de l’Acer mini PC IA ou de l’AMD Gorgon Halo avec ses 192 Go — promettent de faire tourner des modèles jusqu’à 120B+, voire 200B+ pour les plus ambitieux. Enfin, la fragmentation elle-même : il n’existe pas un moteur, mais des familles aux compromis radicalement différents.

La thèse de ce panorama est simple : il n’y a pas de « meilleur » moteur d’inférence local en 2026. Il y a des familles — CPU-first, GPU-first, distribuées, propres à un OS — et le diable est dans les briques internes. Un même modèle quantifié dans deux formats peut produire des résultats et des débits très différents. Comprendre ces briques, c’est la seule manière de ne pas payer le prix fort en électricité, en temps d’ingénierie et en déceptions.

GGUF, safetensors, MLX, ONNX : la guerre des formats de poids n’est pas près de s’éteindre

Tout commence par le format des poids, car il conditionne absolument tout le reste : quels noyaux de calcul seront invoqués, quelle quantification sera possible, et sur quel matériel le modèle daignera s’exécuter.

Le GGUF est le format de la famille CPU-first, celui de llama.cpp et de ses dérivés. Il optimise la portabilité : un fichier GGUF embarque les poids quantifiés et les métadonnées nécessaires pour tourner sur Windows, macOS et Linux, avec ou sans GPU. C’est le format qui a démocratisé l’inférence locale, et sa documentation de 2026 détaille précisément les types de quantification à choisir, les tailles de fichiers et l’exécution selon l’OS. Sa force est aussi sa limite : pensé pour le CPU et l’offload, il n’exploite pas nativement les techniques de batching des serveurs GPU.

Le safetensors, lui, est le format des serveurs de batching comme vLLM et SGLang. Il optimise le chargement rapide sur GPU et se prête aux quantifications AWQ, GPTQ ou FP8, avec des noyaux de calcul spécialisés (cuBLAS, FlashAttention, kernels custom). C’est le format de ceux qui veulent du débit multi-utilisateur, pas de la simplicité d’installation.

Le MLX, format et framework d’Apple, optimise les noyaux Metal sur Apple Silicon. Il tire parti de la mémoire unifiée des Mac pour faire cohabiter CPU et GPU sans copie de données. Le ONNX, enfin, est le cheval de Troie de Microsoft : Windows ML a ajouté en octobre 2026 un support expérimental de llama.cpp pour les modèles GGUF, une API locale compatible OpenAI, la génération de texte ONNX et de nouveaux outils de runtime. Autrement dit, Microsoft parie sur l’interopérabilité des formats plutôt que sur un format propriétaire.

La mise en garde est essentielle : la conversion d’un format à l’autre n’est pas neutre. Un modèle quantifié en Q4_K_M dans GGUF et le même modèle en AWQ sur safetensors ne donneront ni les mêmes résultats ni les mêmes débits. Les stratégies de quantification — Q4_K_M, Q8_0, i-quants côté GGUF ; AWQ, GPTQ, FP8 côté GPU — ne sont pas interchangeables, et les noyaux invoqués diffèrent. Choisir un moteur, c’est d’abord choisir un format, et donc un écosystème de quantifications.

CPU-first contre GPU-first : le duel des moteurs qui ne jouent pas au même jeu

La première grande fracture de l’écosystème oppose la famille GGUF/CPU-first aux serveurs de batching GPU-first. Elles ne répondent pas aux mêmes besoins et ne s’adressent pas aux mêmes utilisateurs.

La famille CPU-first — llama.cpp, Ollama, LM Studio, KoboldCpp — mise sur la simplicité d’installation et l’offload CPU/GPU. llama.cpp, dont la version 0.5.0 fait l’objet d’un guide pratique en 2026, a considérablement mûri : backend, modèles, serveur, vérification GPU, llama-server et dépannage sont désormais documentés. Ollama propose une bibliothèque de modèles prêts à l’emploi, et KoboldCpp (v1.123.1, licence AGPL-3.0) supporte Windows, Linux, macOS, les GPU NVIDIA et AMD ainsi qu’Apple Silicon, avec une API compatible OpenAI. Ces moteurs sont incontournables pour un solo : on installe, on télécharge un GGUF, et ça tourne.

La famille GPU-first — vLLM avec PagedAttention, SGLang avec RadixAttention, TGI — vise le débit multi-utilisateur et la gestion fine du KV cache. Elle excelle quand plusieurs requêtes arrivent en parallèle et qu’il faut maximiser les tokens par seconde agrégés. Mais le « production-ready » de ces serveurs ne tient pas sur un laptop : ils exigent un GPU dédié, une VRAM confortable, et une certaine expertise pour être configurés. ExLlamaV2, par exemple, est documenté comme nécessitant 8 Go de VRAM minimum, avec support multi-GPU — un seuil qui exclut d’emblée les machines modestes.

Il existe des ponts entre les deux mondes. candle-vllm (v0.9.1, licence MIT) supporte macOS, Windows et Linux, les GPU NVIDIA, Apple Silicon, et même le multi-GPU et le multi-nœuds, avec une API compatible OpenAI. exo (Apache-2.0, macOS/Linux) combine API compatible OpenAI, Apple Silicon, inférence CPU et multi-nœuds. Ces projets hybrides brouillent la frontière, mais chacun reste ancré dans une philosophie : simplicité d’un côté, débit de l’autre.

KV cache, batching continu et speculative decoding : les trois leviers qui font vraiment la différence

Si les formats et les familles posent le décor, ce sont trois mécanismes internes qui départagent réellement les runtimes : la gestion du KV cache, le batching continu et le speculative decoding.

Le KV cache est la mémoire des tokens déjà traités. vLLM l’a révolutionné avec PagedAttention, qui fragmente le cache en pages pour éviter le gaspillage mémoire. SGLang pousse plus loin avec RadixAttention, qui réutilise les préfixes communs entre requêtes. llama.cpp gère un cache par préfixe, plus simple mais efficace pour un usage solo. Ce levier change tout en latence : un cache bien géré réduit le time-to-first-token (TTFT) et évite les saturations mémoire qui provoquent des OOM.

Le batching continu, propre à vLLM, SGLang et TGI, permet de traiter plusieurs requêtes simultanément en insérant de nouvelles demandes dans le lot en cours. C’est ce qui fait la différence entre un serveur qui sert dix utilisateurs et un moteur qui en sert un. Mais sur du matériel grand public, le batching continu sature vite le cache et la VRAM : le gain multi-utilisateur se paie en latence individuelle.

Le speculative decoding — draft models, Medusa, EAGLE — consiste à faire générer des tokens par un petit modèle rapide, puis à les valider par le grand modèle. Bien configuré, il peut accélérer la génération de manière significative ; mal configuré, il ajoute un surcoût mémoire et dégrade la qualité. Les directions techniques visibles dans les trackers de releases à fin 2026 pointent vers une standardisation de ces approches (EAGLE, Medusa), mais les données chiffrées manquent encore pour trancher sur matériel grand public.

Le piège est toujours le même : ces trois leviers sont conçus pour des serveurs GPU avec beaucoup de VRAM. Sur un laptop, ils peuvent se retourner contre l’utilisateur. Un moteur CPU-first sans batching continu reste souvent plus prévisible et plus économe pour un usage solo.

Mémoire unifiée, offload et petits clusters : la topologie matérielle dicte le choix du moteur

Le matériel conditionne le runtime, et c’est peut-être l’enseignement le plus important de 2026. Selon que vous êtes sur un laptop, un mini-PC à mémoire unifiée ou un petit cluster, le bon moteur change du tout au tout.

Sur un laptop CPU seul ou avec GPU discret (RTX 4090/5090), la famille GGUF/CPU-first tire son épingle du jeu. llama.cpp avec offload CPU/GPU permet de faire tourner des modèles qui ne tiennent pas entièrement en VRAM. Les gains d’optimisation sont réels : sur un iGPU AMD Radeon 780M, les optimisations Vulkan de llama.cpp ont apporté un gain d’inférence de +50 %, et le réglage MMVQ +12,9 %, avec des débits de l’ordre de 10-12 tok/s sur Llama 3 8B Q4 et Qwen 2.5 7B, et 8-11 tok/s sur Mistral 7B Q4_K_M. Ce sont des chiffres modestes, mais suffisants pour un usage personnel.

Sur un mini-PC à mémoire unifiée, la donne change. Les Mac M3/M4 Ultra et les machines à mémoire unifiée comme l’AMD Strix Halo (256 Go/s de bande passante, bus 256 bits, 16 cœurs Zen 5) ou le Ryzen AI Halo (128 Go, jusqu’à 120B+ de modèles, 3 999 $) permettent de charger des modèles volumineux sans les fragmenter entre RAM et VRAM. MLX sur Apple Silicon exploite les noyaux Metal et la mémoire unifiée ; sur PC, llama.cpp avec offload reste la voie royale. La limite réelle est la bande passante mémoire : 256 Go/s, c’est correct mais loin des GPU discrets haut de gamme.

Sur un petit cluster PME (2 à 8 GPU ou nœuds), les serveurs GPU-first et les stacks distribuées prennent le relais. vLLM et SGLang sur GPU unique, llm-d 1.0 pour le distribué. Les limites sont connues : support ROCm/AMD inégal, GPU Intel absents des comparatifs, et complexité opérationnelle.

llm-d 1.0, KServe, Ray Serve : le « production-ready » qui ne l’est pas pour une PME

Fin octobre 2026, llm-d 1.0 a fait une entrée remarquée. La stack open source d’inférence distribuée, portée par Google Cloud avec un routage cache-aware pour les flottes TPU et GPU, a été présentée à la PyTorch Conference. IBM Research a confirmé une réduction de coût d’inférence de 11,5×. Sur le papier, c’est la solution d’inférence à l’échelle : routage cache-aware, orchestration Kubernetes, multi-modèles, autoscaling.

Mais il faut distinguer la promesse de la réalité d’une PME sans équipe plateforme. llm-d 1.0 suppose une maîtrise de Kubernetes, une observabilité encore jeune, et une complexité opérationnelle qui n’a rien à voir avec un ollama run. Les stacks distribuées comme KServe et Ray Serve partagent ce profil : elles se justifient quand on sert des dizaines de modèles à des centaines d’utilisateurs, pas quand on héberge deux modèles pour une équipe de dix personnes.

Le routage cache-aware est la vraie innovation : il dirige les requêtes vers le nœud qui a déjà le préfixe en cache, réduisant le TTFT. Mais pour en bénéficier, il faut déjà avoir une flotte. Pour une PME, le piège est de croire que « production-ready » signifie « prêt à l’emploi ». Ces stacks sont prêtes pour la production à grande échelle, pas pour une PME qui veut juste faire tourner un modèle sur un serveur.

Le coût par token en électricité : le chiffre que personne ne met dans sa plaquette

Au-delà du matériel, le vrai coût d’un LLM local est l’électricité et le temps d’ingénierie. C’est le chiffre que personne ne met dans sa plaquette marketing, et pourtant c’est lui qui décide de la rentabilité.

La méthode de calcul est simple en théorie : consommation idle plus consommation en charge, multipliée par le prix du kWh, divisée par le nombre de tokens produits. En pratique, tout dépend du moteur et du matériel. Un GPU qui tourne à pleine charge consomme beaucoup plus qu’un CPU en offload ; un moteur qui sature le cache et provoque des OOM fait perdre du temps et de l’énergie en redémarrages. Les optimisations de noyaux — Vulkan, MMVQ — réduisent la consommation par token en réduisant le temps de calcul.

La comparaison avec les API cloud et les abonnements est instructive : le local reste rentable quand le volume est élevé, que la confidentialité est critique ou que la latence doit être maîtrisée. Pour un usage occasionnel, une API cloud reste souvent moins chère. Les benchmarks marketing annoncent des débits impressionnants, mais les mesures tierces sur matériel grand public sont plus modestes — d’où l’importance de croiser les sources et de se méfier des chiffres sans protocole.

Ce qui se dessine dans les trackers de releases : vers des runtimes hybrides et une observabilité native

Les directions techniques visibles fin 2026 dessinent un avenir plus interopérable. Le speculative decoding se standardise (EAGLE, Medusa), l’offload et la mémoire unifiée se généralisent, le routage cache-aware (llm-d, Gateway API Inference Extension) sort des laboratoires, la quantification FP8/FP4 progresse avec des noyaux adaptatifs, et les API OpenAI-compatibles convergent — Windows ML, candle-vllm, KoboldCpp, exo en proposent tous une.

Pour un particulier ou une PME qui doit choisir aujourd’hui, le conseil est de parier sur un écosystème ouvert et interopérable plutôt que sur un moteur isolé. Garder la flexibilité de changer de runtime sans réentraîner ses modèles, c’est choisir des formats standard (GGUF, safetensors) et des API compatibles OpenAI. Les signaux à surveiller : les releases GitHub, les RFC, et les benchmarks indépendants — pas les plaquettes.

En synthèse, la grille de décision est claire : solo sur laptop, restez sur llama.cpp ou Ollama ; mini-PC à mémoire unifiée, MLX sur Apple et llama.cpp sur PC ; petit cluster, vLLM ou SGLang ; et llm-d 1.0 seulement si vous avez déjà une équipe plateforme. Le moteur local en 2026 n’est plus un bricolage — mais il n’est pas non plus un choix anodin.

Sources

• Windows ML: 2026 Updates for GGUF Models and Local AI — Techgenyz (9 octobre 2026)
• AI Development on Windows: from PyTorch and llama.cpp to Windows ML — Microsoft Foundry Blog (7 octobre 2026)
• llama.cpp v0.5.0 in 2026: What Changed, How to Install, Run GGUF & Use the Local API — Gyanaangan (27 septembre 2026)
• Modèles GGUF : types de quantification et exécution — Convly (9 septembre 2026)
• Faire tourner une IA en local en 2026 : guide complet — Brief IA (18 septembre 2026)
• Performance LLM sur GPU AMD Radeon 9070XT — QuellLM (25 septembre 2026)
• Google Cloud Ships llm-d 1.0 With Cache-Aware Routing for TPU and GPU Fleets — MarkTechPost (20 octobre 2026)
• Open-Source llm-d 1.0 Hits Production: IBM Research Confirms 11.5× AI Inference Cost Drop — TechTimes (21 octobre 2026)
• Llm-D 1.0 Debuts at PyTorch Conference with Production Inference Stack — Unite.AI
• Local LLM Inference Engines Compared: The Definitive 2026 Guide — Local LLM
• Local LLM Engines and Tools: Release Tracker — Local Model Watch
• Local LLM Inference 2026 — Ollama, vLLM, SGLang, GGUF Quantization — Singularity Moments
• PromptQuorum — comparatif des runtimes d’inférence locaux 2026

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