Decagon 的 AutoResearch 智能体诊断推理瓶颈、针对生产流量回放测试优化方案，并在多次实验之间保留研究发现。据该公司报告，在端点延迟要求内，通过量化、调度、引擎补丁和投机解码，吞吐量最高可提升 2.5 倍，生产环境的变更需要人工审批。

构建自我改进的推理栈

作者：Pavi Dhiman (@_pavidhiman) 和 Cyrus Asgari (@cyrusasg)

加速推理需要经历诊断、实验和测量的循环。每一次改进都可能暴露新的瓶颈，而每一次实验都会改变下一步值得尝试的方向。在 Decagon，我们构建了 AutoResearch 来执行这一循环：智能体调查服务栈、针对生产流量回放测试变更，并基于先前的发现持续挖掘进一步的提升空间。

推理是 AutoResearch 的早期重点方向，原因有二：

• 搜索空间庞大且因端点而异 → 我们在生产环境中运行十几个模型端点，每个端点都有自己的架构、工作负载、延迟要求和硬件配置。优化之间会相互作用并产生叠加效应，因此为每个端点找到正确的组合需要反复实验，手动优化越来越耗费时间。

• 推理是一个可验证的任务 → 我们可以通过回放相同的工作负载并测量其延迟-吞吐曲线来测试提出的变更。最终，提高每 GPU 每秒成功请求数同时保持在给定的延迟 SLA 范围内，为智能体提供了一个强大的反馈起点，使其能够验证改进并指导下一次实验。

对于已有的模型端点，我们的 AutoResearch 系统会测量现有部署、诊断瓶颈、提出变更，并在 GPU 上运行实验，形成持续自我改进的闭环。其搜索范围涵盖服务参数、GPU 布局、投机解码以及推理引擎的补丁。当发现改进时，它会验证结果，并从新的基线继续推进。

我们在 Devin Cloud 上运行这个闭环，因为推理研究涉及长时间运行的实验和反复的分析。其持久化云会话和预配置环境让我们的编排器能够在各代码仓库之间协调这项工作，同时子智能体并行调查聚焦的问题。[1] Modal 提供 GPU 训练、性能剖析和回放运行的执行环境。

我们的设计围绕两条核心原则展开：

• 构建能够反映生产环境的高保真回放环境

• 构建研究循环以更好地收敛到全局最优解

高保真回放

我们通过在受控负载和生产流量模式下回放生产请求来评估优化效果。回放必须同时复现端点处理的内容以及请求到达的时机。

我们在脱敏 PII 和其他敏感信息之后，从生产日志中重建请求，保留消息结构、系统提示、工具定义、输出 schema 和生成设置。由于脱敏可能改变 token 长度和共享前缀，我们会检查回放是否仍然具有生产环境的代表性，包括影响执行和缓存复用的属性。

然后我们使用两种回放模式：

• 容量测试 → 以递增的到达速率回放请求，每个速率保持数分钟，并随机化请求之间的间隔。这会产生一条作为基线的延迟-吞吐曲线，显示端点在延迟和错误限制内所能承受的最高测试速率。以下是我们基于 post-trained Gemma 4 26B-A4B 构建的其中一个端点：

生产请求回放追踪了负载上升时的 p50、p95 和 p99 延迟。拐点用于指导诊断，容量标记则标识在延迟限制内的最高测试速率。

生产请求回放追踪了负载上升时的 p50、p95 和 p99 延迟。拐点用于指导诊断，容量标记则标识在延迟限制内的最高测试速率。

2. 生产形态测试 → 将生产请求数量或时间戳转换为连续时间间隔内的到达速率，以复现突发流量、持续繁忙期和相对安静的时段。在自动扩缩容场景下，这还能测试部署在突发流量时能否快速扩容，以及在需求下降时能否释放 GPU。受控的合成峰值有助于隔离特定的扩缩容行为。

生产计数定义了每个间隔的目标速率，运行器在遵循这些速率变化的同时随机化单个请求的发送时间。

生产计数定义了每个间隔的目标速率，运行器在遵循这些速率变化的同时随机化单个请求的发送时间。

我们的 Rust 运行器采用开环调度发送请求，不会等待先前的响应完成。当服务器变慢时，流量仍会持续到达，从而暴露负载下的排队情况。

我们将基线回放与生产环境进行验证，比较 token 长度分布、缓存输入 token 比例、请求时序和并发度。仅匹配平均请求速率是不够的，因为请求长度、前缀复用或突发性方面的差异可能改变瓶颈所在，并夸大优化的收益。

