@no_stp_on_snek: 当所有人都在讨论 @SpaceXAI、@AnthropicAI 和 @OpenAI 的更新（但 @GoogleAI 呢？）... 我去测试了…

X AI KOLs Timeline 工具
performance benchmark inference quantization vllm llama-cpp unsloth-ai nvfp4 qwen

摘要

Unsloth 的 NVFP4 量化模型在 vLLM 和 llama.cpp 之间推理性能的详细比较，重点说明了 vLLM 在预填充速度上的优势，但 llama.cpp 在单流智能体工作负载中的解码和缓存优势。

当所有人都在讨论 @SpaceXAI、@AnthropicAI 和 @OpenAI 的更新（但 @GoogleAI 呢？）... 我去测试了 @UnslothAI 的新 NVFP4 模型，以验证他们的说法。 Unsloth 的 NVFP4 检查点在 vLLM 上的预填充速度比我的 llama.cpp GGUF 快大约 2 倍。但我仍然保留了 GGUF，原因完全出乎我的意料。 Qwen3.6-27b NVFP4，单块 5090（32GB），WSL2。公平警告：我的 llama.cpp 使用的是 Blackwell 原生 NVFP4 内核分支，而非官方版本，所以官方构建无法复现这些数字。 预填充：vLLM 约 6600 tok/s，而 llama.cpp 约 2800-3400 tok/s。粗略估计 vLLM 快约 2 倍（我的 llama.cpp 数据是服务端计时，vLLM 是挂钟时间，所以我不会坚持精确的比率）。解码：llama.cpp 109 tok/s，vLLM 使用 MTP 推测解码为 97.9 tok/s，未使用时为 63.8 tok/s。llama.cpp 胜出。权重：16.6GB vs 20.5GB。冷启动：11 秒 vs 数分钟。 首先，我纠正一下自己，因为我差点发布了错误的结论。我曾以为 vLLM 将上下文限制在 32K。实际上并非如此。那个限制是我自己设置的——在内存溢出战斗中保守设定，此后从未重新探测过（感谢 Claude）。KV 池实际上容纳了约 94k 个 token。我的会话完全能容纳。评估时你总是会欺骗自己，而我就被自己骗了。 真正的原因不那么明显，也更有趣：vLLM 会自动为混合 Mamba/DeltaNet 架构禁用前缀缓存。因此，每个智能体回合都会从头开始重新预填充整个对话，在 36k token 时大约需要 5.5 秒。而 llama.cpp 会对循环状态进行检查点，在我的实际流量中达到 97-100% 的缓存命中率。 这就是关键所在。我的工作负载是一个智能体依次执行多个回合，不断发送增长的对话。vLLM 的 2 倍预填充优势被浪费在重复执行 llama.cpp 根本不需要做的工作上，而 llama.cpp 的解码优势则适用于生成的每一个 token。 是的，这是单个请求。这正是重点。vLLM 是为并发服务而构建的，单流是其最差情况。但单流恰恰是我的工作负载，这就是整个论点的核心。 如果你要尝试这个服务配置，以下是曲折经历：7 次尝试。其中四次在相同的约 52GB + 20GB 交换峰值时因 OOM 被杀死，不受编译并行性上限、多模态关闭、小批次、8k 上下文甚至完全 eager 模式的影响。模型加载从来不是问题（每次 14 秒内占用 20.5GB 显存）。峰值出现在加载之后，在性能分析和图捕获阶段，看起来是 vLLM 0.24 中混合门控 DeltaNet 架构特有的问题。它需要 70-100GB 的主机内存。通过将 WSL 提高至 58GB + 48GB 交换内存解决。这是 WSL2 的内存上限问题，原生 Linux 可能永远不会遇到。 公平地说，Unsloth 确实在冷启动的长上下文单次任务中获胜，首次 token 生成时间约快 2 倍。而且他们声称的“2.5 倍”是与其他的 vLLM NVFP4 量化版本对比得出的，因此这个说法完全可以成立，同时它仍然可能在解码方面输给 llama.cpp + MTP。我两者都验证过了，并不矛盾。 总结：请针对自己的工作负载进行基准测试。标题数字几乎从来不是对你最重要的那个数字。
查看原文
查看缓存全文

