Eval bug: Gemma 4 31B + draft-mtp: CUDA illegal memory access when MTP drafts right after the KV cache is rolled back or cleared (checkpoint

快速结论：该报错通常出现在 llama.cpp 使用 draft-mtp 投机解码、且目标模型的 KV cache 刚被回滚（checkpoint 恢复）或整体清空（full re-process / memory_seq_rm）之后开始生成时，表现为 CUDA illegal memory access；优先排查 draft 与 target 的 KV 状态是否同步，以及能否先关闭 MTP 或禁用 checkpoint 来规避。

适用环境：Windows；llama.cpp 官方 Windows CUDA release（build 11840 / 36e36e63a，Clang 20.1.8，x86_64），该问题在 b11734、b11796、b12012、b12020 上也曾出现；CUDA backend；NVIDIA GeForce RTX 4060 Ti 16 GB（compute 8.9），驱动 617.42，CUDA UMD 13.4，32 GB RAM。

最快修复方案：暂无确认的一步修复方案。Issue 中验证过仅“去掉 MTP”（不加载 -md、不使用 --spec-type draft-mtp）在所有测试运行中均为 0 次崩溃，可作为规避手段而非修复。

注意事项：关闭 MTP 会明显降低生成速度（Issue 中约 24.8 降至 18.6 t/s）；--ctx-checkpoints 0 只是减少了 checkpoint 恢复路径，Issue 更新中在 full re-process 后仍会崩溃；更换 Q8_0 drafter 只降低崩溃频率（408 次请求 3 次崩溃对比 0 次崩溃的测试数据，但实际聊天测试中仍崩溃 1 次），并未消除问题；-fa off 和 GGML_CUDA_DISABLE_GRAPHS=1 均未彻底解决。

问题场景

用户在 Windows + NVIDIA RTX 4060 Ti 16 GB 上以官方 CUDA release 运行 llama-server，目标模型为 Gemma 4 31B 的微调（TheDrummer Artemis 31B v1.2，IQ3_XXS），并同时加载 MTP draft 模型（-md mtp-gemma-4-31B-it.gguf --spec-type draft-mtp --spec-draft-n-max 1），KV cache 量化为 -ctk q8_0 -ctv q8_0，61/61 层全部 offload 到 GPU。工作负载为 /completion 请求配合 cache_prompt: true，在共享约 3k token system prompt 的两个长对话间交替，使多数请求需要恢复 context checkpoint。崩溃也出现在 --ctx-checkpoints 0 下的 full prompt re-process 之后，以及普通聊天回复生成过程中。

报错原文

CUDA error: an illegal memory access was encountered
in ggml_backend_cuda_synchronize (ggml-cuda.cu:2709 / ggml-cuda.cu:2845)
with cudaStreamSynchronize at ggml-cuda.cu:110
exit code 0xC0000409

restored context checkpoint (pos_min = 3013, pos_max = 4036, n_tokens = 4037, n_past = 4036, size = 425.013 MiB)
cached n_tokens = 4036, memory_seq_rm [4036, end)
n_gen = 100, tg = 27.90 t/s
CUDA error: an illegal memory access was encountered

forcing full prompt re-processing due to lack of cache data
memory_seq_rm [0, end)

原因分析

从 Issue 的对照实验看，共同因素是“MTP draft 在 target 的 KV cache 被回滚或清空后立刻开始生成”。明确排除的项：关闭 MTP 后所有运行 0 崩溃（run B）；崩溃在 GGML_CUDA_DISABLE_GRAPHS=1 下仍出现（run D），说明与 CUDA graphs 无关；Unsloth 与 ggml-org 的 Q8_0 drafter 49 个张量逐字节一致、仅文件内顺序不同，说明问题不来自 Unsloth 的转换过程。

可能原因：回滚或清空后，draft 上下文的 KV 状态没有与 target 同步推进，导致 draft 侧访问到失效/越界的内存。报告者指出崩溃频率随 draft 拒绝率上升（Q4_0 drafter 接受率 57% 时 408 次请求崩溃 3 次；Q8_0 drafter 接受率 90% 时 420 次请求 0 崩溃；但聊天场景中 Q8_0 接受率降到 47–60% 时仍解析崩溃 1 次），这一关联与上述推测一致。报告中提到的相似 Issue 为 #28619、#25144 和 #22527、#30436，但均未在本次讨论中确认为根因。

环境排查

llama.cpp 版本与 build 号（崩溃出现在 b11734、b11796、b11840、b12012、b12020，Issue 未给出 first bad commit）。
是否为官方 Windows CUDA release，Clang 版本与 x86_64 架构是否一致。
NVIDIA 驱动版本（617.42）与 CUDA UMD 版本（13.4），以及显卡算力（8.9）。
显存占用是否接近上限：Issue 中 16.38 GB 卡上报告 15.76 GB 被占用，检查是否存在过多层 offload 或过大 cache。
是否使用了 GPU 内存超频：报告者原本在 +375 内存超频下崩溃，但在 stock 内存时钟下复现，故超频不是唯一因素，但仍建议按 stock 设置复测。
是否启用 MTP（-md、--spec-type draft-mtp）、--spec-draft-n-max 取值，以及是否开启 --ctx-checkpoints 0。
KV cache 类型（-ctk/-ctv）与 -fa 开关状态，draft 模型文件来源和量化类型。
是否使用 /completion 搭配 cache_prompt: true，以及请求是否频繁命中 checkpoint 恢复或 full re-process 路径。

解决步骤

先做规避：去掉 -md 与 --spec-type draft-mtp（保持其余参数不变），确认是否不再崩溃。Issue 中这是唯一在所有运行中都为 0 次崩溃的设置，但会降低吞吐。
若必须使用 MTP，可优先尝试 --ctx-checkpoints 0。Issue 中该设置在一次 56,625 token 的运行中为 0 崩溃，但它只避开了 checkpoint 恢复路径；后续 full re-process 场景下仍会崩溃。
可优先尝试更换 draft 模型：将 Q4_0 drafter 换为 MTP/mtp-gemma-4-31B-it-Q8_0.gguf（来自 unsloth/gemma-4-31B-it-GGUF）。Issue 中同一工作负载下崩溃从 3/408 降到 0/420，但在混合聊天负载中仍有 1 次崩溃，属于降低频率而非修复。
可优先尝试在 --spec-draft-n-max 1 与 2、3 之间切换做对照；Issue 中 1 时 49 次请求 1 次崩溃，2、3 时为 0 次，但样本量太小，不足以得出可靠结论。
复核显存余量，避免同时满载 offload 与 16k 上下文、q8_0 KV 的组合；Issue 中报告已占用 15.76/16.38 GB，接近上限时先降低上下文或层数再复测。
用 stock 内存频率（不用 +375 超频）复现一次，排除超频对崩溃触发概率的影响；Issue 中 stock 下仍能复现，若已复现则无需继续沿超频方向排查。
排查阶段可先不用 -fa off 或 GGML_CUDA_DISABLE_GRAPHS=1 作为结论：前者改变 KV 类型并导致大部分层无法放入 GPU，后者仍出现过 1 次崩溃。
若以上都不能消除崩溃，保留崩溃日志（含 checkpoint 恢复记录、memory_seq_rm 记录、ggml_backend_cuda_synchronize 行号、Windows nvlddmkm event 153）并在上游 Issue 中跟进。

验证方法

在与崩溃时相同的工作负载下连续运行、记录崩溃次数与生成的 token 数：先验证“MTP off”在同一请求序列上 0 崩溃且无 CUDA error: an illegal memory access was encountered，以确认崩溃路径与 MTP 相关；再对每个规避设置（--ctx-checkpoints 0、Q8_0 drafter、不同的 --spec-draft-n-max）做交替、同序请求的对照运行，确认崩溃是否消失或频率下降。判断标准包括：日志中不再出现 ggml_backend_cuda_synchronize 处的 illegal memory access、进程退出码不再为 0xC0000409、Windows 事件日志不再出现 nvlddmkm event 153。由于 Issue 中单一设置下仍有零星崩溃，短时间无崩溃不等于问题已修复，需要足够长的对照运行。