推理服務商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，部分場景差距非常大。）
數字怎麼來的
測試硬體是NVIDIA 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；TPS、首字延遲、並發吞吐、token消耗與GPU小時數經Baseten部落格核實。