平台：Linux（Ubuntu）/ llama.cpp b10488 / NVIDIA RTX PRO 4500 Blackwell 32GB
模型：Qwen3.8-27B-UD-Q4_K_XL（Unsloth Dynamic v3.0，17.92GB）
用途：Hermes Agent 后端主力模型
日期：2026-08-20（含 1 小时压力测试 + 社区崩溃根因调研）

一、先说结论

• 32GB Blackwell 卡跑 Qwen3.8-27B UD-Q4_K_XL，128K 上下文 + MTP 投机解码，稳定可用。
• 性能：正文吐词 67 t/s（1 小时压测 avg_tps=67.2）。
• 崩溃根因已定位：不是量化问题、不是 llama.cpp 问题——是 NVIDIA Blackwell GSP 固件已知 bug（GB202 die 通病），社区多卡实证。
• 128K 上下文是工程折中：200K 实测 59 分钟崩溃，128K 有长期零崩记录。降 ctx 缩短 kernel 耗时→降低 GSP watchdog 触发概率，非根因修复。
• 根因修复等 NVIDIA：上游已跟踪（NVIDIA/open-gpu-kernel-modules #1080、#1111），无公开 ETA。595-open 是当前唯一可用驱动路径。

二、硬件 / 软件环境

三、模型来源

通过 hf download 直连 HuggingFace 下载，SHA256 校验通过。

四、部署配置

systemd 用户服务 ~/.config/systemd/user/llama-qwen-27B.service：

[Unit]
Description=llama.cpp Qwen3.8-27B UD-Q4_K_XL Service (128K, effort=medium, MTP n-max 2)

[Service]
ExecStart=%h/llama.cpp/build/bin/llama-server \
  -m %h/models/Qwen3.8-27B/Qwen3.8-27B-UD-Q4_K_XL.gguf \
  --mmproj %h/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias qwen3.8-27B \
  --host 127.0.0.1 --port 8000 \
  --ctx-size 131072 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --parallel 1 \
  --jinja \
  --no-mmap \
  --ubatch-size 512 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --cache-ram 32768 \
  --chat-template-kwargs '{"reasoning_effort": "medium", "preserve_thinking": true}' \
  --reasoning-preserve \
  --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0.0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

Environment=CUDA_VISIBLE_DEVICES=0
Restart=on-failure
RestartSec=10

管理命令：

systemctl --user start llama-qwen-27B    # 启动
systemctl --user stop llama-qwen-27B     # 停止
systemctl --user status llama-qwen-27B   # 查看状态
journalctl --user -u llama-qwen-27B -f   # 实时日志

五、1 小时压力测试结果

测试配置

结果

崩溃现场

18:38:42 NVRM: krcWatchdog_IMPL: RC watchdog: GPU is probably locked! Notify Timeout Seconds: 7
18:38:42 NVRM: Xid (PCI:0000:09:00): 8, pid=25546, name=llama-server, channel 0x00000012
18:38:42 CUDA error: the launch timed out and was terminated
18:38:45 systemd: llama-qwen-27B.service: Main process exited, code=dumped, status=6/ABRT

崩溃后 systemd 自动拉起新进程，服务自动恢复。

六、崩溃根因：Blackwell GSP 固件 Bug

这不是什么

• 不是量化模型的问题（Q4_K_M、UD-Q4_K_XL、Q4_K_P 均崩）
• 不是 llama.cpp 的 bug（b8679 之前/之后均有报告）
• 不是驱动版本问题（580/590/595 均复现）
• 不是散热/供电问题（室温 28°C、1600W 铂金电源均有人复现）

这是什么

NVIDIA Blackwell 架构（GB202 die）的 GSP 固件心跳超时 bug。GSP（GPU System Processor）是 Blackwell 上强制启用的固件处理器，在持续高负载下会心跳超时死锁，导致 GPU 进入不可恢复状态。

社区证据

关键对比（#1111 报告者）：同机 RTX PRO 6000 Blackwell + RTX 3090×2，跑相同 llama.cpp 持续推理——Blackwell 45 分钟必崩，Ampere（sm_86）20+ 小时零崩。确认是 Blackwell 特有。

崩溃链

decode kernel 执行（随上下文长度增长）
    ↓ 超过 ~7 秒
GSP watchdog 判定 GPU 锁死
    ↓
krcWatchdog_IMPL: RC watchdog: GPU is probably locked!
    ↓
Xid 8（launch timeout）→ CUDA error: the launch timed out
    ↓
驱动尝试恢复 → WPR2 安全区无法清除 → 恢复失败
    ↓
GPU 死锁，需要重启/Secondary Bus Reset

为什么不同量化源崩溃频率不同

权重分布 → CUDA kernel 执行时间不同 → 超 7 秒看门狗阈值的概率不同：

• UD-Q4_K_XL 更稳定：权重分布让 kernel 执行时间更短，更不容易触发阈值
• Q4_K_P 更频繁：权重分布导致 kernel 执行时间更接近阈值
• 128K 比 200K 更稳定：上下文更短→KV cache 更小→kernel 耗时更短

上游状态

• NVIDIA 内部已跟踪（#1080 标记为 Open，#1111 标记为 Bug）
• 580-open / 595-open 是当前唯一可用驱动路径（Blackwell 不支持闭源驱动）
• 恢复路径在 Blackwell 上根本性损坏（WPR2 安全区无法清除）
• 无公开修复 ETA

七、为何选择 128K 上下文

背景

Qwen3.8-27B 模型支持 256K 上下文，最初我们也想用 200K（实用性与显存的平衡点）。但实测发现：

原理

GSP 固件 bug 的触发条件是任何单次 CUDA kernel 超过 ~7 秒。上下文越长→KV cache 越大→attention kernel 扫描的数据量越多→执行时间越长→越容易超 7 秒阈值。

降 ctx 不是根因修复（阈值不固定，6万 token 处也曾崩过），但能把概率压到工程可接受水平。

关 MTP 的考量

MTP（Multi-Token Prediction）通过扩大单步 batch（draft n=2）提升吞吐，但也增大了 kernel 负载。关 MTP 可进一步降低崩溃概率，但代价：

最终选择 128K + MTP：性能与稳定性的工程最优解。等 NVIDIA 修 GSP 固件后再考虑升 ctx。

八、踩坑与经验

1. MTP 参数名：--spec-type draft-mtp（旧名 mtp 会启动失败），--spec-draft-n-max 2（推荐值，n=3+ 在 Blackwell 上收益递减）。
2. KV cache 用 Q4：--cache-type-k q4_0 --cache-type-v q4_0，128K 上下文 KV 约 32GB RAM（--cache-ram 32768），显著降低显存占用。
3. --no-mmap：Blackwell 上 mmap 有兼容性问题，关掉更稳。
4. --flash-attn on：必须开启，关闭后 kernel 执行时间更长，更容易触发 GSP watchdog。
5. 崩溃后自动恢复：systemd Restart=on-failure + RestartSec=10，崩溃后 10 秒自动拉起。实际影响仅当轮请求丢失。
6. 量化源选择：UD-Q4_K_XL（Unsloth Dynamic）在 Blackwell 上比其它 Q4 量化源更稳定——不是量化质量差异，是权重分布→kernel timing 差异。
7. Blackwell GSP bug 通用性：RTX 5090/5080/5070/5060Ti/PRO 6000/PRO 4500 均受影响（同一 GB202/G200 die），不是个例。社区已有恢复脚本（sbr_recover.sh）但需要 root 权限。