Rocket-ACE: 面向长推理任务的契约感知提前终止策略目标：给 Rocket 找一个不只是“调 vLLM 参数”的研究核心。核心思想：不要只追求 tokens/s，而是优化time-to-valid-answer和valid answers/s。适用场景：AIME、MMLU、JSON/RAG extraction、分类、表单填写、代码补丁等“输出有明确契约”的任务。0. 一句话总结Rocket-ACE（Answer-Contract Early-exit）把每个任务的“有效输出条件”形式化成一个输出契约，在模型生成过程中流式监控答案是否已经满足契约。一旦答案已经可被稳定解析，就立即终止生成，而不是继续等待模型自然 EOS 或生成满max_new_tokens。这不是 vLLM/SGLang 参数调优，而是一个跨后端的任务语义层解码策略：vLLM / SGLang / HF 负责快速生成 token Rocket-ACE 负责判断“任务答案已经足够完成”它优化的不是裸 tokens/s，而是：valid answers per second time to valid answer GPU seconds per solved item对于 Qwen3 thinking 模式、AIME 这类会生成很长 reasoning 的任务，ACE 有非常明确的理论收益：如果完整输出长度是L，答案在第τ个 token 已经出现，那么最多可以少生成L - τ个 token。1. 为什么这不是“调 vLLM 参数”当前 vLLM、SGLang、TensorRT-LLM 已经有很多底层优化：vLLM 支持 automatic prefix caching、chunked prefill、speculative decoding、structured outputs。SGLang 支持 EAGLE-2/EAGLE-3、MTP、DFLASH、NGRAM speculative decoding。TensorRT-LLM 支持 NGram、Medusa、EAGLE 等 speculative decoding。FlashInfer 提供 paged/ragged KV cache、Cascade Attention、POD-Attention 等高性能 kernel。这些技术主要在优化：同样要生成 L 个 token 时，怎样更快生成完。Rocket-ACE 问的是另一个问题：对于任务评测来说，真的需要生成完 L 个 token 吗？很多 benchmark 和业务任务的输出并不需要完整自然语言尾巴。例如：AIME 只需要一个000-999的整数答案。MMLU 只需要A/B/C/D。JSON extraction 只需要满足 JSON schema。Agent report 只需要字段齐全。代码补丁只需要 patch block 完整。如果模型在第τ个 token 已经给出了满足契约的答案，那么后面的 token 对任务指标是冗余的。vLLM/SGLang 本身不会知道“这个答案已经足够被 evaluator 接受”，因为这是任务语义，不是通用推理引擎的职责。因此，Rocket-ACE 的贡献位置是：engine-level serving optimization 之上的 task-contract decoding layer它和 vLLM/SGLang 是正交关系，不是替代关系。2. 背景观察2.1 长推理任务的慢点不是 prefill，而是 decode tail以当前 AIME + Qwen3-4B + HF SDPA 16K 日志为例：sample 1: 6750 tokens sample 2: 10943 tokens sample 3: 4492 tokens sample 4: 8490 tokens sample 5: 16384 tokens这些 token 大量来自 thinking/reasoning。对于 AIME，评测函数最终只看一个整数答案。也就是说，很多 token 对最终 accuracy 没有直接贡献。2.2 Qwen3 默认 thinking 模式会拉长输出Qwen3 的 chat template 默认enable_thinking=True。如果不显式关闭，模型会先生成think.../think推理内容，再给 final answer。这对准确率有利，但会显著增加 decode 长度。Rocket-ACE 不强迫关闭 thinking。它允许模型思考，但一旦 final answer 满足契约，就停止后续无用尾巴。2.3 现有 speculative decoding 不是充分解NGram speculative decoding 适合 prompt/output 有高 n-gram overlap 的场景。TensorRT-LLM 文档也明确说，NGram 直接从 prompt 或之前输出拷贝 draft token，适合 summarization、document QA、multi-turn chat、code editing 等高重叠任务。但是 AIME/数学推理里，后续 reasoning 不一定和 prompt 高度重叠。即使 speculative decoding 有效，它仍然是在尝试更快地产生后续 token，而 ACE 是直接避免生成无用 token。所以两者可以组合：speculative decoding: accelerate tokens before answer commitment ACE: stop after answer commitment3. 方法定义Rocket-ACE 包含三个核心模块：1. Output Contract 2. Streaming Committer 3. Backend Stop Adapter3.1 Output Contract对每个任务定义一个输出契约：C = (V, A, π, valid, commit)其中：V：合法答案空间。A：接受自动机或解析器。π(y)：从生成文本y中投影出任务答案。valid(a)：答案是否满足任务格式。commit(y)：当前前缀是否已经足以提交答案。不同任务的契约示例：任务合法答案空间V答案投影π提交条件AIME000-999整数解析\boxed{...}/Final Answer:后的整数出现最终答案标记且整数合法MMLU{A,B,C,D}解析Answer: A/The answer is A出现唯一选项JSON extractionJSON schemaJSON parserschema 所有必需字段齐全分类label setlabel parser出现唯一合法 label代码补丁diff grammarpatch parserpatch block 闭合且可解析这个契约可以手写，也可以由数据集配置生成。3.2 Streaming Committer生成过程中，Rocket-ACE 不等完整输出，而是维护一个流式解析状态：y_1, y_2, ..., y_t每来一段新 token，就更新：state_t = A.update(state_{t-1}, y_t)当满足：commit(y_{≤t}) = True则立即触发停止。为了避免模型“先说一个答案，后面又自我纠正”，commit 不能太宽松。建议使用强终止标记：\boxed{...} Final Answer: ... final.../final JSON object closed and schema-valid对于 AIME/MMLU，推荐在 prompt 中要求：Put the final answer in final.../final.然后 commit 只接受闭合的final标签。这比简单 stop string 更强，因为它不是只看字符串，而是看任务解析器是否已经得到合法答案。3.3 Backend Stop Adapter不同后端停止方式不同：HF: 使用 streamer 或分块 generate，每 K 个 token 检查一次 contract。 vLLM: 使用 streaming 输出，外部 controller 在 commit 后 abort request。 如果只用 offline generate，则可退化为 chunked generate。 SGLang: 使用 streaming API 或 request control，在 commit 后终止。为了少调参，建议固定一个 chunk 大小：K = 64 tokens如果后端支持真正 streaming，就不需要 chunk；如果只支持批量返回，就用 64 token 一段循环生成。这个K不是性能敏感超参，只是 stop granularity。即使K=128，最多也只是多生成 128 个 token，相比 8K/16K 长输出非常小。4. 理论推导4.1 基础延迟模型令：P：prefill 时间。L：baseline 完整生成长度。τ：第一次满足输出契约的 token 位置。c_t：第t个 decode token 的平均成本。C_A：ACE 流式解析开销。K：chunk 检查粒度。普通推理时间：T_base = P + Σ_{t=1}^{L} c_t如果近似c_t ≈ c：T_base ≈ P + cLRocket-ACE 时间：T_ACE = P + Σ_{t=1}^{τ+δ} c_t + C_A其中δ K，表示分块检查导致最多多生成的 token 数。近似：T_ACE ≈ P + c(τ + δ) + C_A速度提升：S = T_base / T_ACE ≈ (P + cL) / (P + c(τ + δ) + C_A)当 decode 主导，也就是cL P且C_A很小：S ≈ L / (τ + δ)这说明，只要答案出现得比完整输出早，收益就是确定的。4.2 结合本地日志估算当前日志里，完整生成长度包括：6750, 10943, 4492, 8490, 16384假设 AIME final answer 在第τ=1200个 token 左右已经出现，且K=64：sample 1 speedup upper estimate ≈ 6750 / 1264 = 5.34x sample 2 speedup upper estimate ≈ 10943 / 1264 = 8.66x sample 3 speedup upper estimate ≈ 4492 / 1264 = 3.55x sample 4 speedup upper estimate ≈ 8490 / 1264 = 6.72x sample 5 speedup upper estimate ≈ 16384 / 1264 = 12.96x这不是来自更快 kernel，而是来自少生成无用尾巴。即使 vLLM baseline 已经能达到几百 tokens/s，只要它仍然生成完整 long-CoT，ACE 仍然可能在 task latency 上大幅领先：vLLM full: L / r tokens/s vLLM + ACE: (τ + δ) / r tokens/s + parser cost其中r是 vLLM 真实 token throughput。4.3 正确性条件定义 evaluator：M(y) = score(π(y))也就是说，任务分数只依赖输出中可解析的答案，而不依赖完整自然语言。如果在某个前缀y_{≤τ}上：π(y_{≤τ}) = a valid(a) = True并且 commit 条件保证后续 continuation 不会改变提交答案：∀z, π(y_{≤τ} + z) = a那么：M(y_{≤τ}) = M(y_{≤L})这就是 ACE 的正确性基础。实际实现中，强 commit 条件可以通过以下方式保证：1. 使用闭合 final 标签：final.../final 2. 使用唯一 final field：{"answer": "..."} 3. 使用 grammar/schema 保证 final object 完整 4. 对容易自我纠正的自由文本，只在 “final answer” 标记后提交4.4 与 constrained decoding 的关系vLLM 和 SGLang 都支持 structured outputs / co