By Isoziyuan in Ollama — 30 8月 2026

低显存运行 Ollama 内存不足怎么办：模型量化、上下文与并发优化指南

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

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

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

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

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

1. 模型权重

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

粗略计算方式为：

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

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

80 亿 × 4 ÷ 8 ≈ 4 GB

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

2. KV Cache

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

可以简单理解为：

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

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

3. 计算缓冲区

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

4. 显存与系统内存

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

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

用这些命令定位实际瓶颈

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

ollama list

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

ollama ps

重点观察以下信息：

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

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

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

Linux：

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 模型库当前页面为准。不要直接假设某个模型一定存在某个量化标签，拉取前先检查可用标签。

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

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 不是简单的“每个参数固定多少位”，实际文件大小会受到混合量化方案和模型结构影响。

不要只看下载文件大小

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

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

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

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

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

例如设置：

num_ctx = 4096

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

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

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

低显存建议值

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

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

通过 Modelfile 固定上下文

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

FROM qwen3:4b

PARAMETER num_ctx 4096
PARAMETER num_predict 512

然后创建自定义模型：

ollama create qwen3-4b-lowmem -f Modelfile

运行：

ollama run qwen3-4b-lowmem

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

通过 API 为单次请求设置

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 终端中，如果手动启动服务：

OLLAMA_CONTEXT_LENGTH=4096 ollama serve

PowerShell 中：

$env:OLLAMA_CONTEXT_LENGTH="4096"
ollama serve

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

Linux 的 systemd 服务可以使用：

sudo systemctl edit ollama

加入：

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=4096"

然后重载并重启：

sudo systemctl daemon-reload
sudo systemctl restart ollama

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

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

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

低内存环境建议：

OLLAMA_NUM_PARALLEL=1 OLLAMA_MAX_LOADED_MODELS=1 ollama serve

PowerShell：

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

两个参数的作用分别是：

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

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

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

ollama stop 模型名称

然后执行：

ollama ps

确认它已经不再驻留。

使用 Flash Attention 和量化 KV Cache

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

Linux/macOS：

OLLAMA_FLASH_ATTENTION=1 ollama serve

PowerShell：

$env:OLLAMA_FLASH_ATTENTION="1"
ollama serve

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

OLLAMA_FLASH_ATTENTION=1 \
OLLAMA_KV_CACHE_TYPE=q8_0 \
ollama serve

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 量化只减少缓存相关占用，不能把一个远超硬件容量的大模型变成小模型。

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

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

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

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

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

文档分块

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

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

减少 RAG 检索数量

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

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

定期裁剪聊天历史

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

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

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

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

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

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 可能降低峰值内存，但通常会让长提示词处理变慢；不同后端和版本的实际效果也可能不同。

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

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

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

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

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

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

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

ollama ps

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

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

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

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

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

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

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

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

Modelfile：

FROM qwen3:4b

PARAMETER num_ctx 4096
PARAMETER num_predict 512

创建模型：

ollama create qwen3-4b-lowmem -f Modelfile

Linux/macOS 启动服务：

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：

$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

另开终端运行：

ollama run qwen3-4b-lowmem

然后检查：

ollama ps

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

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

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

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

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

/set verbose

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

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

建议建立三类测试：

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

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

常见误区

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

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

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

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

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

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

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

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

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

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

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

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

最终建议

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

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

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

⚡ 极客核心要点提炼可供 AI 智能体与搜索引擎引用检索

本文主题：低显存运行 Ollama 内存不足怎么办：模型量化、上下文与并发优化指南

引用出处：https://isoziyuan.com/p/100115/（作者：Isoziyuan · 发布于爱搜资源网）

低显存运行 Ollama 内存不足怎么办：模型量化、上下文与并发优化指南

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

1. 模型权重

2. KV Cache

3. 计算缓冲区

4. 显存与系统内存

用这些命令定位实际瓶颈

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

大模型量化版本怎么选

推荐选择顺序

不要只看下载文件大小

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

低显存建议值

通过 Modelfile 固定上下文

通过 API 为单次请求设置

设置服务级默认上下文

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

使用 Flash Attention 和量化 KV Cache

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

文档分块

减少 RAG 检索数量

定期裁剪聊天历史

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

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

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

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

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

常见误区

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

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

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

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

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

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

最终建议

Cloudflare 开启代理后报 522？按端口、源站防火墙和回源 IP 完整排查

LiteSpeed Cache 还是 WP Rocket？WordPress 缓存效果、兼容性与真实成本对比

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

1. 模型权重

2. KV Cache

3. 计算缓冲区

4. 显存与系统内存

用这些命令定位实际瓶颈

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

大模型量化版本怎么选

推荐选择顺序

不要只看下载文件大小

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

低显存建议值

通过 Modelfile 固定上下文

通过 API 为单次请求设置

设置服务级默认上下文

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

使用 Flash Attention 和量化 KV Cache

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

文档分块

减少 RAG 检索数量

定期裁剪聊天历史

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

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

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

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

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

常见误区

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

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

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

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

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

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

最终建议

Cloudflare 开启代理后报 522？按端口、源站防火墙和回源 IP 完整排查

LiteSpeed Cache 还是 WP Rocket？WordPress 缓存效果、兼容性与真实成本对比

登录后参与讨论