Eval bug: qwen35 and qwen35moe graph split issues (Severe PP impact, crashes)

快速结论：该报错在使用 qwen35 或 qwen35moe 模型进行多 GPU（CUDA）推理时触发，具体表现为 graph split 不稳定，RS cache 类型分配错误导致 PP 性能严重下降甚至 CUDA 崩溃。优先检查 -ts （tensor split）参数配置以及 llama.cpp 是否已更新至包含 #19866 的修复版本。

问题场景

用户在 llama.cpp 最新 master 分支（commit 418dea39cea85d3496c8b04a118c3b17f3940ad8）下，使用 4 块 CUDA 设备（通过 PCI-E 3.0 x1 连接）加载 Qwen3.5 27B / Qwen3.5-397B-A17B 等 qwen35 或 qwen35moe 系列模型（Q8_0 量化），运行 pp（prefill）和 tg（text generation） 测试时触发。特别在使用 -ts 参数指定不均衡的设备分配（例如 "3;4;1.5;2.7;1" 对应于 5 个设备，或类似涉及 4 个设备的配置）时容易复现。

报错原文

#19860 (similar CUDA error)
# 图分裂示例（发生在 CUDA1 和 CUDA2 层之间）：
node #17871 (   MUL_MAT):              v_prime-37 (   1M) [CUDA1         ] use=1,c=1:    k_cumdecay-37 (view) (  47M) [CUDA1         ]    dnet_add_ch_state-37 (   3M) [CUDA1         ]
node #17872 (       SUB):              v_t_new-37 (   1M) [CUDA1         ] use=2,c=1:  (transposed) (cont) (v (  47M) [CUDA1         ]              v_prime-37 (   1M) [CUDA1         ]
node #17873 (   MUL_MAT):              node_17873 (   3M) [CUDA1         ] use=1,c=1:   key_gdiff_t-37 (view) (  47M) [CUDA1         ]              v_t_new-37 (   1M) [CUDA1         ]
node #17874 (       ADD):    dnet_add_ch_state-37 (   3M) [CUDA1         ] use=1,c=1:              node_17867 (   3M) [CUDA1         ]              node_17873 (   3M) [CUDA1         ]
# ... 更多异常节点
# PP 测试性能从约 635 t/s（正常）降级到约 369 t/s（异常），甚至低至 10-20 t/s（严重情况）

原因分析

核心问题：在 qwen35 和 qwen35moe 模型中，各层的 cache 类型（R cache、RS cache 等） 被错误地分配到不同的 GPU backend，导致 graph split 不稳定，产生大量不必要的跨设备数据传输。

明确证据 1：报告者验证，当分裂发生在普通 kv-cache 层附近时，PP 性能最高（~635 t/s）；当分裂发生在 RS cache 层之间时，PP 性能严重下降（~369 t/s）。
明确证据 2：报告者通过自定义修补（将第 i 层的 R cache 分配给第 i-1 层的 backend），使 Qwen3.5-397B-A17B 的 PP 性能从 10-20 t/s 提升到 170 t/s；对 Qwen3.5 27B 则从 369 t/s 提升到 489 t/s。
可能原因：在 qwen35 和 qwen35moe 模型中，RS cache 的层间依赖关系和 cache 类型与普通 kv-cache 不同，llama.cpp 的 graph split 算法未能正确处理这些特殊 cache 类型的 backend 关联，导致拆分逻辑异常。

环境排查

llama.cpp 版本：确认是否为最新 master 分支（包含 #19866 的修复）。旧版本（如 418dea3）存在问题。
CUDA 设备数量和连接：确认多 GPU 环境（PCI-E 3.0 x1 等慢速连接会放大跨设备传输开销）。
模型类型：确认是否为 qwen35 或 qwen35moe 系列模型（包括 Qwen3.5 27B、Qwen3.5-397B-A17B）。
-ts 参数：检查是否使用了不均衡的 tensor split 比例（例如 "3;4;1.5;2.7;1" 对应 5 设备，或类似 4 设备的不匀配比）。
量化格式：报告者测试中使用 Q8_0，但其他格式也可能触发。
backend：确认是否使用 CUDA backend。

解决步骤

更新 llama.cpp 至最新版本：拉取最新 master 代码，确保包含 #19866 的修复。报告者确认“Yes, it seems it’s resolved, thank you!”，说明该 PR 已解决此问题。
重新编译：确认使用 make 或 cmake 重新编译，清除旧缓存。
调整 -ts 参数（如问题仍存在）：
- 可优先尝试避免使用不均衡的 tensor split 比例，或尝试让分裂点位避开 RS cache 层。
- 如果使用 4 个 GPU，尝试均衡分配，例如 -ts "1;1;1;1" 或根据显存大小动态分配，减少跨层异常。
- 如果使用 5 个 GPU，避免类似 "3;4;1.5;2.7;1" 这样的极高不匀配比。
手动调整层分配（临时方案）：如果更新后问题依旧，且 -ts 调整无效，可以尝试像报告者那样手动调整 cache 的 backend 分配（将 R cache 层分配给相邻层的 backend），但这需要深入理解 graph 结构，仅建议开发者使用。

验证方法

重新运行 pp10000 和 tg512 测试。如果更新至最新版本（包含 #19866），PP 性能应显著恢复：例如从约 369 t/s 恢复到 489 t/s 以上（4 GPU 均衡配置下甚至可达 635 t/s）。同时，不再出现 CUDA 错误或 graph 中异常的跨设备节点（如本文报错原文中所示）。如果使用 5 设备且之前 CUDA 崩溃的案例，更新后应不再崩溃。