容量扫描在引擎预热和每个负载步骤前的前缀缓存重置之后测量可持续流量。生产形态运行则测试容量提升是否能在真实需求下减少 GPU 使用量，允许缓存状态自然演化，并捕捉扩缩容延迟。

候选方案和基线使用相同的请求池、到达调度和延迟要求。在测试变更之前，我们在相同条件下多次回放基线，以测量延迟和服务容量的自然波动。这建立了一个噪声基线，候选方案的改进必须超过该波动并在多次运行中保持稳定，才能被计为收益。

向全局最优收敛

诊断负载增加时的变化

负载曲线显示了性能在何处开始恶化。我们使用多种诊断方法更细致地理解原因，并确定下一步要测试什么：[2]

• 智能体首先检查端点在服务什么以及在哪些方面表现困难。请求日志揭示了诸如长提示词、短响应或重复前缀等模式，生产指标则显示延迟何时上升以及部署如何扩缩容。随后，智能体检查服务配置，找出哪些设置或执行路径能够解释这些行为。

• GPU 性能剖析使我们能够在短时间内记录 CPU 活动和 GPU kernel 执行情况，既展示哪些工作耗时，也展示 GPU 在等待什么。它从两个层面检查 trace：第一个是时间分解，用于识别昂贵的操作，如 attention 或 mixture-of-experts 计算；第二个是执行时间线，展示这些操作如何交互：prefill 是否中断 decode、CPU 工作是否与 GPU 执行重叠，以及 kernel 启动之间的间隙是否导致 GPU 空闲。

针对 Gemma 4 26B-A4B 的 GPU 性能剖析，智能体从中发现性能症状并将其转化为可验证的假设。这些观察引导针对性的实验，以确定哪些变更能改善服务性能。

针对 Gemma 4 26B-A4B 的 GPU 性能剖析，智能体从中发现性能症状并将其转化为可验证的假设。这些观察引导针对性的实验，以确定哪些变更能改善服务性能。

3. 诊断工作负载通过每次改变流量的一个属性来隔离疑似瓶颈。智能体可能在固定输出长度的同时改变提示词长度、比较共享前缀与唯一前缀，或在其他请求解码时引入长提示词。随着智能体遇到不同的工作负载、架构和 prefill/decode 模式，它会不断扩展这套诊断测试。每个可复用的测试都成为一份配方，未来的研究活动可以将其应用到具有类似性能特征的端点。

简化的版本如下：

受控变量，探测目标 更长的提示词，固定输出长度 → prefill 开销 更长的输出，固定提示词长度 → decode 开销 共享前缀 vs. 唯一前缀 → 缓存有效性 生成期间到达的长提示词 → prefill 和 decode 干扰 更高的并发请求数 → 准入和内存限制 突发 vs. 稳定到达 → 排队和扩缩容行为

用子智能体调查相互竞争的假设

我们的 AutoResearch 循环使用一个编排器智能体来协调实验并生成子智能体。父智能体构建回放池、运行上述诊断测试，然后提出 N 个进一步调查的方向，从而启动 N 个子智能体会话。

子智能体通过将详细的调查保持在独立会话中来改善上下文管理，从而让编排器专注于整个研究活动层面的决策。指向这些子智能体会话的摘要和链接使编排器能够在需要时检索更深层的推理。[3]

这还支持对相互竞争的假设进行并行探索，调度、内存和投机解码的研究可以同时推进，每个方向都有一个聚焦的问题和待检验的证据。每个子智能体在独立会话中运行，并由编排器提供明确的上下文启动，包括研究活动标识和实验标识、回放池标识、延迟要求、相关的基线测量、先前的发现以及一个研究问题。

子智能体阅读相关源码、文档、性能剖析结果和先前实验，然后返回包含四个部分的提案：

• 解释： 什么限制了性能，哪些观察支持这一结论

• 干预： 具体的配置变更或引擎补丁，以及按优先级排列的待试配置变更列表

• 预测： 如果解释正确，测量结果应该发生什么变化

• 证伪： 什么样的结果能表明该解释是错误的

子智能体可以提出一系列实验，包括对照组和后续测试。编排器决定这些实验如何融入更大的研究活动，并通过共享测试框架执行它们，使结果成为下一次调查的上下文。

