Eval bug: random crashes in cudaStreamSynchronize

快速结论：该报错是 llama.cpp 在 CUDA 后端执行推理时，GPU 因长时间被占用未响应导致驱动看门狗（Watchdog）超时并触发内核态重置（Xid 8），进而引发 cudaStreamSynchronize 同步失败。优先排查 GPU 看门狗超时时间设置及超长上下文推理导致的单次 Kernel 执行时间过长。

适用环境：Linux（Issue 确认的系统日志为基于 systemd 的发行版）、llama.cpp（version 0.2.0-dev, build 10594, commit 193d1f2d9）、GGML CUDA 后端、NVIDIA RTX 6000（Ada Lovelace 架构）、AMD Ryzen 9950X、Qwen3.8-27B-UD-Q6_K_M 模型（带 mmproj 多模态投影）。未提及具体 CUDA/PyTorch 版本及驱动版本。

最快修复方案：暂无确认的一步修复方案。Issue 中明确验证过的处理方法是参考 #27102 中提出的工作区方案（#27102 评论中的 workaround），即调整 NVIDIA 驱动看门狗超时时间（Notify Timeout Seconds），但该方案代价是必须修改驱动参数，并非代码层面的根治。可优先尝试将系统看门狗超时时间调大（如从默认 7 秒调至 30 秒以上），若问题仍复现再考虑降级/回滚 llama.cpp 版本。

注意事项：上述看门狗超时修改仅能缓解症状，不能从根本上解决 Kernel 执行超时的问题。Issue 标注为 bug-unconfirmed，尚未定位到具体代码缺陷；超长上下文（ctx-size = 1939864）配合 YARN rope-scaling 可能显著增加单次 CUDA Kernel 的调度时间，这是导致驱动看门狗被触发的核心诱因，但官方尚未给出代码层面的修复承诺。

问题场景

用户使用 llama.cpp 的 server 模式（llama-server）加载 Qwen3.8-27B 多模态模型，并配置了超大上下文窗口（ctx-size = 1939864，约 1.94M tokens）以及 YARN rope-scaling（rope-scale = 1.85）。同时在路由配置中启用了 spec-type = draft-mtp（MTP 投机解码）、np = 4（并行 4 个预测头）以及 cache-ram = 32768。模型在持续生成文本（每 3 秒输出约 200 tokens，速度约 65 t/s）时偶发性崩溃，崩溃前约 10 秒系统日志出现 NVIDIA 驱动看门狗报警。

报错原文

[59239] /home/wolf/llama.cpp/ggml/src/ggml-cuda/ggml-cuda.cu:107: CUDA error
[59239] 33.04.052.852 E CUDA error: the launch timed out and was terminated
[59239] 33.04.052.854 E   current device: 0, in function ggml_backend_cuda_synchronize at /home/wolf/llama.cpp/ggml/src/ggml-cuda/ggml-cuda.cu:2537
[59239] 33.04.052.854 E   cudaStreamSynchronize(cuda_ctx->stream())
...
sie 23 13:55:38 oberon kernel: NVRM: krcWatchdog_IMPL: RC watchdog: GPU is probably locked!  Notify Timeout Seconds: 7
sie 23 13:55:38 oberon kernel: NVRM: Xid (PCI:0000:01:00): 8, pid=1582135, name=llama-server, channel 0x00000010

原因分析

可能原因：CUDA 报错信息的“launch timed out and was terminated” 对应的其实是 NVIDIA 驱动层面的看门狗（Watchdog）机制。系统日志显示 Notify Timeout Seconds: 7，即驱动允许单个 CUDA Kernel 在 GPU 上持续执行的最长时间为 7 秒。当推理过程中某个 Kernel（或 Kernel 序列）单次执行时间超过该阈值（例如因为超长上下文导致的巨大矩阵运算、MTP 投机解码产生的前向传播链、或 GC 内存回收造成的临时阻塞），驱动会判定 GPU 无响应（“GPU is probably locked”），随即触发内核态重置该 CUDA 上下文（Xid 8 错误）。

随后 llama.cpp 在 ggml_backend_cuda_synchronize 调用 cudaStreamSynchronize 时发现设备已失效，因此抛出 CUDA error 并 abort。从复现频率看（“Rarely there will be the following crash”），该问题属于偶发性的时序竞争，可能与批次大小波动、投机解码的接受率变化、或系统内存带宽争抢有关。Issue 作者并未定位到具体的 ggml-cuda Kernel 代码缺陷，因此该问题本质上是“驱动看门狗阈值 vs 超长上下文 Kernel 时长”的冲突。

环境排查

确认 NVIDIA 驱动版本（使用 nvidia-smi 查看），并检查 /var/log/syslog 或 journalctl -k 中是否有 NVRM: Xid 相关的看门狗超时记录。
确认 nvidia-smi -q -d WATCHDOG（若驱动支持）或 modinfo nvidia | grep watchdog 查看当前看门狗超时阈值（默认通常为 7 秒）。
确认是否启用了 NVIDIA MPS（Multi-Process Service）或与其它 GPU 任务并发，加剧 GPU 资源争抢。
记录崩溃时的模型上下文占用情况（ctx-size = 1939864 对应显存占用约 38GB+，需确认 RTX 6000（48GB）的剩余显存是否足够支撑峰值临时分配）。
确认 llama.cpp 编译选项（Clang 22.1.8 for Linux x86_64）是否开启了 Debug 或未优化的 CUDA 代码路径，导致 Kernel 执行速度变慢。

解决步骤

修改 NVIDIA 驱动看门狗超时时间（可优先尝试）：参考 #27102 中的 workaround，编辑 Xorg 或 nvidia 驱动的配置参数，将 Notify Timeout Seconds 从默认的 7 秒调大（例如 30 秒或 60 秒）。具体操作视发行版而定（对于使用 NVIDIA 驱动 DIY 的 systemd 系统，可在 /etc/modprobe.d/nvidia.conf 中添加 options nvidia NVreg_RegistryDwords="RMNotifyTimeoutSeconds=30" 后重建 initramfs 并重启）。注意该参数需同时作用于驱动和 GPU 固件，修改后需验证 nvidia-smi -q -d WATCHDOG 是否生效。
回退或更新 llama.cpp：Issue 中该崩溃发生在 commit 193d1f2d9（基于 b0539c43 并合并了 #26692）。可尝试升级到 issue 关闭时（2026-08-23）最新的 stable 分支，或回退到未合并 #26692 之前的分支，验证是否复现。
降低上下文窗口或调整投机解码参数：若上述配置必须保留超长上下文，可尝试将 spec-type = draft-mtp 改为 spec-type = draft（关闭 MTP 投机解码），或将 spec-draft-n-max 从 4 降低到 1-2。同时观察 ctx-size 减半（例如 1000000）后崩溃频率是否下降。
限制并发请求数：Issue 中 np = 4 意味着同时有 4 个并行解码槽位。可临时改为 np = 1 验证是否仅在高并发下触发 Kernel 超时。

验证方法

修改看门狗超时时间后，运行 nvidia-smi -q -d WATCHDOG | grep -i timeout 确认新阈值已生效。随后使用与原 Issue 相同的 router 配置持续高压生成（例如触发多并发请求），观察至少 24 小时或连续生成数万 tokens 后是否仍有 cudaStreamSynchronize 错误。同时检查系统日志（journalctl -k）中没有新的 NVRM: Xid 8 或 NVRM: krcWatchdog_IMPL 记录，并确认 llama-server 进程未退出。