vLLM 能跑 GGUF 吗？十个问题，先给答案

vLLM 通过官方的 vllm-gguf-plugin 跑 GGUF，只在 NVIDIA 和 AMD GPU 上。serve 语法是 repo:quant_type，外加一个必须存在、指向原始模型的 --tokenizer。在 CPU 上，答案仍然是 llama.cpp。

一张卡伺候几个人 → vLLM + vllm-gguf-plugin。一个人、任意硬件、要最全的量化选择 → llama.cpp，一个二进制。没有 GPU 或者 Intel GPU → llama.cpp，CPU 是一等公民。两个引擎读的是同一个 GGUF；差别在于各自优化什么——按硬件和人数选，别按文件格式选。

能——走官方的 vllm-gguf-plugin，在 NVIDIA 和 AMD GPU 上。插件是 vLLM 自家出的，不是社区 fork。两半都要紧：插件是官方的，而且硬件表在 GPU 那里就打住了。

不支持。vLLM 的 GGUF 路径背后没有 CPU 内核——x86/Arm CPU 和 Intel GPU 都在支持硬件表之外。这就是经典报错背后的陷阱：同一个在笔记本上于 vLLM 里 404 的 GGUF，在 Ollama 里跑得好好的，因为 GGUF 的主场就是 CPU 优先的引擎。文件从来不是问题。

一行——仓库、量化类型、tokenizer：

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

语法是 repo:quant_type。陷阱在 --tokenizer 这个参数：它写的是原始模型仓库，永远不是 GGUF 仓库——GGUF 文件只装权重，vLLM 要的是源模型里真正的那套 tokenizer。

大家真会下载的那些 K 系量化——Q4_K_M 之类——能用；奇怪的方案就未必。llama.cpp 仍是该格式的参考实现，所以新的量化方案和新模型架构都先落在那里，之后才进插件。

文档自己就答了这句："vLLM 中的 GGUF 支持非常实验性且未充分优化。"这句话就放在官方 GGUF 页的第一段——比大多数实验特性得到的诚实多了。把插件当成复用已有文件的途径，并给通往 llama.cpp 的退路留门。

不快——而且速度从来不是重点。llama.cpp 把文件 mmap 进内存，GGUF 就地懒启动；vLLM 则像装载任何 checkpoint 一样加载它。vLLM 里的 GGUF 是个内存足迹特性：文档把它说成缩小 VRAM 占用的办法，不是吞吐玩法。吞吐收益在 batching——完全在别处。

具体三种原因：serve 语法写错（用纯路径而不是 repo:quant_type）、--tokenizer 缺失或写错，或者硬件不在支持表里。第四种更少见：插件不覆盖的量化方案。从上到下过一遍下面的表——前三行覆盖了大多数报错。

能——原生支持；GGUF 是 Ollama 的默认格式，不是外加品。从 Hugging Face 拉一个 GGUF，指给 Ollama，完事。如果跑起来时 GPU 还在闲着，那是另一个问题，自有它的检查清单。

这正是 vLLM 为之存在的唯一任务：连续 batching 让并发请求在一份已加载的模型上排队。 GGUF 插件继承了这套机器——诚实的注脚是文档自己那句"未充分优化"， 所以如果你在给共享服务器算容量，先在你的卡上实测你的量化，再答应任何人任何数字。 还有另一个陷阱：单用户跑得好好的 GGUF，一旦 batching 按并发请求数翻倍 KV cache，照样可能挤爆 VRAM—— 权重瘦了；缓存却随每个用户增长。降并发、缩上下文，或者把量化再降一档。