如何协调项目并发、文件 Worker 与外部模型请求

本文属于 Memory Center：AI 编程上下文与记忆系统工程实践，第 30 篇，位于“可靠后台任务”模块。案例背景统一采用实际开发项目；复现步骤使用脱敏教学样例，不代表特定生产事故。

从实际问题出发

同时索引多个项目，每个项目再启动很多文件进程，再并发请求模型，容易让三层并发相乘。吞吐量并不随 Worker 数无限增长，资源竞争还会拖慢交互请求。

按资源种类建立预算

项目级任务、CPU 文件解析和外部模型调用消耗不同资源。应分开控制，再让项目之间共享机器预算。增加网络并发不能解决 CPU 饱和，增加解析进程也不能绕过模型限流。

图中展示的是本篇关注的职责和顺序。正常流程之外，还要结合下面的源码与实验检查失败分支；它不是对某次线上调用的运行时追踪。

观察完整系统的代价

应记录排队时间、执行时间、内存与外部错误。只测单文件速度会忽略并发调度和进程启动成本。预算最好能按实际机器和项目规模配置，而不是在每个调用点写一个独立常数。

关键源码与阅读方法

源码基线为 Memory Center 6e90553（文档标注 5.0.0b24）。定位：memory_center/platform/work_pool.py，函数 share_budget，起始行 49。

以下为当前基线中的函数代码；依赖项目模块，不能作为独立脚本执行。

def share_budget(budget: int, concurrent_jobs: int) -> int:
    """把总预算切给单个在跑项目。

    ``concurrent_jobs`` 是**含本任务在内**的并发项目数。切分在任务准入时
    一次性完成：同时只有 1 个项目时它拿到全部预算；4 个项目同时开时
    每个拿四分之一。先完成的项目不会把它们交还的份额让给仍在跑的项目，
    这是刻意的取舍——代价是有上限的，收益是无需跨进程抢占协调。
    """
    return max(1, int(budget) // max(1, int(concurrent_jobs)))

阅读时先找输入由谁提供，再区分纯计算、读取和写入；遇到异常或提前返回，追问调用方会得到什么，以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现，跨模块行为应继续查看调用处和相应测试。

用一个小实验核对设计

建议在独立临时目录和隔离数据中操作，使用虚构的接口、文档与项目名称。

1. 用一个项目和多个项目执行相同样例。
2. 逐步调整并发。
3. 记录吞吐、尾延迟和错误，不预设提升比例。

**要核对的结果：**资源预算应可解释，增加并发后若错误率或尾延迟恶化，应能回调配置。

可把观察记录为下表；没有执行的项写“未执行”，不能用设计预期冒充实测结果。

核对项	应保留的证据
使用条件	源码版本、配置、输入与项目范围
正常行为	实际返回、来源位置或状态变化
关键失败分支	错误码、可见结果与原状态是否保留
结论范围	已覆盖、未覆盖和需要进一步验证的条件

适用边界与继续阅读

本篇以静态源码与项目设计为依据，给出可执行的核对方法，未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化，应先核对当前合同，再把方法用于自己的实际开发项目。

理解这一节后，可以回到专题总导航，沿同一模块继续阅读；顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择，应连同本篇的代价与限制一起采用。