1. 论文基本信息

1.1. 标题

Seer: Online Context Learning for Fast Synchronous LLM Reinforcement Learning (Seer: 针对快速同步大型语言模型强化学习的在线上下文学习系统)

1.2. 作者

Ruoyu Qin†♢, Weiran He†, Weixiao Huang†, Yangkun Zhang†, Yikai Zhao†, Bo Pang†, Xinran Xu†, Yingdi Shan♢, Yongwei Wu♢, Mingxing Zhang♢1† † Moonshot AI, ♢ Tsinghua University

1.3. 发表期刊/会议

论文发布于 arXiv 预印本平台，其正式发表期刊/会议信息尚未提供。根据其研究内容和引用的文献风格，预计会投稿至计算机系统或机器学习顶级会议。

1.4. 发表年份

2025

1.5. 摘要

该论文提出了一种名为 Seer 的新型在线上下文学习系统，旨在解决现有同步强化学习 (Reinforcement Learning, RL) 系统在训练大型语言模型 (Large Language Models, LLMs) 时面临的性能瓶颈。特别地，它关注于在端到端迭代时间中占据主导地位的推演 (rollout) 阶段，该阶段由于固有的工作负载不平衡而导致严重的长尾延迟 (long-tail latency) 和资源利用率低下。Seer 通过利用共享相同提示 (prompt) 的请求在输出长度和生成模式上的相似性来解决这些挑战。该系统引入了三项关键技术：用于动态负载均衡的分块推演 (divided rollout)、上下文感知调度 (context-aware scheduling) 以及自适应分组推测解码 (adaptive grouped speculative decoding)。这些机制共同作用，显著减少了推演过程中的长尾延迟并提高了资源效率。在生产级 RL 工作负载上的评估表明，与最先进的同步 RL 系统相比，Seer 将端到端推演吞吐量提高了 74% 至 97%，并将长尾延迟降低了 75% 至 93%，从而显著加速了 RL 训练迭代。

1.6. 原文链接

https://arxiv.org/abs/2511.14617

1.7. PDF 链接

https://arxiv.org/pdf/2511.14617v1.pdf

2. 整体概括

2.1. 研究背景与动机

论文试图解决的核心问题: 现代大型语言模型 (LLMs) 的强化学习 (RL) 训练面临严重的性能瓶颈，尤其是在推演 (rollout) 阶段。这个阶段由于工作负载固有的不平衡性，导致了显著的长尾延迟 (long-tail latency) 和资源利用率低下。

为什么这个问题在当前领域是重要的:

1. 推演阶段是主导瓶颈: 强化学习的迭代过程在数据生成（推演）和模型参数更新（训练）之间交替进行。论文指出，推演阶段通常占据总迭代时间的 80% 左右（如 Table 1 所示），因此其效率直接决定了整个 RL 训练的速度。

2. 长生成能力的需求: 随着 LLMs 发展出复杂的思维链 (Chain-of-Thought, CoT) 推理能力，生成的响应长度越来越长（可能达到数万词元），并且长度变化极大。这种长生成任务带来了两个关键瓶颈：

   • 内存消耗波动大: KVCache（键值缓存）的内存占用会随着生成长度动态且不可预测地增长，从几百兆字节到几十吉字节。这导致在并发执行多个请求时，难以有效管理内存，可能引起动态批次收缩 (batch-size shrinkage)、资源利用率低下或昂贵的抢占 (preemption)。
   • 严重的负载不平衡和长尾效应: 极端的长度分布导致在推演后期，只有少数运行时间长的请求占用 GPU 资源，使得大部分加速器处于空闲状态，造成资源浪费。这种长尾效应可能占据总推演时间的一半。

3. 同步 RL 的重要性: 尽管异步 (asynchronous) RL 系统可以通过重叠推演和训练阶段来减少端到端时间，但它们会引入离策略学习 (off-policy learning) 和分布偏差 (distributional skew)，从而损害算法的保真度、模型性能和可复现性。因此，同步 (synchronous) RL 在许多场景中仍至关重要，需要对其效率进行优化。

4. 推测解码 (Speculative Decoding, SD) 的局限性: 传统的基于草稿模型 (draft model) 的 SD 方法在 RL 场景下受限，因为 RL 模型的持续更新导致模型漂移 (model drift)，使静态草稿模型预测失效；同时，草稿模型本身引入的计算开销和内存占用在大批次推演中是不可接受的。

   现有研究存在的挑战或空白: 现有同步 RL 系统往往将每个提示组 (prompt group) 视为一个单一单元进行处理，忽视了同一组内请求之间输出长度和生成模式上的相似性，这些相似性可以被利用来优化调度和推理。

这篇论文的切入点或创新思路: Seer 的核心创新在于利用了在一个提示组 (prompt group) 内，不同响应之间在输出长度和生成模式上的内在相似性。通过在线学习这些上下文信息，Seer 能够实现更精细的资源管理和推理加速，同时保持同步 RL 的算法保真度。

2.2. 核心贡献/主要发现

论文最主要的贡献在于提出了 Seer 系统，一个 novel 的在线上下文学习系统，通过以下三项关键技术，显著优化了同步 LLM RL 训练的推演 (rollout) 阶段：

1. 分块推演 (Divided Rollout) 与全局 KVCache:

   • 创新点: 打破了传统的以提示组 (prompt group) 为单位的调度范式，将请求组分解为独立的请求，并进一步将每个请求分解为多个小块（chunks）。结合全局 KVCache 池 (Global KVCache Pool)，实现了细粒度的动态负载均衡，最大化 VRAM 利用率，并避免了昂贵的抢占 (preemption) 及重新预填充 (re-prefills)。
   • 解决了问题: 严重的资源效率低下、内存消耗波动大、实例间负载不平衡。

2. 上下文感知调度 (Context-Aware Scheduling):

   • 创新点: 利用“推测请求 (speculative request)”机制，通过优先生成每个提示组 (prompt group) 中的一个响应，在线估计该组的预期生成长度和 KVCache 占用。这使得调度器能够实施近似的最长作业优先 (longest-job-first, LFS) 策略，优先处理长任务以最大化批次密度。
   • 解决了问题: 严重的长尾效应 (long-tail effect)，通过更智能的调度减少了长尾阶段的时间消耗。

3. 自适应分组推测解码 (Adaptive Grouped Speculative Decoding):

   • 创新点: 引入分布式分组草稿服务器 (Distributed Grouped Draft Server, DGDS)，为每个组维护一个压缩后缀树 (Compressed Suffix Tree, CST)，聚合同一组内所有请求的词元序列。这创建了一个高度准确、动态且与目标模型同步的“草稿模型”。DGDS 还引入了自适应草稿范围 (adaptive draft range) 机制，以最大化系统吞吐量。
   • 解决了问题: 传统推测解码在 RL 场景中因模型漂移 (model drift) 和大批次开销而失效的问题，进一步加速了推演 (rollout) 阶段的推理，特别是对长请求。

论文得出的关键结论或发现:

• Seer 在生产级 RL 工作负载上的评估显示，与最先进的同步 RL 系统相比：
  • 端到端推演吞吐量 (throughput) 提升了 74% 至 97%。
  • 长尾延迟 (long-tail latency) 降低了 75% 至 93%。
• 这些显著的性能提升表明 Seer 能够极大地加速 RL 训练迭代，且在不牺牲算法保真度 (algorithmic fidelity) 的前提下实现。

3. 预备知识与相关工作

3.1. 基础概念

为了帮助初学者理解本文，以下将对文中提及的关键技术、理论和模型进行解释：

• 强化学习 (Reinforcement Learning, RL):

  • 概念定义: 强化学习是机器学习的一个分支，让智能体 (agent) 在一个环境 (environment) 中通过与环境的交互学习如何做出决策以最大化累积奖励 (reward)。智能体通过策略 (policy) 指导行动，并通过价值函数 (value function) 或奖励信号 (reward signal) 来评估行动的好坏。
  • 在 LLM 中的应用: 在 LLMs 中，RL 通常用于对预训练模型进行微调 (fine-tuning)，使其更好地与人类偏好对齐（如 RLHF，即人类反馈强化学习），或提升模型在特定任务（如复杂推理、长文本生成）上的表现。LLM 智能体通常是一个生成文本的模型，环境是对生成文本进行评估的系统（例如，一个奖励模型）。

