> ## Content Index
> Fetch the complete content index at: https://isoziyuan.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# 低显存运行 Ollama 内存不足怎么办：模型量化、上下文与并发优化指南
- URL: https://isoziyuan.com/p/100115/
- Published: 2026-08-30T07:08:51.000Z
- Updated: 2026-08-30T07:08:50.000Z
- Author: Isoziyuan
- Tags: Ollama, AI工具, 性能优化, 开源项目

很多人看到“Ollama 内存不足”，第一反应是显卡显存不够。实际运行本地大模型时，模型权重、KV Cache、计算缓冲区以及并发请求都会占用内存；如果模型不能完全装入显存，Ollama 还会将部分计算转移到 CPU，此时系统内存也可能成为瓶颈。

因此，解决问题不能只靠“换一个更小的模型”。正确顺序是先确认耗尽的是显存还是系统内存，再从模型参数量、量化等级、上下文长度、并发数和缓存格式几个方面逐步调整。

> 文中命令和参数适用于常见版本的 Ollama。不同操作系统、GPU 后端和 Ollama 版本可能存在差异，操作前可先执行 `ollama --version` 确认版本。

## 先判断：到底是哪一类内存不足

Ollama 推理主要涉及以下几类内存。

### 1\. 模型权重

模型的参数越多、量化精度越高，权重占用越大。权重是最基础、通常也是最大的一部分。

粗略计算方式为：

```text
权重体积 ≈ 参数量 × 每个参数位数 ÷ 8

```

例如，一个 8B 模型如果采用 4 位量化，理论权重约为：

```text
80 亿 × 4 ÷ 8 ≈ 4 GB

```

但这只是权重的理论值。GGUF 元数据、量化分块、运行缓冲区和 KV Cache 都会产生额外占用，所以“4 GB 模型文件”不代表“4 GB 显存就一定能运行”。

### 2\. KV Cache

KV Cache 用来保存当前对话中已经处理过的上下文。它的占用通常随上下文长度近似线性增加，并受到模型层数、注意力结构、KV 精度和并发数影响。

可以简单理解为：

```text
上下文越长 → KV Cache 越大
并发请求越多 → 同时存在的 KV Cache 越多

```

这也是很多模型能在 2048 或 4096 上下文下正常运行，改到 16K、32K 后却突然内存不足的原因。

### 3\. 计算缓冲区

模型加载后还要为提示词预填充、注意力计算和输出生成分配临时缓冲区。某些情况下，加载阶段可以通过，但在输入长文档或开始生成时才出现峰值内存不足。

### 4\. 显存与系统内存

不同硬件的内存机制有所区别：

- **NVIDIA、AMD 独立显卡**：显存和系统内存分开。模型不能完全放入显存时，Ollama 可能进行 CPU/GPU 混合推理。
- **Apple Silicon**：CPU 和 GPU 使用统一内存，但系统、应用和模型会争用同一内存池。
- **无独立显卡或显存太小**：主要使用系统内存进行 CPU 推理，速度通常更慢。
- **Windows 核显或共享显存环境**：任务管理器显示的“共享 GPU 内存”来自系统内存，不能等同于独立显存。

## 用这些命令定位实际瓶颈

先查看已安装模型及其文件体积：

```bash
ollama list

```

启动模型并发送一次请求后，再执行：

```bash
ollama ps

```

重点观察以下信息：

- 当前加载了哪些模型；
- 模型实际使用的上下文长度；
- 处理器一栏显示全 GPU、全 CPU，还是 CPU/GPU 混合；
- 是否同时加载了多个模型。

如果一个 4～5 GB 的量化模型只有一部分进入 GPU，说明显存不足以容纳模型权重、KV Cache和运行缓冲区。混合推理并不是错误，但速度通常会明显下降。

还可以结合系统工具观察。

Linux：

```bash
free -h
nvidia-smi

```

Windows：

- 在任务管理器中查看“内存”；
- 在“性能—GPU”中分别查看专用 GPU 内存和共享 GPU 内存；
- NVIDIA 显卡也可以使用 `nvidia-smi`。

macOS：

- 使用“活动监视器”查看内存压力；
- 特别注意系统是否已经开始大量使用交换空间。

常见现象与原因可以这样对应：

