测到 223 token/s 之后，我为什么切回 llama.cpp

本地模型部署很容易被“每秒生成多少 token”牵着走。我也做过一次这样的切换：在双 RTX 2080 Ti 22GB 上，尝试使用面向 Turing 显卡的 vLLM 定制分支，配合 Qwen3.8-27B 的 NVFP4 权重和 DFlash2 草稿模型。短请求测得很快，但真实客户端的输出无法稳定使用。最后，我把服务切回了原来的 llama.cpp 方案。

为什么会尝试这条路线

当时 llama.cpp + Q4_K_M + MTP 已能完成基础推理，256K 上下文与单图输入也已通过单项检查。但真实交互速度仍有提升空间。社区定制分支公开了双 22GB 2080 Ti、双卡张量并行、FP8 KV Cache 和 DFlash2 的配置，并报告了特定单请求测试下的 200 token/s 以上解码速度。这个数字给了我试验的理由，不是我机器的预期保底值。

要让这套方案在 sm_75 上启动，实际还处理了驱动、CUDA 13、内核编译和部分 FlashInfer 兼容问题。最终服务能启动，/health 返回 200，未授权的模型接口返回 401，短文本、单图、工具调用和接近 256K 的长输入分别通过了基础检查。

在固定小输入、单并发、温度 0、512 token 输出的预热测试中，三次端到端速度是 154.44、223.00、223.31 token/s，中位数 223.00 token/s。这是当时的短请求验收数据，不等同于社区发布的 4K/128 或 32K/512 基准，也没有证明真实工作流可用。

真正的问题出在客户端任务

接入 WorkBuddy 后，简单问题也出现了中英文和内部草稿式文字混杂、句子中断、长时间没有有效正文等现象。直连服务复测时，不同思考设置、采样温度和输出上限会得到明显不同的结果：有的请求把全部输出额度耗在 reasoning 字段，content 仍为空；有的关闭思考后正常，有的又提前结束。

这说明故障与请求参数或解析过程有关，但现有证据不足以把责任单独归给模型、DFlash2、vLLM 解析器或客户端。由于尚未拿到 WorkBuddy 那些异常请求的完整报文和对应日志，我没有把猜测写成根因。

更重要的是，健康检查和短请求测速已经通过，使用者仍拿不到可靠答案。对这个目标用途而言，业务可用性验收失败。2026-09-23 我停止该 vLLM 服务，保留容器和日志，并恢复 llama.cpp + MTP 路线。恢复后基础接口重新通过；复杂长任务仍要继续测试。

下一次我会怎样测

我会先固定同一组真实提示词、图片、工具调用、思考设置和输出上限，再比较两套服务。每个场景至少记录四件事：首个可见正文出现时间、最终答案质量、reasoning 与 content 的分布、解码速度及草稿接受率。性能数据取多轮中位数，同时保留失败样本。

这样才能回答“速度提升有没有转化成工作效率”。这次试验的结论很具体：这一套 vLLM + NVFP4 + DFlash2 + WorkBuddy 组合当时不可用。它不能推出 Qwen3.8-27B 本身不可用，也不能否定其他 vLLM 配置。

资料：vLLM 定制分支 · vLLM 关于推理输出的文档 · Qwen 官方模型页