• 大型语言模型 (Large Language Models, LLMs):

  • 概念定义: 拥有大量参数（通常数十亿到数千亿）的深度学习模型，通过在海量文本数据上进行预训练，学习语言的统计规律、语义和语法。它们能够执行文本生成、摘要、翻译、问答等多种任务。
  • 在 RL 中的作用: 作为强化学习的策略 (policy) 模型，生成响应。

• 同步强化学习 (Synchronous Reinforcement Learning):

  • 概念定义: 一种 RL 训练范式，其中推演 (rollout)（数据生成）和训练 (training)（模型更新）阶段严格按照迭代顺序进行。当前迭代生成的经验 (experience) 必须完全基于当前策略 (policy) 的模型参数，然后才能用于更新模型。这意味着在模型更新之前，所有所需的推演 (rollout) 必须完成。
  • 优点: 保持算法保真度 (algorithmic fidelity)，避免离策略 (off-policy) 数据带来的不稳定性，易于调试和复现。
  • 缺点: 推演阶段通常是瓶颈，导致整体训练速度较慢。

• 异步强化学习 (Asynchronous Reinforcement Learning):

  • 概念定义: 与同步 RL 相反，异步 RL 允许推演 (rollout) 和训练 (training) 阶段并发进行或重叠。训练器可以使用来自旧策略 (policy) 的推演 (rollout) 数据进行模型更新，即使新的推演 (rollout) 仍在进行中。
  • 优点: 可以提高资源利用率，减少端到端训练时间。
  • 缺点: 引入离策略学习 (off-policy learning) 和分布偏差 (distributional skew)，可能导致训练不稳定、收敛速度慢或最终模型性能下降，且难以调试。

• 推演阶段 (Rollout Phase):

  • 概念定义: 在强化学习中，推演 (rollout) 阶段是指智能体 (agent) 与环境 (environment) 交互，生成一系列轨迹 (trajectories) 或经验 (experiences) 的过程。在 LLM 的 RL 训练中，这通常指 LLM 根据给定的提示 (prompt) 生成多个响应（即轨迹 (trajectories)）的过程。
  • 重要性: 推演 (rollout) 阶段生成的数据是用于策略 (policy) 更新的基础，其效率直接影响整个 RL 训练的迭代速度。

• KVCache (Key-Value Cache):

  • 概念定义: 在 Transformer 模型中，尤其是生成文本时，为了避免重复计算已经生成词元的键 (Key) 和值 (Value) 向量，会将这些向量缓存起来。这个缓存被称为 KVCache。
  • 在 LLM 推理中的作用: KVCache 存储了过去所有词元在多头自注意力机制中的键和值表示。随着生成长度的增加，KVCache 会线性增长，占据大量显存 (VRAM)。这是长文本生成中主要的内存消耗来源。
  • 与本文关系: 本文强调 KVCache 的巨大且动态变化的内存占用是 LLM 推演阶段的一个主要挑战。

• 长尾延迟 (Long-tail Latency):

  • 概念定义: 在一个批次或一组任务中，大部分任务可以在较短时间内完成，但少数几个任务需要极长的时间才能完成。这些少数任务构成了“长尾”，导致整体完成时间被这些长任务所主导，即使它们的数量很少。
  • 在 LLM 推演中的体现: 在 LLM 生成中，当批次中包含少数需要生成非常长响应的请求时，即使其他短请求已经完成，这些长请求仍会继续占用计算资源，导致整个批次或迭代的完成时间被拖长。

• 吞吐量 (Throughput):

  • 概念定义: 单位时间内系统完成的工作量。在 LLM 推理中，通常以每秒生成的词元数 (tokens per second) 或每秒处理的请求数 (requests per second) 来衡量。
  • 与本文关系: 本文的目标之一是显著提高推演阶段的吞吐量。

• 推测解码 (Speculative Decoding, SD):

  • 概念定义: 一种加速 LLM 推理的技术。它使用一个更小、更快的草稿模型 (draft model) 来预测未来可能生成的一系列词元（即草稿序列 (draft sequence)）。然后，目标模型 (target model)（大型、准确的模型）并行地验证这个草稿序列。如果草稿序列中的词元被验证通过，就可以跳过这些词元逐一生成的步骤，从而加速推理。
  • 接受率 (Acceptance Rate): 衡量推测解码效率的关键指标，指草稿序列中被目标模型接受的词元比例。接受率越高，加速效果越好。
  • 与本文关系: 本文提出了自适应分组推测解码 (Adaptive Grouped Speculative Decoding) 来解决传统 SD 在 RL 场景中的局限性。

• 思维链 (Chain-of-Thought, CoT) 推理:

  • 概念定义: 一种提示技术，通过引导 LLM 生成中间推理步骤，来解决复杂问题。模型不再直接给出最终答案，而是像人类一样，逐步思考、解释，最终得出结论。
  • 在 LLM 推演中的影响: CoT 推理会显著增加模型生成响应的长度，进一步加剧了KVCache 内存压力和长尾延迟问题。

• 组相对策略优化 (Group Relative Policy Optimization, GRPO):

  • 概念定义: 一种流行的 LLM 强化学习算法，其核心思想是为每个提示 (prompt) 生成 $G$ 个候选响应，并根据这些响应的奖励 (reward) 在组内计算优势 (advantage)。然后，模型使用这些优势来更新策略 (policy)。
  • 与本文关系: GRPO 算法的“分组”特性是 Seer 利用上下文信息 (contextual information) 的核心基础，即同一组内响应的相似性。

• 压缩后缀树 (Compressed Suffix Tree, CST):

  • 概念定义: 一种数据结构，用于高效地存储字符串集合的后缀，并支持快速模式匹配和查询。它通过压缩共享前缀来节省空间。
  • 在本文中的作用: Seer 使用 CST 来聚合同一提示组 (prompt group) 内所有请求的词元序列，作为自适应分组推测解码 (Adaptive Grouped Speculative Decoding) 的“草稿模型”的支撑结构，以生成高质量的草稿词元 (draft tokens)。

• 抢占 (Preemption):

  • 概念定义: 在计算系统中，当资源（如内存）不足时，为了给新任务或更高优先级的任务腾出空间，被迫中断或终止正在运行的低优先级任务的过程。
  • 在 LLM 推演中的影响: 昂贵的抢占 (preemption) 会导致任务需要从头重新预填充 (re-prefills) KVCache，极大地降低吞吐量。

3.2. 前人工作

• 现有的同步 RL 系统:

  • RLHFuse [52]: 尝试通过重叠推演 (rollout) 的长尾阶段与奖励计算和经验收集来减少流水线气泡 (pipeline bubbles)，从而提高资源利用率。
  • Kimi-K2 [36]: 实现了高效的模型卸载和检查点更新。
  • 共同局限: 这些系统虽然在整个 RL 训练流程的优化方面有所贡献，但并未充分解决推演 (rollout) 阶段自身固有的长尾延迟 (long-tail latency) 和资源利用率低下的根本问题。

• 异步 RL 系统 [6, 11, 31, 51, 9, 13, 53]:

  • 方法: 通过允许训练使用来自旧策略 (policy) 的推演 (rollout) 数据，或通过提前进行长尾推演 (rollout) 和请求重打包来减少长尾影响，从而重叠推演 (rollout) 和训练 (training) 阶段。
  • 优点: 可以减少端到端迭代时间，提高资源利用率。
  • 局限性: 引入了离策略学习 (off-policy learning) 和分布偏差 (distributional skew)，可能损害算法保真度 (algorithmic fidelity)，导致最终模型性能下降，并使调试和复现复杂化。因此，在许多需要高保真度的场景中，同步 RL 仍然是首选。

• 推测解码 (Speculative Decoding, SD):

  • 模型基线 SD [3, 18-20, 23]: 通常依赖于一个小型、静态的草稿模型 (draft model) 来预测词元。
    • 局限性:
      • 模型漂移 (Model Drift): 在迭代式 RL 训练中，目标 LLM 会不断更新，导致草稿模型（静态）的预测迅速过时，接受率 (acceptance rate) 下降，从而抵消加速效果。
      • 计算开销: 草稿模型的生成会引入毫秒级的延迟和 GPU 内存占用，这在大批次离线推演 (rollout) 场景中是无法承受的。
  • 无模型基线 SD (N-gram based) [7, 39]: 如 n-gram 方法，通过匹配历史序列来生成草稿。
    • 局限性: 在长上下文场景中，需要与整个输入序列匹配，开销巨大。难以聚合多个潜在匹配，导致草稿词元生成效果不佳。
  • 利用历史序列的 SD [13, 24]: 如 RhymeRL [13] 和 SPEC-RL [24]，提出利用先前 RL 迭代生成的历史序列作为参考来加速解码。
    • 局限性: 在大多数最先进的模型推演 (rollout) 场景中，不同迭代会采样不同的数据来提高泛化能力，导致没有可重用的历史序列。

