Misc. bug: Flaky test-recurrent-state-rollback results on Intel Linux Vulkan

快速结论：该报错出现在 Intel iGPU 的 Linux Vulkan 后端运行 test-recurrent-state-rollback 单元测试时，结果表现为不稳态（复现率约 50%，单模型下低于 10%），典型失败点是 test_shared_seq_reserve 产生 non-finite logit。优先排查 Vulkan 提交同步、Mesa 驱动版本与调度相关环境变量。

适用环境：llama.cpp 0.6.0-dev（build 11515，commit 3d65c90d0），GNU 13.3.0，Linux x86_64；GPU 为 Intel Core Ultra 7 258V（Arc 集成显卡）与 Panther Lake；Ubuntu 24.04.5 / 26.04.1，内核 7.0.0 系列，Vulkan 1.3.275 / 1.4.350 / 1.4.363；Vulkan 后端通过 -DGGML_VULKAN=1 构建。

最快修复方案：暂无确认的一步修复方案。Issue 中验证的趋势是：升级 Mesa 到较新版本（如 kisak-mesa PPA 的 Mesa 26.2.4）后不再复现，且提交 6d5ac3c8 之后未再观察到此问题；可优先尝试使用较新 Mesa 或更新到含该提交的版本。

注意事项：该 Issue 标签为 bug-unconfirmed，根因未在讨论中定位；“升级 Mesa 修复”与“6d5ac3c8 修复”都是 Issue 中的观察结果，而非经确认的根因结论。GGML_VK_SERIALIZE_SUBMISSIONS=1 等环境变量可把失败率降到 0/200，但会牺牲 Vulkan 并行性能，只适合作为排错对照手段，不宜当作正式修复。

问题场景

在 Intel 集成显卡的 Linux 环境里，以 Vulkan 后端编译 llama.cpp 后运行 ctest 单元测试，目标是 test-recurrent-state-rollback（会先连带跑 test-generate-models）。测试覆盖 recurrent state 回滚、多序列 split replay、shared seq reserve 等路径，使用 lfm2moe-moe.gguf 等测试模型。问题表现为同一构建、同一机器上多次运行结果不一致，约 50% 失败；只跑出问题的单个模型时失败率低于 10%。

报错原文

Test #28: test-recurrent-state-rollback ....***Failed    7.86 sec
...
0.00.245.932 E test_shared_seq_reserve: non-finite shared-seq logit at step 0, seq 0, index 0

相关警告（非致命，但出现在失败路径附近）：

W llama_context: n_ctx is not divisible by n_seq_max - rounding down to 512
W llama_context: n_ctx_seq (512) > n_ctx_train (256) -- possible training context overflow

原因分析

可能原因：失败集中在 Vulkan 后端的执行时序上，而不是测试逻辑本身。Issue 中给出的对照实验显示：

仅设置 GGML_VK_SERIALIZE_SUBMISSIONS=1 后失败率从 12/200 降到 0/200，说明问题可能与多个 Vulkan 提交并发执行有关。
GGML_VK_DISABLE_FUSION=1 反而把失败率升到 116/200，说明算子融合与调度组合会明显影响触发概率。
单独关闭异步、graph end 同步（GGML_VK_DISABLE_ASYNC=1、GGML_VK_SYNC_GRAPH_END=1）或设置 LLAMA_SYNC_PRE_UBATCH=1 时同样未再复现（0/50），进一步指向同步时序问题。
换到 Mesa 26.2.4（kisak-mesa PPA）后不再复现，而 Ubuntu 仓库自带 Mesa 25.2.8 下可复现，可能原因与 Mesa 版本相关。

具体是驱动、llama.cpp Vulkan 实现还是两者交互导致，Issue 中未给出定论。测试日志中的 n_ctx 取整与超出训练上下文的警告在通过运行中也会出现，不构成失败的直接证据。

环境排查

确认 llama.cpp 构建参数：是否使用 -DGGML_VULKAN=1、-DGGML_SCHED_NO_REALLOC=ON，以及对应 commit（Issue 中为 3d65c90d0）。
确认 Mesa 版本与来源：Ubuntu 仓库 Mesa 25.2.8 可复现，kisak-mesa PPA 的 26.2.4 未复现。
确认 Vulkan 版本：1.3.275、1.4.350、1.4.363 环境下均出现过，说明不是单一 Vulkan 版本问题。
确认操作系统与内核：Ubuntu 24.04.5 / 26.04.1，7.0.0-38 / 7.0.0-14 内核；Issue 关闭前也更新过 CI 内核到 7.0.0-42。
确认 GPU 型号：U7-258V（Intel Arc 集成显卡）与 Panther Lake；U9-285K + Arc B70 独显环境未复现。
确认模型文件 build-release/tests/test-models/lfm2moe-moe.gguf 存在且未损坏。

解决步骤

先建立可重复的基线：按 Issue 中的方式构建并多次运行测试，记录失败次数，例如

cmake -B build-release -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DLLAMA_FATAL_WARNINGS=ON -DLLAMA_OPENSSL=OFF -DGGML_SCHED_NO_REALLOC=ON -DGGML_VULKAN=1
cd build-release
ctest -C Release --output-on-failure -R test-recurrent-state-rollback

只针对可疑模型单独跑，以便快速迭代：

GGML_SCHED_DEBUG_REALLOC=1 build-release/bin/test-recurrent-state-rollback -m build-release/tests/test-models/lfm2moe-moe.gguf

做环境变量对照实验，判断是否属于同步时序问题（可优先尝试）：GGML_VK_SERIALIZE_SUBMISSIONS=1、GGML_VK_DISABLE_ASYNC=1、LLAMA_SYNC_PRE_UBATCH=1 分别单独运行多次。若某变量能把失败率压到 0，可作为临时规避手段，但不要用于性能场景。
升级 Mesa 到较新版本（如 kisak-mesa PPA 提供的 Mesa 26.2.4）后重复步骤 1，验证是否不再复现。
更新 llama.cpp 到包含提交 6d5ac3c8d5aae1831edf17c2d5cda11abe025bb3 的版本，重新构建并重复测试。
若仍复现，保留 GGML_SCHED_DEBUG_REALLOC=1 的完整日志，并在 Issue 中补充 GPU、Mesa、Vulkan 版本与失败次数统计。

验证方法

用相同命令多次运行（Issue 中对照组为 200 次或 50 次），确认 test-recurrent-state-rollback 不再出现 FAILED，且日志中不再出现 non-finite shared-seq logit at step 0, seq 0, index 0。只跑一两次通过不足以判定修复，因为基线失败率本身就有波动。