华硕 Zephyrus 运行 Ollama 本地大模型「CUDA out of memory」报错排查

dctc_青龙

## 问题现象

一台华硕 Zephyrus G16（AMD Ryzen AI 9 HX 370 + NVIDIA RTX 4070 Laptop GPU，32GB 统一内存），本地跑 Ollama 0.5.x 加载 Qwen2.5-14B 模型，推理个二十来轮对话就开始崩，日志里反反复复刷这个错：

```
Error: CUDA out of memory. Tried to allocate 2.00 GiB (GPU ...)
```

重启 Ollama 能重新加载，但过一会儿又来。调 `--keep-alive`、降 `num_ctx`，这些操作都试过了，治标不治本。

## 可能原因分析

问题根子不在显存容量本身，而是 Ollama 的显存管理机制跟 Zephyrus 混合显卡架构处不来。

华硕 Zephyrus 系列默认开 UMA（统一内存架构）模式或者 iGPU/dGPU 混合模式。G16 的 BIOS 里有「UMA Mode」选项，可以选「UMA Auto」「UMA Dedicated」或「Force UMA」。设在「UMA Auto」的时候，系统会根据负载动态分配内存给核显和独显，CUDA 进程能看到的显存总量就一直在晃。Ollama 初始化推理上下文的时候，按一开始探测到的显存上限预分配 KV Cache；当系统悄悄把部分内存划给 iGPU，原先分配好的显存区域就被压缩了，OOM 随之而来。

另外，Ollama 0.5.x 对 Windows 下 WDDM（Windows Display Driver Model）显存回收机制的处理也不够利索。GPU 显存一旦碎片化，主动回收效率就掉下去了，长对话场景下累积的碎片足以撑爆显存。

高相关性因素清单：

1. BIOS 中 UMA Mode 设为「UMA Auto」或「Force UMA」
2. 后台有进程占着 GPU（比如 ASUS Armoury Crate 监控服务）
3. Ollama 版本低于 0.5.4（该版本优化了 WDDM 显存回收）
4. 模型 `num_ctx` 设得太高（超过 8192 时 KV Cache 占用猛涨）

## 解决步骤

### 步骤一：BIOS 层——固定独显显存分配

重启进 BIOS（开机按 F2），找到「Advanced」→「 UMA Mode」，把设置从「UMA Auto」改成「UMA Dedicated」。

这样一来，iGPU 只用固定的小容量显存（通常 512MB-1GB），剩下的内存全部归属 dGPU。保存退出后，设备管理器里 NVIDIA GPU 的可用显存就是固定值了，不再飘忽。

> 注意：部分 Zephyrus 机型的 BIOS 里这个选项标的是「iGPU Multi-Monitor」，记得一并关掉，防止 iGPU 抢内存。

### 步骤二：系统层——隔离 GPU 后台进程

打开任务管理器，把下面这几个后台进程结束掉：

- ASUS Armoury Crate Service（残留进程容易忽略）
- NVIDIA Container（部分版本会在后台预加载 WebGL 渲染器）

可以用 PowerShell 确认当前 GPU 显存占用：

```powershell
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
```

没有其他进程占着 GPU 之后，重新启动 Ollama 服务。

### 步骤三：Ollama 配置层——限制 KV Cache 容量

环境变量里设一下 `OLLAMA_MAX_LOADED_MODELS=1`，同时把 `num_ctx` 降下来：

```powershell
$env:OLLAMA_NUM_CTX="4096"
```

Qwen2.5-14B 这类模型，`num_ctx` 设为 4096 或 2048 就够用了，单次推理的显存占用能降差不多 40%。

### 步骤四：升级 Ollama 至最新稳定版

```powershell
ollama upgrade
```

Ollama 0.5.4 及之后版本对 Windows 下的显存分配策略做了改进，专门修了 Zephyrus 系列的兼容问题。

### 验证

上面这些改完之后，重新加载模型，跑个一百轮以上对话测试：

```powershell
ollama run qwen2.5:14b
nvidia-smi --query-gpu=memory.used --format=csv -l 5
```

显存曲线平稳，没有突然的尖峰，说明问题搞定了。

