Eval bug: ROCm gfx1151 RPC worker crashes in GGML_OP_TOP_K during DeepSeek V4 prefill after 4096 tokens

快速结论：该报错通常发生在使用 llama.cpp 的 RPC 功能，将 DeepSeek V4 等大模型的长提示词（超过 4096 tokens）分配到 AMD gfx1151（Radeon 8060S / Ryzen AI Max+ 395）ROCm 后端进行预填充时，远程 RPC 工作进程会直接崩溃。优先排查是否因为本地调度器未检查远程设备的算子支持，导致 GGML_OP_TOP_K 在 HIP 后端上使用了超出 GPU 线程块上限的配置。

适用环境：Issue 已确认的环境包括：llama.cpp commit 3653e6d6d（版本号 10326）；AMD Ryzen AI Max+ 395（Radeon 8060S Graphics，gfx1151）；ROCm / TheRock 7.13.0 与 7.14.0；Ubuntu 26.04 (Kernel 7.0.0-29)；使用 RPC + HIP 后端（GGML backends: RPC, HIP）；DeepSeek-V4-Flash-0731 GGUF（UD-IQ3_XXS 量化，4 shards），并搭配 dspark-DeepSeek-V4-Flash-0731-Q8_0.gguf 作为 draft model。

最快修复方案：暂无确认的一步修复方案。Issue 讨论中确认 #24325（通过 RPC 查询远程后端算子支持）可以成功避免崩溃，但此修复尚未合并进主线版本；另一个修复 PR #26592（在 HIP 上启用 hipCUB 路径）虽然能解决原始崩溃，但会引入新的崩溃（报错为 operation not permitted when stream is capturing，发生在 argsort_f32_i32_cuda_cub）。可优先尝试将 RPC 工作进程的 GPU 后端从 ROCm 切换为 Vulkan/RADV（同硬件上已验证稳定，但速度明显更慢），或者等待 #24325 合并后再升级 llama.cpp。

注意事项：此问题与 #24177 不同，启用 --no-spec-draft-backend-sampling 无法规避；减小 --ubatch-size（从 256 降到 128）也不会改变崩溃点（仍精确在 4096 tokens 后崩溃）。Vulkan 后端虽然稳定但速度不明显降低。PR #26592 实验中确认也会在非 gfx1151 的机器（双 Instinct MI50）上触发新的崩溃，说明该 PR 引入的问题并非特定于 GFX1151。

问题场景

用户在双节点环境中运行 llama.cpp 推理：本地使用 llama-server，远程 RPC 工作进程运行 ggml-rpc-server --device ROCm0。模型为 DeepSeek-V4-Flash-0731（UD-IQ3_XXS 量化）。当向服务发送包含约 1.8 万 token 的长提示词时，提示词预填充（prefill）处理到 4096 tokens 后，远程 ROCm RPC 工作进程立即崩溃，导致客户端报错“Remote RPC server crashed or returned malformed response”。短请求（几百 token）可以正常完成。将远程 RPC 工作进程的 GPU 后端从 ROCm 换成 Vulkan/RADV（同一张 Radeon 8060S 显卡）后，相同配置不再崩溃。

报错原文

ggml_cuda_compute_forward: TOP_K failed
ROCm error: invalid configuration argument

Remote RPC server crashed or returned malformed response
recv failed (bytes_recv=0, size_to_recv=8)

原因分析

根据 Issue 讨论中的根因分析（维护者已定位到源码层），这是两个条件共同作用的结果：

1. GPU 端 TOP_K 内核的线程块配置超出上限：在 HIP 后端，GGML_CUDA_USE_CUB 宏从未被定义，因此 ggml_cuda_op_top_k 始终走 bitonic 排序路径（argsort_f32_i32_cuda_bitonic）。该内核设置 block_dims(ncols_pad, 1, 1)，即每个元素一个线程。当 ncols 超过 1024 时，请求的线程块大小超过 1024 上限，触发 hipErrorInvalidConfiguration（即报错中的“invalid configuration argument”）。

