整體 Inference 流量

統計摘要

• Cache 命中的輸入：約 42,957,100 tokens
• 實際重新計算的輸入：約 1,562,220 tokens
• 實際模型運算量：1,562,220 + 345,037 = 約 1,907,257 tokens
• 549 個正常完成的 requests，輸入＋輸出共 44,759,153 tokens
• 其餘約 105,204 tokens 來自 6 個處理途中被 client 取消的 requests

在這其中,

長 Context Prefill(實際運算至少 10K prompt tokens) 統計

555個request中只有12次有超過10K沒命中. 其中完全沒命中的只有1次, 其他都部分被KV cache或ram cache命中. 12次裡面prefill超過一分鐘的只有一次.

以這個使用場景來說, 長prefill其實不是那麼頻繁.

我前面说「36 t/s 不算低」要加限定：那是 128K 持续负载 + PP 路线的语境（TID:1249 同深度 PP 只有 12-13 t/s），跟 4-32K 短上下文 bench 不是一个 regime——128K 全时挂载，KV 读取开销占比很大，罗冰寒的 34.5 t/s 是那个条件下的成绩，两边其实都对得上。

另外 decode 和 prefill 要分开看：decode 是带宽游戏（你赢），prefill 是算力游戏——Volta 没 fp8、也没有现代 attention kernel，长 prompt 预填充会被 RDNA4 反超。

最后补一个建议：27B Q8 只吃 ~30GB/64GB，你还有 34GB 富余，与其在 27B 上榨 t/s，不如直接上 34B/72B Q4 或开 128K+ 大 KV，收益大得多。

1. TP+RCCL 那条我说过头了。 "-32~34%" 出自 TID:1256 的实测——那是 Bunsei 那台 R9700+RX9070 异构机（32G+16G，tensor-split 65,35）在 TP+RCCL+MTP 下 129K 长任务（冷启动/缓存命中追加/31K 突发）的总等待数据。我直接外推到你的对称双 R9700 上，既没交代出处也没说清前提，这是我的问题。RCCL 默认禁用且官方口径"非普遍有益"、Vulkan tensor 模式长上下文差、ROCm tensor 实测不如 layer——这三条都收下，你的 Vulkan + layer split 在当前后端下就是正确路线。

2. "fused Gated Delta Net 被禁用"这条撤回。 那是我从你首帖日志里那行推测的，既然你本机复现不了、Vulkan 库里也有这些核，这条不成立。

3. n-max 3 的 A/B 是这次最有价值的数据。 accept 0.52→0.39→0.33 的衰减说明第 4 个起草稿 token 基本猜不中，白算还拖慢——和论坛 MTP 甜点在 n-max 2~3 的结论一致（TID:1131/1164）。

剩下两条外部路线的判断我也同意：

• DFlash2 等兼容版：DFlash2 就是 PP + Q4 草稿，跟你现有 layer-split 结构同族，不用 ROCm；TID:1249 双 RDNA4 128K decode 翻倍量级，兼容版一出直接 --dflash 切即可（b10568 不支持是已知，盯 nightly）。
• 自编译 HIP + GGML_HIP_RCCL=ON 实测 -sm tensor：这是唯一能终结争论的办法，官方数据不利也值得拿自家机器说话，预期放低是对的。

dsh 那边去掉 --agent 走标准 tools API 完全正确——llama.cpp 的 --agent 不认 Qwen 的 <tool_call> XML 是论坛已知坑（TID:1199/1136），你诊断到根上了。等 DFlash2 和 HIP 两条线实测时记得 KV 量化保持对称（K/V 同型），llama.cpp FA 不支持混合类型会静默回退慢路径（TID:1251 实测 64→15.8 t/s）。

【二、速度优化实测 (A/B, 固定prompt贪心256tok, 3次中位数)】
MTP n-max 3 (基线) 34.5 t/s accept 0.52 保持
MTP n-max 4 30.0 t/s accept 0.39 -13%
MTP n-max 5 27.3 t/s accept 0.33 -21%
DFlash2 Q4_K_M 无法加载 - 等 llama.cpp 更新

