多轮 Agent 场景下，滴滴的 EAGLE-3 训推加速实践

过去两年，大语言模型（LLM）的应用形态从 ChatBot 快速演进为 AI Agent。在自动化代码工程、长文档分析、多轮工具调用等复杂工作流中，上下文长度已从千级 token 扩展至数十万级；与此同时，LLM 的自回归生成具有强串行特性，导致延迟和吞吐成为制约用户体验与成本的核心瓶颈。

围绕这一问题，本文基于开源投机采样框架——SpecForge，介绍滴滴在多轮 Agent 场景中对 EAGLE-3 训练与推理的实践。在训练侧，针对 EAGLE-3 在长序列场景中的显存与通信瓶颈，引入统一序列并行（USP），使得在大规模集群上训练 128K 乃至更长上下文成为可能，现已将相关能力贡献至 SpecForge 开源社区；推理侧，相较 MTP 方法，EAGLE-3 在长序列场景中可实现超过 2 倍 的 TPOT（Mean/P95）收益。上述训练与推理优化，已在实际业务场景中得到验证。

在传统 Chat 场景中，交互以短问答为主，用户对秒级延迟具有一定容忍度；而在 Agent 场景下，执行流程演进为“思考—行动—观察—再规划”的多轮循环，包括读取上下文、生成思考 token、调用工具并基于反馈持续迭代。这样的循环结构会使推理延迟被不断叠加与放大。

以一个直观示例来看：如果模型生成速度是 20 tokens/s，一个包含 500 tokens 的“思考过程”就需要 25 秒，若一个任务包含 10 轮类似循环，仅“思考”就可能达到分钟级。在对实时性要求较高的场景中，这样的延迟难以被接受。

解码阶段通常属于典型的 memory-bound 场景，每生成一个 token 都需要执行一次前向计算，并伴随对显存的高频访问（包含权重访问与 KV cache 读写等）。与此同时，自回归的顺序依赖使得整个生成过程难以并行优化，使得推理呈现“逐 token 串行执行”的特征。

因此在实际执行中，每生成一个 token 都对应一次高成本的前向计算与显存访问开销（权重 + KV cache），直接推高了基础 TPOT；在多并发或多卡环境下，由于部分 decode step 存在排队或同步等待现象，还会进一步拉高 TPOT 的 P95/P99，从而放大长输出请求的端到端长尾延迟。

投机解码可以理解成：先用更便宜的方式写草稿，再让大模型一次性批改；在验证过程中，单次可被接受的 token 越多，推理就越快。其本质价值在于减少 Target 模型的验证 step 数量，使 TPOT 的均值与尾部延迟同时下降，实现整体推理加速。

图 1：投机采样的两阶段流程（Draft → Target 一次验证接受多 token）  

具体来讲就是：

• Draft：生成一段候选 token

• Verify：Target 一次前向整体校验

• Accept/Reject：通过的直接输出，失败则回退重来

在 Agent 长上下文场景中（如工具调用、多轮链式推理、结构化输出），高熵片段通常更为密集，表现为前序一步偏差，后序往往整段作废，导致 Draft 生成序列的 Accept Len 容易骤降，加速效果会明显波动，甚至“越长越不赚”。

业界普遍认为，投机解码的加速效果主要取决于两个因素：Draft 的生成成本，以及 Accept Len 的长度与稳定性。换言之，关键不在于“有没有 Draft”，而在于 Draft 能否以较低的成本，持续生成可被稳定接收的长序列草稿。

表 1：投机采样方法对比

我们对比了不同投机路线（见表 1）。在 Agent 场景里，长上下文（64K/128K+）是常态：工具调用历史、长链路推理、代码/文档混合输入都会把序列拉长。只用 2K/4K 训练会导致上线后高熵段频繁掉链子，Accept Len 变短且波动，加速难以稳定兑现——因此长序列训练是前置条件。

在这个前提下，对比各类投机路线（见表 1）：model-free 复用依赖重复性，高熵段命中率下降快；独立小 Draft/多头预测在长链路里误差更易累积，Accept Len 往往随上下文变长而衰减。所以我们选择训练 EAGLE-3：用 TTT 等机制按真实推理流程对齐训练，让长上下文下的连续放行长度更稳，从而把推理加速真正落到业务场景。

