ollama有哪些使用限制，常见问题和解决思路

本地跑 Ollama 一开始都能出字，用着用着就会撞墙：几个人同时提问就排队、换了个量化档位效果肉眼可见变差、模型加载不上或者跑一半掉到 CPU。这篇按并发、量化、显存三块，把每类坑的判断依据、排查顺序和绕开办法列成清单，照着对一遍就能定位。

本地跑 Ollama，一开始都能出字，用着用着就撞墙：几个人同时提问就排队、换了个量化档位效果肉眼可见变差、模型加载不上或者跑一半掉到 CPU。这些都不是模型本身坏了，而是并发、量化、显存三块限制在起作用。

这篇按这三块把每类坑的判断依据、排查顺序和绕开办法列成清单。你可以当成一份速查表，出问题时对着走一遍，比到处翻帖子快。先说清楚：下面所有「多快」「多能扛」的说法都只是方向性的，具体数字要看你自己的卡和你手上的模型，去站内页面按当时的模型和量化档位估。

并发限制：Ollama 默认不是给多人用的

默认配置下，请求是排队处理的：一个人问完，下一个人才能开始。你在前端看到的是「大家都点了发送，但回复一个一个来」，很容易误以为是卡死，其实是在等。判断方法很简单：看同一时间进来的几个请求，返回时间是不是依次拉开、中间有明显停顿。如果是，就是排队，不是性能问题。

真正能并行的前提，是显存放得下多份上下文和 KV 缓存。卡越紧，越容易退化成串行，甚至表面并行实际互相拖慢。想算自己这张卡大概能扛几个并发，先去 /compute/sizing 按模型和量化档位估一遍，再决定要不要开多并发。

• 先确认是不是真多人同时用：一个人用、短对话场景，并发这块基本不用管，优先查显存和档位
• 如果确实是多人用，先砍单次上下文长度，再考虑并发数，顺序别反
• 别用「多开几个进程」硬扛，容易把显存挤爆，反而整体变慢
• 小团队（比如 5 个人）可以先按串行用，真觉得排队难受再上多并发

量化档位：省显存和质量下降是一条滑梯

量化等级越低，文件越小、越容易塞进显存，但质量掉得并不均匀。长文理解、代码细节、多语言这几类任务掉得最明显，日常闲聊基本感觉不出来。所以「别人说这个档位够用」对你的场景不一定成立，得看你让它干什么活。

判断办法是拿同一批自己的真实问题，在两个相邻档位上各跑一遍对比，别只看别人的结论。术语不清楚的，先去 /ai-dict/category/tech 查一遍再动手，免得把「量化」和「蒸馏」混着理解。

显存与卸载：跑得动和跑得顺不是一回事

模型一部分塞进显存、一部分留在内存时，照样能出字，但速度会断崖式下跌。这也是「昨天还快，今天怎么变慢」最常见的原因：不是模型变了，而是显存不够，开始往内存里卸载。

1. 第一步：看显存占用先确认是不是别的程序（浏览器、别的推理服务、游戏）占着显存。关掉再试一次，速度回来就是被抢了。
2. 第二步：算模型加上下文把模型本身大小和当前上下文长度一起算，是否超出显存。卡的具体规格去 /compute/gpus 对，别凭印象。
3. 第三步：砍上下文把单次上下文长度降下来再试，速度明显回升说明之前就是超了。这是成本最低的一步。
4. 第四步：降量化档位上下文砍完还是慢，再考虑降一档量化。注意配合上一节的对比方法，别为了速度牺牲到不能接受。
5. 第五步：最后才怀疑硬件前面都排除完，再考虑换卡或加显存。顺序反了容易白花钱。

调参思路记住一个顺序：先砍上下文长度，再降量化档位，最后才考虑换卡。显存怎么算的细节，可以参考显存与优化相关的入门词条 /ai-dict/category/hardware，先把账算明白再动手。

一份排查清单：出问题时按这个顺序走

上面三节拆开讲了，实际遇到问题往往混在一起。下面按从外到内的顺序给一份排查清单，照着走能少绕弯。每层都别跳过，前一层没排除就怀疑后一层，很容易误判。

• 第一层：请求是不是排在队里，看返回时间是否依次拉开，判断并发压力
• 第二层：是否发生显存溢出卸载，看生成速度是否突然掉一个量级
• 第三层：量化档位和任务是否匹配，换档位对比同一批题
• 第四层：模型文件是否完整、是否换过模型，排除换模型带来的误判

第四层容易被忽略：有时候你以为是性能问题，其实是模型换过了，或者文件下载不完整。确认模型没变、文件完整，再回头查前三层。价格与官方订阅口径这类信息，去 /official-api 对当时的数字，别拿旧截图当依据。