推理服务商 Baseten 10 月 2 日发了一篇工程博客：他们用 Claude Code 驱动 Fable 5，让智能体从头写出一套只服务单个模型的推理引擎，在全部测试流量模式下都跑赢了 vLLM。
这套引擎叫 VibeQwen，专门伺候阿里的 Qwen-3.6-35B-A3B。作者 Shawn Rushefsky 在文中写道：
“the generated engine, called VibeQwen, outperformed vLLM across all tested traffic patterns, and by very large margins in some cases” （生成的引擎 VibeQwen 在所有测试流量模式下都超过了 vLLM，部分场景差距非常大。）
数字怎么来的
测试硬件是英伟达 B200，对照组是 vLLM 0.25.1，压测工具用的是 AIPerf。几组结果：
- 单流解码 1792 TPS，vLLM 为 943 TPS，快了约 90%；
- 首字延迟从 28 毫秒降到 12 毫秒，约 2.3 倍；
- 32 路并发下吞吐高出 71%。
成本方面，VibeQwen 前后约一周，消耗约 17 亿 token（大部分命中缓存）、约 200 个 B200 小时，总花费在几千美元量级。
同一套方法他们还在图像分割上试了一次。第二个产物叫 Sammie，服务 Meta 的 SAM 3.1，跑在 H100 上，几天做完，花了几百美元、约 2 亿 token。32 路并发时吞吐比 Meta 官方参考服务器高 50%，达到每秒 91 张图。
智能体在里面干了什么
Baseten 把自家一个叫 MetaInfer 的框架扩成完整的服务栈，交给智能体去填。智能体可以翻阅现有开源方案作参考，每改一轮就用 AIPerf 压一遍，按数字决定下一步。
有一条约束写得很具体：凡是可能改变输出精度的改动，智能体都要停下来请人批准。数值上的细微漂移在推理引擎里最难查，提速一旦以精度为代价，压测榜单上是看不出来的，这一条闸门挡的就是它。
博客自己也划了边界。VibeQwen 和 Sammie 都还是实验品，没有接过生产流量。Sammie 的对比更粗，作者承认那组数字只能算”提示性证据”：两边架构不同、加速器不同，也没做对照测试。
放到国内团队这边看
VibeQwen 的对象是开源的 Qwen 模型，国内大量线上服务恰好也跑在 Qwen 加 vLLM 或 SGLang 的组合上，这组数字跟不少团队的日常直接相关。
可以对照一下两种做法的账。通用引擎要照顾几百种模型结构，很多针对单一结构的激进优化做不进去；专用引擎只盯一个模型，能把注意力内核、MoE 路由、调度策略全部按 35B-A3B 的形状去定。过去写一套专用引擎要一个小组几个月，Baseten 这次把它压到了一周、几千美元，粗算下来比一名推理工程师一个月的人力还便宜。
限制也很明显：
- 引擎和模型绑死。Qwen 一升级，结构有变化，引擎大概率要重新生成一遍。
- 测试只覆盖 B200。国内拿得到的卡型差异大，同样的流程在别的加速器上能不能复现，博客没有数据。
- 生产环境要的长尾稳定性、显存碎片、异常请求处理，压测不一定覆盖得到。
即便如此，“每个主力模型配一套自动生成的专用引擎”的路子已经有了一个可复核的样本。vLLM 的定位会不会因此从”线上主力”退到”基准线和兜底”，要看后续有没有团队把这类引擎真正放进生产，并公开跑上几个月的数据。
参考来源：Baseten 工程博客、CocoLoop；Baseten 博客核验 TPS、首字延迟、并发吞吐、token 消耗与 GPU 小时数。