3.3. 技术演进

LLMs 的发展，尤其是思维链 (CoT) 推理能力的兴起，使得模型生成的响应越来越长且长度差异巨大。这直接导致了在 RL 训练的推演 (rollout) 阶段，内存消耗剧增和严重的长尾延迟 (long-tail latency)。早期的 RL 框架主要关注整体流程的编排和并行策略，但对于推演阶段内部的细粒度优化（特别是针对长生成和不平衡工作负载）关注不足。传统的推测解码 (Speculative Decoding, SD) 技术因其静态草稿模型和对 RL 模型漂移的不适应性，无法有效应用于 LLM RL 训练。异步 RL 尝试通过放松算法保真度 (algorithmic fidelity) 来加速，但其固有的缺点限制了其在某些应用中的适用性。

Seer 的工作正是处于这种技术演进的交叉点，旨在在维持同步 RL 算法保真度 (algorithmic fidelity) 的前提下，通过深入挖掘提示组 (prompt group) 内部的上下文信息 (contextual information)，实现对推演 (rollout) 阶段内存管理、调度和推理的全面优化，以应对 LLM 越来越长的生成能力带来的挑战。

3.4. 差异化分析

本文提出的 Seer 方法与现有方法的核心区别和创新点在于：

• 利用组内上下文信息: Seer 的核心洞察是利用 GRPO 等算法中，同一提示 (prompt) 下生成的多个响应（一个提示组 (prompt group)）之间在长度和生成模式上的相似性。这是现有系统（将组视为整体）所忽视的。
• 细粒度资源管理:
  • 分块推演 (Divided Rollout): 将请求分解为更小的块 (chunks)，并结合全局 KVCache 池 (Global KVCache Pool)，实现了细粒度的动态内存管理和负载均衡，避免了传统大批次处理导致的抢占 (preemption) 和资源利用率低下。这是对以往系统处理单元（组或请求）的重大改进。
  • 上下文感知调度 (Context-Aware Scheduling): 通过“推测请求 (speculative request)”在线预测组内请求长度，从而实现近似的最长作业优先 (LFS) 调度。这比传统的静态调度或简单批次调度更具智能性，能有效缓解长尾效应 (long-tail effect)。
• 适应 RL 特性的推测解码:
  • 自适应分组推测解码 (Adaptive Grouped Speculative Decoding): 针对 RL 场景中模型漂移 (model drift) 导致传统 SD 失效的问题，Seer 利用分布式分组草稿服务器 (DGDS) 和压缩后缀树 (CST)，通过聚合组内所有请求的序列信息，动态生成高度准确的草稿。同时，其自适应草稿范围 (adaptive draft range) 机制能够根据系统负载动态调整，克服了静态 SD 的局限性。这是一种针对 RL 独特挑战的定制化 SD 方案，区别于通用的模型基线或无模型基线 SD。
• 保持算法保真度: 区别于异步 RL (asynchronous RL) 方法，Seer 在所有优化措施下，严格维持同步 RL (synchronous RL) 的算法保真度 (algorithmic fidelity)，避免了离策略学习 (off-policy learning) 带来的潜在问题。

4. 方法论

4.1. 方法原理

Seer 的核心思想在于，在组相对策略优化 (GRPO) 等流行的强化学习算法中，对于同一提示 (prompt) 生成的多个响应（即一个提示组 (prompt group)），它们在语义、结构模板和生成长度上往往表现出显著的相似性。Seer 提出了一种名为在线上下文学习 (online context learning) 的新范式，通过在推演 (rollout) 过程中动态地利用这些之前被忽视的组内上下文信息，以最大限度地提高资源效率。

具体来说，Seer 利用了两种主要的上下文信号 (contextual signals)：

1. 长度上下文 (Length Context): 同一提示组 (prompt group) 内的响应通常具有高度相关的生成长度。Seer 通过优先生成每个组中的一个“推测请求 (speculative request)”来在线估计这些长度，从而指导上下文感知调度器 (context-aware scheduler) 采取近似的最长作业优先 (LFS) 策略，有效缓解长尾延迟 (long-tail latency)。

2. 模式上下文 (Pattern Context): 由于组内响应是基于相同的提示 (prompt) 生成的，它们在生成的词元序列中会共享相似的模式。Seer 利用这种模式相似性，通过构建一个分布式分组草稿服务器 (DGDS) 和压缩后缀树 (CST)，为自适应分组推测解码 (Adaptive Grouped Speculative Decoding) 提供高质量的草稿词元 (draft tokens)，从而加速推理过程。

   这些机制在分块推演 (Divided Rollout) 的基础上实现，将请求分解为更小的块，并结合全局 KVCache 池 (Global KVCache Pool)，实现了细粒度的动态负载均衡和内存管理。

4.2. 组相对策略优化 (GRPO)

组相对策略优化 (Group Relative Policy Optimization, GRPO) 是 LLM 强化学习实践中广泛采用的算法。其核心思想是，对于每个提示 (prompt) $x$，从当前的策略 (policy) $\pi_{\theta_{old}}$ 中采样 $G$ 个候选响应 $\{\mathbf{\dot{y}}_i\}_{i = 1}^G$。这些响应通过奖励模型评估得到奖励 $\{r_i\}$，然后在组内进行归一化以计算优势 (advantage) $\{A_{i}\}$。最终，使用裁剪比率损失 (clipped ratio loss) 和 KL 正则化来更新策略 (policy) $\pi_{\theta}$，使其稳定地向参考模型 $\pi_{\mathrm{ref}}$ 靠拢。

GRPO 算法的目标函数 (objective function) 可以表达为： $$\mathcal{L}_{\mathrm{GRPO}} = -\mathbb{E}_{x,y_{i}\sim \pi_{\mathrm{old}}}\left[\min \left(\rho_{i}A_{i},\mathrm{clip}(\rho_{i},1 - \epsilon ,1 + \epsilon)A_{i}\right)\right] + \beta \mathrm{KL}(\pi_{\theta}\| \pi_{\mathrm{ref}})$$ 其中：

• $\mathbb{E}_{x,y_{i}\sim \pi_{\mathrm{old}}}[\cdot]$ 表示对提示 (prompt) $x$ 和从旧策略 (policy) $\pi_{\mathrm{old}}$ 采样得到的响应 $y_i$ 的期望。

• $\rho_{i} = \frac{\pi_{\theta}(y_{i}|x)}{\pi_{\theta_{\mathrm{old}}}(y_{i}|x)}$ 是当前策略 (policy) $\pi_{\theta}$ 与旧策略 (policy) $\pi_{\theta_{\mathrm{old}}}$ 之间生成响应 $y_i$ 给定 $x$ 的概率比率。

• $A_{i}$ 是响应 $y_i$ 的优势 (advantage)。

• $\mathrm{clip}(\rho_{i},1 - \epsilon ,1 + \epsilon)$ 是将比率 $\rho_i$ 裁剪到 $[1-\epsilon, 1+\epsilon]$ 区间内，用于稳定训练。

• $\epsilon$ 和 $\beta$ 是超参数 (hyperparameters)。

• $\mathrm{KL}(\pi_{\theta}\| \pi_{\mathrm{ref}})$ 是当前策略 (policy) $\pi_{\theta}$ 与参考模型 $\pi_{\mathrm{ref}}$ 之间的KL 散度 (Kullback-Leibler divergence)，用于防止策略 (policy) 偏离参考模型太远。

  优势 (advantage) $A_{i}$ 是通过组内奖励 $\{r_{1},r_{2},\ldots ,r_{G}\}$ 计算得到的： $$A_{i} = \frac{r_{i} - \mathrm{mean}\big(\{r_{1},r_{2},\dots,r_{G}\}\big)}{\mathrm{std}\big(\{r_{1},r_{2},\dots,r_{G}\big)\big)}$$ 其中：

