Eval bug: –moe-cache-mib crashes at load on Vulkan (RX 6900 XT, Windows)

快速结论：在使用 llama.cpp 的 Vulkan 后端加载带 --moe-cache-mib 的 MoE 模型时，如果单个 cache bank 张量大小超过 Vulkan 设备/驱动的缓冲区上限，就会在模型加载阶段崩溃。优先排查大容量 --moe-cache-mib 配置及 Vulkan 后端的张量大小检查逻辑。

适用环境：llama.cpp 0.7.0-dev（build 11700，commit 23f7aabc1），Clang 20.1.8 构建的官方 Windows x64 Vulkan 发布包；Windows 11；AMD Radeon RX 6900 XT 16 GB（gfx1030），AMD 专有驱动 Adrenalin 26.8.1（32.0.21045.5002），PCIe 4.0 x16；64 GB RAM。另有用户报告在 RX 7900 XTX、Radeon Pro VII（gfx906）上出现类似问题。

最快修复方案：暂无确认的一步修复方案。可优先尝试的缓解办法是调低 --moe-cache-mib 直到能正常加载（Issue 中 8000 崩溃、2048 可加载），但需要注意低值下启动日志不打印 cache 行，cache 可能未实际生效。

注意事项：降低 --moe-cache-mib 只是绕过超限分配，并不修复根因；Issue 中已说明小 cache 配置为何“看起来未激活”尚未查明。Issue 中的源码分析、本地补丁草案和隔离测试均未上游集成、未在 Vulkan 实机验证，不能视为已验证修复。ROCm 后端在报告中 --list-devices 显示 “(none)”，无法用于对照测试。

问题场景

用户在 Windows 11 上通过官方 Windows x64 Vulkan 发布包运行 llama.cpp，测试 MoE expert cache（--moe-cache-mib）功能。模型为 Qwen3.6-35B-A3B UD-Q4_K_M（22.1 GB）等 MoE 模型，分别使用 llama-server 和 llama-completion 加载：

llama-server.exe -m Qwen3.6-35B-A3B-UD-Q4_K_M.gguf -c 8192 --host 127.0.0.1 --port 8080 --moe-cache-mib 8000

llama-completion.exe -m Qwen3.6-35B-A3B-UD-Q4_K_M.gguf --fit off --cpu-moe --moe-cache-mib 8000 -p "Hello" -n 16

崩溃出现在模型加载阶段，而非推理阶段。不带 --moe-cache-mib 时模型正常运行（生成约 29 t/s）。

报错原文

Eval bug: --moe-cache-mib crashes at load on Vulkan (RX 6900 XT, Windows)

pre-allocated tensor (moe_cache.0.blk.0.ffn_down_exps.weight) in a buffer (Vulkan0) that cannot run the operation (NONE)

ggml_vulkan: Device memory allocation of size 2394685440 failed.
ggml_vulkan: Requested buffer size exceeds device buffer size limit: ErrorOutOfDeviceMemory
ggml_backend_buft_alloc_buffer_n_default: failed to allocate Vulkan0 buffer of size 2394685440
llama_init_from_model: failed to initialize the context: failed to allocate the MoE cache buffers

原因分析

Issue 中的源码分析指向一个尺寸计算缺口：MoE cache 选择 slot 时只校验聚合 bank 总大小是否落在预算内，没有校验每个单独 bank 是否超过后端缓冲区限制；每个 bank 会被创建为包含 n_slots + 1 个条目（含 padding slot）的单个张量，因此无法通过拆分张量来规避单个 bank 张量超限。

Vulkan 后端在分派操作之前就检查张量大小，因此返回 NONE 可能实际是尺寸被拒绝，而不是操作本身不受支持。另一条评论将根因定位为 ggml_backend_vk_device_supports_op() 中的 maxStorageBufferRange 大小预检查被错误应用到了预分配的非计算张量（cache bank 叶子节点、GGML_OP_NONE 及其上的 GGML_OP_VIEW），在不支持 shader_64b_indexing 的设备上触发。

此外，--moe-cache-mib 2048 等较小配置能加载但启动时不打印 cache 行，说明 cache 疑似未激活；其具体原因在 Issue 中尚未查明。

环境排查

确认 llama.cpp 构建版本与后端：是否为官方 Windows x64 Vulkan 包，版本号及 commit 是否与报告一致。
确认 GPU 型号与驱动：报告环境为 RX 6900 XT（gfx1030）配 Adrenalin 26.8.1；其他用户报告 RX 7900 XTX 与 Radeon Pro VII（gfx906）也有同类问题。
确认设备是否支持 shader_64b_indexing，以及 Vulkan 驱动的最大存储缓冲区范围限制。
确认 --moe-cache-mib 取值：8000 在 llama-server 与 llama-completion 下均触发崩溃；2048 可加载但疑似未激活。
确认 RAM 容量：模型约 22 GB，报告机器为 64 GB RAM，后续复测改为 48 GB（16+8+16+8 GB、DDR4-3200）。
ROCm 后端在本机 --list-devices 显示 “(none)”，如需 ROCm 对照需先解决设备识别问题。

解决步骤

先用 --moe-cache-mib 2048 或更小值启动，确认模型可以正常加载运行，排除模型文件本身或基础 Vulkan 环境问题。
把 --moe-cache-mib 调大，逐步定位触发 Requested buffer size exceeds device buffer size limit 的阈值。
若必须使用较大 cache，可跟踪上游针对该问题的补丁进展：Issue 中提到已提交 PR #31114，思路是跳过非计算操作的尺寸预检查（计算操作仍校验其来源，缓冲区类型的分配限制仍约束 bank）。该补丁在 Radeon Pro VII 上报告可加载运行（8.1 t/s，无 cache 时 0.6 t/s），但尚未作为已验证修复对待。可优先尝试基于该 PR 自行构建验证。
构建自定义版本前补充源码级修复方向（仅作参考，未验证）：在 slot 增长时按每个候选 bank 的对齐分配大小和后端尺寸接受能力设上限，并计入额外的 padding slot；注意 Vulkan 缓冲区类型的 get_max_size 返回的是子分配块大小，不等于硬件绝对上限，直接用其作 cap 可能浪费可用显存。
如 Vulkan 下 cache 不可用且性能可接受，暂以不带 --moe-cache-mib 的方式运行（报告中生成约 29 t/s）。

验证方法

使用与报错时相同的模型和 --moe-cache-mib 参数重启 llama-server / llama-completion，确认加载阶段不再出现 pre-allocated tensor ... cannot run the operation (NONE) 与 failed to allocate the MoE cache buffers，且服务能正常生成 token。同时检查启动日志是否打印 cache 相关行，以确认 cache 实际生效而非仅“加载成功”。按 Issue 中评论的反馈，即使某组设置通过，也应换模型和其他参数复测，因为该问题表现为 trial and error。