缓存时间: 2026/07/11 17:27

大家都在讨论 @SpaceXAI、@AnthropicAI 和 @OpenAI 的更新（但是 @GoogleAI 呢？）……

我专门测试了 @UnslothAI 的新 NVFP4 模型，验证了他们的说法。

unsloth 的 NVFP4 检查点在 vLLM 上的 prefill 速度大约是我用 llama.cpp GGUF 的 2 倍。但我还是坚持用 GGUF，而原因完全出乎我的意料。

Qwen3.6-27b NVFP4，单张 5090（32GB），WSL2。注意：我的 llama.cpp 用的是 Blackwell 原生 NVFP4 内核分支，不是官方版本，所以用官方构建无法复现这些数据。

Prefill：vLLM 约 6600 tok/s，llama.cpp 约 2800-3400 tok/s。vLLM 大概快 2 倍（我的 llama.cpp 数据是服务端计时，vLLM 是真实时钟，所以我不纠结精确比例）。Decode：llama.cpp 109 tok/s，vLLM 使用 MTP 推测解码 97.9 tok/s，不使用则 63.8 tok/s。llama.cpp 胜出。权重大小：16.6GB vs 20.5GB。冷启动时间：11 秒 vs 几分钟。

首先纠正我自己的一个错误，因为我差点发表了错误的结论。我之前以为 vLLM 把上下文限制在 32K，其实不是。那个限制是我自己设的，是在一次 OOM 冲突中保守设定的，之后再也没有重新测试（感谢 Claude）。实际上 KV 池能容纳约 94k tokens。我的会话本来完全够用。评估永远是自己骗自己，我也被自己骗了。

真正的原因不那么明显但更有趣：vLLM 对混合 Mamba/DeltaNet 架构会自动禁用前缀缓存。所以每个智能体轮次都会从头重新对整个对话进行 prefill，大约 36k tokens 要花 5.5 秒。而 llama.cpp 会检查点循环状态，在我的实际流量上达到 97-100% 缓存命中率。

这就是关键所在。我的工作负载是一个智能体依次执行轮次，不断发送增长中的对话。vLLM 的 2 倍 prefill 优势全用来重做 llama.cpp 根本不用做的工作，而 llama.cpp 的 decode 优势则体现在生成的每个 token 上。

是的，单个请求。这就是重点。vLLM 是为并发服务设计的，单流是它最差的情况。但单流恰恰是我的工作负载，这也是整篇论述的核心观点。

如果你也想尝试这个服务方案，提一下我的尝试过程：尝试了 7 次。其中 4 次在几乎相同的 ~52GB + 20GB 交换峰值时 OOM 被杀死，无论编译并行度限制、多模态关闭、小 batch、8k 上下文，甚至完全 eager 模式，这个峰值都不变。模型加载从未出问题（每次 14 秒内占用 20.5GB 显存）。这个峰值出现在加载之后，在 profiling 和图捕捉阶段，看起来是 vLLM 0.24 中混合门控 DeltaNet 架构的特有问题。它需要 70-100GB 的主机内存。解决办法是将 WSL 提高到 58GB + 48GB 交换空间。这是 WSL2 的内存上限问题，原生 Linux 可能永远不会遇到。

公平地说，unsloth：它在冷启动长上下文单次生成中确实有优势，首令牌时间大约快 2 倍。而且他们声称的“2.5 倍”是针对其他 vLLM NVFP4 量化版本测量的，所以这个说法完全可能属实，同时它在 decode 上仍然输给 llama.cpp + MTP。我检查了两者，并不矛盾。

总结：评估你自己的工作负载。标题上的数字几乎从来不是对你真正重要的数字。

相似文章