Eval bug: 2-GPU CUDA tensor split is unstable with Qwen3.8-27B on Windows, including with MTP disabled

快速结论：该报错是 llama.cpp 在 Windows 下多 GPU（2× RTX 3090）CUDA 张量并行（tensor split）或层并行（layer split）推理时出现的稳定性问题，表现为 CUDA illegal memory access 或进程无提示崩溃。优先排查多 GPU 异步 CUDA 执行顺序与 AllReduce 同步机制，而非单纯依赖禁用 MTP 或 CUDA graphs 来规避。

适用环境：llama.cpp b10595（commit e8eed4525aaca00a78d8f837dce90dd4d4708133）；Windows 11 官方 CUDA 13.3 x64 构建；Ryzen 9 9950X + 96 GB DDR5 + 2× RTX 3090 24 GB；Qwen3.8-27B（Unsloth GGUF，Q6_K_M 及 UD-Q5_K_XL、DFlash2 变体）；BF16 KV cache 与 mmproj；涉及 BeeLlama fork（基于 llama.cpp 6fdd0ac89）。Issue 已确认 Python 版本不在讨论范围内。

最快修复方案：暂无确认的一步修复方案。Issue 仍处于 bug-unconfirmed 状态，作者未提供已验证的官方补丁。可优先尝试将多 GPU 推理降级为使用更保守的同步/单流配置（以牺牲 prefill 吞吐为代价约从 1349 tok/s 降至 795–806 tok/s），或更换/复核硬件稳定性（作者最终自述问题可能源于其显卡 undervolt 不稳定）。

注意事项：禁用 CUDA graphs（LLAMA_GRAPH_REUSE_DISABLE=1）、禁用 MTP、限制 WDDM collectives 至单槽、调整同步时序等均被作者证实不能根除故障；broad sync 只会移动故障发生位置。上述慢速同步变体虽能让测试序列通过，但作者将其视为时序敏感证据而非修复方案。最终”undervolt 不稳定”推测仅来自作者个人后续反思，未在 Issue 中被官方确认，仍需谨慎对待。

问题场景

用户在 Windows 11 上使用官方 llama.cpp b10595 构建加载 Qwen3.8-27B-UD-Q6_K_M.gguf（BF16 mmproj），通过 --device CUDA0,CUDA1、--split-mode tensor、--tensor-split 1,1 在两块 RTX 3090 上发起推理。小规模 canary 与单次大提示词请求可通过，但在随后的图像优先（image-first）请求中发生故障。使用 MTP（Multi-Token Prediction）与 --no-mmproj-offload，且 MTP 被禁用时故障依然存在。后续在 layer split（--split-mode layer --tensor-split 50,50）配置下，使用 DFlash2 draft 模型（固定于 CUDA0）也能复现非法内存访问，非法访问却报在 CUDA1。

报错原文

Eval bug: 2-GPU CUDA tensor split is unstable with Qwen3.8-27B on Windows, including with MTP disabled

典型 CUDA 错误栈摘录：

CUDA error: an illegal memory access was encountered
current device: 1
ggml_backend_cuda_synchronize
cudaStreamSynchronize(cuda_ctx->stream())

current device: 0
ggml_cuda_ar_acquire_slot
allreduce.cu:368
cudaEventSynchronize(p->ev_pool[i][slot].ker)

作者同时报告部分运行（3 次全新运行中 1 次）在 prompt 处理至 12,288 tokens 时进程被直接终止，日志中无任何 CUDA 错误或优雅关闭信息。

原因分析

Issue 明确指出影响区域不仅限于 MTP。可能原因包括：多 GPU CUDA 异步执行顺序与生命周期管理缺陷（涉及目标图复用、scheduler/buffer 生命周期、跨设备传输）；Windows 下两设备无 P2P 时的 collective 路径（AllReduce）槽位复用同步问题在 tensor-split 重度故障模式中是强嫌疑；layer-split 与 tensor-split 故障未必同根，但证据共同指向多 GPU CUDA ordering/lifetime 问题。作者在 Issue 发布后自述：若崩溃随机且深度排查无果，可能并非软件问题，而是用户显卡 undervolt 在特定电压下不稳定所致——该论断未被官方确认，可作为可能原因之一。

环境排查

确认 llama.cpp 版本为 b10595（commit e8eed4525aaca00a78d8f837dce90dd4d4708133）或更高；BeeLlama fork 基线 commit 6fdd0ac89。
确认操作系统为 Windows 11，使用官方 Windows x64 CUDA 13.3 构建。
确认双卡型号各为 RTX 3090 24 GB、驱动与 WDDM 模式；检查是否存在无 P2P 跨设备 collective 路径。
检查每 GPU 的 free VRAM 是否与作者环境相当（故障时最低约 8536 MiB / 8440 MiB），并排除共享内存渐进增长。
若在自用硬件上排查，需额外评估显卡 undervolt 或供电稳定性（作者个人的最终推断）。
确认 MTP 状态、CUDA graphs 状态、mmproj offload 设置、KV cache 类型（BF16、--kv-unified）。

解决步骤

复现与基线定位：使用作者给出的官方 b10595 构建与 Qwen3.8-27B-UD-Q6_K_M.gguf、BF16 mmproj、2× RTX 3090，以 --split-mode tensor --tensor-split 1,1 --ctx-size 131072 -b 4096 -ub 1024 --cache-type-k bf16 --cache-type-v bf16 --kv-unified 复现 CUDA abort，可优先禁用 MTP 排除其干扰。
扩大执行模式验证：作者建议确认故障不限于 tensor split；可将 --split-mode 切换为 layer 并配合 --tensor-split 50,50（draft 固定 CUDA0）观察能否复现非法内存访问。
排除已知无效操作：禁用 CUDA graphs、设置 LLAMA_GRAPH_REUSE_DISABLE=1、缩减 WDDM collective 至单代槽、broad sync/retirement prior generations、将故障 Q5_K 操作改走 cuBLAS、关闭 CUDA fusion/MMQ——以上均被作者证实无效或仅移动故障点，不必重复尝试。
可优先尝试慢速同步/单流配置：作者发现部分 slower synchronization/single-stream 变体可以让测试序列通过，但 prefill 会从约 1349 tok/s 降至 795–806 tok/s；作者明确将此视为 timing/order sensitivity 证据而非修复。若非性能敏感场景，可用此配置绕过故障以继续工作。
复核硬件稳定性：若软件层面所有方向均已排除且崩溃呈随机性，依据作者后期个人经验，建议检查显卡 undervolt 设置在特定负载/电压下是否稳定，必要时恢复默认电压曲线重新跑相同测试序列。
关注上游进展：当前标签为 bug-unconfirmed，建议持续跟踪 llama.cpp Issue #27750 及 #27122 是否有官方补丁或确认的根因分析。

验证方法

以多轮混合请求（文本/图像）压力测试验证：确认小 canary、约 24k token 大请求、图像优先请求均能连续通过且 llama-server 不中断。在 layer split 配置下，验证能稳定完成 >170k retained tokens 后继续发起新请求不触发 CUDA error: an illegal memory access。若采用慢速同步配置，还需确认 prefill 性能保持在可接受范围（约 795–806 tok/s），并确认无 AllReduce cudaEventSynchronize 错误输出。若怀疑显卡 undervolt，需在恢复默认电压后连续多次干净运行同一压力序列以确认故障消除。