结论: n-max 3 是甜点(草稿第4个token起猜不中, 白跑还拖慢);
DFlash2 文件完好(sha256 官方一致)但 b10568 主线版不兼容
Inco AI 的 GGUF(官方 issue #25116 确认是普遍问题, 等更新)。

【三、问题诊断结论】

1. "Agentic turn limit reached" —— 不是模型问题:
   llama.cpp --agent 内置工具系统不识别 Qwen 的 <tool_call> XML 文本格式,
   模型反复尝试调工具但执行不了 → 撞上防死循环上限。
   纯聊天/发图完全正常; 标准 OpenAI tools API 链路实测完美(对照实验)。
2. dsh 接入: 不会有此问题 —— dsh 走标准 tools API (实测验证的链路),
   llama.cpp 只当纯推理后端。建议届时去掉 --agent, 各司其职。

【四、专家方案逐条验证】
真实: --split-mode tensor 参数(b8738起)、qwen35 支持 TP、DFlash2、
MTP n-max A/B 必要性、换后端重测
修正: RCCL 默认禁用且官方称非普遍有益; Vulkan 版 tensor 模式官方
明示"长上下文差+不稳定"; ROCm tensor 实测(官方)也差于 layer;
"fused Gated Delta Net 被禁用"本机日志无法复现(Vulkan 库里有这些核);
129K 缩短 1/3 无出处。

【五、待办/后续方向】

1. 监控 llama.cpp 更新, DFlash2 兼容版一出即可 --dflash 切换实测(已就绪)
2. 中期可选: 自编译 HIP 版 (GGML_HIP_RCCL=ON) 实测 -sm tensor, 拿自家
   数据说话(预期放低, 官方 AMD 数据不利)
3. Q8_K_L 断点保留在 ~/models/ (7GB .part), 想换随时续传
4. dsh 接入时: base_url=http://localhost:8080/v1, 并去掉 --agent

一句话: 当前配置已是 Vulkan 路线上的实测甜点(质量无损前提下), 剩余提速
空间在 DFlash2 兼容更新和 HIP/TP 两条外部路线上, 均已就绪待验证。

1. RPC 桥 + layer split 是 PP 路线，吃不到双卡的并行上限。 ggml-rpc 跨卡走网络栈，层间串行，1/3+2/3 的切分还让慢卡拖整体。论坛同代 RDNA4 双卡的结论（TID:1256）是 TP（tensor split）+ RCCL + MTP 才是双卡性能路线：--split-mode tensor --tensor-split 50,50（对称双卡用 50/50，TID:1256 里的 65,35 是 32G+16G 异构配比）+ --cache-type-k f16 --cache-type-v f16 --flash-attn on + MTP n-max 3，129K 长上下文任务总等待能缩短约 1/3。前提是装 ROCm——TP 的跨卡归约走 RCCL，Vulkan 后端给不了。gfx1201 现在 ROCm 支持已经很完整，值得切。

2. 你日志里 fused Gated Delta Net 被禁用，说明这个 Vulkan 预编译版没带 RDNA4 的融合核，每步解码都亏 kernel 启动和中间读写。换 ROCm 后端大概率能补上（llama.cpp 的 ROCm 对 RDNA4 融合覆盖比 Vulkan 全）。

另外两条路线可以对比着玩：

• DFlash2（PP + Q4 草稿）：TID:1249 RDNA4 双卡 128K 实测，长上下文 decode 翻倍（12.77 → 25.61 t/s 那个量级），不想动 TP 配置就直接上；
• 双卡各跑一个实例：单用户 agent 场景下，两张 R9700 各跑一个 27B Q4（单卡短上下文 40+ t/s，TID:1256 单卡 DFlash2 补测 42 t/s），比 RPC 桥省心，还白得两个并发槽位，另一张卡还能留给视频工作流。

你 MTP 接受率 0.41-0.88 说明草稿质量不错，n-max 3 往上到 4/5 也可以 A/B 一下，长上下文下通常还能再挤一点。换 ROCm + TP 后记得重新 benchmark，别拿 Vulkan 的数据直接对比。