| 现象                | 更可能的原因                |
| ----------------- | --------------------- |
| 模型加载时立即报错         | 模型权重本身太大，系统内存或显存不足    |
| 短问题正常，输入长文档后失败    | 上下文和 KV Cache 过大      |
| 单个请求正常，并发时失败      | 并发请求复制了上下文缓存和运行缓冲区    |
| 显存已满，但系统内存还有空间    | 模型未能完全装入 GPU，可能需要混合推理 |
| 系统内存持续增长并开始使用交换空间 | 模型、上下文或同时加载的模型过多      |
| 第一次运行正常，切换模型后失败   | 旧模型仍驻留内存，或加载了多个模型     |
| 生成过程中突然退出         | 计算峰值、长上下文或操作系统终止了进程   |

## 低显存电脑应该选择多大的模型

选择模型时，不要只看“显存能否勉强装下权重”，还要为操作系统、KV Cache和计算缓冲区预留空间。

以下只是保守的起点，不是硬性兼容表。不同模型架构、量化版本、操作系统和上下文设置都会改变实际结果。

| 硬件条件              | 建议起步范围                      | 建议上下文     |
| ----------------- | --------------------------- | --------- |
| 无独显，8 GB 系统内存     | 1B～3B 的 Q4 模型               | 2048      |
| 无独显，16 GB 系统内存    | 3B～7B 的 Q4 模型               | 2048～4096 |
| 4 GB 显存、16 GB以上内存 | 1B～4B Q4，或小型模型混合推理          | 2048～4096 |
| 6 GB 显存           | 3B～7B Q4                    | 2048～4096 |
| 8 GB 显存           | 7B～8B Q4，必要时部分转移到 CPU       | 4096 左右   |
| 12 GB 显存          | 7B～14B Q4，取决于架构与上下文         | 4096～8192 |
| 16 GB 显存          | 14B Q4 较合适，更大模型需谨慎          | 4096～8192 |
| 24 GB 显存          | 可尝试 20B～32B Q4，但长上下文仍会显著增内存 | 按任务设置     |

低显存环境下，可以优先考虑这些参数规模：

- **日常中文问答、摘要**：1.5B～4B 的 Qwen 系列模型；
- **轻量通用任务**：Llama 3.2 1B/3B、Gemma 3 1B/4B 等；
- **本地编程辅助**：Qwen2.5-Coder 1.5B/3B/7B 等轻量版本；
- **简单分类、改写、信息提取**：1B～4B 模型通常比想象中更实用。

具体可用名称和标签应以 Ollama 模型库当前页面为准。不要直接假设某个模型一定存在某个量化标签，拉取前先检查可用标签。

模型拉取后可查看其基本信息：

```bash
ollama show qwen3:4b

```

实际使用中，一个较新的 3B～4B 模型往往比一个被压到极低精度的老旧大模型更适合低内存设备。与其强行运行 14B 的 Q2 或 Q3 版本，不如先测试 4B～8B 的 Q4 版本。

## 大模型量化版本怎么选

量化的本质是用更少的位数保存模型权重，从而降低磁盘、内存和显存占用。代价是可能损失输出质量，而且量化越激进，损失通常越明显。

常见量化等级可以这样理解：

| 量化类型     | 大致特点                | 低显存适用性        |
| -------- | ------------------- | ------------- |
| F16/BF16 | 质量高，体积和内存占用最大       | 不适合低显存        |
| Q8       | 接近高精度，体积仍较大         | 显存较充足时使用      |
| Q6       | 质量较好，体积略低于 Q8       | 中高配置          |
| Q5\_K\_M | 质量和体积兼顾，通常比 Q4 更占内存 | 有一定余量时        |
| Q4\_K\_M | 常见平衡点，质量、速度和体积较均衡   | 优先推荐          |
| Q4\_K\_S | 通常略小于 Q4\_K\_M      | 内存更紧张时        |
| Q3       | 体积更小，但质量下降更容易察觉     | 仅在 Q4 无法运行时考虑 |
| Q2       | 压缩激进，质量损失通常较明显      | 最后的妥协方案       |

其中，`K_M` 和 `K_S` 不是简单的“每个参数固定多少位”，实际文件大小会受到混合量化方案和模型结构影响。

### 推荐选择顺序

低显存电脑可以按照下面的顺序尝试：

1. 先选择合适参数量的 `Q4_K_M`；
2. 内存还有余量、希望提高质量，再尝试 `Q5_K_M`；
3. `Q4_K_M` 仍无法稳定运行，先把模型参数量降一级；
4. 只有无法换小模型时，再考虑 `Q3`；
5. 不建议仅为了运行更大的参数量而长期使用极低精度量化。

例如，8B Q4 与 4B Q5 相比，谁效果更好取决于具体模型和任务，并不存在“参数更多就一定更强”的通用结论。应使用自己的中文问答、代码或文档测试集进行比较。