在将 EAGLE-3 用作投机解码方案后，训练阶段会出现一个反直觉现象：序列长度达到 16K+ 时便开始 OOM。按照常规 SFT 的经验，这一现象并不符合预期——以约 1.5B 规模的 Draft 模型为例，在 batch=1、未开启 checkpoint 的情况下，16K 序列的单卡显存占用通常在约 30GiB 左右，在 80GB 显存卡上仍应有较大余量。

这一差异的关键在于 EAGLE-3 训练目标的“双重性”：即：不只是“把 token 拟合好”，还需要拉长可连续接收的长度，为此，EAGLE-3 改变了训练形态。要理解显存为何突然变重，需要从其两个核心设计出发进行分析。

3.1 多层特征融合：条件更强，状态也更多

EAGLE-3 并不是简单放大 Draft，而是增强它的输入条件。在生成候选 token 时，由于不同层级承载的信息粒度不同，Draft 会融合 Target 的低层 / 中层 / 高层特征，而不是只使用最后一层 hidden state。

• 低层：局部形式、短程线索

• 中层：结构与模式

• 高层：语义与决策信号

通过多层信息融合，可以提升多步预测的稳定性，使 Draft 更容易生成“连续可被接收”的高一致性草稿。但这一设计在工程上带来的代价也较为直接：

• 需要保留多层特征参与计算

• 反向传播时需要保存更多中间激活

相比传统 SFT 仅依赖单层表示的方法，这种多层特征参与会显著增加激活存储与反传计算开销，且该开销随序列长度增长而进一步放大。

3.2 TTT：把推理流程搬进训练

更大的显存压力来自 TTT（Training-Time Test），即在训练阶段引入推理过程。传统训练通常以 ground truth 历史 token 作为条件，而在真实推理中，Draft 只能基于自身刚生成的历史继续生成，这会导致训练-推理分布不一致：训练阶段 Step1 模型始终接收“干净输入”，而推理阶段 Step2 则需要在“带误差的历史”上持续生成。一旦前序预测出现偏差，误差会逐步累积，后续 token 更容易被拒收，导致 Accept Len 快速下降。

为缓解这一问题，EAGLE-3 在训练阶段引入 TTT 机制（见图 2），按照真实 decode 流程展开：先生成一步预测，再将该预测作为下一步输入，多步递进，从模拟真实推理过程。通过这种方式，使训练与推理形态保持一致，让模型在训练阶段即适应“带误差历史”的输入环境，从而在推理时获得更稳定的连续接收能力。

3.3 显存为什么会OOM？

直观来看，Draft 模型规模并不大，但由于 EAGLE-3 的训练形态不同于常规 SFT，其显存开销来源也发生了变化：除了与参数规模相关的基础开销外，更主要的消耗来自“中间状态”与“训练展开步数”。可以将这两部分理解为两层“放大器”。

放大器 1：多层特征参与训练（激活存储增加）

EAGLE-3 的 Draft 会用到 Target 的多层特征，这会带来更多输入状态与中间表示。在 offline 训练中，这体现为更多 hidden states 的加载、缓存与搬运成本；在 online 训练中，还会叠加 Target 前向生成特征的显存与调度压力。真正反向传播的主要压力仍集中在 Draft/Fusion 路径及 TTT 多步展开产生的激活上。随着序列长度增加，这部分激活占用也会更快增长。

放大器 2：TTT 的多步展开（k 倍计算与中间态）

普通 SFT 基本是“一次前向算完 loss”。而 TTT 则是在训练中模拟推理 decode：如果需要连续预测 k 个 token，就需要将过程展开 k 次（每一步基于上一步的预测继续向后计算）。由于反向传播需要保存每一步的中间结果，显存开销会近似按 k 倍放大。当序列长度 L 也很大时，两者会叠加形成乘法效应：每一步本身就因为 L 很长而“很重，再叠加 TTT 的展开步数 k，最终出现“16K+ 就触发 OOM”的现象。

一句话总结：EAGLE-3 的显存问题来自<长序列 L × TTT 展开步数 k × 多层特征带来的额外中间态>的叠加，而不是 Draft 参数量本身。

4.1 EAGLE-3显存墙的实质：“中间状态”

