Eval bug: [ROCm] Severe PPL explosion starting from b10040

快速结论：在 ROCm/HIP 后端构建的 llama.cpp 上运行 llama-perplexity 或正常推理时，从 b10040 起出现严重的 PPL 暴涨（PPL 从约 7.7 恶化到数千），表现为模型输出质量骤降、上下文理解变差、工具调用失败；优先排查是否为 b10040 之后的 ROCm 回归，并核对上下文长度是否超过 512。

适用环境：Linux（Ubuntu 26.04 宿主、Fedora 44 复现）；ROCm/HIP 后端（HIP、GGML_HIP，实测含 rocm/dev-ubuntu-24.04:7.2.4、ROCm 7.1.1、GGML_HIP_NO_VMM=ON）；硬件为 Ryzen AI Max+ 395（iGPU Radeon 8060S，gfx1151）；llama.cpp b10040 及之后版本（含 v0.2.0 / 最新 master）。Vulkan 后端作为对照组正常。

最快修复方案：暂无确认的一步修复方案。Issue 中已验证的可行规避方式是回退到 b10038 / 5839ba352471b2a7b45e7ba401619a6896f10f8b（该提交下 PPL=7.7241）或改用 Vulkan 后端构建，二者均可恢复正常输出质量。

注意事项：回退到 b10038 只是规避，并不意味着 ROCm 回归已被修复；Issue 被标记为 bug-unconfirmed 且已 stale 关闭，官方是否确认并修复该回归无明确证据。rocWMMA 并非有效规避手段（见评论区复现结论），问题与量化类型、模型也不强相关。此外，该问题在较短上下文（如 -c 512）下可能不出现，因此不能用短上下文测试来”确认已修复”。

问题场景

用户在 Linux 上使用 ROCm/HIP 后端（GGML_HIP）自行构建 llama.cpp，运行 llama-perplexity 或 llama-cli 进行推理。测试模型包括 Llama-3.2-3B（Q4_0）、Qwen3.6-35B-A3B-UD-IQ4_XS、Laguna-S-2.1 等。表现为上下文理解显著退化、工具调用频繁失败，用 llama-perplexity 跑 wikitext-2 时 PPL 出现数量级暴涨。使用相同模型与参数的 Vulkan 构建则一切正常。触发点与上下文长度相关：-c 512 时 PPL 正常，从 -c 2048 起开始爆炸。

报错原文

Final estimate: PPL = 3024.3587 +/- ...

# 分提交 PPL 结果
b10038        : PPL = 7.7241
5839ba352471b2a7b45e7ba401619a6896f10f8b : PPL = 7.7241
b10040        : PPL = 3024.3587   (Broken / PPL Explosion)
bb4caa7540188872173c44d161602d9271386413 (Latest master / v0.2.0) : PPL = 2177.3497

# 按上下文长度
c=512   : PPL = 6.1261   (Normal)
c=2048  : PPL = 854.1640 (Broken)
c=8192  : PPL = 1772.1673 (Broken)
c=16384 : PPL = 1242.5407 (Broken)
c=32768 : PPL = 1545.4765 (Broken)

原因分析

根据 Issue 的 bisect 结果，最后一个正常提交为 b10038（5839ba3），从 b10040 起 PPL 立即从 7.7 量级跳到 3000 量级，并在最新 master 上仍然存在，因此可判断这是 b10040 引入的 ROCm/HIP 后端回归。评论区补充的证据表明该回归与量化类型、模型种类无关，rocWMMA 也不是规避途径；且只在上下文长度增大（≥2048）时显现，短上下文（-c 512）不触发。这说明问题可能出在与长上下文处理相关的 ROCm kernel 路径上，但 Issue 中并未定位到具体代码变更，确切根因属未确认。

环境排查

确认 llama.cpp 构建版本：./build/bin/llama-cli --version，核对是否处于 b10040 及之后（含最新 master / v0.2.0）。
确认后端：是否为 GGML_HIP / HIP（ROCm）构建，是否有可用的 Vulkan 构建作对照。
确认 ROCm 版本与镜像：Issue 中实测环境为 rocm/dev-ubuntu-24.04:7.2.4、ROCm 7.1.1（rocm-core-7.1.1-4.fc44）。
确认 GPU 与目标架构：Ryzen AI Max+ 395 / Radeon 8060S（gfx1151），第二台 gfx1151 机器也可复现。
确认构建选项：是否使用 GGML_HIP_NO_VMM=ON、GPU_TARGETS=gfx1151 等。
确认测试上下文长度：短上下文（-c 512）不会暴露问题，需用 -c 2048 及以上进行验证。

解决步骤

先用同一模型、同一参数在 ROCm 构建与 Vulkan 构建上各跑一次，确认退化仅出现在 ROCm 侧。
用较长上下文复现，记录 PPL 基线，命令参考：
llama-perplexity -m /models/llama-3.2-3b-q4_0.gguf -f /wikitext-2-raw/wiki.test.raw -c 32768 -ngl 999 --chunks 1
回退到已验证正常的提交 5839ba352471b2a7b45e7ba401619a6896f10f8b（b10038），重新构建 ROCm 版本。
可参考 Issue 中的构建方式：cmake -B build-bs -DGGML_HIP=ON -DGPU_TARGETS=gfx1151 -DCMAKE_BUILD_TYPE=Release，再 cmake --build build-bs --target llama-perplexity -j$(nproc)。
若不方便回退，可切换为 Vulkan 后端构建作为规避手段，Issue 中该构建在相同模型和参数下工具调用表现正常。
不要指望通过更换量化类型、更换模型或启用 rocWMMA 来绕开该问题，评论区已排除这些方向。
若必须停留在新版本，先限制上下文长度（<2048）使用，但这只是降低暴露概率，不代表问题消失。

验证方法

在回退后的提交上重新执行相同命令，确认 Final estimate: PPL 回到 7.x 量级（Issue 中 b10038 为 7.7241），且长上下文（-c 2048 及以上）下不再出现数百至数千的 PPL；同时实际对话与工具调用的输出质量恢复正常。注意不要只用 -c 512 测试，因为该长度在出问题的版本上也显示正常。