Gufo 性能实测……Qwen 27B 拿到 70 tok/s，但你得看清细则。

最近所有人都在喊，说我不该再用 halogen 了，应该改用 Gufo，因为它开源，而且“要么一样好、要么更好”。我去看了一眼他们的 GitHub（GitHub.com/gufo-org/gufo），立马就……“Qwen 27B Q4：单用户 70.56 tok/s，8 用户 123 tok/s”，而且是在 Strix Halo 设备上？那必须得试试啊……所以我今天终于忍不住动手试了。 环境配置：从他们官方的 podman 镜像安装的 gufo 0.4.0，模型用的是 Unsloth 的 Qwen3.8 27B UD-Q4_K_XL，外加 DFlash2 Q4_K_M 草稿模型，基准测试用的是他们自带的脚本和默认设置（贪心解码、关闭思考模式、输出 128 个 token、关闭 prompt 缓存）。如果你想先看结论……是的，我测到了 70.22 tok/s。所以这个数字是真的。但产生这个数字的 prompt 是“把这个词 red 恰好写 1000 遍”。 但这个数字也不算真的。在这组数字里，所有速度都来自投机解码。草稿模型一次向前猜大约 7 个 token，27B 主模型在一遍推理中校验，只保留它认可的部分。当输出是一个词不断重复时，草稿模型每次猜都对。而在真实 prompt 上，它大概只对一半。 他们的基准测试里还有另外一组共九条普通 prompt（一段 C++、一道应用题、一段摘要、意大利语、中文、JSON、一小段小说、一份调试清单）。在这些 prompt 上： | | 重复单词的 prompt | 普通 prompt | |---|---|---| | 1 用户 | 70.2 tok/s | 中位数 39.4 tok/s，不同 prompt 从 22 到 52 不等 | | 8 用户，他们公布的“聚合”数字 | 122.6 | 82.4 | | 8 用户，实际交付的 token 数 | 82 | 52 | 关于最后一行：那个“123 tok/s 聚合”数字，是把每个请求的解码速度加在一起得出的，不包含 prompt 处理时间和排队时间。如果你只按墙上时钟时间统计实际从输出口出来的 token 数，那就是 82 tok/s，普通 prompt 上则是 52。 公平地说，gufo 团队并没有隐瞒这些。他们的基准测试文档里有独立的“混合”和“重复”两列，公布的混合数字和我测出来的一致。只是仓库描述和 README 顶部只展示了最好的情况。而且在 APU 上，27B 模型以 Q4 量化跑出 39 tok/s 仍然相当不错。他们文档显示，如果没有草稿模型，速度大约只有 12 tok/s。 我还想知道的另一件事是，它与 halogen（peonist-ai/halogen-flash-server，我平时用的那个）相比如何。两者都能跑 Qwen3.8 Flash-Next，所以我把它放在两个服务上，向两边发送完全相同的 prompt。两台机器，相同的硬件、相同的系统镜像。贪心解码、关闭思考模式、输出 256 token。 | | halogen 0.13.8 | gufo 0.4.0 | |---|---|---| | 九条普通 prompt 的平均解码速度 | 43.9 tok/s | 38.2 tok/s | | 4 个用户同时使用，端到端 | 76.6 tok/s | 63.1 tok/s | | 冷启动 prompt 处理，约 9.7k token | 1288 tok/s | 1495 tok/s | | 那个“red” prompt | 56.9 tok/s | 87.4 tok/s | 所以对于日常生成，单用户场景下 halogen 快约 13%，四用户场景下快约 18%。gufo 在处理长 prompt 时快 16%，在重复性 prompt 上则快得多。 我再补充几点，免得有人在评论区质疑： - 我知道权重并不相同。halogen 使用它自己的 4-bit 格式，gufo 使用 Unsloth 的 GGUF。我只测了速度，完全没有比较输出质量。 - 那是两台不同的机器，但硬件和软件完全相同，我的机器在其他基准测试上结果一致度在 1% 以内。但毕竟是两台机器。 - 正面对比每个配置只跑了一轮。复现他们数字的部分则重复了 3 次。 - gufo 在过去四天里已经发布了四个版本，所以这些数据到下周可能就过时了。 gufo 还有很多与性能无关的、我很喜欢的优点。它接受普通的 GGUF 格式，许可证是 MIT，27B 模型加载大约只需 3 秒（Flash-Next 是 13 秒），每条请求的日志行会告诉你草稿命中率和缓存命中情况，还支持 8 个批处理会话。它还有 ASR、TTS 和图像模型，这些我还没碰过。他们的基准测试会对有无草稿模型的输出分别做哈希，每次结果都完全相同，说明投机解码路径不会改变模型的输出内容。 如果你也想试试，有一点需要注意：它会提前为每个会话预留内存。4 个会话、64k 上下文的 Flash-Next 占用了 94GB。所以这并不是什么障眼法。我检查的所有内容都能复现。只是要知道，那个 70 是只有在你的工作负载是极其可预测的文本时才能达到的天花板，用普通任务时请按 27B 大约 30 多 tok/s 来做规划。 我把整套环境都保留下来了，打算接下来几天继续研究实际的输出质量。如果有人想看特定的测试，我很乐意跑其他 prompt 或用不同设置试一试。