在 64K / 128K 级别的长序列训练中，显存的主要消耗来自“中间状态”，包括 attention 的中间激活（如 softmax 相关中间量、Q/K/V 张量等），以及反向传播必须保留的激活，包括 EAGLE-3 特有的多层特征参与训练所带来的额外激活存储，与 TTT 多步展开引入的 k 轮中间态堆叠。这类开销的共同特点是会随着序列长度 L 快速增长，并在 TTT 场景下近似按 k 倍进一步放大。因此，即使 Draft 参数量本身并不大，长序列训练也会很快撞上显存墙，其瓶颈并不在参数规模，而在“激活与 attention 中间状态”。

4.2 显存墙：128K 下单卡训练无法启动

当序列长度扩展到 128K 时，瓶颈主要来自 attention 和激活等中间状态，而非参数规模本身。在此基础上，再叠加第 3 节中的多层特征与 TTT 多步展开机制，显存开销会随 L×k 快速放大，使得单卡难以稳定启动训练。不同并行方式在长序列场景下的作用边界如下：

因此，要让长序列训练可行，必须引入序列并行（Sequence Parallelism, SP），在 token 维度对激活与 attention 中间状态进行切分。接下来我们将进一步说明，为什么需要通过 USP 将 SP 进一步做到“既能跑、又能快、还要稳”。

4.3 为什么进一步需要 USP：不仅要能切，还要切得快、切得稳

序列并行（SP）虽然降低了显存占用，但在扩展到更长序列时仍面临两个关键限制：其一是更高的通信频率，序列切分越细，跨卡数据交换越频繁；其二是更高性能的算子，attention 的实现方式直接影响整体吞吐与显存开销。

综合这两方面因素，我们采用 USP（Unified Sequence Parallelism），在统一框架下组合序列并行策略，兼顾显存切分与通信/算子效率，将长序列训练从“可启动”进一步提升为“可规模化”。

我们为 EAGLE-3 实现了 USP，将注意力计算拆分为“主干（main）+ TTT 分支（branch）”两条路径：主干部分采用 ring attention 进行分布式计算，分支部分在本卡完成增量更新，最终通过 LSE 进行数值一致性融合。该设计一方面将显存压力按序列维度分摊到多卡，另一方面保证了训练过程的稳定性，使 Accept Len 不受影响。

基于这套实现，超长序列训练从“无法启动”推进到单机 8 卡即可稳定支持 128K 上下文；在此基础上，进一步提升上下文长度时，也可以通过扩展 SP 规模（横向增加卡数或机器数）实现持续扩展。

5.1  USP：把 Ulysses（按 head 切）+ Ring（按序列切）组合起来

在 EAGLE-3 的长序列训练中，显存压力主要来自两个方面：一是序列长度 L 很大，使得 attention/KV/及激活等中间状态随之快速增长；二是 TTT 需要进行多步展开，使整体训练开销近似再乘以 K。在这种 L×K 的设置下，单一并行方式通常难以覆盖全部瓶颈，因此我们引入 USP，将两种互补的序列并行方式统一到同一条 attention 计算路径中。

• Ulysses：按 head 维度切分（All-to-All 重排），将 attention 计算分摊到不同 head 上，使吞吐更容易提升；但由于切分粒度受 head 数限制，在序列较长时，显存开销更多来自序列相关的中间状态，仅依赖 head 切分难以完整覆盖。

• Ring：按序列/token 维度切分（ring attention 通信），将随序列长度 L 增长的 KV/中间状态按 token 分布到多卡，从而使显存可随 SP 规模近似线性下降；但其代价是通信更频繁，因此要在算子与通信编排上做好优化，才能兼顾性能与稳定性。

USP 的核心作用在于将两者统一协同：由 Ring 负责将长序列训练的显存压力“托住”，由 Ulysses 提升并行计算效率，同时结合后续的要介绍的“主干 / 分支解耦 + LSE 融合”机制，保证在分布式切分条件下 EAGLE-3 的计算规则与数值口径依然一致。

这类 USP/SP 在社区中并不是全新概念，已有不少开源实现与工程实践，不同框架和 attention kernel 在实现路径上也各有取舍。因此重点并不在于“重新定义 USP”，而在于如何让 USP 真正适配 EAGLE-3 的训练形态（TTT + 分支结构 + 训推一致性），并在工程层面真正跑通 128K 级别的长序列训练规模。

5.2 难点是什么：TTT 不是一条线，而是“主干 + 分支”的树状可见性

