AWS 说 8GB 内存能塞 7.5 万个 agent：数字没错，但测的不是你以为的那个东西

AWS 开源博客 10 月 23 日发布了一个叫 Infinity 的 agent 运行时，标题数字很抓眼：7.5 万个并发 agent 能塞进一台 8GB 内存的树莓派 5。不少转述直接把它读成了“以后人人都能跑 agent 大军”，先别急着信这个版本。

Infinity 的核心想法本身是扎实的，也是它真正值得学的地方。传统 agent 框架是“阻塞式”的：调模型、等工具、再调模型，agent 等工具返回的几分钟甚至几小时里，进程和内存一直被占着。Infinity 换成“挂起-恢复”：agent 一调工具就把对话存下来挂起，工具结果一到再恢复继续。工具调用要等几天也没关系，中间什么都不用跑，serverless 函数可以直接结束。这是 AWS 和 UC 伯克利 Hydro 项目的合作成果，Apache 2.0 开源。

但 7.5 万这个数字的测试条件要打折看。独立分析指出，实测是在一台服务器级 AMD EPYC 单线程上跑 8 万个 agent、接模拟模型，每个 agent 跑 20 轮、每轮约 1.2KB 的流式输出；空闲 agent 的内存增速约每 agent 100KB，大头是对话历史。也就是说它测的是“记住对话的成本”，不是 8 万次真实模型推理，更不是生产吞吐。真实 agent 一攒工具输出、文件内容、报错日志，单个 agent 的状态很容易到 MB 级——按 1MB 一个算，8GB 也就约 8000 个，还没算系统开销。

所以这篇的正确读法是：别拿 7.5 万去规划你的部署规模，但要把“挂起-恢复”这个设计带走。如果你正在做长耗时 agent（等构建、等审批、等外部回调），把“等工具时不占进程”做进架构，比堆机器更省钱；如果你在评估这类运行时，先问一句：测试里的工具输出有多大、对话历史攒到多长——这两个数，才决定你的真实上限。

可信度：AWS 官方博客口径（10 月 23 日）+ 独立分析对测试条件的拆解交叉；100KB/agent、8 万 agent 均为测试条件口径，非生产承诺。