大型模拟一卡，多数人的第一反应是关掉画面特效。但在大发娱乐App这类以Agent为核心的系统里，画面通常不是最贵的那一项。
先算一笔账：卡顿其实是预算超支
把大型模拟想成一份每个“模拟日”必须按时交付的工作。要交付的量，可以粗略写成三个数的乘积：活跃Agent数，乘以每个Agent每个模拟日的决策次数，再乘以单次决策的成本。而设备能提供的，是在一个刷新周期里能完成的总量。前者超过后者，模拟就会变慢，或者变得不同步。
下面是一个模拟示例，数字纯属假设，只为演示逻辑。某城市有4000个居民，每个居民平均每天做6次值得重新判断的决策，共24000次决策。若单次决策平均耗费一个固定单位，一天就是24000个单位；设备一个刷新周期最多处理20000个单位，超出的4000个单位就必须被推迟。玩家看到的，就是“模拟速度上不去”。
有了这个框架，三个旋钮的含义就清楚了：减少居民数，是降低第一个乘数；调低模拟速度，是给同一份工作更长的时间；降低决策精细度，是压低第三个乘数。它们能互相替换，但代价不同。
三个旋钮，各自牺牲什么
| 旋钮 | 调整方式 | 省下的算力来自 | 你要付出的代价 |
|---|---|---|---|
| Agent数量 | 缩小城市或世界规模 | 活跃个体变少 | 群体现象（堵车、房价）的统计更粗糙 |
| 模拟速度 | 降低倍速，或减少每帧步进 | 同样的工作分摊到更长时间 | 推进同样多的天数要花更久 |
| 决策精细度 | 更多决策走规则和缓存，少走完整推理 | 单次决策成本下降 | 个体行为的差异略有下降 |
大发娱乐App的设计思路，是尽量让第三个旋钮少被玩家感知：多数居民的日常决策沿用习惯，只有遇到新情况才做完整判断，这也是模拟游戏为什么不能给每个NPC每秒调用一次大模型所讨论的“事件驱动”思路。按具体设置名称与可调项，以App内实际界面为准，这里讲的是各选项背后的道理。
为什么Agent数量翻倍，卡顿不是翻倍
很多人以为算力和Agent数量是线性关系，实际往往不是。至少有两个原因让它更陡。
其一，Agent之间会互相影响。居民多了，路上车多了，每个居民做路线判断时要考虑的信息也更多，单次决策的成本本身在上升。其二，同步等待。如果一批Agent必须等最慢的那一个完成，才能进入下一步，那么规模越大，越容易被少数拖后腿的个体拖住整体。
一项可作参照的研究：Xie等人的团队于2024年在AI Metropolis一文中报告，在他们测试的一种生成式Agent工作负载里，约95%的模拟时间花在大模型推理上，并指出全局同步步进会制造“假依赖”，限制并行度；他们用依赖追踪做乱序执行来提高吞吐。这个数字只针对他们测试的具体负载和硬件，不能直接套到任何一个游戏，但它说明了一个方向：与其一味提升设备，不如减少等待和无谓的推理。
对玩家来说，实际含义是：城市模拟为什么需要“批量推理”而不是一个个慢慢想，正是把同类决策攒成一批一起处理，摊薄单次成本。批处理做得好，规模翻倍的代价就低于翻倍，反之则可能远高于翻倍。
同一座城市放在三台设备上，会怎样
为了看清“设备性能”这个因素，继续沿用前面的模拟示例：4000个居民、每天24000次决策。假设有三台设备，每个刷新周期分别能处理12000、20000和36000个单位（数字同样是假设）。
- 12000单位的设备：只能处理一半的决策，必须把大部分居民的日常决策改走缓存和习惯，或者把规模缩到2000人左右，才能保持模拟日按时结算。
- 20000单位的设备：略有缺口。适度提高“沿用习惯”的比例，就能放下4000人，日常使用没有明显感受。
- 36000单位的设备：有余量，可以同时打开更高的倍速，或者把规模放大到6000人左右。
这个例子想说明的是：不存在一个对所有设备都成立的“推荐规模”。大发娱乐App更合理的思路，是让规模、速度和精细度三者可以按设备联动调整，而不是把玩家扔进一个固定档位。玩家能做的，是理解这三者是同一笔预算的不同写法，改其中一个，另外两个的余量就跟着变。
同样的道理也适用于内存。大发娱乐AI保存的不只是当前状态，还有Agent的记忆与历史，越往后世界越“重”。所以一个刚开局很流畅的大世界，运行数十个模拟日之后开始变慢，并不奇怪，它需要的是定期保存重载或缩小规模，而不是怀疑设备突然变差了。
按症状对号入座
不同的“慢”，指向不同的瓶颈。先辨认症状，再动旋钮。
- 时间推进得很慢，但画面流畅：模拟本身跟不上，问题在活跃Agent数或决策精细度。先缩小规模或降低精细度。
- 画面掉帧，模拟推进正常：瓶颈在渲染而非模拟。此时降低画面相关选项才有效。
- 刚开始流畅，运行一段时间后越来越慢：往往是Agent的记忆和历史记录在累积，占用越来越多的内存。这一类要看内存而不是处理器，可以对照大型城市模拟很卡时的CPU、内存和规模排查。
- 只在某个特殊事件之后卡：例如大规模搬迁、突然扩建。这是一次性的突发负载，事件处理完自然恢复，不必调整设置。
- 倍速拉高才卡，正常速度没事：说明设备的余量刚好够正常速度，属于预期行为，降到能稳定运行的倍速即可。
几种看似有用、其实只是挪了个地方的做法
反复重启App。重启能释放一部分内存，让症状暂时消失，但如果根源是模拟规模和设备不匹配，几分钟后会重新出现。
只降倍速，不动规模。倍速降低后每一步有更多时间，卡顿感缓解，但你等于把“同样的天数要多花时间”悄悄付了出去。如果你的目标是观察长期趋势，比如城市十年的变迁，这个代价往往不可接受，更合理的做法是缩小规模。
把居民数砍到极小。大发娱乐城市AI的很多现象依赖足够的异质性：不同的工作地点、不同的出发时间。居民数量降到一定程度以下，堵车、租金分布这类群体现象会变得过于平滑，看起来流畅，实际上失去了观察价值。比较稳妥的方式是先降到刚好能稳定运行的规模，而不是尽可能小。
一个可以照做的调整顺序
- 先确认症状属于上面哪一类，是模拟慢、画面卡，还是越跑越慢。
- 模拟慢时，先把倍速降到正常速度，判断问题是否只在高倍速下出现。
- 仍然慢，再缩小活跃规模，每次调整一小步，运行几个模拟日观察，而不是一次砍掉一半。
- 越跑越慢时，检查内存占用，保存后重新载入，判断是否是累积性问题。
- 调整之后记录三个数：规模、倍速、每个模拟日的耗时。下次遇到类似问题就有了自己设备的经验值。
最后一条最容易被忽略，却最有用。每台设备的余量不同，通用建议只能给出方向，你自己记下的那一组“规模、速度、耗时”，才是这台设备真正的上限。找到它以后，性能问题就从一个模糊的“很卡”，变成一个可以提前预估的数字。
