ollama有哪些使用限制，从选型到落地的完整流程说明

很多人第一次用 Ollama 跑本地模型，装完能说话就以为完事了，一上多人同时提问、一换量化档位、一加长上下文，速度立刻塌下来，甚至直接爆显存。这篇不重复怎么安装怎么拉模型，只讲限制在哪里、怎么提前测出来，以及一套从选型到上线的检查顺序，帮你在给团队用之前就把坑踩完。

很多人第一次用 Ollama 跑本地模型，装完能说话就以为完事了。一上多人同时提问、一换量化档位、一加长上下文，速度立刻塌下来，甚至直接爆显存。这篇不重复怎么安装怎么拉模型，只讲限制在哪里、怎么提前测出来，以及一套从选型到上线的检查顺序。

核心就一句话：Ollama 是给单人桌面用的，它的默认行为全是按「一个人慢慢用」来设计的。给团队用之前，先把并发、量化、显存这三块的天花板摸清楚，比事后救火划算得多。

并发：它是给单人桌面的，不是给团队服务的

默认的模型服务方式在多人同时请求时会一个等一个：第二个请求的等待时间几乎等于第一个的生成时间。五个人同时问，最后进来的那位要等前面几个全部生成完，体验直接崩。这不是 bug，是默认设计如此。

判定标准很简单：把「预期同时在线人数 × 单次生成时长」算出来，和你能接受的等待上限比。超了，就说明这套不适合直接当团队服务，要么加服务层排队，要么换方案。

• 先数清楚峰值同时在线人数，别拿平均数算
• 量一次真实业务输入下单次生成要多久，不是用「你好」测
• 两个数相乘，和你承诺给同事的等待上限对比
• 超过上限就别硬扛，考虑加队列或换专门的服务框架
• 不适用的情况：单人本地问答、离线批处理、偶尔几个人的知识库 Demo，这类没必要为了并发折腾

量化与显存：省下来的显存要从别处还回去

量化档位越低，权重占显存越少，但同一个模型的上下文缓存和中间激活不会等比例缩小。结果就是短对话跑得挺欢，一进长对话先崩的往往不是权重，而是缓存。所以别只看模型能不能加载起来，要看它能不能撑住你最长的输入。

验证方法：用你真实最长的输入去测，而不是用一句「你好」去试。短输入跑得飞快不代表实际业务跑得动，这一点在选型阶段最容易漏。

绕不开的几个开关：层数卸载、常驻与监听

层数卸载

显存不够时部分层被丢到 CPU，速度断崖式下降，要先查是不是卸载层数被调低或自动降了

模型常驻

模型闲置会被从显存踢出，下次请求要重新加载，给人用的感觉是第一句话特别慢

监听地址

默认只本机能连，对外服务前先确认监听地址和端口范围，否则接前端工具会一直连不上

这三个开关不涉及调优技巧，全是「不知道就会踩」的坑。排查顺序建议是先看监听能不能通、再看模型是不是每次都在重载、最后才怀疑是不是卸载层数导致变慢，从外到内一层层排除。

从选型到落地的四步流程

1. 第一步定场景分清单机自用、小团队内网、对外接口三种，限制容忍度完全不同；对外接口对排队和稳定性要求最高。
2. 第二步定模型和档位按目标机器的显存倒推参数量与量化档位，别反过来先选模型再凑机器；倒推完到 核对当时的模型资料。
3. 第三步压测单人、3 人、预期峰值各跑一轮，记录首字延迟和生成速度；一轮不够就换真实最长输入再跑。
4. 第四步验收把压测数字写进使用说明，告诉同事什么情况下会慢，避免被当成故障来报修。

这四步里最容易被跳过的是第四步。写使用说明不是形式主义，它决定了后面同事遇到慢的时候是来找你修 bug，还是知道「哦，这是并发满了」。

什么情况下该换工具而不是继续调 Ollama

判断办法看压测瓶颈在哪：如果瓶颈是排队，也就是单次生成速度其实正常、但人多就等很久，说明问题在服务层，不在模型和显存，继续调参意义不大。反过来，如果单人也慢，那才是模型和硬件的事。

• 需要稳定支撑多人并发、要求请求排队公平和吞吐指标时，专门的服务框架更合适
• 需要多卡切分跑超大模型时，也该换
• 需要细粒度批处理调度时，同样不建议硬调
• 机器本身够用、只是偶尔两三个人用，那继续用 Ollama 没问题，别过度设计

选型阶段想横向对比不同本地部署方案的成本和工作量，可以到 看已有的部署类指南，再结合自己机器的实际情况判断，不要只照搬别人的配置清单。