快速结论：该报错通常出现在 llama.cpp 的 llama-server 以 HIP 后端、多 GPU 运行 Qwen3.5 系（如 Qwen3.5-35B-A3B）模型并启用 context checkpoint（--ctx-checkpoints）后，加载或匹配检查点时触发 GPU 内存访问故障。优先排查 context checkpoint 机制与 HIP 多卡拆分组合，最直接的规避方向是禁用 context checkpoints。
适用环境：Linux；HIP/ROCm（原帖为 CDNA 架构如 MI100，另有社区在 2× MI50 gfx906、ROCm 7.2.4 下复现）；双 GPU 及以上；模型为 Qwen3.5-35B-A3B-UD-Q6_K_XL.gguf（qwen35moe 混合架构）。原帖未给出 Python、PyTorch、CUDA 版本。
最快修复方案：暂无确认的一步修复方案。已有复现者报告设置 --ctx-checkpoints 0 后可持续运行数周不再出现该 fault，可作为规避选项（该配置并非上游确认的正式修复）。
注意事项：禁用 context checkpoint 对混合循环模型影响较大：社区实测在“同 prompt 追加 512 token”的续写场景下，开启检查点时仅需重新预处理 516 token、prefill 约 0.75 s；关闭后需重跑全部 8954 token、prefill 约 7.44 s。此外原帖作者在单卡或 --device ROCm0,ROCm0 下未能复现，说明该问题与真实多卡环境相关；根因尚未定位。
问题场景
用户使用 llama.cpp 的 llama-server 以 -ngl 99 -fa 1 加载 Qwen3.5-35B-A3B 模型，配合 --ctx-checkpoints 128 --checkpoint-every-n-tokens 4096、-np 2、-ub 2048 -c 48000 等参数，在两块 AMD GPU（HIP/CDNA）上运行。当服务在后续请求中根据 LCP 相似度复用 slot、创建并匹配上下文检查点时（日志中 Checking checkpoint with [4052, 4052] against 4560...），进程发生 GPU 内存访问故障崩溃。报告者指出自 PR #20087 合入后问题被暴露，并提供了 requesttest.py 复现脚本。
报错原文
slot update_slots: id 0 | task 111 | Checking checkpoint with [4052, 4052] against 4560...
Memory access fault by GPU node-4 (Agent handle: 0x55aa5dbd9e30) on address 0x7f6615a2a000. Reason: Page not present or supervisor privilege.社区在 2× MI50 上复现到同类报错：
Memory access fault by GPU node-1 (Agent handle: 0x...) on address 0x... Reason: Page not present or supervisor privilege.原因分析
目前根因未确定。可确认的事实与线索如下：
- 崩溃发生在检查点匹配/加载阶段，因此问题与 context checkpoint 数据在 HIP 多卡环境下的读写有关（可能原因，尚未证实）。
- 原帖作者排除了与 Issue #20433 的关联：回退对应 commit 后问题依旧。PR #20087 更可能是暴露该问题，而非引入。
- 仅在真实多卡环境出现；作者在单卡及
--device ROCm0,ROCm0下均无法复现，Mac 上用虚拟设备模拟也未复现，倾向为 HIP 特有的行为，但评论者认为也可能是 llama.cpp 代码中的缺陷被 HIP 路径触发。 - 调试手段受限：rocgdb 未能定位问题；ROCm asan 需要 xnack+，作者的 MI100 机器内混有 gfx1100 GPU 而无条件启用，且 asan 仅限 CDNA Instinct 显卡。
- 有社区报告 Windows 下 HIP + CUDA 混用加载 3.5 397B 时，创建 context checkpoint 也会冻结，但该报告与本案是否为同一问题尚未确认。
环境排查
- 确认是否确实使用多块 AMD GPU 运行，且是否使用
--split-mode layer（有复现者指出-sm tensor会段错误，-sm layer正常）。 - 确认 llama.cpp 构建版本与后端（HIP/ROCm 版本、是否为社区构建如 gfx906 分支）。
- 确认是否启用了 context checkpoint：
--ctx-checkpoints、--checkpoint-every-n-tokens。 - 确认模型名称与量化格式（Qwen3.5 系 qwen35moe 混合架构）。
- 原帖未提供 Python、PyTorch、CUDA 版本，这些项目无法据此排查。
- 可参考复现命令，逐项核对：
./bin/llama-server -ngl 99 -fa 1 -m Qwen3.5-35B-A3B-UD-Q6_K_XL.gguf -c 48000 -np 2 -sps 0.3 -cram 65536 --port 8080 -ub 2048 --ctx-checkpoints 128 --checkpoint-every-n-tokens 4096。报告者强调其中每个参数都很关键，改动任一参数都可能无法用复现脚本触发（但正常使用中大多数时候仍会失败）。
解决步骤
- 若需要先恢复可用服务，可优先尝试在启动参数中加入
--ctx-checkpoints 0关闭 context checkpoint。社区复现者表示该配置下已连续运行数周未再出现 fault，可直接绕开崩溃路径。 - 评估关闭检查点的性能代价：在混合循环模型上，检查点是目前唯一有效的 prompt 复用手段。续写测试中关闭后需重新 prefill 全部 8954 token（约 7.44 s），开启时仅需 516 token（约 0.75 s）。对长上下文服务，可同时设置
--cache-ram 0观察缓存行为是否变化，但这不改变检查点被关闭的事实。 - 用 Issue 提供的 requesttest.py 与上述 llama-server 命令做最小复现前，先记录可稳定触发的参数组合，作为后续验证对照。
- 如具备多卡 AMD 环境，可向 Issue 反馈硬件（7900XTX、MI50 等）与复现结果，协助上游定位；注意只有 CDNA 架构可运行 ROCm asan。
- 关注该 Issue 上游进展；截至目前没有确认的代码级修复方案。
验证方法
以相同请求脚本和相同 llama-server 参数连续发起多轮对话，观察日志中是否仍出现 Checking checkpoint with [..., ...] against ... 后紧跟 Memory access fault by GPU node-...。若使用 --ctx-checkpoints 0 后数周内不再出现 fault，可视为规避成功，但这不代表根因已修复。
参考来源
相关讨论中提及的其他 Issue 与资源：#20433、#22351、PR #20087、requesttest.py 复现脚本
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
这个方案解决了吗？
可以继续搜索完整报错，或查看同一工具的其他排查指南。
![[Bug]: Stream cut after finish_reason but before the include_usage chunk is logged as success with locally counted usage (cached_tokens lost](https://www.chat-gpts.plus/wp-content/uploads/2026/10/47332-45006be2-768x403.jpg)