• $r_i$ 是响应 $y_i$ 获得的奖励 (reward)。

• $\mathrm{mean}\big(\{r_{1},r_{2},\dots,r_{G}\}\big)$ 是组内所有响应奖励的平均值。

• $\mathrm{std}\big(\{r_{1},r_{2},\dots,r_{G}\}\big)$ 是组内所有响应奖励的标准差。

  GRPO 的这种“分组”生成特性，即为每个提示 (prompt) 生成 $G$ 个响应，是 Seer 利用组内上下文信息 (contextual information) 进行优化的核心基础。

4.3. Seer 架构概述

Seer 旨在加速推演 (rollout) 阶段，同时保持同步 RL 的算法保真度 (algorithmic fidelity)。其架构主要由三个核心模块组成：

1. 推理引擎池 (Inference Engine Pool): 包含多个推理实例 (inference instances) 和一个分布式 KVCache 池 (distributed KVCache pool)。这些实例负责执行推理请求，并具备负载均衡和缓存重用能力。

2. 请求缓冲区 (Request Buffer): 作为所有请求的统一入口点，管理请求的输入、输出和运行时状态。

3. 上下文管理器 (Context Manager): 维护所有请求的上下文视图 (contextual views)，并根据请求上下文 (contexts) 提供调度决策。

   这些模块共同协作，通过分块推演 (Divided Rollout)、上下文感知调度 (Context-Aware Scheduling) 和自适应分组推测解码 (Adaptive Grouped Speculative Decoding) 三项关键技术来解决 LLM 推演中的挑战。

下图（原文 Figure 5）展示了 Seer 的系统架构：

该图像是一个示意图，展示了 Seer 系统的组件及其工作流程。图中包括请求缓冲区、上下文管理器、推理引擎池等部分，描述了如何通过分割 rollout 调度器、上下文感知调度和分组草稿服务器等技术来优化 RL 工作负载的处理。图中包含的工作流旨在提高资源利用率并减少长尾延迟。

• Request Buffer (请求缓冲区): 接收来自 RL Trainer 的提示组 (prompt group)，将其分解为独立的请求和更小的块 (chunks)，并管理其运行时状态。
• Context Manager (上下文管理器): 监听推测请求 (speculative requests) 的生成，维护和更新组内的长度估计，并基于此生成调度决策。
• Distributed Grouped Draft Server (DGDS) (分布式分组草稿服务器): 聚合同一组内所有请求的词元序列，构建压缩后缀树 (CST)，为推测解码 (speculative decoding) 提供模式上下文 (pattern context)。
• Global KVCache Pool (全局 KVCache 池): 跨推理节点共享 KVCache 存储，支持分块推演 (Divided Rollout) 中的请求迁移和重调度，避免重新预填充 (re-prefills)。
• Inference Engine Pool (推理引擎池): 包含多个 Inference Instances (推理实例)，每个实例运行一个 LLM，执行词元生成。它们与 DGDS 交互进行推测解码 (speculative decoding)。
• 整个流程协同工作，以减少长尾延迟 (long-tail latency) 和提高吞吐量 (throughput)。

4.4. 分块推演 (Divided Rollout) 与全局 KVCache

4.4.1. 传统推演系统的局限性

在传统的推演 (rollout) 系统中，推理实例以组 (group) 为单位处理请求。一个提示组 (prompt group) 被作为一个整体随机分发到某个推理实例，并且一旦分配，它就绑定在该实例上直到完成。这种方法存在两个主要限制：

1. 严重的负载不平衡和内存管理挑战: 不同提示组 (prompt group) 的生成长度差异巨大，导致实例间的负载不平衡。在单个实例内部，动态增长的 KVCache 内存占用难以预测，可能导致内存耗尽，触发昂贵的抢占 (preemption)，或为了避免抢占而预留大量内存，造成资源利用率低下。
2. 忽视组内上下文: 将每个组视为一个整体，未能利用同一组内请求之间的上下文相似性 (contextual similarities)，这些相似性本可以用于优化。

4.4.2. Seer 的分块推演

为了解决这些问题，Seer 基于请求缓冲区 (Request Buffer) 实现了分块推演 (Divided Rollout) 机制。它不仅将一个提示组 (prompt group) 分解为 $G$ 个独立请求，还进一步将每个请求根据生成长度划分为多个块 (chunks)。这种子请求级别的推演 (rollout) 由请求缓冲区 (Request Buffer) 管理，其中包含每个请求的元数据（如组 ID、提示长度、原始 max_tokens、当前生成长度）。

当一个请求从请求缓冲区 (Request Buffer) 调度出去时，它的 max_tokens 被设置为一个较小的块大小 (chunk size)（例如 8K 词元）。当前块完成后，该请求会被重新加入请求缓冲区 (Request Buffer)，并迭代地重新提交，直到生成 $<eos>$ 词元或达到其原始 max_tokens 限制。

分块推演 (Divided Rollout) 带来的优势:

• 细粒度内存管理 (Fine-grained Memory Management): 每个请求以更小的块 (chunks) 生成词元，使 KVCache 占用在整个生成过程中保持相对恒定。调度器可以动态计算最大并发级别，以避免触发抢占 (preemption)，从而最大化资源利用率。
• 动态负载均衡 (Dynamic Load Balancing): 调度粒度从每个提示组 (prompt group) 的单次实例选择，变为 $G \times \text{num\_chunks}$ 次选择。当子请求重新提交时，Seer 根据实时监测的在途请求并发度 (in-flight request concurrency) 和内存占用，动态选择负载最小的推理实例。这显著减少了由实例间负载不平衡引起的长尾效应 (long-tail effect)。

4.4.3. 全局 KVCache 池 (Global KVCache Pool)

为了高效支持分块推演 (Divided Rollout) 并避免在重新调度时重复计算 KVCache，Seer 借鉴了 Mooncake [28] 的设计，构建了一个分布在多个推理节点上的全局 KVCache 池 (Global KVCache Pool)。这个池采用DRAM/SSD 两层架构 (two-tier DRAM/SSD architecture)。它允许请求在请求缓冲区 (Request Buffer) 中等待调度时，其 KVCache 数据可以被高效地存储和迁移，而无需昂贵的预填充 (prefill) 重新计算。这使得 Seer 的分块推演 (Divided Rollout) 成为一种主动的请求迁移和负载均衡机制，对上层透明，专为离线推理工作负载设计。

4.5. 上下文感知调度 (Context-Aware Scheduling)

4.5.1. 挑战与动机

除了实例间的负载不平衡，实例内部的调度不平衡也会导致长尾延迟 (long-tail latency)。在内存限制下，一些长请求可能被推迟到最后，进一步加剧长尾效应。然而，如前所述（§3.2），同一提示组 (prompt group) 内的请求生成长度高度相关。Seer 利用这一观察结果，通过在线学习长度上下文来指导调度，实现近似最长作业优先 (LFS) 的调度策略。

4.5.2. 调度机制

基于分块推演 (Divided Rollout)，Seer 将每个组的第一个请求指定为推测请求 (speculative request)。它充当一个在线探针 (probe)，用于估计该组中剩余请求的预期工作负载。

算法 1 (Context-Aware Scheduling based on Divided Rollout) 描述了上下文感知调度的工作流程。该算法由 Seer 的全局调度器 (global scheduler) 持续调用，每次返回一个调度决策 $(r^{\ast},i^{\ast})$，将选定的请求 $r^{\ast}$ 分配给推理实例 $i^{\ast}$，直到所有请求完成。

算法 1: 基于分块推演的上下文感知调度 (Context-Aware Scheduling based on Divided Rollout) $$Require: Active requests R = {r_{g,i}} grouped by prompt g, group-level length estimates {L_g}; inference instances I with KV-usage telemetry. Ensure: A scheduling decision (r*,i*) with r* ∈ R and i* ∈ I - 1: for all r_{g,i} ∈ R do 2: if r_{g,i} is finished then 3: L_g ← UPDATE ESTIMATE (L_g, L_{g,i}) 4: remove r_{g,i} from R 5: else if r_{g,i} is the group's speculative request then 6: add to high-priority queue Q_spec 7: else 8: add to low-priority candidate set C_rest 9: end if 10: end for 11: r* ← None 12: if !IS_EMPTY(Q_spec) then 13: r* ← PICK_SFS(Q_spec) ▷ SFS: smallest generated length first 14: else if !IS_EMPTY(C_rest) then 15: r* ← PICK_LFS(C_rest) ▷ LFS: largest L_g first 16: else 17: return all requests are finished 18: end if 19: r*.max_tokens ← min(chunk_size, r*.ori_max_tokens - r*.generated_tokens) 20: i* ← SELECT_INSTANCE(I, r*.max_chunk_tokens, KV-usage) 21: if i* ≠ None then 22: return (r*,i*) 23: end if 24: return no available instance for this cycle$$

