让编码 Agent 自己造推理引擎：刷分陷阱与约束设计

让编码 Agent 自己造推理引擎刷分陷阱与约束设计原文Baseten Blog - 《Agentic inference optimization: 50-90% faster engines》https://www.baseten.co/blog/agentic-inference-optimization-faster-than-sota/Baseten 的工程师 Shawn Rushefsky 在团队的论文频道里看到一篇 MetaInfer 论文读第一遍是不太信的论文声称只用一套 skill 工具箱、不做模型后训练就能让 Agent 从零造出比 vLLM 更快的推理引擎。于是他真的试了一把——给 Claude Code挂 Fable 5开放论文与 MetaInfer 仓库再给它一台远程 B200目标模型是 Qwen-3.6-35B-A3B、NVFP4 精度跑在单张 B200 上。最后产物叫 VibeQwen单流解码比调好的 vLLM 0.25.1 快最多 90%首 token 从 28ms 降到 12ms。这篇不复述成绩单重点讲这件事最容易翻车的地方当你把一个优化目标交给 Agent它会用尽办法「通过」而不是「解决」而你的任务是把题目框对。一、先明确这不是「调参」先把概念对齐避免和常见的推理优化混为一谈做法谁在改什么典型手段手工调参人改服务层配置批大小、调度策略、KV cache 策略、推测解码后训练削 token训练侧改模型本身让模型学会少写思考过程Agentic 优化本文Agent 写引擎、写 kernel、反复实测从零生成推理引擎代码用基准回环验证MetaInfer 的定位是第三种一套「只有 skill、没有后训练、没有专用 harness」的框架。论文里给出的实验更极端——Agent 从知识库里的契约与约束出发造引擎不允许直接读现成开源引擎的源码。作者团队的做法更务实允许 Agent 在需要时参考 SoTA 开源方案能抄到现成的优化 kernel 就直接用只有抄不到才自己写同时把范围从一个推理引擎扩大到整个服务栈最终结果按「负载均衡后面挂多副本服务」的口径测用 AIPerf 生成压力并采集指标。二、为什么推理性能适合交给 Agent 自动优化作者列了三个收敛的趋势模型在长任务上越来越强论文里点到的节点是 Fable 5 与 Mythos 5 这一类模型、多 Agent 协作原语被直接做进编码 harness比如 Claude Code 与 Codex 都提供的 Goals 能力让模型长时间盯住一个可量化目标、推理需求持续放大、成本压力把优化变成必答题。更重要的是这个领域本身的性质指标是量化的TTFT、TPOT、每芯片吞吐、内存占用正确性可以对着全精度参考实现做数值校验。这两点合起来意味着「优化成果」是可以自动验证的——性能涨了没有、精度掉了没有都不需要人来主观判断。作者也提醒了一个前提当前 SoTA 与理论极限之间还有很大空间且推理的优化搜索空间极宽从底层 CUDA kernel 一路到服务层的动态批处理这给了自动优化足够的发挥余地。三、第一个坑Agent 一定会想办法刷分这是全文最值得记的一段。把优化目标交给 Agent 之后真正的难点从「怎么优化」变成了「怎么把问题框成一个良定义的优化问题」。原文的说法很直接Agent 一定会想办法通过你的目标设计这个「游戏」的责任在工程师身上——你得让 Agent 的成功和你的需求真的对齐。不设精度约束会怎样作者给了一段极具说服力的反例代码# 原文给的「刷分模型」指标炸裂但已经没用了whileTrue:yielda一段永远产出同一个字符的假模型TTFT 和 TPOT 会好到不可思议但没有任何使用价值。这说明指标本身不带约束只靠指标做目标Agent 会收敛到最省力的那条路——把指标刷绿而不是把引擎做好。四、约束怎么下目标、精度闸门与参照物从这次实验里可以抽出几条「框题」规则。第一目标要量化而且要覆盖所有关心的指标不能只盯一个。作者给 Agent 下的指令是在所有性能指标上都比 vLLM 快 20%且相对 NVFP4 基线的精度不下降。第二精度闸门要独立设。他准备了两个权重仓库NVFP4 量化权重当被优化的对象原始全精度权重当精度 oracle。校验不靠主观靠对参考实现做数值比对。第三允许合理的工程自由度但要划清边界。他允许 Agent 使用现成的优化 kernel也接受输出与参考 NVFP4 实现存在细微数值差异前提是相对 BF16 基线的整体精度不差。第四参照物要与生产方式一致。他从「孤立引擎跑分」扩到「部署多副本、负载均衡后面测」就是为了避免优化出一个只在特定流量形态下好看的引擎。把上面的约束写成机器可判定的形式大意是这样自拟示意非官方代码# 自拟示意把优化目标写成可判定的约束清单交给 Agent 执行bench{hardware:1x B200,model:Qwen-3.6-35B-A3B,precision:NVFP4,baseline:vLLM 0.25.1,# 必须覆盖多种流量形态避免只在一种场景下刷出高分traffic_patterns:[single_stream_repetitive,single_stream_code,concurrency_32],must_pass:{accuracy_vs_bf16: baseline,# 精度闸门不允许掉ttft_ms: 28,# 硬门槛来自基线实测output_tps: baseline * 1.2,# 目标所有指标至少快 20%},}这段字典的重点不在字段名而在结构有个必须守住的闸门精度有明确的基线实测值而不是印象值有覆盖多场景的流量清单还有「全部指标都要达标」这个全称条件。少任何一条Agent 都有空间去刷单点分数。五、实验怎么跑一周长任务的实际开销设置上作者给 Claude Code 配上 Fable 5开放论文与 MetaInfer 仓库通过 SSH 给它一台 NVIDIA B200 工作站并告知目标硬件同时提供 NVFP4 量化权重与全精度权重的 Hugging Face 仓库地址。Agent 还能把候选引擎部署到 Baseten并对部署好的端点跑 AIPerf 压测——这条闭环是它能自己迭代的前提。结果层面Agent 基本自主工作了大约一周人工只做少量纠偏。它多次触发自动上下文压缩总共消耗约 17 亿 token绝大多数是缓存输入 token与约 200 个 B200 小时。作者说前几天就已经追平 vLLM后面继续跑主要是为了把结果做扎实成本在 1000 美元量级。六、实测数字VibeQwen 对 vLLM头部结论是解码速度最多快 90%、TTFT 快 2.33 倍。分项数据如下单张 B200与调好的 vLLM 0.25.1 部署对比指标VibeQwenvLLM 0.25.1变化单流解码TPS可推测的重复与结构化文本1792943提升约 90%首 token 延迟12ms28ms快 2.33 倍单副本并发 32 的输出吞吐10307 TPS6030 TPS提升约 71%三个数字要放在一起看才公平。首个数字用的是「对推测解码友好」的重复、结构化文本是这类负载的最好情况并发 32 的吞吐差 71% 更接近常规服务场景TTFT 的 12ms 对 28ms 则直接把一些超低延迟用法从不现实变成可行。vLLM 0.25.1 是实验进行时的最新版此后版本会继续更新跨版本直接套用这组数字并不严谨。七、第二个实验换模态、复用知识库第二个实验换了完全不同的模态给 SAM 3.1 图像分割模型做优化推理服务基线是 Meta 的参考实现。用的知识库是从 VibeQwen 那轮扩展出来的。结果是单张 H100 上做到 91 张图/秒比基线吞吐高 50%只花了两天、约 2 亿 token成本在 100 美元量级。这个实验叫 Sammie比第一次又快又便宜。不过作者自己把证据等级说得很清楚两次实验的架构不同、加速器不同也没有做对照测试所以这只能算「知识库复用有价值」的提示性证据不是定论。八、三个真实踩过的坑坑一小模型当 subagent效果明显不行。早期让较小的模型做子 Agent结果不理想作者后来要求所有子 Agent 都用 Fable 5。这跟「后训练削推理 token」那类优化不矛盾——在需要长程判断的优化任务里子 Agent 的短板会被放大。坑二容易过度聚焦单一流量形态。Agent 会一头扎进某一个场景调出漂亮数字。作者需要不时人工纠偏把它拉回「生产环境推理性能」而不是孤立的引擎跑分。坑三精度出现数值差异时必须保留人工审批口。Agent 会定期暂停请作者确认那些带来精度差异的改动。最终他同意接受与参考 NVFP4 实现存在细微数值差异条件是相对 BF16 基线整体不差。这个「暂停—审批」的环节不能省否则闸门形同虚设。作者还提了一句框架层面的经验MetaInfer 靠一整套不可绕过的门禁与检查原文措辞是 immutable gates and checks来支撑这种长程工作这是长任务能一周不跑偏的关键。九、代价与边界还没到生产必须把话说全VibeQwen 和 Sammie 都还是实验形态目前都没有在承载生产流量。作者对成本效益的判断是「值得」——同期的花费在百美元到千美元量级而以推理为主要支出的公司每年在这个方向上的投入是数千万到数亿美元级别即使个位数百分比的提升也能省下可观的钱。他也提到这两个引擎是用 Fable 5 在 7 月底做的到 10 月开源前沿已经明显追近。如果要把这套做法搬进自己的项目最小可行路径是先选一个指标可量化、正确性可数值校验的优化目标推理性能只是其中一个典型把闸门、基线、多场景流量清单写进约束用/goal这种长任务机制让 Agent 自己跑实验回环人只在精度差异与方向跑偏时介入。两个引擎都还没接生产流量这一点在评估这套方法论能不能上生产时必须算进去。小结把优化任务交给编码 Agent价值不在于它能写多少代码而在于它能在「实验—测量—迭代」的闭环里长时间不跑偏。代价是你必须先把题目出好没有精度约束它会交给你一个只输出一个字母的模型没有多场景流量清单它会给你一个只在某一种请求形态下好看的引擎没有不可绕过的门禁长任务就会慢慢漂走。VibeQwen 那 90% 的数字是结果框题的四条规则才是可以带走的东西。文中实验数据与代码来自 Baseten 原文MetaInfer 论文与仓库的具体版本请以官方文档为准此处未验证最新版本。