当前的USP 实现中，默认 attention 是一张标准的 causal attention（下三角），即第 t 个 token 只能看 [0..t-1]。只要是这种线性的因果结构，序列切分与通信/归一化的规则都比较固定。但在 EAGLE-3 里，TTT 的关键动作是：训练时不再只依赖 ground truth 历史，而是让 Draft 先前向生成一段 token（对应的 hidden state 也随之产生），再将这些“自生成的历史”用于下一步训练。

也就是说，Step2/Step3 在训练时会真实“吃到” Step1 的预测输出，而不是永远站在干净真值上。

当这种“自生成历史”被引入训练输入后，整体计算图的结构也随之变化（如图5）：除原有的主干线性因果链外，还会额外形成由 TTT 展开带来的分支路径。对应到 attention mask 上，也不再是简单的下三角结构，而是“主干 + 若干由展开产生的额外块”的组合形式。

这正是问题所在：常规 USP 默认的 mask 假设被打破，无法将其当普通 causal attention 直接做序列切分与融合，否则在分布式切分后出现口径不一致（该看的没看到 / 不该看的看到了），进而影响训练稳定性与最终 Accept Len 表现。

5.3 我们的方法：在 USP 分布式 attention 中“先分支、再融合”

如第 3.2 节图 2 所示，TTT 的作用是让训练过程更接近推理过程，从而缓解长序列下的 train/test mismatch，使 Accept Len 更稳定。这里不再展开图 2 的细节，但需要强调其对工程实现的关键影响：一旦引入 TTT，训练阶段的 attention 结构不再是标准的 causal attention（三角形），而会演化为“主干 + 分支”的组合结构。也正因为这一结构变化，许多现成的 USP/SP attention（默认仅适配标准 causal mask）无法直接复用到 EAGLE-3 上，问题不在于并行切分本身，而在于如何正确计算分支部分，以及如何在主干与分支之间保持一致的归一化与融合口径。

顺带回答一个常见问题：为什么其他投机解码方法较少使用 TTT？它们是否不存在 train/test mismatch？实际上，这类方法同样存在不同形式的 mismatch，只是“表现形态”与“处理方式”不同（可参考表 1）。例如 MTP 通常在一次前向中直接生成多步候选，后续步并不会经历“生成—作为新条件输入—继续生成”逐步的自回归更新，因此一旦早期 token 出现偏差，后续更容易出现连锁放大。工程上通常会将有效步长控制得较短，并通过校验/回退机制降低风险，但也因此限制了整体加速收益。

本质差异在于：这类方法通常不会像 TTT 一样将“连锁误差”提前暴露到训练过程，从而让模型在训练阶段就学习如何在“带误差历史”下维持更长的稳定接收长度与更高的 Accept Len 稳定性。

基于这一训练形态（如图 6 所示），我们在 USP 分布式 attention 中采用“先分支、再融合”的解耦计算方式，整体分为三步：

• Step 1：主干（Main）沿用 ring attention（causal attention）。将主干历史按 token 分片分布到多卡，通过 ring 通信完成主干的 causal attention 计算，得到主干输出 Out_main 以及用于后续融合的归一化统计量 LSE_main。

• Step 2：分支（Branch）在本卡完成增量更新。这里的关键在于，TTT 分支更像是“局部增量”，仅涉及少量新增 token 的 KV（TTT 步数通常在 7 以内），而单卡在 SP 下承担的主干序列分片往往达到万级 token，两者量级差异明显，因此无需通过 ring 跨卡补齐历史，可以直接在本卡完成点状或块状的增量计算，得到分支贡献 Out_branch 及其统计量 LSE_branch（或 step-wise LSE）。

• Step 3：Fusion（流式 softmax 融合），将分支结果作为增量并入主干，并保证 softmax 归一化口径一致。具体做法是采用“流式 softmax”（类似 FA 的分块归一化），在每次引入分支增量时同步更新整体归一化统计量，并将 Out_branch 按对应权重并入 Out_main（实现上用 log-sum-exp/LSE 保持数值稳定）

  直观来看，并不是先汇总所有项再统一做归一化，而是在引入分支增量的同时持续维护归一化过程，从而得到与整体 softmax 等价的结果，同时避免额外的全局同步开销。一句话总结：主干通过 ring 机制解决“长序列可计算”的问题，分支利用“无需通信”的特性在本地进行增量更新，最终通过流式 softmax 融合，保证结果能够正确合并且归一化口径一致。

5.4 为什么这能解决“长序列训不动”：显存、稳定性、吞吐三件事一起兼顾

