vLLM 能跑 GGUF 吗？能——但只在 GPU 上

上周有读者问：为什么他的 GGUF 文件在无 GPU 的机器上被 vLLM 拒收，同一个文件在 Ollama 里却跑得好好的。先给短答案：能。vLLM 可以跑 GGUF——通过官方插件，但只在 GPU 上。 插件叫 vllm-gguf-plugin，语法是 repo:quant_type；一旦你在 CPU 上尝试，就已经出了官方支持硬件表的范围。下文全部来自 vLLM 官方文档和 vllm-project/vllm 仓库记录（2023 年 2 月至今 9.2 万+ star），是文档，不是我的实测台架。

GGUF 模型怎么用 vLLM serve？

两步：装插件，然后把 vLLM 指向模型。GGUF 支持已经不住在 vLLM 内核里——文档写明它「已迁移到 vllm-gguf-plugin」，所以只敲 pip install vllm 不够：

uv pip install vllm-gguf-plugin

# 直接从 Hugging Face 加载，repo_id:quant_type 格式：
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M 
  --tokenizer Qwen/Qwen3-0.6B

# 或者用已下载的本地文件：
vllm serve ./Qwen3-0.6B-Q4_K_M.gguf 
  --tokenizer Qwen/Qwen3-0.6B

--tokenizer 不是摆设。官方文档建议用基座模型的 tokenizer，因为 GGUF 的 tokenizer 转换「耗时且不稳定，对大词表模型尤其如此」。省掉这一行，等于拿一个 flag 去换一次漫长又看心情的启动。

两张 GPU，一个模型：加 --tensor-parallel-size 2，同一个 GGUF 会切到两张卡上——张量并行对 GGUF 一视同仁。

vLLM 为什么在 CPU 上拒绝 GGUF？

这是最反直觉的部分。GGUF 的江湖名声是 CPU 优先——llama.cpp 正是靠它在笔记本和树莓派上扬名。而在 vLLM 里，位置整个倒了过来。官方硬件兼容表给 GGUF 的判定是：

硬件	vLLM 中的 GGUF
NVIDIA Volta / Turing / Ampere / Ada / Hopper	支持
AMD GPU	支持
Intel GPU	不支持
x86 CPU	不支持
Arm CPU	不支持

来源：vLLM 量化文档。原因是架构性的：vLLM 的 GGUF 路径把块反量化进为批量 serving 设计的 GPU kernel，背后没有任何 CPU kernel——因为 vLLM 是服务引擎，不是笔记本玩具。机器上没有 GPU，任何 flag 都救不了你，请用 llama.cpp。

会坏什么：一份诚实的限制清单

同一页文档里有一句值得原样引用的警告：「vLLM 的 GGUF 支持高度实验性且未经充分优化」。具体来说：

• 量化覆盖比 llama.cpp 窄。 大家都在下的 K-quant（Q4_K_M 之流）能用；冷门方案就未必。格式的参考实现仍然是 llama.cpp。
• 架构支持慢半拍。 新模型家族先落在 llama.cpp，插件随后跟进。
• 没有 mmap 式的懒加载。 llama.cpp 把文件映射进内存；vLLM 像普通 checkpoint 一样整体加载。
• 它首先是省内存的功能。 文档把 GGUF 定位为压低 VRAM 占用的手段，不是吞吐量的赌注。

这些都没有藏着掖着。全都写在官方 GGUF 页面的第一段——比大多数实验性功能坦率得多。

GGUF 供 vLLM 与 llama.cpp 之争：谁赢？

读同一个文件的两把不同工具：

	vLLM + GGUF	llama.cpp
CPU 推理	不行	行，一等公民
并发用户	continuous batching，为它而生	有限
量化覆盖	子集，实验性	参考标准
安装	vLLM + 插件	一个二进制
最适合	一块 GPU，多个用户	单用户，什么硬件都行

如果你要用一块 GPU 给团队供模型，vLLM + GGUF 让你复用 local-LLM 世界通用的同一批 Q4_K_M 文件——更多选择见我们的 GGUF 量化指南。引擎的完整对比，见 llama.cpp vs Ollama 与如何本地运行 GGUF 模型。

一句话规则：同一个文件，相反的本能——llama.cpp 把 GGUF 当成正主，vLLM 把它当成选项之一。