2. RPC 层绕过了算子支持检查：llama.cpp 本地调度器在调度算子前，会调用 ggml_backend_cuda_device_supports_op 检查 GGML_OP_TOP_K 的 ne[0] <= 1024 限制（条件不满足时回退到 CPU）。但 ggml_backend_rpc_device_supports_op 目前无条件返回 true（源码中 TODO 备注“调用远程后端并缓存结果”尚未实现），因此客户端调度器不会检查远程设备的算子限制；远程 rpc_server::graph_compute 直接调用 ggml_backend_graph_compute，没有调度器也没有 CPU 回退逻辑，导致远程 HIP 后端直接中止进程。

3. 为什么精确在 4096 tokens 处崩溃：DeepSeek V4 的 CSA 注意力将 KV 压缩约 4 倍，ggml_top_k() 的行长度约为 n_kv/4。当处理到 4096 tokens 时，行长度约为 1024 列，刚好在线程块上限边缘（每增一个 ubatch，ncols_pad 变为 2048，立即超限）。共享内存断言（GGML_ASSERT）未触发，因为 4096 个 int 仅 16 KB，低于 LDS 限制。

环境排查

确认 llama.cpp 版本是否为 Issue 中的 10326（commit 3653e6d6d）；建议检查是否有包含 #24325 或 #26592 的新版本。
确认远程 RPC 工作进程使用的后端是否为 ROCm/HIP（--device ROCm0），以及 ROCm 版本为 7.13.0 或 7.14.0。
确认 GPU 架构是否为 gfx1151（Radeon 8060S / Ryzen AI Max+ 395）。
确认模型是否为 DeepSeek-V4-Flash-0731 GGUF 及其量化版本（UD-IQ3_XXS），以及是否启用了 speculative decoding（draft model）。
检查是否启用了 --no-spec-draft-backend-sampling（Issue 确认此参数无法规避本问题）。
尝试将 ubatch-size 从 256 改为 128，确认崩溃点是否仍在 4096 tokens（Issue 确认不改变失败点）。

解决步骤

临时规避方案（已验证有效）：将远程 RPC 工作进程的 GPU 后端从 ROCm 切换为 Vulkan/RADV，同一张 Radeon 8060S 上运行 ggml-rpc-server --device Vulkan0。此方案不会崩溃，但预填充速度明显下降。
等待上游修复：关注 PR #24325（通过 RPC 查询远程后端算子支持）的合并状态。Issue 讨论中确认该 PR 可以成功避免此崩溃（让远程设备正确拒绝 TOP_K 算子，走 CPU 回退路径）。
注意 PR #26592 的副作用：该 PR 通过 hipCUB 启用 CUB 路径来修复本问题，但在测试中会引入新的崩溃（报错 operation not permitted when stream is capturing，位于 argsort_f32_i32_cuda_cub 的 DeviceSegmentedRadixSort::SortPairsDescending）。此问题在双 Instinct MI50 上同样出现，并非 GFX1151 特有，不建议自行合入此 PR。
确认本地 supports_op 修改无效：不要试图在客户端本地打补丁修改 GGML_OP_TOP_K 的 ne[0] <= 1024 限制，因为该限制只影响本地 ROCm 设备，RPC 设备完全绕过此检查。
升级 llama.cpp：定期检查上游主线版本是否已合并 #24325 或等效修复，合并后升级并重新测试长提示词预填充。

验证方法

使用与 Issue 中相同的复现步骤验证：启动远程 ROCm RPC 工作进程和本地 llama-server，先发送短请求确认正常，再发送包含约 18k token 的长提示词，观察是否仍会在 4096 tokens 后崩溃（客户端出现 “Remote RPC server crashed or returned malformed response”）。若使用 Vulkan 后端作为替代方案，确认长提示词预填充可全程完成且不崩溃，同时记录性能差异用于权衡。