算法步骤详解:

1. 请求分类 (Request Classification):

   • 遍历所有活动请求 $r_{g,i}$（属于提示 $g$ 的第 $i$ 个请求）。
   • 如果请求 $r_{g,i}$ 已完成，则更新其所属组 $g$ 的长度估计 $\hat{L}_{g}$ (行 3)，并从活动请求集合 $R$ 中移除 (行 4)。
   • 如果请求 $r_{g,i}$ 是该组的推测请求 (speculative request)，则将其加入高优先级队列 $Q_{spec}$ (行 6)。
   • 否则 (即非推测请求且未完成)，将其加入低优先级候选集合 $C_{rest}$ (行 8)。

2. 调度决策 (Scheduling Decision):

   • 优先调度推测请求 (Speculative Request Priority): 如果 $Q_{spec}$ 不为空，则从 $Q_{spec}$ 中选择一个请求 $r^{\ast}$。这里采用最短作业优先 (SFS) 策略（PICK_SFS），即选择当前已生成词元最少的请求。这确保了短请求能尽快完成并退出队列，同时长请求会留在队列中，暴露其作为潜在长尾 (long-tail) 候选的特性 (行 13)。
   • 近似最长作业优先 (Approximate LFS): 如果 $Q_{spec}$ 为空（即所有推测请求都在处理中或已完成），且 $C_{rest}$ 不为空，则从 $C_{rest}$ 中选择一个请求 $r^{\ast}$。这里采用最长作业优先 (LFS) 策略（PICK_LFS），即选择其所属组 $g$ 的估计长度 $\hat{L}_{g}$ 最大的请求。这个估计值是由上下文管理器 (Context Manager) 动态维护的 (行 15)。
   • 如果两个队列都为空，则表示所有请求已完成 (行 17)。

3. 长度估计更新 (Length Estimation Update):

   • 上下文管理器 (Context Manager) 维护每个提示组 (prompt group) $g$ 的估计输出长度 $\widetilde{L}_{g}$。
   • 这个值会根据组内所有已完成请求的最大生成长度动态更新。
   • 如果组内所有请求都未完成，则该组被认为是潜在的长尾 (long-tail) 候选，其估计输出长度保守地设置为原始 max_tokens 限制。

4. 分配 chunk 大小和实例 (Assign Chunk Size and Instance):

   • 为选定的请求 $r^{\ast}$ 设置其当前块 (chunk) 的 max_tokens，取块大小 (chunk_size) 与剩余未生成词元数中的最小值 (行 19)。
   • 调用 SELECT_INSTANCE 函数，根据推理实例 $I$ 的 KVCache 使用情况和请求 $r^{\ast}$ 的最大块词元数 (max_chunk_tokens)，选择负载最轻的实例 $i^{\ast}$ (行 20)。
   • 如果找到可用实例，则返回调度决策 $(r^{\ast},i^{\ast})$ (行 22)。否则，表示当前周期没有可用实例 (行 24)。

优点:

• 通过推测请求 (speculative requests) 尽早发现长任务，并利用其长度信息指导后续调度。
• 近似最长作业优先 (LFS) 策略有助于在高优先级处理长任务，减少长尾延迟 (long-tail latency)。
• 结合全局 KVCache 池 (Global KVCache Pool)，请求可以在请求缓冲区 (Request Buffer) 中等待调度，而不会在块 (chunk) 执行之间丢失状态，从而实现了更灵活的调度。

4.6. 自适应分组推测解码 (Adaptive Grouped Speculative Decoding)

4.6.1. 挑战与动机

传统的推测解码 (Speculative Decoding, SD) 在 RL 推演 (rollout) 阶段面临诸多限制：模型漂移 (model drift) 导致接受率 (acceptance rate) 下降，以及草稿模型本身的计算和内存开销在大批次场景下无法承受。为了解决这些问题，Seer 提出了自适应分组推测解码 (Adaptive Grouped Speculative Decoding)。

4.6.2. 分布式分组草稿服务器 (Distributed Grouped Draft Server, DGDS)

Seer 引入了 分布式分组草稿服务器 (Distributed Grouped Draft Server, DGDS)，这是一个分布式框架，用于在请求和实例之间共享推测上下文 (speculative context)。DGDS 的核心数据结构是压缩后缀树 (Compressed Suffix Tree, CST)，它能够高效地聚合来自多个序列的上下文统计信息 (contextual statistics)，并以低复杂度提供草稿词元 (draft tokens)。DGDS 将同一组内所有请求的序列上下文 (context) 聚合到一个统一的 CST 中，从而为所有推理实例提供高质量的推测词元 (speculative tokens)。

下图（原文 Figure 6）展示了分布式分组草稿服务器的架构：

该图像是示意图，展示了全局分组草稿服务器的架构，包含实例和草稿客户端的交互过程。图中标示了异步附加、全局聚合、定期获取和本地推测四个关键步骤，体现了如何优化推理引擎的效率。

• Inference Instances (推理实例): 每个实例运行 LLM，生成词元，并将新生成的词元异步 (asynchronously) 发送给 DGDS。

• Draft Clients (草稿客户端): 作为推理实例的库组件，定期从 DGDS 同步最新的 CST。

• Distributed Grouped Draft Server (DGDS) (分布式分组草稿服务器): 维护每个提示组 (prompt group) 的 CST。它接收来自推理实例的词元更新，进行全局聚合 (Global Aggregation)，并将 CST 状态提供给草稿客户端。

  DGDS 的运行分为四个关键步骤：

1. 异步追加 (Asynchronous Append): 每个推理实例运行一个独立的进程来处理输出词元。新生成的词元会通过 group_id 标识，发送给 DGDS。为了减少通信开销，每个请求会批量发送一定数量的词元更新。 以下是 update_cst API 的描述： 表 3: 分组草稿服务器 API (Grouped Draft Server API)

   Operation	Description	Parameters
   update_cst	Append generated tokens from a specific request to the compressed suffix tree	const string& group_id, int request_id, int prev_token_count, const vector<int>& new_tokens

   • group_id: 请求所属的提示组 (prompt group) 的 ID。
   • request_id: 组内特定请求的 ID。
   • prev_token_count: 该请求在发送新词元前的已生成词元数。
   • new_tokens: 新生成的词元序列。

2. 全局聚合 (Global Aggregation): DGDS 聚合来自属于同一组的请求的词元更新。为防止跨请求干扰 (cross-request interference)，DGDS 通过 request_id 隔离更新，将每个新词元仅映射到 CST 中相应的本地路径。

3. 周期性获取 (Periodic Fetch): 每个推理实例内嵌一个草稿客户端 (draft client) 作为库组件。该客户端会定期从 DGDS 同步最新的 CST。为了减少通信开销，客户端只获取与其实例上正在处理的请求对应的 CST，并支持增量同步 (incremental synchronization)。 以下是 fetch_cst API 的描述： 表 4: 草稿客户端 API (Draft Client API)

   | Operation | Description | Parameters

   Description	Returns
   predict	$vector<float>$
   get_scores	$vector<float>$

   • group_ids: 正在获取 CSTs 的提示组 (prompt groups) 的 ID 列表。
   • draft_cache_info: 客户端本地缓存的 CST 状态信息，用于增量同步 (incremental synchronization)。

4. 本地推测 (Local Speculation): 推理实例基于其本地 CST 执行推测解码 (speculative decoding)。由于 CST 聚合了同一组中所有请求的路径，实例可以共享上下文统计信息 (contextual statistics) 并获得更高质量的草稿词元 (draft tokens)。

4.6.3. 自适应草稿范围 (Adaptive Draft Range)

DGDS 引入了自适应推测范围机制 (adaptive speculation range mechanism)，根据计算强度动态调整草稿长度 (draft lengths)。

• 针对不同模型架构（如稠密模型和专家混合模型 (Mixture-of-Experts, MoE)），Seer 预计算了针对单个请求和整个批次的推测词元阈值 (speculation token thresholds)。

