Comparatif des moteurs d'inférence

Le moteur est le programme qui transforme les poids en jetons : il charge le fichier, exécute la passe avant du transformer et parle généralement HTTP par-dessus. La bonne nouvelle, c'est que presque tous les moteurs exécutent le même modèle à peu près à la même vitesse sur le même matériel — le choix de moteur relève du flux de travail, du support de format et de la concurrence, pas du tok/s brut. La mauvaise nouvelle est la même : chasser les benchmarks entre eux est surtout de l'effort gaspillé.

Le paysage

Une note de lignée : Ollama et LM Studio exécutent tous deux llama.cpp sous le capot. Les comparer à llama.cpp, c'est comparer l'emballage, pas l'inférence.

À savoir aussi : llama.cpp livre plus qu'un serveur — des outils de quantification et de conversion, un harnais de benchmark et des bindings pour une douzaine de langages.

Pour aller plus loin

vLLM est né de l'intuition de la paged attention (voir concurrence) : traiter la mémoire GPU comme un OS traite la RAM, et bien plus de requêtes tiennent. C'est la réponse par défaut à « j'ai un serveur GPU et du vrai trafic ».

SGLang met en cache les préfixes entre requêtes (RadixAttention) : si 40 agents partagent le même prompt système de deux pages, le prompt est traité une fois, pas 40. Il est aussi connu pour son décodage contraint rapide — voir sortie structurée.

exllamav2 est le tranchant pour exactement une niche : un utilisateur unique sur un GPU NVIDIA unique voulant le maximum de tok/s par bit de quantification. L'histoire serveur et la portée matérielle sont minces ; la niche est réelle.

MLX est le framework ML d'Apple, construit pour la mémoire unifiée. À ce jour, mlx-lm bat souvent le chemin Metal de llama.cpp sur les gros modèles — d'assez près pour qu'un Mac mérite d'essayer les deux (plus dans Apple Silicon).

transformers est la référence lente et fidèle : quand un moteur quantifié fait quelque chose d'étrange, exécuter le même modèle à travers lui répond « est-ce le moteur ou le modèle ? ». C'est aussi la plomberie sous les outils de fine-tuning (voir fine-tuning).

Choisir selon le besoin

Deux notes sur le tableau :

• « Commencez par » n'est pas « vous limitez à » — chaque moteur de bureau lit le même GGUF, essayer un second coûte cinq minutes, pas une migration.
• Quand vous comparez vraiment, tenez tout constant : même modèle, même quant, même prompt, modèle déjà chaud.

La division de format reflète la division bureau/serveur

GGUF contre safetensors (voir formats de modèles) n'est pas qu'une préférence de conteneur — cela décide de votre moteur. GGUF est le format fichier unique, pré-quantifié, qui tourne partout, et tout l'écosystème bureau (llama.cpp, Ollama, LM Studio) est construit dessus. safetensors est le format de tenseurs shardés de l'écosystème Hugging Face ; les moteurs serveur à haut débit (vLLM, SGLang, transformers) le consomment, généralement quantifié à la volée (variantes AWQ/GPTQ) plutôt que pré-empaqueté.

L'arbre de décision réel est donc court : bureau et mono-utilisateur → moteurs GGUF ; serveur et simultané → moteurs safetensors. Tout le reste est du détail.

Quand quelque chose « ne peut pas tourner », vérifiez d'abord le format — la moitié des « le moteur X ne peut pas exécuter le modèle Y » est un décalage GGUF/safetensors, pas un écart de capacité.

Les frais généraux ne font pas l'histoire

Sur un matériel identique avec un quant identique, les moteurs atterrissent à peu près à 10–20% les uns des autres en décodage flux unique — souvent parce qu'ils partagent un backend. Ce qui fait réellement bouger votre vitesse perçue par multiples, pas en pourcents :

• Que le modèle soit déjà chargé — un chargement à froid coûte de quelques secondes à une minute.
• Que toute la conversation soit renvoyée à chaque tour — coût de contexte, voir jetons.
• Que les requêtes fassent la file derrière les autres — voir concurrence.
• Que les couches soient sur le GPU — voir paramètres moteur.

Même GPU, même 8B Q4_K_M, flux unique (illustratif, pas des specs) :
llama.cpp / Ollama / LM Studio    ~130–145 tok/s   (même moteur en dessous)
exllamav2 EXL2 ~4bpw              ~160–180 tok/s   (chargeur réglé pour le décodage)

Même GPU, 8 flux de chat simultanés :
llama-server file sérielle        chaque flux attend ; débit total plat
vLLM                              tous les flux proches de la vitesse flux unique

Choisissez le moteur qui colle à votre flux de travail, puis dépensez votre énergie sur les motifs d'E/S plutôt que sur les benchmarks de moteurs.

Un fichier, plusieurs moteurs

Un GGUF téléchargé pour Ollama tourne aussi directement dans llama.cpp et dans LM Studio — les moteurs ne convertissent ni ne retéléchargent ; vous les pointez sur le même fichier (Ollama peut importer un chemin local avec un Modelfile d'une ligne). Pareil côté serveur pour le safetensors entre vLLM et SGLang. Conséquence pratique : pas de verrou fournisseur au niveau fichier, et se tromper de moteur coûte des minutes.

Voilà pourquoi cette page pousse le flux de travail plutôt que les benchmarks : quand vos besoins changent, les modèles déjà téléchargés vous suivent.

Quand passer à autre chose qu'Ollama

Les défauts d'Ollama sont excellents jusqu'à ce qu'ils ne le soient plus. Passez à un moteur de service quand :

• Vous avez besoin d'une concurrence soutenue au-delà de quelques flux (voir concurrence).
• Vous voulez un cache de préfixe entre nombreux agents partageant un prompt système (SGLang).
• Vous devez servir des quants safetensors AWQ/GPTQ directement depuis l'écosystème HF.
• Vous testez en charge une fonctionnalité produit avant de la livrer.
• Vous avez besoin de parallélisme de tenseurs multi-GPU pour faire tenir un gros modèle entre cartes.

Tant qu'aucune n'est vraie, le confort vaut plus que le débit.

Voir aussi : formats de modèles · paramètres moteur · servir un endpoint · choisir un modèle