vLLM peut-il faire tourner du GGUF ? Oui — via le plugin, sur GPU uniquement\nLe plugin, la syntaxe repo:quant, le drapeau tokenizer jamais optionnel — et la table matérielle qui refuse les CPU à la porte.\n

■ space · le bureau de l'interprète

■ la réponse d'abord

Oui — vLLM fait tourner du GGUF, via vllm-gguf-plugin, sur GPU uniquement.

Syntaxe repo:quant_type + --tokenizer modèle de base ; CPU x86/Arm et GPU Intel : non pris en charge.

Un GPU, beaucoup d'utilisateurs simultanés → vLLM ; pas de GPU ou la plus large couverture des quants → llama.cpp.

Les mots des docs eux-mêmes : « très expérimental et sous-optimisé » — une fonctionnalité d'empreinte mémoire, pas un pari de débit.

AU BUREAU

Dites sur quoi tourne le fichier. Le bureau vérifie sa liste d'invités — la table officielle de compatibilité matérielle des quants de vLLM — et tamponne un verdict.

PRISE EN CHARGE

Les noyaux GPU sont derrière le chemin GGUF — le plugin déquantize les blocs directement en service par lots. Avancez au comptoir.

route : uv pip install vllm-gguf-plugin → vllm serve repo:quant

source de la liste d'invités : la table officielle de compatibilité matérielle des quants de vLLM — le refus est architectural : aucun noyau CPU ne se trouve derrière le chemin GGUF, parce que vLLM est un moteur de service, pas un joujou de portable

LE COMPTOIR

Deux étapes, et un drapeau qui n'est jamais décoratif :

uv pip install vllm-gguf-plugin

# directly from Hugging Face, repo_id:quant_type format:
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M \
  --tokenizer Qwen/Qwen3-0.6B

# or a local file you already downloaded:
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf \
  --tokenizer Qwen/Qwen3-0.6B

démarrage propre. Les docs recommandent le tokenizer du modèle de base parce que la conversion des tokenizers GGUF est « chronophage et instable, surtout pour certains modèles à grands vocabulaires ». Une ligne, pas de long démarrage.

La prise en charge GGUF ne se livre plus dans le cœur de vLLM — les docs notent qu'elle « a migré vers OOT vllm-gguf-plugin » ; un simple pip install vllm ne suffit pas.

Deux GPU, un modèle : --tensor-parallel-size 2 partage le même GGUF sur les deux cartes.

Vous arrivez d'Ollama sur CPU ? C'est le moteur, pas le format — llama.cpp fait tourner du GGUF sur des Raspberry Pis. vLLM n'a aucun noyau CPU derrière le GGUF.

Un verrou surplombe celui du matériel : l'OS. vLLM sur Windows signifie WSL2 — le sauter coûte l'impôt du fork.

LA LISTE HONNÊTE DES LIMITES

La même page des docs porte une mise en garde digne d'être citée verbatim : « La prise en charge GGUF dans vLLM est très expérimentale et sous-optimisée. » Concrètement :

La couverture des quants est plus étroite que llama.cpp. Les K-quants que les gens téléchargent réellement (Q4_K_M et compagnie) fonctionnent ; les schémas exotiques peuvent ne pas le faire. llama.cpp reste l'implémentation de référence du format.
La prise en charge d'architectures est en retard. Les nouvelles familles de modèles débarquent d'abord dans llama.cpp ; le plugin suit plus tard.
Pas de chargement paresseux façon 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. Les docs présentent GGUF comme un moyen de réduire l'usage VRAM, pas un pari de débit.

Rien de tout cela n'est caché — tout est dans le premier paragraphe de la page GGUF officielle, ce qui est plus que la plupart des fonctionnalités expérimentales n'obtiennent.

MÊME FICHIER, INSTINCTS OPPOSÉS

	vLLM + GGUF	llama.cpp
Inférence CPU	non	oui, de première classe
Utilisateurs simultanés	batching continu, conçu pour ça	limité
Couverture des quants	sous-ensemble, expérimental	la référence
Installation	vLLM + plugin	un seul binaire
Idéal pour	un GPU, beaucoup d'utilisateurs	un utilisateur, tout matériel

Servir une équipe à partir d'un GPU ? vLLM + GGUF réutilise les mêmes fichiers Q4_K_M que le reste du monde local-LLM.

Un utilisateur, tout matériel ? llama.cpp est un seul binaire et le format entier.

La règle d'une ligne : même fichier, instincts opposés — llama.cpp traite le GGUF comme le format, vLLM le traite comme une option.

■ cachet d'honnêteté Les docs, pas mon banc d'essai. Testé sur : le dossier public — vLLM + vllm-gguf-plugin · NVIDIA Volta → Hopper · GPU AMD. Noté 2026-09-23, rafraîchi 2026-10-12. Tout ce qui est ici vient de la documentation vLLM et du dossier du dépôt vllm-project/vllm (92 000+ étoiles depuis février 2023) : la liste d'invités est leur table de compatibilité matérielle verbatim, les mises en garde sont leurs mots entre guillemets, et aucun tokens-par-seconde n'a été inventé pour combler les trous.

fin du bureau de l'interprète · rien de fetché · tout est local