这套 USP 设计带来的效果主要体现在三个方面：

• 显存可控：通过在序列维度进行分片，每张卡仅需保存 1/SP 的主干 KV 与中间态；

• 训练更稳：借助 LSE 融合保证分布式切分下归一化口径一致，使计算规则正确，从而避免 loss 漂移，实现训推一致，并维持 Accept Len 的稳定；

• 吞吐更高：将最重的主干计算交由高效的 ring attention 路径处理，而分支部分采用轻量级增量更新，避免将稀疏分支按致密矩阵计算与同步，从而提升整体执行效率。

5.5 进一步补齐长序列 offline 训练的三块“工程地基”

(1) 输入与 loss 计算都按 SP 分片：显存随卡数近似线性下降

在长序列 offline 训练中，最容易踩的坑是：先将 hidden states / targets 整段加载到 GPU，再在算子内部做切分，这会导致即使开启 SP，显存峰值依然难以下降。我们将“切分”前移到数据入口，offline dataset 通过 mmap 读取 hidden states，每个 SP rank 仅加载自身对应 token 分片，同时 loss/metric 的归约也按 SP 口径处理。这样显存压力从“单卡扛全序列”变为“多卡分摊序列”，显存占用随 SP degree 基本线性缩放，使长序列训练具备真正可扩展性。

(2) 统一训练口径：将 backend 差异收敛到 adapter

如果 USP / 非 USP 路径长期分叉，最容易在 loss/metric 归约、step view、position_ids 等细节上出现隐性不一致，并在长序列场景下被放大为可见偏差。为此我们引入 adapter 抽象层，将 step view、分布式 loss/metric reduction、position_ids 等训练口径统一收敛，从而减少长序列训练中最难定位的“漂移问题”。

(3) 压缩 hidden states：存储更省，精度不变

offline 模式下的主要压力来自磁盘存储，因此我们对 hidden states 做了压缩处理，使磁盘占用下降约 25%。同时压测结果显示 Accept Len 保持不变（1.93 vs 1.93），time/step 仅小幅增加（0.45s → 0.47s，约 4%）。

5.6 效果：能训、训得稳

通过这套 USP 方法，我们同时兼顾三个工程目标：

• 长序训练：单机 8 卡即可稳定支持 128K 上下文训练；

• 训练得稳：loss 与推理侧 Accept Len 对齐，确保训推一致性与加速收益可真实兑现。

6.1 实验设定

实验场景：Agent 长序列推理压测（对比 MTP baseline 与 EAGLE-3）  

• 并发 = 请求数：1 / 8 / 32  

• Batch size = 20，

• 指标：  

• Accept Len：单次验证平均接受 token 数  

• TPOT：单位输出 token 的 decode 延迟（mean / P95，单位 ms/token）

6.2 Accept Len 对比：EAGLE-3 稳定是 MTP 的 ~2.2–2.3×

结论：EAGLE-3 的平均 Accept Len 约为 MTP 的 2.2–2.3×。这意味着在相同输出长度下，EAGLE-3 往往能用更少的验证轮次完成生成，是 TPOT 显著改善的核心因素。

6.3 P95 TPOT：尾部延迟稳定降低约 35%–44%

在并发 1–32 范围内，EAGLE-3 相对 MTP 在 P95 TPOT 上稳定降低约 35%–44%。

结论：在高并发压力下，EAGLE-3 能显著降低单位输出 token 的尾部成本，使服务在 P95 口径下更稳定。

6.4 Mean/Median TPOT：以并发 8 为例，Mean TPOT 降低约 59%（≈2.4×）

在并发 8，TPOT单位ms/token：

• EAGLE-3：Mean TPOT 4.38，Median TPOT 3.27  

• MTP：Mean TPOT 10.67，Median TPOT 11.70 

计算：

• Mean TPOT 降幅 = 1 − 4.38 / 10.67 ≈ 58.9%

• 等价加速倍数 = 10.67 / 4.38 ≈ 2.44×

结论：在该压测设定下，EAGLE-3 相比 MTP：Mean TPOT ≈2.4×（降低约 59%），P95 TPOT 下降约 35%–44%。

7.1 当前挑战：从“能训练”走向“能长期跑、能稳定赚”

挑战 1（合并 OOD）：Accept Len 为何会掉？如何长期稳定？