• 推理实例根据当前并发级别 (concurrency levels) 动态计算最大草稿长度 (draft length)。

• 生成草稿词元 (draft tokens) 时，系统还会根据词元出现频率和 CST 提供的置信度分数 (confidence scores) 过滤候选词元，以提高接受率 (acceptance rate)。

• Seer 还实现了多路径推测解码 (multi-path speculative decoding)，这是一种基于树的草稿变体 [41]，通过束搜索 (beam search) 机制返回多个候选路径，以在长尾 (long-tail) 阶段进一步提高接受长度 (acceptance length)。

• 对于带有分组查询注意力 (Grouped Query Attention, GQA) 的模型，Seer 使用级联注意力 (cascade attention) 来高效处理多路径草稿。对于多头潜在注意力 (Multi-head Latent Attention, MLA) 等算术强度高的注意力机制，则将其作为多个注意力操作处理。

  这种自适应控制能够保持解码准确性，同时最大化分布式推演 (rollout) 实例的整体吞吐量 (throughput) 和效率，特别是在长尾 (long-tail) 阶段，当并发度较低时，允许更大的草稿长度 (draft lengths) 和多路径 (multi-path) 探索，从而显著加速。

5. 实验设置

5.1. 测试平台

实验基础架构包含 32 个高性能计算节点，每个节点配备 8 块 H800 GPU。部署策略旨在平衡任务性能与资源效率，根据模型大小和架构配置不同数量的 GPU 和并行策略。

5.2. 模型与工作负载

实验中采用了组相对策略优化 (GRPO) 算法。为了验证 Seer 设计的通用性，选择了三种具有不同规模和输出特征的模型进行评估： 以下是原文 Table 5 的结果：

• Moonlight [25]: 一个 65B 参数的模型，最大上下文长度 2K，最大输出长度 16K，平均输出长度 22386。采用张量并行 (Tensor Parallelism, TP8) 策略。

• Qwen2-VL-72B [42]: 一个 72B 参数的模型，最大上下文长度 2K，最大输出长度 32K，平均输出长度 7615。采用张量并行 (TP8) 策略。

• Kimi-K2 [36]: 一个 130B 参数的模型，最大上下文长度 16K，最大输出长度 100K，平均输出长度 38959。采用数据并行 (Data Parallelism, DP32) 和专家并行 (Expert Parallelism, EP32) 策略。

  这些模型都被训练为具备思维链 (Chain-of-Thought, CoT) 能力的推理模型。Moonlight [25] 和 Kimi-K2 [36] 在数学数据集上训练，而 Qwen2-VL-72B [42] 在使用 LLM-as-a-Judge [34] 奖励模型进行语言-视觉混合推理任务上训练。

5.3. 对比基线

本文使用 veRL [32] 作为基线系统。veRL 是一个同步训练系统，集成了协同训练和推演 (rollout)。在 RL 算法逻辑层面，Seer 与同步 veRL 保持一致，即每次训练迭代仅使用当前策略 (policy) 生成的数据。

5.4. 评估指标

对 Seer 系统性能的评估主要围绕以下几个关键指标展开：

5.4.1. 吞吐量 (Throughput)

• 概念定义: 吞吐量衡量的是系统在单位时间内成功处理的请求或完成的工作量。在 LLM 生成任务中，通常表示为每秒钟生成的词元数。更高的吞吐量意味着系统能够更快地完成推演 (rollout) 任务。
• 数学公式: $$\text{Throughput} = \frac{\sum_{i=1}^{N} \text{OutputTokens}_i}{\text{TotalTime}}$$
• 符号解释:
  • $\text{OutputTokens}_i$: 第 $i$ 个请求生成的词元数量。
  • $N$: 总请求数量。
  • $\text{TotalTime}$: 完成所有请求所需的总时间（秒）。

5.4.2. 长尾延迟 (Long-tail Latency)

• 概念定义: 长尾延迟特指在所有请求处理完毕后，排在最后一部分请求（例如，最后 10% 的请求）完成所需的时间。这个指标突出显示了少数极端长请求对整体完成时间的拖累程度。降低长尾延迟是优化高性能分布式系统（尤其是 LLM 推理）的关键目标之一。
• 数学公式: 论文中没有直接给出长尾延迟的数学公式，但通常它指的是完成所有请求总时间中，最后一个百分位（如 10%）的请求所消耗的时间。如果按时间排序，可以表示为： $$\text{Long-tail Latency} = \text{Time}(\text{Completion of } P_{tail} \text{ requests}) - \text{Time}(\text{Completion of } (1-P_{tail}) \text{ requests})$$ 其中 $P_{tail}$ 是长尾请求的比例（例如 0.1 表示 10%）。
• 符号解释:
  • $\text{Time}(\text{Completion of } X \text{ requests})$: 完成 $X$ 比例请求所需的时间。
  • $P_{tail}$: 长尾请求的比例，例如 0.1。

5.4.3. 完成时间 (Completion Time)

• 概念定义: 完成时间指的是从推演 (rollout) 阶段开始到所有请求处理完毕所需耗费的总时长。它直接反映了整个推演 (rollout) 迭代的效率。
• 数学公式: $$\text{Completion Time} = \text{End Time} - \text{Start Time}$$
• 符号解释:
  • $\text{End Time}$: 推演阶段结束的时间戳。
  • $\text{Start Time}$: 推演阶段开始的时间戳。

5.4.4. KVCache 利用率 (KVCache Utilization)

• 概念定义: KVCache 利用率衡量的是 GPU 显存中用于存储 KVCache 的内存空间，占总可用 KVCache 内存的比例。高利用率意味着 GPU 资源得到了充分使用，避免了浪费。
• 数学公式: $$\text{KVCache Utilization} = \frac{\text{Actual KVCache Memory Used}}{\text{Total Available KVCache Memory}} \times 100\%$$
• 符号解释:
  • $\text{Actual KVCache Memory Used}$: 当前实际使用的 KVCache 内存量。
  • $\text{Total Available KVCache Memory}$: 系统为 KVCache 分配的总内存量。

5.4.5. 平均接受长度 (Mean Acceptance Length)

• 概念定义: 在推测解码 (speculative decoding) 中，平均接受长度指的是每次推测过程中，目标模型 (target model) 能够连续接受的草稿词元 (draft tokens) 的平均数量（包括奖励词元）。较高的平均接受长度意味着草稿模型 (draft model) 预测更准确，推测解码 (speculative decoding) 的加速效果更显著。
• 数学公式: $$\text{Mean Acceptance Length} = \frac{\sum_{j=1}^{M} \text{AcceptedTokens}_j}{M}$$
• 符号解释:
  • $\text{AcceptedTokens}_j$: 第 $j$ 次推测中被接受的词元数量。
  • $M$: 推测的总次数。

6. 实验结果与分析

6.1. 核心结果分析

Seer 在推演 (rollout) 吞吐量和长尾延迟方面取得了显著的性能提升。

吞吐量提升: 下图（原文 Figure 7）展示了 Seer 和同步 veRL 在三种任务（Moonlight, Qwen2-VL-72B, Kimi-K2）上的推演 (rollout) 吞吐量（每秒输出词元数）和完成时间对比。虚线表示 10 次迭代的平均吞吐量。

该图像是图表，展示了在不同迭代下，Seer和veRL系统的推理吞吐量和完成时间。其中包括三个子图：分别为(a) Moonlight、(b) Owen2-VL-72B和(c) Kimi-K2，展示了Seer相对于veRL的性能提升。数据表明，Seer在吞吐量和完成时间上都有显著改善，提升幅度可达74%至97%。

• Moonlight (65B): Seer 相比 veRL 吞吐量提升了 74%。

• Qwen2-VL-72B (72B): Seer 相比 veRL 吞吐量提升了 97%。

• Kimi-K2 (130B): Seer 相比 veRL 吞吐量提升了 77%。

  总体而言，Seer 在不同工作负载下，推演 (rollout) 吞吐量提升了 74% 至 97%。这表明 Seer 的各项优化机制，特别是利用在线上下文学习 (online context learning)，能够有效提升资源利用率，从而大幅加速 LLM 的生成过程。

长尾延迟和总时间减少: 下图（原文 Figure 8）展示了三个 RL 任务的尾部延迟和总时间。

