Eval bug: Qwen 3.5 weird behavior…

快速结论：该问题通常出现在 llama.cpp 使用 CUDA 后端、通过 Docker 同时挂载多块 NVIDIA GPU 运行 Qwen 3.5 GGUF 模型时，即使将 temperature 设为 0，输出也可能变成一串 /////// 或 ???????，并且结果不稳定；优先排查多 GPU 切分与 KV cache 类型相关配置。

适用环境：llama.cpp 镜像 ghcr.io/ggml-org/llama.cpp:server-cuda（版本 8589 / 08f21453a，GNU 14.2.0）；操作系统 Linux；后端 CUDA；硬件为 NVIDIA RTX 6000 Ada x8、AMD EPYC 9354；模型为 unsloth/Qwen3.5-9B-GGUF 的 Qwen3.5-9B-BF16.gguf；启动参数包含 --n-gpu-layers 999、--cache-type-k bf16、--cache-type-v bf16。

最快修复方案：暂无确认的一步修复方案。Issue 在 2026-05-19 关闭时标签为 bug-unconfirmed，讨论中未给出明确验证过的修复步骤。可优先尝试减少同时使用的 GPU 数量，因为报告显示设备数达到四块或更多时才复现。

注意事项：“减少 GPU 数量”只是根据复现规律推导的规避手段，并非 Issue 中确认的正式修复；-fit off 已被报告不能解决该问题。在根因未确认前，不建议把该现象直接归因于模型本身或采样参数。

问题场景

用户在 Linux 上通过 Docker 运行 llama.cpp 的 CUDA 镜像，加载 Qwen 3.5 9B BF16 GGUF 模型，使用 llama-server 或 llama-completion 推理。当通过 --gpus 指定多块 GPU（例如 device=7,6,5,4）并设置 --n-gpu-layers 999 时，模型输出会非确定性地退化成连续的 //////////////// 或 ????????????????。用户特别指出，即使 temperature 为 0，结果仍然会在多次运行之间变化，这与通常对贪心解码稳定性的预期不符；同样的模型在 vllm 中未观察到该行为。

报错原文

Eval bug: Qwen 3.5 weird behavior...
content":"////////////////////////////////////////////////////////////////"
????????????????????????????????
common_perf_print:    graphs reused =         31
> EOF by user

原因分析

目前 Issue 未确认根因。根据复现规律，最可能的方向是多 GPU CUDA 切分路径存在不稳定因素：问题只在四块或更多 GPU 同时参与时出现，减少 GPU 数量后复现概率下降甚至不再出现。temperature=0 仍然结果不稳定，说明问题更可能发生在采样之前的计算或通信环节，而不是采样器本身。此外，用户使用了 --cache-type-k bf16 与 --cache-type-v bf16，KV cache 类型是否与多 GPU 切分、CUDA kernel 存在交互，仍属于未验证的可能原因。Issue 关闭时标签为 bug-unconfirmed，因此不能把上述方向当作已确认结论。

环境排查

确认 llama.cpp 镜像版本与构建信息，例如 version: 8589 (08f21453a) 是否为当前复现版本。
确认后端为 CUDA，并检查 Docker 内可见 GPU 数量与 --gpus 传入的设备列表是否一致。
确认复现时使用的 GPU 数量：Issue 中报告单卡或少量卡较难复现，四块及以上更容易触发。
确认是否使用 --cache-type-k bf16 与 --cache-type-v bf16；可尝试对照默认 cache 类型测试，但这只是排查方向，并非已验证修复。
确认 --fit off 是否已关闭；Issue 中明确表示 -fit off 不能解决该问题。
确认模型文件与快照是否一致，例如 Qwen3.5-9B-BF16.gguf 的下载来源和文件完整性。
如果使用 llama-server，同时检查 --jinja、--repeat-penalty 1.0、--presence-penalty 0.0、--min-p 0.0、--top-k 20、--top-p 0.95、--temp 0.6 等参数组合是否与复现命令一致。

解决步骤

先用 Issue 中的最小复现命令确认问题：通过 Docker 挂载多块 GPU，使用 llama-completion 或 llama-server 加载 Qwen 3.5 9B BF16，并将 temperature 设为 0。
逐次减少 GPU 数量进行对照测试，例如从 device=7,6,5,4 降为 7,6,5、7,6、7。Issue 报告显示四块及以上更容易出现，减少设备数可能降低触发概率。
如果减少 GPU 后不再复现，可优先在稳定配置下运行，等待上游对多 GPU CUDA 路径的进一步确认。
如果必须使用多 GPU，可尝试对照更改 KV cache 类型，例如去掉 --cache-type-k bf16 与 --cache-type-v bf16，观察是否仍出现连续斜杠或问号。该步骤属于可优先尝试的排查，并非 Issue 已验证修复。
不要依赖 -fit off 作为修复手段；Issue 中已明确该选项没有帮助。
如果问题仍然存在，收集好版本信息、GPU 设备列表、启动命令、完整日志以及 GOOD/BAD 对照结果，再向上游提交或补充信息。

验证方法

用相同 prompt、temperature=0、n_predict 和相同模型，在调整后的 GPU 配置下重复运行多次。如果输出不再出现连续 /////// 或 ???????，并且多次运行结果保持一致，即可认为规避措施生效。但需要注意，该问题本身是非确定性的，单次正常输出不足以证明彻底解决，建议至少按 Issue 中的循环方式做多轮对照，并记录 GOOD/BAD 计数。