■ space · 译员的柜台

■ 先说答案

能 —— vLLM 能跑 GGUF,经由 vllm-gguf-plugin, 只在 GPU 上。

语法 repo:quant_type + --tokenizer 基础模型; x86/Arm CPU 与 Intel GPU:不支持。

一张 GPU 多个并发用户 → vLLM;没有 GPU,或要最宽的量化覆盖 → llama.cpp。

文档原话: 「高度实验性且未经充分优化」 —— 省内存的特性,不是吞吐的玩法。

在柜台

先说文件在什么之上跑。柜台核对客人名单 —— vLLM 官方的量化硬件兼容表 —— 然后盖章判词。

支持

GGUF 这条路的背后是 GPU 内核 —— 插件把块反量化,直接进批量服务。请到柜台。

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

客人名单出处:vLLM 官方量化硬件兼容表 —— 挡在门外是架构性的:GGUF 这条路背后没有 CPU 内核,因为 vLLM 是服务引擎,不是笔记本玩具

柜台

两步,外加一面从不装饰的旗标:

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

干净开局。 文档推荐用基础模型的 tokenizer,因为 GGUF tokenizer 转换「耗时且不稳定,特别是对某些大词表模型」。一行,没有漫长的启动。

GGUF 支持不再随 vLLM 核心自带 —— 文档注明它「已迁往 OOT vllm-gguf-plugin 」;光一个 pip install vllm 不够。

两张 GPU、一个模型: --tensor-parallel-size 2 把同一个 GGUF 分片到两张卡上。

从 CPU 上的 Ollama 过来的?那是引擎的事,不是格式的事 —— llama.cpp 在树莓派上都能跑 GGUF。GGUF 这条路背后,vLLM 没有 CPU 内核。

硬件这把锁上面还有一把:操作系统。Windows 上的 vLLM 意味着 WSL2 —— 绕过它就要交 fork 税。

诚实的限界清单

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

这些都没藏着 —— 全在官方 GGUF 页面的第一段里,这待遇已经比大多数实验性特性好。

同一个文件,相反的直觉

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

从一张 GPU 服务一支团队?vLLM + GGUF 复用 local-LLM 世界里通用的那些 Q4_K_M 文件。

一个用户、任何硬件?llama.cpp 一个二进制就是整个格式。

一行规则: 同一个文件,相反的直觉 —— llama.cpp 把 GGUF 当格式,vLLM 把它当选项。

■ 诚实印记 看法来自文档,不是我的实测台。 实测环境:公开记录 —— vLLM + vllm-gguf-plugin · NVIDIA Volta → Hopper · AMD GPU。2026-09-23 记录,2026-10-12 刷新。这里的一切都来自 vLLM 文档与 vllm-project/vllm 仓库的公开记录(自 2023 年 2 月起 92,000+ 星):客人名单逐字来自他们的硬件兼容表,警告原话用引号标出,没有虚构任何 tokens-per-second 来补缺。

译员的柜台到此为止 · 没有任何 fetch · 全程本地