编排器智能体向四个子智能体委派任务，并选择要运行的并行实验。

编排器智能体向四个子智能体委派任务，并选择要运行的并行实验。

这种分工兼顾了探索的广度和深度，因为多个子智能体可以同时调查不同的机制，而父智能体运行可用的实验。有前景的方向会获得更深入的调查，而反复出现中性结果则会促使研究活动探索另一个实验分支。

对于 Gemma 4 26B-A4B，智能体利用 GPU 性能剖析和回放测量确定了四个调查方向：

子智能体调查方向，候选实验 调度与缓存 → 扫描 prefill chunk size 和 prefill–decode 间隔，然后测试前缀缓存复用是否会改变最优调度配置 投机解码与 drafter 训练 → 微调兼容的 drafter，比较受支持的 Draft-OPD 和 D-PACE 训练配方，并联合调整草稿深度和验证设置 Kernel 与量化 → 剖析昂贵的 kernel，测试 CUDA-graph 捕获大小和覆盖率，评估受支持的权重和 KV-cache 精度变更。当性能剖析暴露出 CPU 开销或 GPU 空闲时间时，调查引擎补丁 并行与准入 → 比较张量并行和数据并行布局，测试每个 GPU 上的多个服务实例，并扫描并发上限，以区分准入限制与内存/计算约束

通过共享评估框架运行实验

只有主编排器运行研究活动的实验，因此它通过一个通用框架管理部署、预热、流量生成、测量和评分，并在可用 GPU 容量内调度并发运行。

编排器还会通过将新配置对回放池运行负载测试和自动扩缩容测试，来检查结果是否构成有效证据，以观察负载曲线如何随新优化而变化。

每个完成的实验都会获得一个判定：

判定，含义 更好 → 容量提升超过基线噪声 相同 → 实验未建立有意义的改进 更差 → 性能退化或必需的约束未满足 无效 → 该运行无法支持比较，需要修正

我们区分无损收益（如保持模型输出不变的调度或内存管理变更）和有损收益（可能影响输出质量的权重或 KV-cache 量化）。有前景的结果会经过重复测试，然后由人工审查性能-质量权衡并决定合并哪些变更。

推进有前景的方向，然后寻找下一个瓶颈

取得进展后，循环会继续探索进一步的改进，同时持续测试替代的服务策略，降低过早陷入局部最优的风险。子智能体探索相互竞争的解释，编排器在收益停滞时重新审视替代方案，每次确认的改进都会触发新的诊断。对照组和消融实验检查早期的选择是否仍然有效，从而降低停留在局部最优的风险。

当候选方案满足确认标准后，它成为新的工作基线（原始基线仍作为研究活动总收益的参考）。随后智能体在新的服务限制下重复诊断，重新审视瓶颈所在。

任何进一步的优化都叠加在这个新基线之上，以创造更大的吞吐量提升。然而，独立测量的两个改进可能竞争相同的资源，因此组合候选方案需要对照组和消融实验来确定哪些变更对结果有贡献。

每个改进都成为进一步测试的基线。一个研究活动在 FP8 之上保留了 NGRAM 投机，另一个在后续测试未能建立额外收益后保留了其调度基线。

每个改进都成为进一步测试的基线。一个研究活动在 FP8 之上保留了 NGRAM 投机，另一个在后续测试未能建立额外收益后保留了其调度基线。

最终，当某一方向的反复实验不再产生可测量的收益时，编排器会转向另一个假设。研究活动在到达截止日期或没有更多基于当前发现的实验时结束。它会保存最佳的已确认配置和所有未解决的问题，以便未来的工作从中继续。

完整闭环

系统将决策与评估分离：

• 外层研究循环 决定调查什么：编排器诊断瓶颈，将聚焦的问题委派给子智能体，并从其提案中选择实验

• 内层评估循环 在相同的工作负载和延迟要求下测试每个候选方案，通过增加负载来测量配置如何改变服务容量。

每个结果都为下一个决策提供信息，不成功的实验会完善或否定一个假设。有前景的实验进入重复测试、正确性检查和生产形态回放。确认的改进成为新的工作基线，在新的服务限制下触发另一次诊断。共享记忆在各迭代和端点之间传递发现，而生产部署仍然需要人工审查。

完整的 AutoResearch 循环，结果进入共享记忆，而生产部署仍需人工审查。

完整的 AutoResearch 循环，结果进入共享记忆，而生产部署仍需人工审查。

投机解码