AMD APU bad allocation of gemma4:eXb models

快速结论：该报错是 AMD APU（带 iGPU 的 Ryzen 处理器）在 Vulkan 后端下加载 gemma4:eXb 系列 MoE 模型时，因单个专家权重张量超过 iGPU Vulkan 最大缓冲区分配限制，导致部分层回退到 CPU 运行。优先排查方向是确认是否使用了较新的 Ollama 版本（0.30 及以上），并尝试设置 OLLAMA_IGPU_ENABLE=1 环境变量。

适用环境：Ollama 0.20.0（问题出现版本）/ 0.30.0-rc31（修复版本）；Linux（Debian 13）；AMD Ryzen 7 5700G（iGPU）；AMD 独立显卡（对照正常）；Vulkan 1.4.309。

最快修复方案：升级到 Ollama 0.30.0 及以上版本（Issue 中确认 v0.30.0-rc31 已修复），并通过环境变量 OLLAMA_IGPU_ENABLE=1 重新加载模型。新版本将显存规划交给 llama-server 的 common_params_fit，可避免旧的 GPU 估算器过度分配。

注意事项：在 0.30 之前的旧版本中，此问题无用户侧解决方案，只能接受 CPU/GPU 混合加载；旧版本输出结果仍正确（需包含 MoE 精度修复）。修复方案在 Issue 中已在 Intel 和 AMD iGPU 上验证通过。

问题场景

用户在 AMD APU 平台（Ryzen 7 5700G，集成显卡）使用 Ollama 加载 gemma4:e4b（11 GB）和 gemma4:e2b（8.4 GB）模型时，模型未完全加载到 GPU，而是以约 62%–68% 的 CPU / 系统内存比例运行。相同或更大的稠密模型（如 gemma4:26b、gemma4:31b、mistral-small3.2:24b）以及独立显卡环境下同型号的 eXb 模型均可 100% 加载到 GPU。

报错原文

AMD APU bad allocation of gemma4:eXb models

NAME          ID              SIZE     PROCESSOR          CONTEXT    UNTIL   
gemma4:e4b    c6eb396dbd59    11 GB    62%/38% CPU/GPU    32768      Forever

alloc_tensor_range: failed to allocate Vulkan0 buffer of size 469762048

原因分析

可能原因：MoE（混合专家）模型变体（e4b/e2b）的专家权重张量在单层内较大，需要一次连续的大块缓冲区分配。iGPU 的 Vulkan 最大缓冲区分配大小通常小于独立显卡，当单个张量超过该限制时，该层会回退到 CPU 计算。这解释了为什么总大小更大的稠密模型（如 26b/31b）反而能 100% 加载到 GPU——它们的单张量尺寸分布更均匀，未超过 iGPU 的单缓冲区上限。

根本原因来自 Ollama 旧的 GPU 估算器过度分配，导致超出 Vulkan 每缓冲区上限。Ollama 0.30 版本将显存规划移交给 llama-server（common_params_fit），已解决该问题。

环境排查

确认 Ollama 版本：0.20.0 存在此问题，0.30.0-rc31 已修复。
操作系统：Linux（Debian 13），内核 6.18.15。
显卡：AMD APU 集成显卡（Ryzen 7 5700G），Vulkan 1.4.309。
对照环境：AMD 独立显卡下同型号模型无此问题。
排查日志：使用 OLLAMA_DEBUG=1 ollama serve 启动服务，加载模型时观察是否出现 alloc_tensor_range: failed 开头的 Vulkan 缓冲区分配失败日志。

解决步骤

升级 Ollama 至 0.30.0 及以上版本（确认 v0.30.0-rc31 已修复该问题）。
设置环境变量：OLLAMA_IGPU_ENABLE=1（iGPU 场景需要显式启用）。
重新启动 Ollama 服务并加载 gemma4:e4b 或 gemma4:e2b 模型。
如果仍存在问题，请收集调试日志：OLLAMA_DEBUG=1 ollama serve，查找 alloc_tensor_range: failed to allocate Vulkan0 buffer 相关报错。