线上 Agent 的 OOD 主要有两类来源，但最终都会表现为 Accept Len 下降 → TPOT 反弹：

• OOD-A：数据/流程分布漂移（需要更快迭代训练） 提示词模板、工具参数、工作流编排、甚至业务策略会持续变化，导致线上分布快速漂移（data drift / policy drift）。一次离线训练很快过期，模型收益会随时间逐步衰减。

• OOD-B：模型能力不足（需要更强表达的 Draft）在多 Agent 混部场景下，任务类型更发散。即使数据回流训练跟得上，若现有 Draft 的表达能力/泛化能力不足，仍会使得“关键高熵段”命中率偏低，导致 Accept Len 的上限偏低、波动偏大。

结论：OOD 并不是单一问题，而是“双因素驱动”：一方面需要更快的训练更新机制，另一方面需要更强、更可泛化的 Draft 能力，两者缺一不可。

挑战 2：长序列训练与特征管线成本仍高

长序列下，无论 online 还是 offline，都存在结构性成本：

• Offline：依赖 hidden states/特征落盘与搬运，单 Agent 规模很容易到 TB 级；存储、IO、数据管理成本高。

• Online： target 生成特征与训练过程强耦合，在长序列+大模型场景下资源排布较为紧张，容易与线上服务产生显存与算力争抢问题，整体调度与横向扩展也不够友好。

挑战 3：系统要面向“稳定收益”，而不仅是 mean

线上真实场景更关注 P95/P99 的稳定收益。在高熵片段或 OOD 场景下，如果仍然采用固定步长“硬跑”，验证开销可能反向放大，进而引发尾部延迟波动。因此系统需要具备基于置信度或一致性的动态退让能力。

挑战 4：算法快速演进，Infra 必须可插拔

投机范式在快速演进（如：DFlash扩散式投机等），如果每引入一种新方法就需要重写训练/推理的关键路径，迭代速度会被 infra 拖慢。因此需要抽象出“数据/特征接口、验证接口、调度策略”，降低接入成本。

7.2 后续规划：更快追上 OOD + 更健康的成本结构 + 更稳的尾延迟

规划 A：分离式特征生成 + 训练解耦（把成本结构做健康）

Target 特征生成尽量复用低峰时段的线上 server，或通过共享离线 server 批量生成，减少专属大卡的长期占用；Draft 多 epoch 训练依托 Mooncake store 进行样本复用，避免重复生成 hidden states 带来的额外开销，资源调度更加弹性，长序列显存压力更可控，长期综合成本更健康。

规划 B：近线/在线快速迭代（对应 OOD-A：分布漂移）

建立线上数据回流机制，优先收集被 Reject 的片段、低置信片段以及高熵工具调用片段，用于针对性微调；同时，为显著降低 Accept Len 的衰减速度，使整体收益曲线更加平稳，可将模型更新节奏从周/月级提升至天级，在条件允许时进一步逼近小时级（视稳定性与收益约束而定）。

规划 C：更强表达的 Draft + 路由专精（对应 OOD-B：能力不足）

引入 MoE / Routing Draft 机制，根据 Agent 类型、工具链特征与任务模式进行路由分配，将请求分发到不同专家路径；采用更强表示能力的 Draft 架构（更强的条件建模 / 泛化能力）以覆盖高熵片段，实现在多 Agent 混部场景下，仍能保持 Accept Len 的上限与稳定性。

规划 D：面向未来范式的可插拔框架

抽象训练侧的数据/特征接口与推理侧的验证/调度接口；将新范式（例如扩散式投机）的接入成本降低为“替换模块”而非“改造架构”，从而实现是跟上算法演进速度，而不是被 infra 形态所限制。

Agentic AI 需要处理长上下文、多轮工具调用与长链条推理，这类工作流对推理系统的要求不仅是“更快”，更是在长上下文与高并发下持续、稳定地快。围绕这一目标，我们为 EAGLE-3 适配并落地统一序列并行（USP），将长序列训练从“起不来/训不稳”推进到“可规模化”，并在 Agent 长序列压测中验证了 TPOT（Mean/P95）与 Accept Len 的显著收益。

在这一过程中，滴滴始终积极参与上游 SpecForge 开源社区建设，在构建内部系统能力的同时，将相关实践回馈并开放给社区开发者共同使用。目前相关能力已集成至 SpecForge，支持开箱即用，欢迎大家试用：