mrsaynothing.dev
vLLM 跑 GGUF 常见问答：十个来自搜索的问题，一次答清
十个关于 vLLM 和 GGUF 的真实搜索问题——CPU 支持、serve 语法、量化覆盖、tokenizer 陷阱——按官方文档和我们实测过的文章作答。
五分钟核对清单
失败模式有一张表——从上到下过一遍。
| 症状 | 原因 | 解法 |
|---|---|---|
serve 时 404 或 "model not found" |
GGUF 按纯路径传入——vLLM 要 repo:quant_type |
改用 repo:quant_type 形式（下一节） |
| 加载时 tokenizer 报错 | --tokenizer 缺失或指向 GGUF 仓库 |
指向原始基础模型仓库 |
| 在 Ollama/llama.cpp 能跑，在 vLLM 拒绝 | 同一文件，不同引擎——vLLM 的 GGUF 路径只认显卡 | CPU 机器留在 llama.cpp |
| 加载时量化方案被拒 | 插件不覆盖的冷门量化 | 降到 Q4_K_M 或同类——参见 量化指南 |
Can vLLM run GGUF ?
能——走官方的 vllm-gguf-plugin，在 NVIDIA 和 AMD 显卡上。插件是 vLLM 自家出的，不是社区 fork。两半都要紧：插件是官方的，而且硬件表在显卡那里就打住了。完整 serve 流程在 Can vLLM Run GGUF? Yes — on GPU Only。
vLLM 在 CPU 上支持 GGUF 吗？
不支持。vLLM 的 GGUF 路径背后没有 CPU 内核——x86/Arm CPU 和 Intel 显卡都在支持硬件表之外。这就是经典报错背后的陷阱：同一个在笔记本上于 vLLM 里 404 的 GGUF，在 Ollama 里跑得好好的，因为 GGUF 的主场就是 CPU 优先的引擎。文件从来不是问题。
怎么用 vLLM 伺服 GGUF 模型？
一行——仓库、量化类型、tokenizer：
vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B
语法是 repo:quant_type。陷阱在 --tokenizer 这个参数：它写的是原始模型仓库，永远不是 GGUF 仓库——GGUF 文件只装权重，vLLM 要的是源模型里真正的那套 tokenizer。
验证：伺服起来，然后 nvidia-smi——vLLM 进程占用的应该是显存，不是系统内存。
vLLM 支持哪些 GGUF 量化？
大家真会下载的那些 K 系量化——Q4_K_M 之类——能用；奇怪的方案就未必。llama.cpp 仍是该格式的参考实现，所以新的量化方案和新模型架构都先落在那里，之后才进插件。下载任何东西之前，先用 GGUF 量化指南算算体积。
vLLM 的 GGUF 支持能上生产吗？
文档自己就答了这句："vLLM 中的 GGUF 支持非常实验性且未充分优化。"这句话就放在官方 GGUF 页的第一段——比大多数实验特性得到的诚实多了。把插件当成复用已有文件的途径，并给通往 llama.cpp 的退路留门。
vLLM 加载 GGUF 比 llama.cpp 快吗？
不快——而且速度从来不是重点。llama.cpp 把文件 mmap 进内存，GGUF 就地懒启动；vLLM 则像装载任何 checkpoint 一样加载它。vLLM 里的 GGUF 是个内存足迹特性：文档把它说成缩小显存占用的办法，不是吞吐玩法。吞吐收益完全在别处——batching；而且这份启动开销每次重启都要再付一遍，不像 kv-cache 在模型驻留期间一直摊销。
vLLM 还是 llama.cpp 跑 GGUF——谁赢？
同一个文件，相反的本能：llama.cpp 把 GGUF 当格式本身，vLLM 把它当可选件。一张卡伺候几个人 → vLLM 加插件。一个人、任意硬件、要最全的量化选择 → llama.cpp，一个二进制。正面对比表——CPU、并发、量化覆盖、安装——在 深挖篇里。
我的 GGUF 文件在 vLLM 里为什么失败？
三种真实原因，都在上表里：serve 语法写错（用纯路径而不是 repo:quant_type）、--tokenizer 缺失或写错，或者硬件不在支持表里。第四种更少见：插件不覆盖的量化方案。从上到下过一遍表——前三行覆盖了大多数报错。
Ollama 能跑 GGUF 吗？
能——原生支持；GGUF 是 Ollama 的默认格式，不是外加品。从 Hugging Face 拉一个 GGUF，指给 Ollama，完事。如果跑起来时显卡还在闲着，那是另一个问题，自有它的检查清单：Ollama Not Using GPU? Fix It。
几个用户能共用一台 vLLM GGUF 服务器吗？
这正是 vLLM 为之存在的唯一任务：连续 batching 让并发请求在一份已加载的模型上排队。GGUF 插件继承了这套机器——诚实的注脚是文档自己那句"未充分优化"，所以如果你在给共享服务器算容量，先在你的卡上实测你的量化，再答应任何人任何数字。这一话题簇假定的一切——格式、引擎、硬件——都画在 本地跑 LLM 枢纽里。
还有一个陷阱：装得下，一上负载就内存爆掉
单用户跑得好好的 GGUF，一旦 batching 按并发请求数翻倍 kv-cache，照样可能挤爆显存。权重瘦了；缓存却随每个用户增长。降并发、缩上下文，或者把量化再降一档——这套算容量的逻辑和任何 vLLM 部署一样。
上面的十个答案各追溯到两个出处：vLLM 官方文档和我们自己的 serve 日志。还没人发布的是一份基准——同一张卡上，插件的 Q4_K_M 对 llama.cpp 里的同一个文件，tok/s 并排比。那个基准跑完，会先落进 本地 LLM 枢纽。