ollama有哪些使用限制：并发和显存在哪先卡住你

本地跑模型的人多半是从 ollama 起步的，装完、拉下来、能对话，就觉得成了。等真把它接到一个小工具里、或者同时开几个请求，问题才冒出来：后面排队的请求一直转圈、显存满了直接掉到 CPU、量化档位选错答非所问。这篇不吹它好用，只讲清楚这几处限制在什么情况下会咬你，以及怎么提前摸一遍底。

本地跑模型的人多半是从 ollama 起步的。装完、拉下来、打两句话能回，就觉得成了。等你真把它塞进一个小工具里，或者同时开几个请求，毛病才冒出来：后头排队的请求一直转圈，显存一满直接掉到 CPU，量化档选歪了答非所问。这篇不吹它好用，只把这几个坎在哪、什么时候会咬你讲清楚。

先说明一点：下面说的都不是 ollama 的 bug，多半是你对它的默认行为理解偏了。它默认就不是给你当高并发服务端用的，定位更接近「本地一个能跑起来的模型运行器」。你把期待放对了，很多坑其实提前就能避开。

并发这块，先把「能同时来几个」想清楚

最容易踩的一脚，是把 ollama 的接口当成能横向扩展的服务。实际情况是：默认按单请求队列走，第二个请求进来是排队，不是并行加速。接口照样返回，看着是通了，但延迟一层层叠上去，你在上层根本分不清是模型慢还是排队慢。

还有一种更隐蔽的：你同时挂两个不同模型，显存不够，后加载的把前一个挤掉了。表现是——刚聊过的模型再问一句，又要重新加载一遍。第一次遇到会以为是模型崩了，其实是显存装不下两个。

• 先量基线：同一个请求连发几次，记下单次耗时，再同时发两三个对比，差多少就是排队成本
• 如果延迟随并发线性涨，说明就是队列，别指望加并发提速，改成在上层做请求合并或限流
• 模型切换频繁的场景，把常驻策略调一调，不然每次切都重新加载，体验很差
• 想快速摸延迟底，可以到 /tools/speed-test 跑一轮，拿自己机器上的数说话

量化给了你「跑得动」，代价得自己认

量化这件事，很多人只看到「能跑起来了」，没注意同一模型不同量化档，显存和速度差一大截，输出质量也跟着变。最容易被看出来的地方是长文总结、写代码、还有涉及数字的推理——档位压狠了，它就开始含糊、漏点、算错。

另一个坑：tag 名里带个小后缀，别默认当成同一个东西。同一模型不同档位，回答风格和准确度都会有差别，你以为在对比模型，其实是在对比量化档。

判断标准很简单：如果你需要「它说的每句话我都能拿去用」，那就别在量化上省。反过来，只是拿它当个草稿机、思路启发，压一档换速度是划算的。这条不适用于对输出一致性有硬要求的场景，那种情况宁可缩小模型规模。

显存不是「够装下就行」，还要留余量

显存这块最常见的误判，是拿「刚好装下模型」当标准。实际跑起来，上下文长度才是真正的显存杀手。长文档、长对话，会随轮次一点点往上吃，开头能跑，不代表跑一下午还能跑。

还有常驻策略。模型加载后占着显存不放手，多模型来回切的场景，不提前规划就是反复挤掉、反复重载。这不是性能问题，是配置没对齐你的使用方式。

1. 定任务形态先想清楚是单人对话、几个人共用，还是程序里循环调。三种对并发的期待完全不同，别拿单人对话的经验去套批量调用。
2. 定模型和量化档按显存留出两三成余量反推能开多大上下文，别按峰值把显存占满，留的那部分就是给长对话和系统开销的。
3. 压一轮并发两三个、上下文拉长、连跑十几分钟，看是否掉速、是否回落到 CPU。回落 CPU 就是显存不够的明确信号。
4. 记天花板把这套配置能撑到哪写进部署笔记，后面换模型、换档位才有参照，不用每次重新试。

显存测算别靠估。可以到 /models/deploy 看模型的部署要求，再到 /compute/sizing 按模型和量化档算一遍，两个页面配合着看，比拍脑袋靠谱。

上手之前，照这个顺序摸一遍底

把上面几节串起来，其实就是一套自检顺序。不用等出了问题再回头查，装完就先走一遍，能省掉后面大量「怎么突然变慢了」的排查。

先定任务

单人对话、多人共用、程序批量调，三种期待不一样，先对号入座

再定配置

模型加量化档，显存留余量反推上下文，别占满

然后压测

并发、长上下文、长时间连跑，看掉速和回落

最后记录

把天花板写下来，换模型时有参照

这套顺序有一个前提：你清楚自己机器的显存上限。如果连这个都没量过，先去系统里确认，再回来套流程。不适用的情况也有——如果你只是本地一个人偶尔问两句，并发和常驻这两块基本不会咬到你，重点看量化档选得合不合适就行。

ollama 的限制大多不是它差，是你拿服务端的期待去用它。把期待摆正，坑就少一半。