该图像是一个图表，展示了三种模型（Moonlight、Qwen2-VL-72B 和 Kimi-K2）在使用 veRL 和 Seer 系统时的总回滚时间和尾部时间。通过对比，Seer 系统显著减少了时间，分别在 Moonlight、高达 85%、Qwen2-VL-72B 达到 93% 和 Kimi-K2 减少 75%。

• Moonlight: 尾部延迟减少了 85%。

• Qwen2-VL-72B: 尾部延迟减少了 93%。

• Kimi-K2: 尾部延迟减少了 75%。

  长尾延迟 (long-tail latency) 的问题在内存受限的任务（如 Moonlight 和 Qwen2-VL-72B）中尤为突出，其中最后 10% 的请求可能消耗高达总执行时间 50% 的时间。Seer 通过利用在线上下文学习 (online context learning) 和细粒度的请求调度，显著降低了长尾延迟，减少幅度在 75% 到 93% 之间。这极大地改善了系统吞吐量。这证实了 Seer 的设计理念，即通过动态负载均衡、上下文感知调度和自适应推测解码，有效解决了 LLM 长生成任务带来的挑战。

6.2. 改进分解 (Ablation Study)

为了量化 Seer 各个优化组件对整体性能的贡献，论文进行了消融研究 (ablation study)。下表（原文 Table 6）展示了通过增量集成每个主要优化组件所获得的累积端到端加速比。为了最小化系统方差的影响，评估了每个任务的第 5 次迭代（共 10 次）。

表 6: 三个 RL 任务的性能提升分解 (Performance improvement breakdown across three RL tasks)

• 基线 (Baseline): 代表原始的同步 veRL 系统，性能为 1.00x。

• + 分块推演 (+ Divided Rollout):

  • 引入 Seer 的分块推演 (divided rollout) 机制，实现了跨实例的动态细粒度负载均衡，缓解了实例间负载不平衡导致的长尾延迟 (long-tail latency)，并减少了因 KVCache 内存消耗变化而引起的实例内抢占 (preemption) 开销。
  • 此优化对内存受限的任务产生了显著改善，吞吐量 (throughput) 提升高达 35% (Kimi-K2 为 1.35x)。

• + 上下文感知调度 (+ Context Sched.):

  • 在分块推演 (divided rollout) 的基础上，引入上下文感知调度 (context-aware scheduling)。它利用学习到的组内长度分布来指导请求优先级。通过采用近似的最长作业优先 (LFS) 策略，缓解了由长运行请求延迟执行引起的长尾延迟 (long-tail latency)。

  • 此优化提供了额外的吞吐量提升，最高可达 13% (Qwen2-VL-72B 从 1.31x 提升到 1.44x，增加了约 10%)。

  • 下图（原文 Figure 9）展示了 Seer 在 Qwen2-VL-72B 任务推演 (rollout) 迭代期间的 KVCache 利用率和平均运行请求数。与基线（Figure 3a）相比，Seer 在整个推演 (rollout) 过程中保持了持续较高的内存利用率，同时显著缩短了长尾 (tail) 阶段的持续时间。

    该图像是图表，展示了16个实例的KVCache使用情况与平均运行请求数的变化趋势。图中显示，KVCache使用百分比随着时间的推移而逐渐下降，同时平均运行请求数的波动情况也被标示出来。

  • 图 9 显示，在 Seer 的调度下，KVCache 利用率在早期阶段能保持较高水平，并且随着请求的完成，平均运行请求数能更快下降，有效避免了基线中在尾部阶段资源利用率急剧下降的问题。

• + 分组推测解码 (+ Grouped SD):

  • 为了进一步解决尾部请求固有的计算资源利用不足问题，Seer 引入了自适应分组推测解码 (adaptive grouped speculative decoding)。该技术根据运行时特性动态调整推测深度和宽度，并利用共置请求之间的模式相似性来加速 LLM 推理。

  • 推测解码 (speculative decoding) 组件在调度优化之上，额外贡献了 30% 至 44% 的性能提升 (Qwen2-VL-72B 从 1.44x 提升到 1.87x，增加了约 30%)。

    这些结果清晰地表明，Seer 的每一个核心组件都对整体性能提升做出了显著贡献，并且它们协同工作，实现了对同步 RL 推演 (rollout) 阶段的全面加速。

6.3. 上下文感知调度研究

为了验证长度上下文 (length context) 的有效性，论文通过改变调度器可用的长度信息进行了消融研究 (ablation study)。比较了三种情况：

1. 无上下文 (No-Context): 仅应用分块推演 (divided rollout)，不使用长度上下文指导调度。

2. Seer (Context-Aware Scheduling): 应用分块推演 (divided rollout) 和上下文感知调度 (context-aware scheduling)。

3. 预言机 (Oracle): 提前获取所有请求的实际输出长度，并使用这些精确长度指导调度，作为理论最优上限。

   实验在 Qwen2-VL-72B 任务的第 5 次推演 (rollout) 迭代中进行。下图（原文 Figure 10）展示了吞吐量 (throughput) 和长尾延迟 (long-tail latency) 的对比。

   该图像是图表，展示了不同方法下的归一化吞吐量和归一化尾延迟时间。左侧柱状图显示了基线、无上下文、上下文感知和Oracle的归一化吞吐量，分别为1.00x、1.31x、1.44x和1.51x。右侧柱状图则比较了同样方法的尾延迟时间，基线为1.00x，而无上下文、上下文感知和Oracle分别为0.94x、0.13x和0.01x。整体上，图表反映了不同策略在性能上的差异。

• 吞吐量:
  • 无上下文 (No-Context) 相较于基线（1.00x），通过分块推演 (divided rollout) 显著提升了吞吐量至 1.31x。
  • Seer (Context-Aware Scheduling) 进一步提升吞吐量至 1.44x，接近预言机 (Oracle) 的 1.51x。
• 长尾延迟:

  • 无上下文 (No-Context) 仅将长尾延迟从基线的 1.00x 减少到 0.94x，效果有限。这表明分块推演 (divided rollout) 虽然改善了负载均衡，但未能根本解决长尾问题。

  • Seer (Context-Aware Scheduling) 显著将长尾延迟降低到 0.13x，相较于基线减少了 87%。这表明利用长度预测信息进行近似最长作业优先 (LFS) 调度极大地缓解了长尾效应。

  • 预言机 (Oracle) 调度实现了近乎完美的 0.01x 长尾延迟，作为理论最佳性能。Seer 的表现达到了预言机 (Oracle) 性能的 95%。

    实验结果表明，尽管存在预测误差，上下文感知调度 (context-aware scheduling) 仍能提供显著的性能优势，有效解决了长尾延迟 (long-tail latency) 问题。

6.4. 自适应分组推测解码研究

本节探讨了两个关键问题：(1) 分组上下文 (group context) 是否有助于推测解码 (speculative decoding) 性能？(2) 自适应推测解码 (adaptive speculative decoding) 如何提高系统吞吐量？

下图（原文 Figure 11）展示了不同推测解码 (SD) 策略的消融研究 (ablation study) 结果，对比了 Qwen2-VL-72B 任务第 5 次推演 (rollout) 迭代的标准化吞吐量。

该图像是一个图表，左侧展示了不同方法下的标准化吞吐量，其中Seer方法的吞吐量达到1.30x，明显优于其他方法。右侧图表展示了在时间变化下的平均接受长度和运行请求数，表明Seer在资源利用上表现更佳。

• 无 SD (No-SD): 作为基线，禁用推测解码 (speculative decoding)，吞吐量为 1.00x。
• 无上下文 (No-Context): 禁用组内模式上下文共享，吞吐量仅提升到 1.19x。
• 无自适应 (No-Adapt): 禁用自适应调度，吞吐量仅提升到 1.03x，几乎没有提升。
• Seer (+ Grouped SD): 启用了自适应分组推测解码 (adaptive grouped speculative decoding)，吞吐量达到了 1.30x，相较于无 SD (No-SD) 提升了 30%。

分析：

• 分组上下文的有效性: 与无上下文 (No-Context) 相比，Seer 的分组推测解码 (grouped speculative decoding) 取得了显著更高的吞吐量（1.30x vs 1.19x）。这证明了组内模式上下文共享对于生成高质量草稿词元 (draft tokens) 并提高接受率 (acceptance rate) 的重要性。没有组上下文共享，草稿词元 (draft tokens) 质量下降，导致平均接受长度变短，加速效果减弱。

