几千个AI角色同时运行，卡住的多半不是画面，而是每个角色每一步都在排队等模型。把“慢”拆成调用次数、单次开销和等待时间三笔账，每一笔都有各自的省法。
先问一句：时间到底花在了哪里
优化之前要先知道账花在哪。Xie等人2024年在arXiv发表的AI Metropolis，在其测试的生成式智能体工作负载里报告，约95%的模拟时间用于LLM推理。这个数字有明确的适用范围，只是他们测的那一类模拟，不能理解为所有多Agent系统都这样分布。但它提醒了一件事：在模型驱动的模拟里，先别怀疑寻路和渲染，先数一数模型被叫了多少次。
一笔假设的账：3,000个角色一天要调用多少次
下面的数字是模拟示例，用来说明量级，不代表任何真实测量。
假设一个城市有3,000个AI居民，游戏里一天分成24个决策时间点。最朴素的写法是每个居民每个时间点都问一次模型：3,000乘24，一天72,000次调用。如果单次调用平均耗时1秒、且一次只处理一个请求，光是排队就要近20小时，玩家看到的只有“转圈”。
现在按情况拆开：绝大多数时间点居民处在“睡觉”“上班”“在家吃饭”这类稳定状态里，根本没有需要判断的东西。假设只有5%的时间点出现了新情况，比如通勤路线堵了、收入变了、邻居搬走了，那么一天只剩3,600次调用，同一笔账少了95%。这笔省下来的钱，比任何底层优化都大。
还要留意另一个常被混淆的量：调用次数和等待时间不是一回事。3,600次调用如果一个接一个地跑，仍然要一个多小时；如果每次能带上几十个同类请求一起处理，实际推理批次可能只剩几十到一百多批。所以“少调用”和“一起调用”是两个独立的优化，前者压缩总量，后者压缩单位成本，两者相乘才是最终的体感。
再看一个反例。假设为了追求“更聪明”，把每个居民的记忆全部塞进提示词，输入变长，单次推理明显变慢，批次能放的请求数也跟着下降。结果是调用次数没变、总耗时反而增加。在这类系统里，提示词长度本身就是性能参数，需要和调用次数一起计入预算。
四个杠杆，各自省什么，各自付出什么
| 杠杆 | 省的是 | 代价 |
|---|---|---|
| 事件触发 | 调用次数 | 要定义“什么算新情况”，漏判会让角色显得迟钝 |
| 批处理 | 单次开销，同类请求合并进一次推理 | 要等一批凑齐，反应有延迟；请求格式要统一 |
| 异步与乱序执行 | 等待时间，不相关的角色不再互相等 | 要追踪谁依赖谁，实现复杂，出错难查 |
| 小模型与预生成动作 | 单次成本，简单决定用本地小模型 | 表达力下降，需要把选项限制在有限集合里 |
四个杠杆并不冲突，通常按这个顺序叠加：先用事件触发把调用次数压下来，再用批处理把剩下的请求合并，然后处理等待，最后才考虑换模型。前两项的具体做法，大发娱乐在批量推理一文和事件驱动的NPC一文里分别展开过。
全局同步的“假依赖”：为什么城市两端要互相等
最容易被忽视的是等待时间。很多模拟按统一的时间步推进：第N步所有角色都做完，才开始第N+1步。这对保证正确性很省心，但会制造一种“假依赖”：城市东边的面包师和西边的公交司机在这一步里毫无关系，却要等对方那一次慢速推理结束。
Xie等人的做法是追踪角色之间真实的依赖关系，只让可能互相影响的角色保持顺序，其余的可以乱序往前跑。他们在摘要中报告，相比带全局同步的标准并行模拟，速度提升在1.3倍到4.15倍之间，智能体越多越接近最优。全文里的一组测试给出了更具体的口径：500个智能体、8块L4 GPU时，相对并行同步版本为4.15倍；到1,000个智能体时，相对并行同步的加速趋于平稳，约3.94倍。这些结果针对的是特定工作负载和硬件，不能直接搬到别的游戏里，但它们说明了一个方向：等待，往往比计算本身更可优化。
MobileCity（Ye等人，2025）走的是另一条路：4,000个模拟智能体，让每个智能体在预生成的动作空间里选择，并用本地模型生成记忆来压低算力成本。AgentScope（Pan等人，2024）则在框架层面引入基于actor的分布式机制和并行执行，用于支持更大规模的智能体模拟。三种路线的共同点是把“想”拆碎，让它不必在一条队里排。
规模上去以后，哪些问题会换个形式冒出来
对大发娱乐这样的多场景系统来说，这个问题更现实：城市、经营和战略共用一套调度，一个场景里的批处理积压会挤占另一个场景的时间。所以预算不能只按单个世界估算，还要给每个场景留出上限，谁超了就自动降级为规则更新。
把等待压下去之后，瓶颈通常会转移。第一个转移的地方是状态存储：几千个角色各自带着记忆、画像和关系，每一次读写都要落地，内存压力会先于算力压力出现，这也是大发娱乐App比普通游戏更吃内存的原因之一。第二个转移的地方是一致性：乱序执行意味着两个角色的更新顺序不再固定，若没有明确的依赖规则，同一个存档可能在两次运行里得到不同的结果。这对需要读档回放的模拟游戏是不能接受的，所以任何乱序都要以“结果可复现”为前提。
第三个是长尾。批处理的平均速度可能很好，但偶尔一批里混进一个特别长的请求，整批都会被拖住。常见的做法是按长度分桶，把相近长度的请求放进同一批，同时给每一批设置超时，超时的请求退回规则更新，而不是让整个世界卡在那里。
大发娱乐怎么判断“还要不要再加角色”
在大发娱乐AI大模型的设计里，规模上限不是由“机器还能撑多少角色”决定的，而是由“多加的这些角色，玩家能不能看出区别”决定的。可以用下面三个问题过一遍，其中涉及的数字同样是假设场景：
- 每一帧的预算。假设希望模拟时间流速下每个游戏小时不超过10秒真实时间，那么每小时的推理批次和等待都要装进这个预算。装不下，就不能再加。
- 差异是否可见。把角色从3,000加到6,000，通勤分布、店铺客流、房租的走势有没有明显不同？如果没有，多出来的3,000个角色只是耗电。
- 是否需要为“看得见”的角色多花钱。玩家镜头附近的角色可以用完整的记忆和推理，远处的可以用规则或者聚合成群体。这类“分层精度”比平均地增加角色更划算。
这套取舍是混合游戏AI思路的直接延伸：模型负责需要判断的地方，传统模拟器负责需要算得准和算得快的地方。设备较弱的玩家在大发娱乐App里看到的规模选项，本质上也是同一笔预算账。
还有一点值得单独说明：这些预算都要在“最慢的设备”上成立。开发机上跑得流畅的规模，放到内存较小、散热较差的手机上，可能立刻变成掉帧和发热。所以规模选项应该给出明确的档位，每一档写清角色数量、模拟速度和被降级为规则更新的比例，让玩家用一点细节换取流畅，而不是在卡顿里自己猜原因。
几千个角色能不能同时运行，答案不在“机器多强”，而在有多少次调用本来就不该发生。先把这些删掉，再谈并行。
