速评：11 月 4 号 17:59 UTC 挂上 arXiv 的 ServerBench，最扎眼的数字不是那个 4.87 倍，是 22/33。
33 次运行，22 次交出了通过验证的系统。这行被作者写在结果那一段，跟「13 次超过最强基线」并排放着，语气是成绩。
我倒觉得这是整篇摘要里最诚实、也最刺人的一行。
先把这基准要干什么说清楚。它不让 agent 写函数，它让 agent 交一整套专用 LLM 服务：会话之间的依赖得保住，时延约束得顶住，正确性还得验得过，实现层和运维层的决策要一起协调完。这活的交付定义很硬，能跑、达标、验得过，缺一个就是没交出来。八位作者，Zhuoming Chen 提的 v1，736 KB，cs.AI 底下，两天前的事。顺手说一句，现在 arXiv 页面上 PDF、实验性 HTML、TeX 源码、音频摘要入口一应俱全，736 KB 这个体积我点开的时候还愣了一下，33 次运行的完整结果八成全塞在附录表里。
指标设计我得夸一句。美元/美元，每单位 GPU 成本换到的、满足时延条件的 token 价值。干净就干净在它没法靠堆卡刷：多插两张卡，分子涨，分母也涨，分数原地不动。想往上走只有一条路，真去做容量规划和负载取舍。作者三点发现的第一条说的正是这个，高价值的设计是把容量提升和负载选择绑在一起动，不是单点猛推到 benchmark 满意为止。
这个问法比现在市面上那一票 agent benchmark 都难糊弄。那些测试问的是「你会不会写代码」，pass@k 一跑，任务清单打勾，完事；ServerBench 问的是「你能不能把一个系统调到达标，并且证明它达标」。后者更接近真实工作，也更难靠采样次数堆出来。
然后说那个 4.87 倍。Claude Sonnet 5.5 在 Gemma E4B 上拿 2.97，对着 vLLM 参考实现算出 4.87 倍。看清楚，分母是参考实现，不是最强的人工调优。参考实现是起评线，不是天花板。这个区别在传播里一定会被磨掉，磨成「AI 比 vLLM 快五倍」，标题里再添两个字。我不信这圈子里有谁能把这种数字原样传三手。
那 11 次没交出来，我也不觉得是「agent 不行」的证据。系统这活的下限本来就比写代码低：代码写错了编译器当场骂你，系统调错了它不骂你，它只是慢一点、抖一点，你还以为自己调对了。所以论文第三点发现，说要验证优化过程中新引入的执行路径，这不是凑数的套话，这是这份基准跟「agent 完成率 XX%」那类东西的分水岭。有状态回放保住会话依赖，独立验证卡住提交物，11 个模型撒进 3 种部署环境——换环境还成不成，比在一个环境里刷多高有用得多。
三分之二能交付就算好消息，这不是 agent 的体检报告，是行业预期的体检报告。
不过上面那段，我自己也得打个折。我说 22/33 是「最诚实的一行」，反过来也讲得通：作者可能就是把它当卖点在写，系统级任务上三分之二的成功率，听起来已经够唬人。两种解释我都拿不出证据，v1 才挂两天，那个实验性 HTML 版我都没点开看完。这就是写论文速评最难受的地方——能评的只有框架、措辞，以及它选择把哪个数字提到前面；评不了它对不对。真要检验，得等社区把这 11 个模型的配置重跑一遍，可这年头谁等得起一个月？
唯一我敢下死手的是：方法论部分比结果部分值钱。结果会过期，榜单第一的保质期撑不过一个月；独立验证加有状态回放这套谁抄过去都能用。
这里立个 flag：接下来三个月，会有人拿「4.87 倍」当标题，但提 22/33 的一个都不会有。等第一批厂商博客开始把 ServerBench 分数往里塞，这个基准就完成了从评测方法到营销素材的转化——到那时候再翻回今天这版摘要，会觉得它克制得不像话。