### 不要只看下载文件大小

假设 `ollama list` 显示某模型占用约 5 GB，也不能据此判断 6 GB 显存一定足够。运行时至少还要考虑：

```text
实际占用 =
模型权重
+ KV Cache
+ 计算缓冲区
+ GPU驱动与图形应用占用
+ 可能的多模态投影组件

```

浏览器硬件加速、游戏、视频剪辑工具和桌面特效也会占用显存。运行 Ollama 前关闭这些程序，有时就能释放数百 MB 到数 GB 空间。

## Ollama 上下文长度应该设置多少

上下文长度不是越大越好。它表示模型一次能够处理的历史消息、系统提示词、当前输入和生成内容的总范围。

例如设置：

```text
num_ctx = 4096

```

这 4096 个 token 需要由以下内容共同使用：

- 系统提示词；
- 历史聊天记录；
- 当前用户输入；
- 工具调用内容；
- 模型生成的回答。

如果还设置了较大的输出上限，就需要为输出预留足够空间。

### 低显存建议值

| 使用场景        | 建议从这里开始               |
| ----------- | --------------------- |
| 简短问答、翻译、改写  | 2048                  |
| 日常聊天、普通代码辅助 | 4096                  |
| 较长文档摘要      | 8192                  |
| 长文档、长代码仓库分析 | 先做分块，不要直接盲目提高到 32K 以上 |

如果 4096 可以正常运行，而 8192 内存不足，最直接的解决办法就是恢复到 4096。只有任务确实需要时，才提高上下文。

### 通过 Modelfile 固定上下文

先创建一个名为 `Modelfile` 的文件：

```dockerfile
FROM qwen3:4b

PARAMETER num_ctx 4096
PARAMETER num_predict 512

```

然后创建自定义模型：

```bash
ollama create qwen3-4b-lowmem -f Modelfile

```

运行：

```bash
ollama run qwen3-4b-lowmem

```

这里的 `FROM` 应替换为已经成功拉取的模型名称。`num_predict` 用来限制单次生成长度，防止任务无意间生成过多内容。

### 通过 API 为单次请求设置

```bash
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3-4b-lowmem",
  "prompt": "请把下面的内容总结为五点：……",
  "stream": false,
  "options": {
    "num_ctx": 4096,
    "num_predict": 256
  }
}'

```

每次请求显式设置上下文，更适合需要按任务控制内存的应用。例如普通聊天使用 4096，只有文档摘要请求才使用 8192。

### 设置服务级默认上下文

Linux 或 macOS 终端中，如果手动启动服务：

```bash
OLLAMA_CONTEXT_LENGTH=4096 ollama serve

```

PowerShell 中：

```powershell
$env:OLLAMA_CONTEXT_LENGTH="4096"
ollama serve

```

如果 Ollama 已经作为桌面程序或系统服务运行，仅在另一个终端设置环境变量不会修改现有进程。需要先退出原有 Ollama 进程，再使用新环境启动。

Linux 的 systemd 服务可以使用：

```bash
sudo systemctl edit ollama

```

加入：

```ini
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=4096"

```

然后重载并重启：

```bash
sudo systemctl daemon-reload
sudo systemctl restart ollama

```

修改后运行一次模型，再通过 `ollama ps` 检查实际上下文，不要只依赖配置文件判断。

## 限制并发和同时加载的模型

如果单个请求正常、两个请求同时执行就内存不足，问题通常不是模型本身，而是并发导致的额外 KV Cache和缓冲区占用。

低内存环境建议：

```bash
OLLAMA_NUM_PARALLEL=1 OLLAMA_MAX_LOADED_MODELS=1 ollama serve

```

PowerShell：

```powershell
$env:OLLAMA_NUM_PARALLEL="1"
$env:OLLAMA_MAX_LOADED_MODELS="1"
ollama serve

```

两个参数的作用分别是：

- `OLLAMA_NUM_PARALLEL=1`：限制单个模型的并行请求数量；
- `OLLAMA_MAX_LOADED_MODELS=1`：限制同时驻留内存的模型数量。

对于个人电脑上的聊天界面、编辑器插件和自动化脚本，还要检查是否存在后台重复请求。例如一个编辑器可能同时发送代码补全、聊天、标题生成和嵌入请求。

不再使用某个模型时，可以主动卸载：

```bash
ollama stop 模型名称

```

然后执行：

```bash
ollama ps

```

确认它已经不再驻留。

## 使用 Flash Attention 和量化 KV Cache

