Eval bug: server silently stops processing when /metrics endpoint is scraped by VictoriaMetrics

快速结论：在启用 --metrics 的 llama-server 上，当 VictoriaMetrics 每秒抓取 /metrics 且一次请求的提示词处理时间足够长（约超过 20 秒）时，服务端可能静默停止生成，即出现 Eval bug: server silently stops processing when /metrics endpoint is scraped by VictoriaMetrics。优先排查请求生成阶段是否卡在 CUDA graph 重放（replay）中，以及抓取端的实现方式（压缩、keepalive、抓取间隔）是否与之一同出现。

适用环境：llama-server 0.4.1-dev（build 10964，commit b29c606e2），MSVC 19.51.36256.0 x64 构建；Windows；CUDA（GGML 后端）；AMD Ryzen 9 9950X3D + 2× RTX 5070Ti；模型 utautako/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF；启动参数含 --models-preset、--models-max 1、--metrics，配置里开启 cont-batching、spec-type = draft-mtp、flash-attn = on、split-mode = tensor、tensor-split = 0.5,0.5。报告者称在 511f9c137 上至少可复现。

最快修复方案：Issue 中没有确认的一步修复方案。报告者最终发现，同时设置 GGML_CUDA_DISABLE_GRAPHS=1 并在 VictoriaMetrics 抓取配置中设置 disable_compression: true 后，生成时间明显延长，但在一次 188 秒的生成后仍然卡死，因此该组合不能视为已修复。

注意事项：GGML_CUDA_DISABLE_GRAPHS=1 会关闭 CUDA Graph 加速，可能影响性能；disable_compression、disable_keepalive、抓取间隔等设置只改变客户端行为，是否真正规避问题未被证实。Issue 标签为 bug-unconfirmed，根因尚未确定，所有“原因”应视为待验证的假设。

问题场景

用户在 Windows 上运行 llama-server，通过 --models-preset 加载 Qwen3.8-27B-NVFP4-MTP-Q8attn GGUF，开启 MTP 投机解码、Flash Attention、分布式张量切分到两张 RTX 5070Ti，并启用 --metrics。VictoriaMetrics 每秒抓取一次 /metrics；当请求的提示词处理耗时较长时，服务端在无报错的情况下停止处理，GPU 占用降为 0，客户端收不到响应。报告者用 PowerShell 脚本每秒抓取时未复现，只有 VictoriaMetrics 抓取时出现。

报错原文

Eval bug: server silently stops processing when /metrics endpoint is scraped by VictoriaMetrics

原因分析

根据 Issue 中的日志分析，卡死并不是发生在提示词处理或服务器队列阶段，而是发生在生成阶段的 CUDA graph 重放过程中：目标解码线程在重放 258 个 CUDA graph 中的第 162 个后不再返回，n_decode_total 停留在 109，后续 /metrics 请求仍由 worker 线程正常响应，因此日志看起来“没有异常”。可能原因是：在 sm_120（RTX 5070Ti 计算能力 12.0）、双卡 tensor split、CUDA graph 重放组合下触发 CUDA 层挂起，与 Issue #27330 描述的 RTX 5090 Laptop 挂起模式相似；/metrics 抓取本身在 CPU 测试中未能单独复现问题，可能只是同一进程内唯一的并发活动，因而成为触发条件之一，而非根因。

报告者补充的对照结果互相矛盾：单独设置 disable_compression: true 会卡，单独设置 GGML_CUDA_DISABLE_GRAPHS=1 也会卡，两者同时设置后可撑到 188 秒但仍会卡死。因此不能确认抓取端压缩方式与 CUDA graph 之间存在确定因果关系。

环境排查

确认 llama.cpp 版本与构建方式：报告者使用 0.4.1-dev build 10964 / b29c606e2，MSVC x64；不同版本行为可能不同。
确认 CUDA 后端是否启用 CUDA Graph，以及显卡计算能力（RTX 5070Ti 报告为 sm_120）。
确认是否使用双卡 tensor-split，以及 split-mode 设置。
确认是否开启 MTP 投机解码（spec-type = draft-mtp、spec-draft-n-max = 3），以及 flash-attn、量化 cache 类型（q8_0）等配置。
确认抓取端是否为 VictoriaMetrics，以及其 scrape_interval、disable_compression、disable_keepalive 设置；同时确认是否有其他每秒级抓取。
在卡死时刻检查系统层面证据：dmesg 或 Windows 事件查看器中是否有 Xid 报错（Issue 中提到 #27330 涉及 Xid 8 与 RC watchdog）。

解决步骤

先做对照实验：停止 VictoriaMetrics 抓取，连续发起多个足够长的请求进入生成阶段，观察是否仍然卡死。若仍卡死，说明抓取不是必要条件，应转向排查 CUDA graph 挂起。
设置 GGML_CUDA_DISABLE_GRAPHS=1 后重新运行服务器，并保持抓取继续，观察卡死是否消失或推迟。Issue 中该设置单独使用无效，但这是缩小范围的必要对照。
在 VictoriaMetrics 抓取配置中加入 disable_compression: true，同时保留上一步的环境变量，并重复长请求测试，记录卡死发生的时间点。可优先尝试该组合，但需注意它并未被确认修复问题。
分别单独测试 disable_keepalive: true 与将 scrape_interval 从 1s 调大，判断抓取频率或连接复用是否影响复现概率；Issue 中这两项单独测试均未解决问题。
当卡死发生时，立即查看 dmesg 或 Windows 事件日志中的 Xid 记录，并对照 llama.cpp 日志中最后一次 CUDA Graph 重放的位置，确认是否与 #27330 的模式一致。
若上述步骤仍无法规避，可向原 Issue 或 #27330 补充复现信息（版本、sm_120、双卡、MTP、抓取端配置、卡死时刻日志），等待上游给出已验证的修复。

验证方法

在保留抓取端运行的条件下，连续发起多个耗时超过 2～3 分钟、能进入生成阶段的请求，观察是否还会出现 GPU 占用归零、客户端无响应的情况；同时检查 llama.cpp 日志中解码计数是否持续增长、是否出现 yield 之后不再有后续输出的情况。由于报告者在 188 秒后仍复现卡死，验证时建议把观察时间放长，并检查系统日志中是否出现 Xid。