交易员.Coder本地跑大模型最容易让人破防的场景，就是字还没生成几个，电脑先卡得鼠标都飘。我前阵子在一台老机器上折腾ollama部署qwen3.5，遇到的问题非常典型：显存占用持续爬升、系统内存占用90%以上、生成速度为个位数token每秒，最严重的时候连打字都一卡一卡的。折腾了一圈下来，发现这类卡顿极少是单一原因造成的，而是一整套资源分配策略没对上。这篇文章就把我从定位问题到最终优化完成的完整过程写出来，包含每一步的判断依据、具体命令和踩过的坑，希望能帮你少走弯路。
1. 卡顿定位：先搞清楚你的电脑卡在哪一层
很多人一看卡顿就急着换模型、加内存，其实大概率是白花钱。我建议先花十分钟做一次资源画像，把卡顿原因精确到硬件层级，再决定动哪里。
1.1 三分钟判断法：ollama ps与任务管理器配合使用
打开终端执行 ollama ps，先看当前加载的模型、显存占用和上下文窗口。这个命令输出的信息量很大，比如模型名称后面的数字，很直观地暴露了问题。
再打开系统监视器（Windows用任务管理器，Linux用 htop 或者 nvidia-smi），重点看四样资源：GPU显存、GPU利用率、系统内存、swap/虚拟内存。把卡顿发生时的资源截图记录下来，后面优化完还能对比效果。
我调试那台机器时的典型特征是：GPU利用率只有20%左右，但显存溢出到共享内存，系统内存90%以上，磁盘I/O长时间接近100%。这说明模型推理的中间数据被挤到了内存甚至磁盘上，每往CPU传一次数据都要等盘片转一圈，卡顿自然就来了。
1.2 卡顿类型与根源对照：你的问题属于哪种
不同卡顿表现对应完全不同的根源，我整理了一个对照表：
| 卡顿表现 | 大概率根源 | 优先检查项 |
|---|---|---|
| 输入对话时界面就卡 | 上下文窗口设置过大，KV缓存膨胀 | num_ctx 参数、模型量化等级 |
| 点击发送后长时间无响应 | 模型冷启动或首次load权重 | 磁盘读取速度、模型量化大小 |
| 生成过程中每隔几秒顿一下 | 显存溢出触发内存换页 | 显存占用、量化等级、GPU显卡型号 |
| 生成速度慢但电脑不卡 | CPU推理无法利用GPU | Ollama是否识别GPU、驱动版本 |
| 退出模型后系统仍然卡 | 虚拟内存被撑大且不回收 | 系统swap设置、后台残留进程 |
你自己对照一下就能锁定排查方向。如果只是生成慢但不卡，那是算力问题；如果是整个系统卡到鼠标漂移，多半是内存或磁盘换页问题，这两者的解法完全不一样。
1.3 容易被忽略的冷启动延迟
很多卡顿其实不是持续性的，而是发生在第一次对话或者切换模型时。ollama加载模型需要把几个GB的权重从磁盘读入显存或内存，机械硬盘上这个过程可以长达几分钟，期间电脑就像死机一样。
如果你把ollama装在外置移动硬盘或老式机械盘上，速度会更惨。我实测同一台机器，模型放在NVMe固态上冷启动不到10秒，放到旧机械硬盘上要40秒以上。所以如果你的卡顿集中在“每次开机第一次提问”，二话不说，先把模型目录迁移到固态硬盘。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模型选型与参数权衡：qwen3.5的体量决定了它吃资源
很多人的卡顿在选模型那一刻就注定了。qwen3.5这种级别的大模型，原始权重大得惊人，直接拿满精度版本硬跑，消费级显卡肯定扛不住。关键在于是否选对量化版本，以及有没有把上下文窗口控在一个合理范围内。
2.1 量化版本怎么选：不是越小越好
拿qwen3.5来说，它在ollama上通常提供了多个量化标签，常见的有 fp16、q8_0、q5_k_m、q4_k_m、q3_k_s 等。数字越小，模型体积越小，但精度损失也越大。很多人贪体积直接选最低档，结果模型输出质量肉眼可见地下降，这不是卡顿问题，是另一个极端。
我实测的经验：8GB显存以下机器优先 q4_k_m，别贪 q3；12GB显存以上可以尝试 q5_k_m 或 q8_0，优先保推理速度和质量平衡。需要注意的是，同一个模型的不同量化版本需要重新拉取，ollama仓库里都有对应标签，用 ollama pull 模型名:标签 即可。选错标签也不用慌，重新拉取一次就行，不会覆盖掉原来的版本。
这里还要多说一句，fp16 满精度版本虽然看起来“原汁原味”，但显存占用几乎是量化版的三倍以上。除非你是32GB显存的顶级卡，否则真不建议本地跑满精度版本。
2.2 上下文窗口是隐藏的显存杀手
上下文窗口（num_ctx）决定模型一次能“记住”多少token的对话内容。默认128到2048之间，实际如果你不手动改，有些大模型会自动设置一个偏高的值，导致KV缓存暴增。
KV缓存是什么？它相当于模型在推理时保留的“短期记忆”，占用的显存和上下文长度成线性关系。比如2048窗口可能只占1GB显存，拉到32768窗口后可能直接吃掉10GB。很多人的卡顿，根源就是这个参数被拉得过高，把整块显存吃光了。
解决方案是启动时显式指定 num_ctx。比如运行命令：
bash复制ollama run qwen3.5 --num-ctx 8192
如果只是想快速对话，甚至可以用4096。这个值并不是越高越好，对话超过设定长度后，最早的记忆会被“截断”，但对绝大多数使用场景已经够了。你把它压到合理范围，显存压力骤减，卡顿立刻缓解。
2.3 显存与内存的分工策略
本地部署大模型，显存是第一优先级，内存是兜底，磁盘是最差兜底。如果模型体量 + KV缓存 + 其他占用的总和超过了显存容量，系统会走“显存溢出→占用共享内存→占用系统内存→swap磁盘”这条路径，一层比一层慢。
我建议你先算一下账：本机显存多大，模型量化后多大，预估KV缓存多大，其他程序占多少。如果总和接近或超过显存，那优化目标就是“减重”，要么换更低的量化版本，要么缩小上下文窗口，要么关掉无关GPU占用。不要指望系统自动调度得好，它只会让你的机器慢到怀疑人生。
3. 参数调优实战：让ollama在现有硬件上跑得更顺
定位到问题后，接下来就是动手调整。这里分享几个我实测有效的参数和环境变量，改动成本极低，但效果非常明显。
3.1 开启Flash Attention：这是最容易忽略的一步
Flash Attention是一种高效的注意力计算方式，能显著降低KV缓存的显存占用，同时提升计算速度。ollama可以通过环境变量来启用它。
在Linux或macOS上，执行：
bash复制export OLLAMA_FLASH_ATTENTION=1
Windows PowerShell里则是：
powershell复制$env:OLLAMA_FLASH_ATTENTION = "1"
设置完后重启ollama服务（一般在终端退出再重新 ollama serve 或直接重开ollama应用）就生效了。我实测在同一个模型、同一个上下文长度下，开启后显存占用能下降15%~25%，生成速度有一定提升。如果你的模型比较大，这一步属于必做项。
3.2 限制并发与预加载数量，防止资源互相抢占
ollama默认允许并行处理多个请求，也会预加载多个模型。这对服务器场景是好事，但本机使用时很容易出现：你只是问了一句话，ollama却在后台同时加载了三个模型，显存瞬间爆炸。
通过环境变量可以限制这种行为：
bash复制export OLLAMA_NUM_PARALLEL=1
export OLLAMA_MAX_LOADED_MODELS=1
Windows下同样用 $env: 设置，或者直接在启动服务的bat文件里写好。这样同时只会运行一个模型、处理一个请求，其他对话排队等待。看起来“并发”低了，但换来的是每个请求都能跑完，而不是所有人一起卡死。
3.3 显存占用问题的临时急救方案
如果你正在对话中途发现显存快满了，又不想重启模型丢上下文，可以用ollama的卸载功能：新开一个终端执行 ollama stop 模型名，它会释放显存和内存。虽然对话上下文会丢失，但总比电脑死机要好。
另外要注意，ollama在你停止使用模型后并不会立刻卸载，它会保留一段时间以便快速响应。如果觉得它占着资源不放，可以调低环境变量 OLLAMA_KEEP_ALIVE，比如设为5分钟：
bash复制export OLLAMA_KEEP_ALIVE=5m
这样对话结束后五分钟后模型会自动释放，把显存还给其他程序。对于经常要切到其他图形软件、游戏的人来说，这个参数非常实用。
3.4 内存不足时的 swap 优化
虽然模型加载到内存是难免的，但系统内存被撑满到用swap的程度，就成了灾难。Linux下你可以临时提高swap大小，比如创建一个额外的swap文件：
bash复制sudo fallocate -l 16G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Windows上则是手动调整虚拟内存大小，建议初始值设为物理内存的1.5到2倍。这一步治标不治本，但在你还没来得及换模型版本的时候，它能先帮你撑过最艰难的一段时间。
4. 从系统层面减负：很多卡顿根本不在ollama
如果你按照前面几步调完，卡顿有缓解但没根治，问题很可能出在ollama之外的系统环境上。我排查问题时的经验是：先排除系统干扰，再回头琢磨ollama本身。
4.1 驱动与CUDA环境的坑
先说结论：显卡驱动版本和ollama的兼容性直接影响能否正确调用GPU。如果ollama在CPU上硬跑，就是你的GPU完全没干活，生成速度自然慢到让人怀疑机器坏了。
排查方法很简单：执行 ollama run 后打开 nvidia-smi，看进程列表里有没有ollama。如果没有，说明GPU没被使用。常见的解决办法是更新显卡驱动，或者在ollama里重新指定CUDA库路径。
还有一点容易被忽略：某些笔记本的“节能模式”或“自动切换显卡”功能会让ollama跑到核显上，而核显跑大模型的效率比独显差得远。检查一下系统显卡设置，在控制面板里把ollama或终端的GPU选择改为“高性能独立显卡”，这一步往往能立竿见影。
4.2 关掉占资源的非必要进程
这是我经常给身边朋友的建议：跑大模型之前，把浏览器里的几十个标签页先清理一下，因为现在的浏览器本身就能吃几个GB内存。还有各种即时通讯工具、云盘客户端、桌面动画特效，都是潜在的内存大户。
如果你不想手动一个个关，用系统的进程管理工具按“内存”降序排，把确实不需要的进程直接结束。我一般习惯在跑模型前把除了终端和必要工具之外的东西全关一遍，干净环境下跑大模型，卡顿概率会低很多。
4.3 散热与功耗限制对推理速度的影响
最后说一个很多人没想到的因素：散热。大模型推理是高负载任务，CPU和GPU会长时间跑在高温状态。笔记本如果散热不给力，会迅速触发温度墙降频，导致推理速度暴跌。
我调试的过程中就遇到过：刚开始跑还很流畅，三分钟后速度突然降一大截，一摸笔记本底面烫得厉害。后来把笔记本底部垫高，用散热底座对着吹，速度立刻回回来。台式机则要检查机箱风道和显卡风扇是否被灰尘堵住。这个问题最容易假装成“模型问题”或者“软件问题”，实际就是物理散热问题，排查思路一定不要忽略它。
5. 常见故障排查实录与避坑清单
这一部分是我在多个场景中调试后整理出的最常遇见的问题，以及针对性的处理办法。你在实际部署中如果遇到类似现象，可以直接对着表看。
5.1 典型问题速查表
| 现象 | 排查步骤 | 解决办法 |
|---|---|---|
| ollama不调用GPU | nvidia-smi 没有ollama进程 |
重装驱动；检查GPU被节能模式占用；在ollama服务配置中显式指定设备 |
| 显存溢出导致系统崩溃 | 任务管理器看到显存满+内存满 | 降量化等级；减 num_ctx；开启Flash Attention；限制 MAX_LOADED_MODELS |
| 每次冷启动卡几分钟 | 模型文件放在机械盘或移动存储 | 迁移到本地固态；减少模型体积；预先加载到内存 |
| 输出速度忽快忽慢 | 温度墙/功耗墙触发 | 检查散热；笔记本垫高；限制后台高占用；台式机清灰 |
| 对话一长就开始卡 | KV缓存随上下文膨胀 | 降低 num_ctx；开启Flash Attention；手动重启模型清理缓存 |
| 多个模型同时加载互相挤 | ollama后台预加载多个模型 | 设置 OLLAMA_MAX_LOADED_MODELS=1；用 ollama stop 释放 |
5.2 操作顺序建议：从最简单到最复杂
如果你面前是一台全新的机器，准备从头部署，我建议按这个顺序来操作：
- 更新显卡驱动，重启机器，确认能被普通图形程序调用。
- 安装ollama，拉取质量/体积比均衡的量化版本，不要直接拉fp16。
- 先跑一条测试消息，用
ollama ps确认模型已加载，再用nvidia-smi确认调用的是GPU。 - 设置
OLLAMA_FLASH_ATTENTION=1、OLLAMA_NUM_PARALLEL=1，重启服务。 - 根据首次运行的显存占用情况，决定是否降低
--num-ctx或换更低的量化版本。 - 清理系统后台进程，确认散热条件良好。
这套流程走下来，绝大多数“ollama部署qwen3.5后电脑卡顿”的问题都能缓解。
5.3 换模型版本时容易踩的坑
很多人想换低量化版本来解放显存，结果拉下来发现体积没小多少，原因可能是拉错了标签。所以拉取前一定要用 ollama list 确认本地已有的模型标签，从ollama官方仓库或模型详情页看清楚同一个名字下有哪些不同量化版本，别凭感觉猜。
另外，不同量化版本切换后，之前的会话上下文无法继承。也就是说你换了量化版本，所有历史对话都从零开始，这点要提前知道，免得聊到一半换模型白丢上下文。
写在最后的经验
从我个人反复调试的经验来看，ollama部署qwen3.5这种重量级模型，卡顿的核心原因八成集中在显存溢出、上下文窗口过大、GPU没被正确调用这三件事上。把环境变量和量化层级调对，至少能解决一半问题，剩下的往往要靠“减少系统负载”和“改善散热”来兜底。每次遇到卡顿，不要急着加硬件，先把这几个变量都检查一遍，大多数情况都能救回来。如果你也碰到过类似的卡顿，欢迎对照我上面写的顺序重新调整一次，大概率会有惊喜。