vLLM peut-il exécuter du GGUF ? Dix questions, répondues d'abord

vLLM exécute le GGUF via le plugin officiel vllm-gguf-plugin, uniquement sur GPU NVIDIA et AMD. La syntaxe de serve est repo:quant_type avec un --tokenizer obligatoire pointant vers le modèle original. Sur CPU, llama.cpp reste la réponse.

Un GPU qui sert plusieurs personnes → vLLM + vllm-gguf-plugin. Une personne, n'importe quel matériel, le plus large choix de quants → llama.cpp, un seul binaire. Pas de GPU ou GPU Intel → llama.cpp, CPU de première classe. Les deux moteurs lisent le même GGUF ; la différence est ce qu'ils optimisent — choisissez par matériel et par effectif, pas par format de fichier.

Oui — via le plugin officiel vllm-gguf-plugin, sur GPU NVIDIA et AMD. Le plugin est celui de vLLM lui-même, pas un fork communautaire. Les deux moitiés comptent : le plugin est officiel, et le tableau du matériel s'arrête au GPU.

Non. vLLM n'a aucun kernel CPU derrière son chemin GGUF — les CPU x86/Arm et les GPU Intel sont hors du tableau du matériel pris en charge. C'est le piège derrière le signalement classique : le même GGUF qui renvoie 404 dans vLLM sur un portable tourne parfaitement dans Ollama, car le terrain natal du GGUF, ce sont les moteurs CPU-d'abord. Le fichier n'a jamais été le problème.

Une ligne — le dépôt, le type de quant, et le tokenizer :

vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B

La syntaxe est repo:quant_type. Le piège est l'option --tokenizer : elle nomme le dépôt du modèle original, jamais le dépôt GGUF — les fichiers GGUF portent des poids, et vLLM veut le vrai tokenizer du modèle source.

Les K-quants que les gens téléchargent réellement — Q4_K_M et compagnie — fonctionnent ; les schémas exotiques peuvent non. llama.cpp reste l'implémentation de référence du format, si bien que les nouveaux schémas de quant et les nouvelles architectures y débarquent d'abord et n'atteignent le plugin que plus tard.

La doc répond elle-même : « Le support GGUF dans vLLM est hautement expérimental et sous-optimisé. » Cette phrase siège dans le premier paragraphe de la page officielle GGUF — plus d'honnêteté que la plupart des fonctions expérimentales en reçoivent. Considérez le plugin comme un moyen de réutiliser des fichiers que vous avez déjà, et gardez la sortie vers llama.cpp ouverte.

Non — et la vitesse n'a jamais été l'enjeu. llama.cpp maquette le fichier en mémoire, donc un GGUF démarre avec paresse ; vLLM le charge comme n'importe quel checkpoint. Le GGUF dans vLLM est une fonction d'empreinte mémoire : la doc le présente comme un moyen de réduire l'usage VRAM, pas un jeu de débit. Le gain de débit, c'est le batching — entièrement ailleurs.

Trois causes réelles : une mauvaise syntaxe de serve (chemin brut au lieu de repo:quant_type), un --tokenizer manquant ou erroné, ou un matériel hors du tableau pris en charge. Une quatrième est plus rare : un schéma de quant que le plugin ne couvre pas. Parcourez le tableau ci-dessous de haut en bas — les trois premières lignes couvrent la plupart des signalements.

Oui — nativement ; le GGUF est le format par défaut d'Ollama, pas un add-on. Tirez un GGUF depuis Hugging Face, pointez Ollama dessus, voilà. Si le GPU reste oisif pendant l'exécution, c'est un autre problème, avec sa propre liste de contrôle.

C'est la seule mission pour laquelle vLLM existe : le batching continu met en file les requêtes concurrentes contre un modèle chargé une seule fois. Le plugin GGUF hérite de cette machinerie — l'honnête réserve est la ligne « sous-optimisé » de la doc elle-même, si bien que si vous dimensionnez un serveur partagé, mesurez votre quant sur votre carte avant de promettre qui que ce soit un chiffre. Et encore un piège : un GGUF qui sert très bien un seul utilisateur peut quand même exploser la VRAM quand le batching multiplie le cache KV par requête concurrente — les poids ont rétréci ; le cache grossit à chaque utilisateur. Réduisez la concurrence, raccourcissez le contexte, ou descendez le quant d'un cran.