当上下文较长时，Flash Attention 可以降低注意力计算的内存压力，并可能改善推理性能。可在启动 Ollama 服务前设置：

Linux/macOS：

```bash
OLLAMA_FLASH_ATTENTION=1 ollama serve

```

PowerShell：

```powershell
$env:OLLAMA_FLASH_ATTENTION="1"
ollama serve

```

在支持的版本和后端中，还可以配合量化 KV Cache：

```bash
OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
ollama serve

```

PowerShell：

```powershell
$env:OLLAMA_FLASH_ATTENTION="1"
$env:OLLAMA_KV_CACHE_TYPE="q8_0"
ollama serve

```

常见选择包括：

- `f16`：精度较高，占用较大；
- `q8_0`：通常是降低 KV Cache 占用的优先选择；
- `q4_0`：占用更低，但更可能影响长上下文质量。

建议先使用 `q8_0`，确认任务结果没有明显变化后再考虑 `q4_0`。KV Cache 量化只减少缓存相关占用，不能把一个远超硬件容量的大模型变成小模型。

如果环境变量没有生效，应检查：

1. Ollama 是否已经在后台运行；
2. 是否真正重启了服务；
3. 当前 GPU 后端是否支持相关功能；
4. `ollama ps` 中的上下文和加载状态是否符合预期。

## 输入长文档时，不要只会增大上下文

很多 Ollama 内存不足问题来自 RAG 或文档总结应用。程序把整个 PDF、网页正文、检索结果和聊天历史一次性塞进模型，即使模型支持长上下文，也可能造成速度急剧下降或内存溢出。

更有效的做法是控制输入内容。

### 文档分块

将长文档切成多个片段，逐段摘要，再对摘要做二次汇总：

```text
原始文档
→ 按章节或 token 分块
→ 分别生成局部摘要
→ 汇总局部摘要
→ 生成最终结论

```

### 减少 RAG 检索数量

不要默认取回十几段内容。先尝试：

- 减少 `top_k`；
- 去除重复片段；
- 使用重排模型筛选；
- 限制每段文本长度；
- 只保留和问题直接相关的上下文。

### 定期裁剪聊天历史

长期对话不应无限追加。可以采用：

- 只保留最近若干轮；
- 将早期对话压缩成摘要；
- 单独保存结构化事实；
- 新任务开启新会话。

这些方法通常比把 `num_ctx` 从 4096 提高到 32768 更节省内存，也更容易保持回答质量。

## 仍然内存不足时，可以降低提示词批处理大小

长提示词的预填充阶段可能产生较高的瞬时占用。Ollama 的运行选项中可通过 `num_batch` 调整提示词批处理大小，例如在 API 请求中测试：

```bash
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3-4b-lowmem",
  "prompt": "较长的输入内容……",
  "stream": false,
  "options": {
    "num_ctx": 4096,
    "num_batch": 128,
    "num_predict": 256
  }
}'

```

如果仍在预填充阶段内存不足，可继续测试 `64`。较小的 `num_batch` 可能降低峰值内存，但通常会让长提示词处理变慢；不同后端和版本的实际效果也可能不同。

它属于后续微调手段，优先级低于：

1. 换更小模型；
2. 使用 Q4 量化；
3. 降低上下文；
4. 限制并发；
5. 关闭其他显存占用程序。

## CPU/GPU 混合推理是否值得使用

低显存电脑只要系统内存足够，Ollama 可能把部分模型层放在 GPU，其余部分放在 CPU。这能让显存较小的电脑运行更大的模型，但需要接受几个限制：

- 推理速度会下降；
- CPU 和 GPU 之间可能存在数据传输开销；
- 系统内存占用仍然很高；
- 不能解决系统内存本身不足的问题；
- 使用机械硬盘交换空间时，速度可能慢到难以使用。

例如，8 GB 显存加 32 GB 系统内存，可能通过混合推理运行显存无法完全容纳的模型。但如果只有 8 GB 系统内存，即使显卡有一定能力，也很容易因为操作系统和模型争用内存而失败。

Ollama 通常会自动选择卸载方案。运行后使用：

```bash
ollama ps

```

查看模型是全 GPU、全 CPU，还是混合执行。除非在做兼容性排查，否则一般不需要优先手动强制 CPU 推理。

## 交换空间只能救急，不能代替内存

Linux swap、Windows 页面文件和 macOS 交换空间可以降低进程被立即终止的概率，但它们不是显存，也远慢于物理内存。

