北京
我想提高本地AI代理运行器的并发上限。界面现已支持多个终端面板同时运行，直觉告诉我，运行器进程本身正在成为瓶颈。
在修改任何配置之前，我写了一个基准测试来验证这个假设：当N个会话同时运行时，真正出问题的到底是什么——模型服务器、硬件，还是调度策略？
结果证明，我的直觉完全错了。
基准测试的设置
我编写了一个基准脚本，向运行器发起N个并发聊天会话。每一轮都会访问本地模型（通过Ollama运行hermes3），使用固定提示词，走完整条流水线：回合前的意图分类、聊天响应、回复后的记忆提取。
我跟踪了四个具体指标：
- ttfa（首次活动时间）：POST请求到发出第一个内部事件，衡量运行器在接触Ollama之前的事件循环表现。
- first-Ollama：POST请求到第一个请求进入模型队列。
- done：POST请求到用户收到答案。
- wall（排空）：回复后的记忆提取尾部在Ollama后台完全结束的总耗时。
结果：N=1处出现硬墙
在N=4时，墙钟时间放大到单会话基线的4.80倍。因为4.8倍已经超过4倍，所以并发请求的实际表现比纯粹、完美有序的串行队列还要差。
瓶颈分解的结果立刻清晰了：
- 不是运行器的问题：ttfa在所有运行中都稳定在0.0秒。运行器的事件循环在毫秒级处理并路由传入的POST请求，完全没有排队。
- 不是硬件的问题：CPU峰值仅为63%，空闲内存从未低于约5.9GB。
- 是Ollama的问题：延迟堆叠在Ollama内部针对已加载模型（hermes3 8.0B Q4_0）的请求队列中。
此外，wall（排空）指标证明，后台记忆提取在用户收到答案后很久仍让Ollama保持饱和——这是天真的RPS基准测试完全遗漏的隐藏税。
反转：作业队列因策略而非负载失败
更值得玩味的是，问题并不出在负载本身，而是Ollama的作业调度策略。面对并发请求，Ollama默认将共享同一模型的请求串行化处理，而非按优先级或响应时间做智能调度。这意味着即使硬件资源充足——CPU只用掉63%，内存还剩5.9GB——吞吐量依然被队列策略锁死。真正的优化空间不在堆硬件，而在调整模型队列的调度逻辑。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