## 扩展：其他 Zephyrus 机型的兼容性问题

G16 不是个案。基于社区反馈，G14（RTX 4060/4070）、幻系列（幻14、幻16）都有这情况，根子都是 Zephyrus 混合显卡调度机制和 Ollama 静态显存分配策略之间的设计冲突。

拿 Zephyrus G14 2024 款来说，AMD Ryzen 9 8945HS 处理器，同样开 UMA 架构。用户如果在「UMA Auto」模式下同时跑 Ollama 推理和 VS Code 的 GitHub Copilot 插件，后者的 Language Server 会在后台吃掉 200-300MB 显存，可用餐亚就更紧了。有用户反映加载 Llama3-8B 模型，跑不到十轮对话就 OOM，比 G16 的二十来轮还早翻车。

幻16翻转版（Flow Z16）稍有不同，Intel 处理器 + NVIDIA RTX 4070 组合，Intel 核显负责视频输出，NVIDIA 独显负责计算。Intel 平台没有「UMA Mode」这个概念，问题就换了种形式：Ollama 初始化时把系统内存映射为 CUDA 可寻址空间，系统内存紧张的时候，Windows 触发内存压缩，部分映射被回撤，CUDA 访问路径就断了。症状表现为偶发性「CUDA error: an illegal memory access」，而不是 OOM。排查思路差不多——确保系统内存有足够余量，建议至少 16GB 物理内存保持空闲。

## 技术背景：为什么移动版 RTX 更容易中招

桌面版 RTX 4070 是 12GB GDDR6，移动版 RTX 4070 Laptop GPU 通常只有 8GB GDDR6，部分厂商还通过 BIOS 限制把可用显存降到 6GB 来控发热。Zephyrus G16 的 RTX 4070 移动版在「UMA Auto」模式下，CUDA 进程能支配的显存可能只有 6-7GB，而不是标称的 8GB。

Qwen2.5-14B 模型 FP16 精度下权重大约 28GB，理论上根本塞不进移动版 RTX 4070。Ollama 实际用的是量化推理（INT4/INT8），把模型权重压到 8-10GB，加上 KV Cache（每 token 约 1KB，乘以 context length）和激活值的显存占用，总量轻轻松松突破 8GB 上限。所以移动版 RTX 4070 跑 14B 级别模型本身就站在显存临界线上，任何一点额外的波动都可能成为压垮骆驼的最后一根稻草。

真想更稳地跑 14B 模型，硬件配置得往上走：RTX 4080 Laptop（16GB 显存）或 RTX 4090 Laptop（16GB 显存）的机型，显存宽裕得多；或者考虑桌面级方案（RTX 4070 Super 桌面版配台式机）。内存方面，系统最好有 32GB 或以上统一内存，避免系统内存不够的时候向 UMA 架构抢占本该分给 dGPU 的带宽。

## 常见问题

### 1. Zephyrus的核心概念/组成是什么？

Zephyrus通常指与本文主题相关的核心对象/方案。可从"它解决什么问题、依赖哪些组件、如何与现有系统集成"三点来理解。

### 2. Zephyrus与同类方案相比差异在哪里？

对比Zephyrus与同类方案时，建议看三项：运行时与依赖复杂度、资源占用曲线（空闲/峰值/回收）、以及生产可观测性（日志/指标/追踪）。

### 3. Zephyrus有哪些安全/合规注意事项？

Zephyrus相关的安全要点通常包括：密钥/令牌最小权限、敏感数据不落盘或脱敏、外部调用白名单与审计日志；生产环境建议开启严格的权限隔离。

## 小结

这问题的本质是 BIOS 显存分配策略和 Ollama 运行时探测机制不兼容，不是硬件资源不够。解法关键在于把 dGPU 的显存资源固定下来，把动态分配的干扰因素踢掉。BIOS 设置调整成本最低、效果最稳，优先搞这个。

其他 Zephyrus 机型（G14、幻系列）如果搭载 RTX 4060 及以上移动版 GPU，打算长期跑本地大模型推理，建议 BIOS 里统一把 UMA Mode 设为「UMA Dedicated」，别让这类问题反复找上门。