ollama服务API接口限制

自己机器上跑 Ollama，单条请求挺顺，一旦并发上来就排队、超时、显存爆，或者局域网里别人也能直连你的端口。这篇不讲协议怎么兼容，只讲工程侧怎么把并发数和访问控制这两件事管住：先量基线，再定上限，最后加一层门。

自己机器上跑 Ollama，单条请求挺顺，一旦并发上来就排队、超时、显存爆，或者局域网里别人也能直连你的端口。这篇只讲工程侧怎么把并发数和访问控制这两件事管住：先量基线，再定上限，最后加一层门。协议兼容、模型格式这些不是重点，先放一边。

判断限制之前，先想清楚你卡在哪一层。有人把并发调不动怪接口，其实是显存装不下第二份上下文；有人明明只是本机开发，却先花时间搭反向代理。先分层，再动手，能省掉一半无用功。

先分清三类限制，别混着调

Ollama 的「限制」至少有三层，调错层等于白调。模型侧决定同一时刻能装下几份上下文；服务侧决定几个请求能被同时处理、其余怎么等；接入侧决定谁能碰到这个端口。三层各自独立，改一层不会自动带着另一层变好。

容易踩的坑是把「服务侧并发不够」和「显存不够」当成一回事。前者加参数能缓解，后者加参数只会更快把显存吃满。测的时候两类指标都要看，别只盯着耗时。

动手调之前，先把基线量出来

没有任何基线就开始调参，等于闭眼拧螺丝。先跑单请求，记录首字延迟和整体耗时，这是后面所有判断的参照。想省事可以到 /tools/speed-test 量一遍自己的延迟基线，把结果存下来。

1. 跑单请求基线固定一个典型提示词，重复几次取稳定值，记下首字延迟和总耗时。
2. 逐级加并发从 1 开始往上加，记录第几个请求开始明显变慢、第几个开始超时。你要找的是排队拐点，不是崩溃点。
3. 同步看资源曲线同时盯显存占用和进程内存，判断是算力吃满，还是模型在被反复加载卸载。
4. 回退一档留余量把实际上限设在拐点之前，留出一档余量，别贴着悬崖跑。

如果拐点出现在显存快满的时候，说明瓶颈在模型侧，调服务端参数没用，该考虑更小的量化版本或减少同时驻留的模型数量。

并发与排队怎么调：改配置还是改调用方

能改服务端就改并行数，让服务明确接受几个同时处理的请求，剩下的排队。但调大之前先确认显存够装对应份数的上下文，否则只是把失败提前。不方便改服务端，就在调用方限流。

• 用信号量或队列把并发压到实测上限之内，比无脑重试温和得多
• 短请求高频的负载靠排队，长请求低频的负载靠错峰，同一套参数不一定都合适
• 客户端超时要显式设置并留出排队时间，否则排队中的请求会被先掐断
• 把并行数和超时值写进配置注释，下次换机器时有参照

# 思路示意：调用方用队列把并发压住
# 并发上限取实测拐点回退一档后的数字
seq 1 20 | xargs -P 3 -I{} curl -s http://127.0.0.1:11434/api/generate -d @req.json

什么情况下不用调：单用户、串行调用、机器只服务一个人时，把并行数调大没有收益，反而更容易把显存顶满。先确认真的有并发来源再动。

访问控制：别把本地端口开成公共接口

Ollama 默认只监听本机回环地址，这是最安全的形态。要让同局域网的其他机器用，再考虑对外监听，并且只开到需要的网段，不要图省事开成任意来源可达。

对外监听时，不要让别人直连服务端口。前面加一层反向代理，把鉴权和限流放在那一层，服务本身退回内网。机器上多一块网卡、换了网络环境，都要重新对一遍允许来源。

端口一旦对外，访问控制就变成独立问题，和并发数字要分开处理。

不适用的情况也要说清：纯粹本机开发、单用户、没有外部调用方时，加鉴权代理是多余的，别为了「规范」给自己增加维护负担。

上线后怎么知道又顶不住了

光看总耗时分不清是慢在排队还是慢在推理，所以每个请求至少记三个字段：排队等待、处理耗时、是否失败。三者分开，才知道该降并发还是该换模型。

• 出现持续排队时，优先降并发或换更小的量化版本，而不是加大重试次数
• 本地和云端接口并存时，本地顶不住可以按规则切走，切换阈值写清楚由谁触发
• 周期性回看当时的数字，配置和模型都可能变，早期标定的上限会过期
• 把每次调整的原因记一行，下次排查不用从头猜

阈值和对比数据不要凭记忆，站内会持续更新各家接口的公开资料和实测口径，到 /price-watch 核对当时的数字，再决定本地这条链路值不值得继续扛。