65%和34%：Decagon让Agent在生产流量回放里调推理栈

Decagon 公开了一套叫 AutoResearch 的系统。它把推理优化拆成诊断、实验、测量，再让 Agent 循环执行。SGLang 官方转推提到，这套系统已经用在 Decagon 的推理栈里。原文作者是 Pavi Dhiman 和 Cyrus Asgari，全文在这里，SGLang 的转推在这里。

Decagon 在线上服务十几个模型端点。每个端点的架构、负载、延迟要求和硬件配置都不同，优化之间还会互相影响。手动一项项试，成本越来越高。推理又正好是可验证任务：同一个负载重放一遍，量延迟吞吐曲线，看每 GPU 每秒成功请求数是否在 SLA 内提升，Agent 就能拿到明确反馈。

AutoResearch 的循环不复杂：先测当前部署，诊断瓶颈，提出改动，在 GPU 上跑实验。搜索范围包括 serving 参数、GPU 布局、投机解码和推理引擎补丁。找到提升后先验证，再把结果变成新基线，继续找下一个瓶颈。系统跑在 Devin Cloud 上，GPU 训练、profiling 和回放由 Modal 提供环境。

两个设计原则撑起这套东西：回放要足够像生产，研究循环要尽量收敛到全局更优。回放请求从生产日志重建，先做 PII 脱敏，但保留消息结构、system prompt、工具定义、输出 schema 和生成参数。脱敏会改变 token 长度和共享前缀，所以还要检查回放是否仍能代表生产。

回放分两种。容量测试把请求按递增到达率打进去，每个速率保持几分钟，并随机化请求间隔，画出延迟吞吐负载曲线，找延迟和错误限制内能撑住的最高测试速率。生产形态测试把生产请求数或时间戳转成逐区间到达率，复现突发、持续繁忙和空闲段，顺便测自动扩缩容在突发时加容量够不够快、需求下降时会不会释放 GPU。

执行器是 Rust 写的，按开环调度发请求，不等前一个响应结束。服务器变慢时流量继续到，队列压力就会暴露出来。基线回放要和生产的 token 长度分布、缓存输入 token 比例、请求时间和并发对上。只匹配平均请求速率不够，长度、前缀复用、突发性一变，瓶颈就会变，优化收益也可能被高估。

诊断靠日志、生产指标、serving 配置和 GPU profiling。Profiling 既看时间分解，找出 attention 或 MoE 计算这类昂贵操作，也看执行时间线，判断 prefill 是否打断 decode、CPU 工作是否和 GPU 重叠、kernel 启动间隙有没有让 GPU 空转。诊断 workload 每次只改一个流量属性，比如固定输出长度改提示长度，比较共享前缀和唯一前缀，或在 decode 时插入长提示。跑过的测试会沉淀成 recipe，复用到性能特征相似的端点。

编排上有一个 orchestrator agent 和多个 subagent。父级建回放池、跑诊断，然后拆出 N 个方向，开 N 个 subagent 会话。每个 subagent 拿到活动标识、实验标识、回放池标识、延迟要求、基线测量、历史发现和一个研究问题。它读源码、文档、profile 和旧实验，返回四部分：解释哪里限制性能，干预要改哪项配置或引擎补丁，预测指标会怎么变，以及什么结果能证伪。

只有 orchestrator 跑正式实验。它统一管部署、预热、流量生成、测量和打分，并在 GPU 容量内调度并发实验。结果分无损和有损。调度、内存管理这类不改模型输出的算无损；权重或 KV cache 量化可能影响质量，算有损。有希望的候选要重复测试，再由人看性能和质量取舍，决定是否合入。

一个提升确认后，它成为新的工作基线，原始基线继续作为整轮活动总收益的参考。Agent 在新 serving 极限上重新诊断。两个独立测出的优化可能抢同一份资源，所以组合候选要做对照和消融，确认到底是谁贡献了结果。一个方向反复没有可测收益，orchestrator 就换假设。活动到截止时间或没有更多有证据支持的实验时结束，保存最佳配置和开放问题。

投机解码是单独阶段。目标是让 drafter 适配微调后的 target model，并针对生产负载特化。可选起点包括 MTP heads、DFlash、DFlash2、EAGLE 和 DSpark。Decagon 在 Gemma 端点上发现，现有 DFlash2 drafter 的 served acceptance length 比生产 MTP head 高约 17%，继续训练又比这个起点 drafter 高 14%。训练数据会覆盖任务、提示和输出长度、语言、对话阶段、工具使用和结构化输出；难例按 drafter 预测 target 输出的表现加权；rollout 会把 target 拒绝的位置拿来监督；采样密度和 D-PACE 这类权重方法也通过实验判断。

护栏包括并发 GPU、时间和 GPU 小时限制，训练变体数量限制，新代码先过 CPU 检查和 50 步 GPU 排练，回放负载、延迟限制和正确性要求固定，serving 池不参与训练和 checkpoint 选择。确认的收益生成部署 PR，人审质量取舍后再上生产。

共享记忆存在版本控制文件里。端点内记忆避免重复跑已经失败或中性的改动；跨端点记忆记录瓶颈、技术、模型、硬件、负载和引擎版本，把相似约束下的发现翻出来。它还会保留分歧：投机解码在某些端点有用，在另一些端点有害，两个结果都留着，下一轮去找解释差异的条件。

结果上，AutoResearch 在量化、kernel 选择、调度、GPU 执行、拓扑和投机解码上都找到过收益。Gemma 部署里，调 prefill-decode 区间让回放容量最高提升 65%；为 select-playbook 端点适配 DFlash2 drafter，让吞吐相对生产 drafter 提升 34%。原文有一张结果表，按各端点生产延迟要求列 requests/s/GPU 增益，基线是 SGLang 默认或 Decagon 当前调优配置。

原文配了负载曲线、生产形态回放、GPU profiling、子 Agent 编排、完整循环和结果表，建议对照看：AutoResearch 全文。回复里还有读者追问：为什么不让 subagent 自己跑实验，subagent 和实验结果之间有没有来回；回放噪声里有多少来自 LLM 输出不确定性，SGLang 的确定性 kernel 能不能帮上忙。正文没有直接回答这两个问题，但它们是这套系统下一步值得盯的细节。