■ 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 的支持高度实验性且未经充分优化。」 具体来说:
- 量化覆盖比 llama.cpp 窄。 大家真正会下载的 K 量化(Q4_K_M 及其同类)都能用;冷门方案未必。llama.cpp 仍是该格式的参考实现。
- 架构支持滞后。 新模型家族先落地 llama.cpp,插件晚一步跟上。
- 没有 mmap 式的懒加载。 llama.cpp 把文件内存映射;vLLM 像加载任何 checkpoint 那样加载它。
- 首先是一项省内存的特性。 文档把 GGUF 定位成压缩 VRAM 占用的手段,不是吞吐的玩法。
这些都没藏着 —— 全在官方 GGUF 页面的第一段里,这待遇已经比大多数实验性特性好。
同一个文件,相反的直觉
| vLLM + GGUF | llama.cpp | |
|---|---|---|
| CPU 推理 | 不能 | 能,头等着 |
| 并发用户 | continuous batching,为它而生 | 有限 |
| 量化覆盖 | 子集,实验性 | 参考标准 |
| 安装 | vLLM + 插件 | 一个二进制 |
| 最适合 | 一张 GPU,多个用户 | 一个用户,什么硬件都行 |
从一张 GPU 服务一支团队?vLLM + GGUF 复用 local-LLM 世界里通用的那些 Q4_K_M 文件。
一个用户、任何硬件?llama.cpp 一个二进制就是整个格式。
一行规则: 同一个文件,相反的直觉 —— llama.cpp 把 GGUF 当格式,vLLM 把它当选项。
译员的柜台到此为止 · 没有任何 fetch · 全程本地