可以适当增加交换空间来避免模型加载时直接崩溃，但不应期待它提升推理性能。出现以下情况时，应该换小模型，而不是继续增加交换空间：

- 磁盘持续高负载；
- 系统界面明显卡顿；
- 每个 token 需要等待很久；
- 内存压力长期处于高位；
- 固态硬盘持续产生大量写入。

建议至少为系统和其他应用保留约 10%～20% 的物理内存余量。不要把模型配置到刚好吃满全部内存。

## 一套可直接执行的低内存配置

以已经拉取的 `qwen3:4b` 为例，先创建低内存版本。

`Modelfile`：

```dockerfile
FROM qwen3:4b

PARAMETER num_ctx 4096
PARAMETER num_predict 512

```

创建模型：

```bash
ollama create qwen3-4b-lowmem -f Modelfile

```

Linux/macOS 启动服务：

```bash
OLLAMA_CONTEXT_LENGTH=4096 \
OLLAMA_NUM_PARALLEL=1 \
OLLAMA_MAX_LOADED_MODELS=1 \
OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
ollama serve

```

PowerShell：

```powershell
$env:OLLAMA_CONTEXT_LENGTH="4096"
$env:OLLAMA_NUM_PARALLEL="1"
$env:OLLAMA_MAX_LOADED_MODELS="1"
$env:OLLAMA_FLASH_ATTENTION="1"
$env:OLLAMA_KV_CACHE_TYPE="q8_0"

ollama serve

```

另开终端运行：

```bash
ollama run qwen3-4b-lowmem

```

然后检查：

```bash
ollama ps

```

如果仍然内存不足，按以下顺序调整：

1. 将 `num_ctx` 从 4096 降到 2048；
2. 关闭浏览器、游戏和其他 GPU 程序；
3. 执行 `ollama stop` 卸载其他模型；
4. 确认并发数为 1；
5. 换成 1B～3B 模型；
6. 确认使用的是 Q4，而不是 Q8、F16；
7. 必要时把 KV Cache 改为 `q4_0` 并重新验证质量；
8. 最后再考虑减小 `num_batch` 或使用 CPU/GPU 混合推理。

## 如何比较优化前后的推理性能

优化不能只看“是否成功启动”，还要观察速度和输出质量。

在交互模式中可以尝试启用详细统计：

```text
/set verbose

```

然后使用固定提示词测试，记录：

- 模型加载时间；
- 提示词处理速度；
- 输出生成速度；
- 首个 token 等待时间；
- 系统内存峰值；
- 显存峰值；
- 输出是否出现明显事实错误或逻辑退化。

建议建立三类测试：

1. 一条简短中文问答；
2. 一段 2000～4000 token 的文档摘要；
3. 一段符合日常需求的代码生成任务。

每次只修改一个变量，例如先比较 Q4 和 Q5，再比较 4096 与 8192 上下文。不要同时更换模型、量化和上下文，否则很难判断究竟是哪一项产生了影响。

## 常见误区

### “模型文件只有 5 GB，我有 6 GB 显存，肯定能跑”

不一定。运行还需要 KV Cache、缓冲区和驱动占用，6 GB 显存很可能无法完整容纳。

### “模型标注支持 128K，就应该设置成 128K”

支持只是模型架构的理论上限，不代表本机硬件能高效运行，也不代表任务真的需要这么长的输入。

### “量化只影响文件大小，不影响效果”

量化会影响权重精度。Q4 通常是低内存环境的平衡点，Q2、Q3 更容易出现质量下降。

### “显存不足就全部转到 CPU”

转到 CPU 仍然需要系统内存，而且通常明显变慢。系统内存不足时，这种方式没有帮助。

### “增加交换空间就能运行任意模型”

交换空间只能减少崩溃概率，无法提供接近物理内存的推理速度，更不能替代 GPU 显存。

### “上下文设得越大，回答越聪明”

上下文只是容量，不等于推理能力。无关内容过多反而可能降低回答质量，同时增加内存和延迟。

## 最终建议

解决 Ollama 低显存内存不足，最有效的原则可以概括为：

```text
先降模型参数量
→ 再选 Q4 量化
→ 把上下文控制在 2048～4096
→ 限制并发和驻留模型数量
→ 使用 Flash Attention 与 q8_0 KV Cache
→ 最后再考虑混合推理和批处理参数

```

对大多数低显存电脑来说，稳定运行一个 3B～8B 的 Q4 模型，通常比勉强加载更大的低精度模型更实用。模型能够持续响应、系统不进入交换、长输入不会崩溃，才是本地 AI 推理性能优化真正应该追求的结果。