vLLM & GGUF FAQ : dix questions de recherche, répondues

tl;dr

Oui, vLLM exécute le GGUF — via le plugin officiel vllm-gguf-plugin, uniquement sur GPU NVIDIA/AMD.
CPU et GPU Intel : non pris en charge — llama.cpp est la voie dans ces cas, et c'est de toute façon l'implémentation de référence du format.
La syntaxe de serve est repo:quant_type plus --tokenizer avec le dépôt original du modèle — l'option tokenizer n'est jamais facultative.

Ces dix questions sortent directement des données de recherche de ce site même — chacune est une requête pour laquelle nous nous classons avec zéro ou quasi-zéro clics. Les réponses viennent de la doc officielle vLLM et de notre étude approfondie testée Can vLLM Run GGUF?.

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.

testé sur : Volta → Hopper · GPU AMD · vLLM + vllm-gguf-plugin · source : documentation officielle vLLM

le bilan de cinq minutes

fig 1 — choisissez par matériel et par effectif, pas par format de fichier. Les deux moteurs lisent le même GGUF ; la différence est ce qu'ils optimisent.

Connaissez votre matériel : GPU NVIDIA/AMD, ou CPU seulement
Comptez vos utilisateurs : vous seul, ou plusieurs sur un serveur
GPU + plusieurs utilisateurs → installez vllm-gguf-plugin, prenez la commande serve ci-dessous
Servez, puis appelez l'endpoint une fois pour confirmer

Les modes d'échec ont un tableau — parcourez-le de haut en bas.

tout syntax CPU quant

Symptôme	Cause	Correction
`404` ou « modèle introuvable » au serve	GGUF passé comme chemin brut — vLLM veut `repo:quant_type`	Utilisez la forme `repo:quant_type` (section suivante)
Erreur de tokenizer au chargement	`--tokenizer` manquant ou pointé vers le dépôt GGUF	Pointez-le vers le dépôt du modèle de base original
Tourne dans Ollama/llama.cpp, refuse dans vLLM	Même fichier, moteur différent — le chemin GGUF de vLLM est GPU-seulement	Les machines CPU restent sous llama.cpp
Schéma de quant rejeté au chargement	Quant exotique hors de la couverture du plugin	Redescendez à `Q4_K_M` ou compagnie — voir le guide de quantification

Can vLLM run GGUF ?

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. Le pas-à-pas complet de serve se trouve dans Can vLLM Run GGUF? Yes — on GPU Only.

vLLM prend-il en charge le GGUF sur CPU ?

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.

Comment sert-on un modèle GGUF avec vLLM ?

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.

vérification : servez-le, puis nvidia-smi — le processus vLLM doit tenir de la VRAM, pas de la RAM système.

Quels quants GGUF vLLM prend-il en charge ?

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. Avant de télécharger quoi que ce soit, évaluez la taille avec le guide de quantification GGUF.

Le support GGUF de vLLM est-il prêt pour la production ?

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.

vLLM charge-t-il le GGUF plus vite que llama.cpp ?

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 se trouve entièrement ailleurs : le batching — et ce coût de mise en route se répète à chaque redémarrage, à la différence du kv-cache qui paie son loyer tant que le modèle reste chargé.

vLLM ou llama.cpp pour le GGUF — qui gagne ?

Même fichier, instincts opposés : llama.cpp traite le GGUF comme le format, vLLM comme une option. Un GPU qui sert plusieurs personnes → vLLM plus le plugin. Une personne, n'importe quel matériel, le plus large choix de quants → llama.cpp, un seul binaire. Le tableau face-à-face — CPU, concurrence, couverture des quants, installation — est dans l'étude approfondie.

Pourquoi mon fichier GGUF échoue-t-il dans vLLM ?

Trois causes réelles, toutes dans le tableau ci-dessus : 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 de haut en bas — les trois premières lignes couvrent la plupart des signalements.

Ollama exécute-t-il le GGUF ?

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 : Ollama Not Using GPU? Fix It.

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. Tout ce que ce cluster suppose — le format, les moteurs, le matériel — est cartographié dans le hub run-LLMs-locally.

Encore un piège : ça charge, puis ça pète la mémoire sous charge

Un GGUF qui sert très bien un seul utilisateur peut quand même exploser la VRAM quand le batching multiplie le kv-cache 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 — la logique de dimensionnement est la même que pour tout déploiement vLLM.

Les dix réponses ci-dessus remontent à deux sources : la documentation officielle vLLM et nos propres logs de serve. Ce que personne n'a encore publié, c'est un banc — Q4_K_M via le plugin contre le même fichier dans llama.cpp sur une seule carte, tok/s côte à côte. Quand ce banc tournera, il atterrira d'abord dans le hub local-LLM en premier.