La semaine dernière, un lecteur demandait pourquoi son fichier GGUF échoue dans vLLM sur une machine sans GPU alors que le même fichier tourne sans problème sous Ollama. Réponse courte, avant tout le reste : oui, vLLM exécute le GGUF — via un plugin officiel, sur GPU uniquement. Le plugin s’appelle vllm-gguf-plugin, la syntaxe est repo:quant_type, et dès que vous tentez la chose sur CPU, vous sortez du tableau matériel supporté. Tout ce qui suit vient de la documentation vLLM et de l’historique du dépôt vllm-project/vllm (92 000+ étoiles depuis février 2023) — les docs, pas mon banc de test.
Comment servir un modèle GGUF avec vLLM ?
Deux étapes : installer le plugin, puis pointer vLLM vers le modèle. Le support GGUF ne fait plus partie du cœur de vLLM — la doc précise qu’il « a migré vers vllm-gguf-plugin », donc un simple pip install vllm ne suffit pas :
uv pip install vllm-gguf-plugin
# Directement depuis Hugging Face, format repo_id:quant_type :
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M
--tokenizer Qwen/Qwen3-0.6B
# Ou un fichier local déjà téléchargé :
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf
--tokenizer Qwen/Qwen3-0.6B Le flag --tokenizer n’est pas décoratif. La doc officielle recommande le tokenizer du modèle de base car la conversion du tokenizer GGUF est « longue et instable, en particulier pour les modèles à grand vocabulaire ». S’en passer, c’est échanger un flag d’une ligne contre un démarrage long et capricieux.
Deux GPU, un modèle : ajoutez --tensor-parallel-size 2 pour répartir le même GGUF sur les deux cartes — le tensor parallelism fonctionne avec GGUF comme avec n’importe quel autre format.
Pourquoi vLLM refuse-t-il le GGUF sur CPU ?
C’est la partie qui surprend. La réputation du GGUF, c’est d’abord le CPU — c’est le format sur lequel llama.cpp a bâti sa légende, sur des laptops et des Raspberry Pi. Dans vLLM, la situation s’inverse. Le tableau officiel de compatibilité matérielle marque le GGUF :
| Matériel | GGUF dans vLLM |
|---|---|
| NVIDIA Volta / Turing / Ampere / Ada / Hopper | supporté |
| GPU AMD | supporté |
| GPU Intel | non supporté |
| CPU x86 | non supporté |
| CPU Arm | non supporté |
Source : documentation quantization vLLM. La raison est architecturale : le chemin GGUF de vLLM déquantise les blocs vers des kernels GPU conçus pour le servicing par lots. Il n’y a pas de kernel CPU derrière, car vLLM est un moteur de service, pas un jouet de laptop. Sans GPU sur la machine, aucun flag ne vous sauvera — passez à llama.cpp.
Ce qui casse : la liste honnête des limites
La même page de doc porte un avertissement à citer tel quel : « le support GGUF dans vLLM est hautement expérimental et sous-optimisé. » Concrètement :
- La couverture des quantizations est plus étroite que llama.cpp. Les K-quants que tout le monde télécharge (Q4_K_M et compagnie) fonctionnent ; les schémas exotiques, pas toujours. llama.cpp reste l’implémentation de référence du format.
- Le support des architectures traîne. Les nouvelles familles de modèles arrivent d’abord dans llama.cpp ; le plugin suit.
- Pas de chargement paresseux type mmap. llama.cpp mappe le fichier en mémoire ; vLLM le charge comme n’importe quel checkpoint.
- C’est d’abord une fonctionnalité d’empreinte mémoire. La doc présente le GGUF comme un moyen de réduire l’usage VRAM, pas un pari sur le débit.
Rien de tout cela n’est caché. Tout est dans le premier paragraphe de la page GGUF officielle — ce n’est pas donné à toutes les fonctionnalités expérimentales.
vLLM ou llama.cpp pour le GGUF : qui gagne ?
Des outils différents qui lisent le même fichier :
| vLLM + GGUF | llama.cpp | |
|---|---|---|
| Inférence CPU | non | oui, premier citizen |
| Utilisateurs simultanés | continuous batching, conçu pour | limité |
| Couverture des quants | sous-ensemble, expérimental | la référence |
| Installation | vLLM + plugin | un binaire |
| Idéal pour | un GPU, plusieurs utilisateurs | un utilisateur, tout matériel |
Si vous servez un modèle à une équipe depuis un seul GPU, vLLM + GGUF permet de réutiliser les mêmes fichiers Q4_K_M que le reste du monde local-LLM partage — avec plus de choix dans notre guide des quantizations GGUF. Pour la comparaison complète des moteurs, voir llama.cpp vs Ollama et comment exécuter des modèles GGUF en local.
La règle en une ligne : même fichier, instincts opposés — llama.cpp traite le GGUF comme LE format, vLLM comme une option.
FAQ
vLLM peut-il exécuter des modèles GGUF ?
Oui. Installez le vllm-gguf-plugin, puis servez avec la syntaxe repo:quant_type — mais uniquement sur GPU. Le chemin CPU de vLLM ne couvre pas le GGUF.
vLLM exécute-t-il du GGUF sur CPU ?
Non. Le tableau officiel de compatibilité matérielle marque le GGUF comme non supporté sur CPU x86 et Arm — llama.cpp ou Ollama restent la voie CPU.
Servir du GGUF avec vLLM ou llama.cpp ?
vLLM quand un seul GPU doit servir plusieurs utilisateurs simultanés ; llama.cpp quand la machine n'a pas de GPU ou pour la couverture de quantizations la plus large.
— mrsaynothing
— mrsaynothing
Notes de terrain sur l'IA, Linux et l'auto-hébergement.
Recevez le prochain how-to par e-mail
Un e-mail par article. Réparez et avancez.
qu'est-ce que c'est ?128k de contexte sur desktop : mensonge. Le cache KV l'a mangé.
Ces notes vous plaisent ? Je vis de ce métier. engagez-moi