多智能体服务，和单请求服务不是一回事
一篇 10 月 29 日提交的 arXiv 论文 MAServeBench，想解决一个过去评测很少量化的盲区：当多个智能体协作时，它们不是各自独立的请求，而是把一次用户任务拆成彼此依赖、在不同时间就绪的模型与工具操作。协作规则本身会改变并发、计算和内存需求的形态，从而暴露出只盯单请求吞吐时看不到的瓶颈。论文把多智能体协作当成服务负载的一个可配置维度，用可组合的阶段去捕捉智能体如何协调与交换上下文，再用层级语义轨迹保存真实发生的操作与依赖，以便在同一工作量下做可复现的比较。
它给出的提醒很直白：服务的吞吐效率，不总是等于及时的任务完成。一个系统可以把 GPU 填得很满、把 token 吐得很快，但任务可能因为智能体之间的协调卡住、因为上下文在多个角色间反复交换而迟迟交不出结果。评测若只盯硬件利用率，会高估真实可用度。
两个视角，对不上
把这件事拆成两个视角看会更清楚。服务商那一侧天然看吞吐、看 GPU 与 NPU 的利用率，因为那是他们卖的资源和要优化的指标；用户那一侧只看任务有没有按时完成，卡在协作时序里多久。MAServeBench 的关键价值，是把这两个视角拉到同一张图上——它把负载连到具体的硬件行为，揭示为什么「跑得满」和「交得早」会脱节。
这对选型有现实意义。给多智能体系统挑硬件、定配额，不能只看单卡算力和标称吞吐，还要先看它怎么协作：是层层交接、共享总线，还是中心编排？不同拓扑在并发、内存和上下文交换上的压力完全不同，瓶颈常常落在智能体之间的协调上，而不是落在某张卡上。
这也解释了为什么不少团队的多智能体项目「单机跑得通、上线就变慢」：他们在压测时模仿的多是单请求高峰，而真实流量里占大头的是角色之间的等待与上下文搬运。先把协作拓扑画出来，再决定买多少显存、设多大并发，这个顺序不能反。
仪器本身，不是结论
冷水要写清。MAServeBench 是一套基准与可复现的测量方法，它点出的是方向，不是一份可直接套用的容量公式；论文的具体数字来自它自己构造的协作负载，换一套真实业务流，瓶颈位置可能完全不同。更现实的是，今天绝大多数团队连单智能体的服务画像都没画清楚，先谈多智能体的精细调度为时略早。但它的提醒值得记住：多智能体系统的可观测性，要把「协作时序」当成一等公民，而不只是把每个模型的延迟加起来。
对工程的意思是，先在自家负载上量一量——哪些步骤在等、哪些上下文在反复传、哪一段因为依赖未就绪而空转，往往比再加几张卡更能解释为什么任务交得慢。