• 自适应策略的重要性: 无自适应 (No-Adapt) 策略仅带来 3% 的微弱提升。这是因为在推演 (rollout) 过程中，批次大小和平均请求长度会发生剧烈变化。固定的 SD 策略容易导致计算瓶颈或计算资源利用不足。

• Seer 的自适应行为: Seer 采用动态 SD 策略，根据当前系统负载和后缀草稿树提供的概率，自适应调整草稿词元 (draft tokens) 的数量。下图（原文 Figure 12）展示了 Qwen2-VL-72B 任务中，平均接受长度在推演 (rollout) 过程中的演变。

  该图像是一个图表，展示了三种模型（Moonlight、Qwen2-VL-72B 和 Kimi-K2）在使用 veRL 和 Seer 系统时的总回滚时间和尾部时间。通过对比，Seer 系统显著减少了时间，分别在 Moonlight、高达 85%、Qwen2-VL-72B 达到 93% 和 Kimi-K2 减少 75%。

  • 在短请求为主、批次较大的早期阶段，系统生成较少的草稿词元 (draft tokens)，导致平均接受长度较低（如 < 2）。

  • 在长请求为主、批次较小的长尾 (long-tail) 阶段，系统生成更多的草稿词元 (draft tokens)，平均接受长度显著提高（超过 3.5）。

  • 这种自适应行为使得系统能够优先加速长请求，从而最大化整体吞吐量 (throughput)。

    综合来看，自适应分组推测解码 (adaptive grouped speculative decoding) 结合了组内模式上下文 (pattern context) 的优势和对动态工作负载的自适应能力，为 Seer 带来了显著的性能提升。

7. 总结与思考

7.1. 结论总结

论文提出了一种名为 Seer 的新型系统，旨在加速同步大型语言模型强化学习 (LLM RL) 的推演 (rollout) 阶段。Seer 的核心创新在于在线上下文学习 (online context learning)，它利用了组相对策略优化 (GRPO) 等算法中，同一提示组 (prompt group) 内请求之间在输出长度和生成模式上的相似性。

通过分块推演 (divided rollout)，Seer 实现了细粒度的动态负载均衡和高效的 KVCache 管理，显著减少了因内存波动和负载不平衡导致的抢占 (preemption) 和资源浪费。上下文感知调度 (context-aware scheduling) 利用推测请求 (speculative requests) 在线估计组内请求长度，并采用近似最长作业优先 (LFS) 策略，有效缓解了长尾延迟 (long-tail latency) 问题。自适应分组推测解码 (adaptive grouped speculative decoding) 则通过分布式分组草稿服务器 (DGDS) 和压缩后缀树 (CST) 聚合组内模式上下文，动态生成高质量的草稿词元 (draft tokens)，并在系统负载变化时自适应调整推测范围，进一步加速了推理过程。

实验结果表明，与现有最先进的同步 RL 系统相比，Seer 在生产级 RL 工作负载上实现了 74% 至 97% 的端到端推演吞吐量提升，并将长尾延迟降低了 75% 至 93%。这些成果在严格保持了同步 RL 算法保真度 (algorithmic fidelity) 的前提下，极大地加速了 LLM 的 RL 训练迭代。

7.2. 局限性与未来工作

论文没有明确列出“局限性与未来工作”的章节，但从其专注点和未提及的方面可以推断出一些潜在的局限性和未来研究方向：

潜在局限性:

• 对 GRPO-like 算法的依赖: Seer 的核心优势在于利用了 GRPO 等算法中“组”的概念。如果未来的 RL 算法不采用这种分组采样模式，或者组内请求的相似性不再显著，Seer 的上下文学习 (context learning) 机制可能效果会大打折扣。
• DGDS 和 CST 的开销: 维护分布式分组草稿服务器 (DGDS) 和压缩后缀树 (CST) 会引入一定的通信和计算开销。虽然论文提到了优化（如异步追加、增量同步），但在极端高并发或超大规模的场景下，这些开销是否仍可忽略，需要进一步验证。
• 预测误差的影响: 上下文感知调度 (context-aware scheduling) 依赖于对请求长度的预测。尽管论文展示了其接近预言机 (Oracle) 的性能，但预测误差在特定情况下可能导致次优调度。
• 通用性挑战: Seer 针对长生成、CoT 推理等特定工作负载进行了优化。对于其他类型的 RL 工作负载（例如，生成短文本、不同奖励模型评估机制）其性能优势可能有所不同。
• 全局 KVCache 池的扩展性: 尽管全局 KVCache 池 (Global KVCache Pool) 提供了两层存储（DRAM/SSD），但随着模型规模和生成长度的进一步增加，其管理和传输开销可能会成为新的瓶颈。

未来可能的研究方向:

• 泛化到更广泛的 RL 算法: 探索 Seer 的上下文学习思想如何应用于非 GRPO 类型的 RL 算法，或在组内相似性不那么明显的场景下进行优化。
• 更智能的长度和模式预测: 结合更先进的机器学习模型来预测请求长度和生成模式，进一步提高调度和推测解码的准确性。
• 跨迭代上下文学习: 除了组内上下文，是否可以利用跨迭代的上下文信息（例如，历史迭代中的生成模式）来进一步优化？这可能需要更精妙的设计来避免引入离策略问题。
• 混合同步/异步模式: 探索 Seer 的优化技术如何与部分异步 RL 方法结合，以在算法保真度 (algorithmic fidelity) 和效率之间取得更好的平衡。
• KVCache 管理的进一步创新: 针对超长上下文和超大模型，研究更高效的全局 KVCache 池 (Global KVCache Pool) 设计，例如基于深度学习的压缩、更智能的预取策略等。
• 动态资源分配: 将 Seer 的调度机制与更细粒度的资源分配策略（例如，动态 GPU 显存分配）结合，以实现更极致的资源利用率。

7.3. 个人启发与批判

个人启发:

• 系统-算法协同设计的重要性: Seer 成功的关键在于深入理解了 LLM RL 训练的算法特性（GRPO 的分组），并将其与系统层面的优化（调度、内存管理、推理加速）紧密结合。这强调了在人工智能系统设计中，不能孤立地看待算法和底层系统，而是要进行系统-算法协同设计 (system-algorithm co-design)。
• 挖掘“隐藏”的上下文信息: 论文巧妙地利用了“同一提示组内请求的相似性”这一之前被忽视的上下文信息。这提示我们，在许多看似独立的任务或数据点中，可能存在尚未被充分利用的内在关联，这些关联可以成为性能优化的宝贵资源。
• “探针”机制的通用性: “推测请求 (speculative request)”作为在线探针 (probe) 来获取任务属性（如长度估计）的思路非常通用且有效。这种方法可以应用于其他需要预知任务属性以进行优化的场景。
• 自适应机制的价值: 自适应草稿范围 (adaptive draft range) 成功解决了静态推测解码在动态工作负载下的效率问题，再次证明了动态、自适应策略在复杂系统中的重要性。

批判:

• 过度依赖 GRPO 结构: Seer 的核心假设是 RL 算法会生成“组”请求，且组内请求具有相似性。如果未来 RL 算法向完全非分组、高度异构的生成模式发展，Seer 的核心优势将不复存在。这种对特定算法范式的依赖可能限制其长期通用性。
• 复杂性成本: Seer 引入了分布式分组草稿服务器 (DGDS)、压缩后缀树 (CST) 和复杂的调度逻辑。虽然带来了显著性能提升，但这种复杂性也意味着更高的开发、部署和维护成本。对于中小型团队或资源有限的场景，其适用性可能受限。
• 可观测性和调试难度: 复杂的分布式系统和高度动态的调度机制可能会增加系统的可观测性和调试难度。当出现性能问题时，定位瓶颈可能更具挑战性。
• KVCache 预取策略的详细程度不足: 论文提到全局 KVCache 池 (Global KVCache Pool) 会基于请求队列信息主动预取 KVCache。但具体的预取策略（例如，何时触发、预取多少、如何避免错误预取）没有详细说明，这对于其效率和资源利用至关重要。
• 对异构硬件的考虑: 论文在实验中使用了同构的 H800 GPU。在实际生产环境中，可能会存在异构硬件（不同型号 GPU、不同网络带宽），Seer 的负载均衡和 KVCache 迁移策略如何在这种复杂环境下保持高效，值得进一步探究。