【veRL && HybridFlow】一种高效灵活的RLHF框架

混合编程模型（Hybrid Programming Model）混合编程模型（Hybrid Programming Model）自动映射算法（Auto-Mapping algorithm）自动映射算法（Auto-Mapping algorithm）3D并行混合引擎（3D‑HybridEngine）3D并行混合引擎（3D‑HybridEngine）根本原因：存储需求的不同源于模型是。HybridFl

逆羽飘扬

1067人浏览 · 2025-11-18 16:53:50

逆羽飘扬 · 2025-11-18 16:53:50 发布

系列综述：
💞目的：本系列是个人整理为了学习RHLF优化的，整理期间苛求每个知识点，平衡理解简易度与深入程度。
🥰来源：材料主要源于字节开源的HybridFlow框架进行的，每个知识点的修正和深入主要参考各平台大佬的文章，其中也可能含有少量的个人实验自证。
🤭结语：如果有帮到你的地方，就点个赞和关注一下呗，谢谢🎈🎄🌷！！！

请先收藏！！！，后续继续完善和扩充👍(●’◡’●)

文章目录

概述

基本知识

当前LLM主流训练流程
- 学会说话： 随机初始化的 Transformer 参数矩阵基于海量文本进行自监督预训练得到初始语言模型Initial Language Model
- 说的更好：初始语言模型Initial Language Model基于提示文本集（Prompts & Text Dataset）进行监督微调SFT得到 SFT 模型
- 说的更专业安全： SFT 模型基于具有人类偏好信号的文本（Human Augmented Text）进行强化学习微调RLHF得到最终对齐模型
RLHF概述
- 定义：基于强化学习RL框架，将人类偏好或评价作为奖励信号，从而引导LLM生成更符合人类偏好和价值观的输出
- 在LLM训练中的作用
  - 训练流程：LLM在预训练阶段通过海量文本积累广泛的知识，然后再通过监督微调SFT在特定领域数据集进行训练，从而能够更好的基于指令进行回答
  - 问题：在预训练和 SFT 后，因数据集的有害偏见内容，可能会导致大模型的回答出现偏离人类价值的内容
  - 解决方法：通过引入人类反馈强化学习（RLHF），以进一步使 LLM 与人类价值观保持一致，以构建有用且无害的人工智能
传统RL框架
- 建模：传统的 RL 可以将强化学习过程抽象为数据流图，建模成一个有向无环图（DAG），其中
  - 主要计算部分：每个节点代表一个神经网络的计算操作
  - 主要通信部分：每条边表示神经网络计算之间的依赖关系
- 目标：解决小规模智能体在单一场景下的强化学习任务工程化落地问题
- 核心特点
  - 节点：使用小规模网络（CNN/MLP，通常仅几百 MB），对计算资源要求低，输入输出张量维度小
  - 边：张量顺路传递，小维度的张量可沿着交互逻辑在内存中直接传递，无需额外的中间处理（如耗时的磁盘IO等）
  - 控制器：单控制器调度，传统 RL 任务目标单一，可由单控制器统一指挥调度节点执行顺序
现代大模型RLHF
- 目标：解决LLM在多场景下对齐人类复杂偏好的工程化落地问题，同时提高LLM的训练效率和稳定性
- 核心特点
  - 节点：承载巨型Transformer网络（占用显存几十GB到几百GB参数），单节点通常无法运行完整的LLM，每个节点都进行部分任务的分布式计算
  - 边：高复杂度的张量流转，基于RL的数据流涉及更复杂的模型（例如，用于Actor/Critic/Reference/Reward的 LLM），每个模型都运行不同的计算，导致更加复杂的依赖关系
  - 控制器：多控制器分布式协同调度。因目标复杂（需同时对齐安全性、准确性等多维度人类偏好）、节点众多（策略 / RM / 价值模型独立训练又相互依赖）等问题，单控制器无法支撑
强化学习的核心建模——马尔可夫决策过程（MDP）
- 定义：用于在部分随机、部分可控的序列决策问题中建模智能体与环境的交互，从而描述智能体（Agent）在动态环境中通过交互学习最优行为的数学模型
- 组成（MDP通常表示为五元组 $\gamma)$ ）
  - 状态集S：“环境所有可能样子的集合”，Agent 只能通过观测这些状态来感知当前环境。
  - 动作集A：智能体在特定状态下可采取的动作集合。
  - 转移概率P(s’|s, a)：在状态s执行动作a后转移到下一个状态s'的概率
  - 奖励函数R(s, a, s’)：执行动作后获得的即时奖励，用于量化决策的短期收益，即转移到该状态的结果好坏与否
  - 折扣因子γ： $\gamma \in [0,1]$ 状态转移的奖励折扣因子，用于平衡短期与未来奖励的权重（接近0注重短期，接近1注重长期）
- 基本性质
  - 马尔可夫性：系统动态仅依赖当前状态与动作，与历史无关
  - 最优策略存在性：在有限状态和动作空间下，存在唯一的确定性平稳最优策略（即每个状态对应固定最优动作）
MDP建模
- 状态集S：“环境所有可能样子的集合”，Agent 只能通过观测这些状态来感知当前环境。
- 动作集A：智能体在特定状态下可采取的动作集合。
- 转移概率P(s’|s, a)：在状态s执行动作a后转移到下一个状态s'的概率
- 奖励函数R(s, a, s’)：执行动作后获得的即时奖励，用于量化决策的短期收益，即转移到该状态的结果好坏与否
- 折扣因子γ： $\gamma \in [0,1]$ 状态转移的奖励折扣因子，用于平衡短期与未来奖励的权重（接近0注重短期，接近1注重长期）
- MDP的回合示例
  - 输入 prompt：“请介绍一下量子计算。”
  - Actor 模型生成一段回答（动作）。
  - Critic 模型评估这段回答的质量（价值）。
  - Reward 模型给出一个分数（奖励）。
  - 根据奖励和优势，系统更新 Actor 模型，让它下次生成更好的回答。
RLHF的MDP 决策过程
- RLHF原理：通过 MDP 建模 Actor 模型的文本生成行为，让模型在 “生成 Token→接收奖励→优化策略” 的闭环中，逐步生成符合人类偏好的内容。
- 具体流程
  - 状态（State, S）：对应 “用户输入提示 + 已生成的所有 Token 构成的完整上文”。例如，用户输入 “请解释什么是碳中和？”，Actor 生成 “碳中和是指” 后，当前状态 S 就是 “请解释什么是碳中和？+ 碳中和是指”—— 而非仅 “碳中和是指” 这部分后缀。状态的核心作用是为模型提供 “语义上下文”，确保下一个 Token 的生成符合逻辑连贯性。
  - 动作（Action, A）：对应模型在当前状态下选择的 “下一个 Token”。例如，基于上述状态 S，模型可能选择 “企业”“国家”“人类” 等 Token 作为下一个动作，动作空间 A 即模型的完整词汇表（如 Llama-2 的 32000 个 Token）。
  - 策略（Policy, π）：对应 Actor 模型本身，策略的目标是在给定状态 S 下，输出每个动作 a（Token）的选择概率 π(a|S)（由 actor logits 经 softmax 转化而来），本质是 “基于上下文预测最优 Token 的概率分布”。
  - 奖励（Reward, R）：对应奖励模型（RM）对 “完整生成文本” 的一次性量化评估，是 MDP 奖励过程最核心的特性 ——延迟性。
- RLHF 中 MDP 的奖励具有显著的 “延迟性”
  - 奖励触发时机延迟：模型生成每个 Token 时，不会立即获得奖励反馈。只有当整个文本序列生成完成（即 “一个回合结束”），奖励模型才会根据文本的 “人类偏好度”（如准确性、流畅性、无害性）给出一个统一的奖励分数 R
  - 奖励覆盖整个回合动作：这个延迟奖励 R 并非针对某个单一 Token（动作），而是对整个回合中所有动作（Token 序列）的 “集体评价”。模型需要通过这个 “全局奖励” 反推每个 Token 选择的优劣，进而调整后续生成策略
MDP 的奖励执行过程（结合RLHF 的 PPO 流程）
- 初始状态触发：用户输入提示 S₀（如 “请说明垃圾分类的意义”），作为 MDP 回合的初始状态。
- 序列动作执行：Actor 模型基于 S₀生成第一个 Token a₁（如 “垃圾分类”），形成新状态 S₁=S₀+a₁；再基于 S₁生成 a₂（如 “的意义”），形成 S₂=S₁+a₂；重复该过程直到生成结束符，得到完整 Token 序列 a₁→a₂→…→aₙ，对应状态序列 S₀→S₁→…→Sₙ₋₁。
- 延迟奖励计算：奖励模型接收完整的 “提示 - 回答对”（S₀ + a₁→aₙ），输出回合奖励 R（如 R=0.7，代表该回答符合人类偏好但仍有优化空间）。
- 优势函数反推：Critic 模型基于每个状态 Sᵢ（i=0 到 n-1）的价值预测 V (Sᵢ)，结合最终奖励 R 计算优势函数 A (Sᵢ, aᵢ)=R - V (Sᵢ)—— 该值量化了 “在状态 Sᵢ下选择动作 aᵢ” 的实际价值与预期价值的差异。
- 策略优化更新：Actor 模型利用优势函数 A (Sᵢ, aᵢ) 调整策略，对 A>0（即动作 aᵢ提升了最终奖励）的 Token 选择增加概率，对 A<0 的 Token 选择降低概率；同时更新 Critic 模型，让其价值预测 V (Sᵢ) 更接近实际奖励 R。

RLHF理论概述

RLHF相关知识
- 定义：基于人类偏好的强化学习（RLHF，Reinforcement Learning from Human Feedback）是一种训练微调方法，建立在传统的 RL 算法之上，广泛采用近端策略优化方法PPO，用于将大型语言模型（LLM）与人类偏好对齐。
- 原理：通过引入人类偏好信号（对模型输出的反馈，通常是排序或评分）来替代传统 RL 中的“奖励函数”来训练模型，使其生成更符合人类期望的内容。
- 优点：相比传统的监督微调（SFT），RLHF 能更好地处理主观性、复杂性和安全性问题
RLHF 数据流图
- 定义：是一种通过节点定义计算任务、边定义数据依赖的方式，将 PPO、Safe-RLHF 等算法的三阶段逻辑（生成→准备→训练）转化为结构化的可视化流程的数据表示形式
- 组成
  - 节点（Node）：每个节点对应一个模型的核心计算任务，需标注任务类型（生成 / 推理 / 训练）和模型身份（actor/critic/ 参考策略 / 奖励模型等）。例如，“actor - 生成” 节点代表 actor 模型执行自回归生成任务，“critic - 训练” 节点代表 critic 模型执行前向 + 反向计算以更新参数。
  - 有向边（Edge）：表示源节点生成的数据传输给目标节点，例如 actor 生成的提示 - 响应对同时传输给多个目标模型
  - 三阶段逻辑：所有RHLF算法的数据流图均需明确 “生成、准备、训练” 三阶段，确保流程逻辑统一
RLHF 流程（四模型+三阶段）
- 生成阶段（Generation）
  - Actor 模型：根据一批提示（prompts）自回归地生成回答（responses）
  - 计算量：自回归生成，每生成一个 token 需一次前向传递，序列长度 T 和 batch 大小 B 决定总计算量O(B⋅T)
- 准备阶段（Preparation）
  - Reward模型：为完整的(prompt, response) 对进行一次前向传递计算出一个标量奖励 $r_θ(x,y)$
  - Critic模型：为prompt 和已生成的前 t 个 tokens 进行一次前向传递计算出一个每个 token 位置的状态价值 $V_ϕ$ ，从而预测当前对话的未来期望
  - ref_policy模型：与 Actor 模型一样处理相同的(prompt, response) 对，计算KL 散度惩罚 $KL[p_π∥pref]$ ，防止 Actor 偏离原始模型过远（避免“胡言乱语”）
  - 计算量：对于 Critic、Reward 和 Reference 模型，都对整个生成的序列进行一次前向传递来获得所需的值
- 训练阶段（Training）
  - 原理：通过强化学习优化 Actor 和 Critic 模型，用人类偏好替代传统奖励函数，从而实现高效的奖励学习
  - 计算量：进行多轮迭代，每轮包含前向+反向传递（有梯度更新）
RLHF的主流算法
- 近端策略优化（PPO，Proximal Policy Optimization）
  - 原理：
    - 裁剪替代目标（Clipped Surrogate Objective）：通过截断概率比率（如限制在 0.8-1.2 倍）控制策略更新步长，避免策略更新幅度过大导致性能崩溃
    - 广义优势估计（GAE）：结合多步奖励计算优势函数，降低方差并提升样本效率。
    - KL 散度惩罚：防止策略过度偏离参考模型（如 SFT 模型），避免 “灾难性遗忘”。
  - 优缺点
    - 优点：稳定性好，适合LLM训练，并且实践效果好，是ChatGPT/InstructGPT的奠基性算法
    - 缺点：工程实现复杂，需要同时加载4个模型，计算和显存开销巨大
- 直接偏好优化（ DPO，Direct Preference Optimization）
  - 原理：
    - 直接利用人类偏好数据优化策略
  - 优缺点
    - 优点：无需训练额外奖励模型，显存占用低，且可以直接优化人类偏好，减少因奖励模型不准确导致的对齐误差
    - 缺点：对偏好数据质量要求高，计算成本高
- 组相关偏好优化（GRPO ）
  - 原理：GRPO 将人类偏好视为群体决策问题，通过分组比较与归一化提升优化稳定性：
    - 组内 Z-score 标准化：将同一输入下的多个回答奖励值转换为组内相对分数，消除不同组标注尺度差异。
    - KL 散度惩罚增强：强制新策略与参考策略保持相似，防止优化过程中策略偏离预期。
    - 群体偏好聚合：在医疗咨询等安全敏感场景中，GRPO 将有害回答率降低至 0.8% 以下，较 PPO 提升 3 个百分点。
  - 优缺点：
    - 优点：去掉价值网络显存占用低，并且用“组内相对排名”估计优势适配多目标奖励。
    - 缺点：每组必须大量采样，推理/排序成本随样本数线性（甚至二次）增加，训练耗时比 PPO 更长。
基于 PPO 的 RLHF系统（主流）
- 组成
  - 主模型Actor：要进行微调和改进的SFT模型，目标是通过调整自身参数，生成能获得更高奖励的回答
  - 评估模型Critic：将提示prompt和已生成的response 前缀作为当前状态s，计算未来累计期望奖励值V(s)
  - 基准策略模型Reference Policy Network：是初始SFT模型的副本，用于计算当前 Actor 和 Reference Policy 在生成相同回答时的概率分布，如果Actor 偏离 Reference 太远会受到惩罚，从而防止Actor被过度优化，丢失基本的语言能力
  - 奖励模型Reward Model：基于人类对不同回答的排序偏好训练而成，每一个（提示，回答）对计算一个初始的奖励信号），来量化一个回答在“符合人类偏好”方面的好坏程度
- 三阶段逻辑详述
  - 生成（Generation）—— 仅 actor@生成节点
    - 节点：actor@生成节点接收用户输入的 批量提示（Prompts），通过自回归生成
      - prompt-response对：策略执行的观测结果（属性），Actor策略模型在给定提示（prompt）下生成的响应（response）序列
      - actor logits：Token选择的倾向概率（方法），用于计算KL 散度惩罚损失和PPO 策略梯度损失的必要中间量
    - 有向边：同步传输prompt-response对给准备阶段的3个推理节点（critic@推理 、ref_policy@推理 、reward_model@推理）
  - 准备（Preparation）—— 3 个 推理任务节点 接收actor@生成节点传来的 提示-响应对并行前向推理
    - critic@推理节点：输出 状态价值（Values），即对每个响应的 “好坏程度” 的量化评估
    - ref_policy@推理节点：输出参考 logits 概率，作为 actor 模型更新的 “基准概率”，避免更新幅度过大
    - reward_model@推理节点：输出 样本级 / Token 级奖励分数（Rewards），即人类偏好的量化映射
    - 优势值计算节点（无模型）：接收上面三个模型的计算结果（ critic 价值、参考 logits概率、奖励分数），通过 GAE（广义优势估计）算法计算 优势值（Advantages），输出到 actor@训练和 critic@训练节点
  - 训练（Training）—— 2 个 “训练型节点” 更新 actor 和 critic 的参数
    - actor@训练节点：接收优势值``actor logits``参考 logits概率，通过前向计算损失（PPO clip 损失）、反向传播更新自身权重，无数据输出
      - critic@训练节点：接收优势值、状态价值（Values），通过前向计算 MSE 损失（价值预测与真实优势值的误差）、反向传播更新参数，无数据输出
    - 执行逻辑：若数据流图将两节点配置为 “共置同一 GPU 组”，则边标注 “串行执行”；若配置为 “分置不同 GPU 组”，则边标注 “并行执行”（由自动映射算法决定）

异构模型存储

按内存占用排序：Actor模型 ≈ Critic模型 > > Reference模型 ≈ Reward模型

根本原因：存储需求的不同源于模型是推理&训练并用，还是仅执行推理生成

训练：需要保存完整的“训练状态”，包括参数、梯度和优化器状态。其中优化器状态是主要的内存瓶颈，约为6倍参数的显存占用
推理：只需要保存模型参数，内存占用远小于训练。

模型角色	执行阶段任务	存储内容	内存占用特点
Actor（演员）‍	训练 + 生成（推理）	模型参数 + 梯度 + 优化器状态	内存占用最大，需支持训练与生成双重负载
Critic（评论家）‍	训练 + 推理	模型参数 + 梯度 + 优化器状态	与演员类似，但不参与生成，内存略低
Reference（参考策略）‍	仅推理（前向计算）	仅模型参数	内存占用最小，只进行前向传播来计算生成内容的KL散度
Reward（奖励模型）‍	仅推理（前向计算）	仅模型参数	与参考模型类似，预训练好仅用于打分

Critic 在 RLHF 流程中的具体作用
- 核心价值
  - 细粒度化评估：Critic 通过提供每个位置的基准值 $V(s_t)$ ，从而细粒度化生成长回答过程中每个具体令牌的贡献是好是坏
  - 稳定的优化：为 PPO 算法提供了计算优势函数所必需的基准值，从而使得 Actor 模型能够进行高效、稳定且细粒度的策略优化
- 原理
  - 经验收集与评估阶段
    - 生成回答： Actor 模型根据提示生成一个完整的回答。
    - 前向传播：对于这个生成的回答，Critic 模型会进行一次前向传播。为回答中的每一个令牌位置 t 都输出一个价值估计 $V(s_t)$ ，即从当前位置t到回答结束的期望奖励
  - 优势函数计算
    - 实际奖励：由 Reward Model 给出的最终奖励 R，并减去基于 Reference Model 的 KL 惩罚，得到调整后的奖励。
    - 预测价值： Critic 为每一步预测的价值 $V(s_t)$
    - 计算每个生成步骤 t 的 $优势函数 A(s_t) = (实际获得的累计奖励) - (Critic预测的期望奖励 V(s_t))$
      - $A(s_t) > 0$ ：在状态 $s_t$ 下生成令牌 $a_t$ 的实际效果优于 Critic 的预期。这是一个“惊喜”，Actor 应该加强在此状态下生成该令牌的行为。
      - $A(s_t) < 0$ ：在状态 $s_t$ 下生成令牌 $a_t$ 的实际效果差于 Critic 的预期。这是一个“失望”，Actor 应该减弱在此状态下生成该令牌的行为。
      - $A(s_t) = 0$ ：实际效果与预期一致。
  - 优化阶段
    - 作为被优化的对象：通常使用均方误差损失，最小化预测值 $V(s_t)$ 与目标值（如基于实际奖励计算的回报）之间的差距，反向传播更新Critic权重，使其预测更精准。
    - 作为 Actor 优化的指导者：PPO 用于更新 Actor 策略的目标函数使得Actor 的更新方向是 $最大化 (策略概率比) * A(s_t)$

RLHF的执行机制

RHLF的执行
- 难点
  - 多模型协同：RLHF 流程涉及多模型协同，且模型多为百亿参数级，需要借助分布式架构才能运行
  - 多阶段计算：RLHF算法执行过程涉及多个阶段，包括生成、准备、训练等
- 解决方法：采用控制器范式作为底层调度架构，解决RLHF 中多模型协同的分布式任务调度和数据通信问题
控制器范式分类
- 单控制器范式
  - 本质：单控制器在只包含少量节点的RLHF数据流图，可通过全局视图和较小的控制开销实现资源协调
  - 优点
    - 全局优化：拥有硬件资源和整个数据流的全局视图，能够灵活地进行资源映射和执行顺序协调
    - 简化开发：用户可以将数据流的核心功能写成一个进程，单控制器通过“封装 + 自动调度 + 数据抽象”，自动化的分布式训练
  - 缺点
    - 调度开销大：在大型集群中，控制器需要向所有工作节点发送协调消息，随着规模扩大，控制开销可能成为瓶颈
    - 单点故障风险：控制器是整个系统的核心，一旦出现故障，整个数据流执行将受到影响
- 多控制器范式
  - 本质：每个设备（或工作进程）配备独立控制器，自主管理本地计算，设备间通过点对点通信协调数据依赖
  - 优点
    - 高可扩展性与低开销：控制责任被分散到各个工作节点，节点间通过高速链路（如PCIe）进行点对点通信，调度开销低，非常适合在大型集群上扩展。
    - 无单点故障：由于没有中心控制器，单个节点的控制器故障不会导致整个系统瘫痪，容错性更好。
  - 缺点
    - 开发复杂：在每个设备上对应的分布式系统控制逻辑和计算逻辑的代码相互嵌套，难以维护和扩展
    - 缺乏全局视图：每个工作节点只拥有系统状态的局部视图，难以实现全局性的优化决策
    - 协调复杂：需要显式地通过点对点通信来协调不同模型或组件之间的执行顺序，增加了程序的复杂性和出错风险
HybridFlow 框架解决方法
- 混合控制器调度
  - 原理
    - 节点内：采用多控制器范式并行驱动多个模型进行高效的分布式计算
    - 节点间：采用单控制器范式全局协调模型间的数据通信
  - 作用
    - 由单控制器统筹全局控制流，多控制器负责本地计算流，从而解耦计算和控制，使每个模型能够专注于本地计算
- 3D-HybridEngine 零冗余重分片
  - 原理
    - 零内存冗余：优化内存管理，避免为同一模型的不同并行策略保存多份参数副本。
    - 高效重分片：显著减少在训练和生成阶段之间切换时，因模型并行策略不同而导致的参数重分片通信开销。
  - 目标：解决 RLHF 中 Actor 模型“如何高效执行” 的瓶颈问题，特别是训练和生成（推理）阶段间的切换开销。
- 自动设备映射算法（Auto-Mapping）
  - 目标：基于模型结构、集群GPU拓扑和单卡内存限制，计算最优模型放置策略和并行策略，从而最小化每轮 RLHF 迭代时间，动态适应资源需求变化
  - 输入：模型结构、集群 GPU 拓扑、内存限制
  - 输出：最优模型放置策略 + 并行策略（如 actor 放 64 卡，critic 放 32 卡）
  - 目标：最小化每轮 RLHF 迭代时间，动态适应资源需求变化（如 generation 阶段 GPU 需求高，training 阶段 memory 需求高）
并行策略
- 数据并行（DP）
  - 原理
    - 复制模型：将完整的模型副本存放在多个设备（如GPU）上
    - 分割数据：将一批输入数据分割成多个更小的子集（微批次），每个设备处理一个子集
    - 梯度同步：在每个训练步骤结束时，所有设备同步彼此的梯度更新，以确保模型副本保持一致
  - 相关优化： ZeRO 通过将原来每个GPU需存储的完整优化器状态、梯度和模型参数进行分片存储在不同GPU上，从而极大降低每个GPU的内存开销
- 流水线并行（PP）
  - 原理：
    - 将模型的执行流程按序纵向切分，将每个阶段放置在不同的设备上，解决单个设备无法容纳整个模型的问题
  - 相关优化：通过流水线并行优化技术（如DualPipe），减少流水线气泡，提高设备资源利用率
- 张量并行
  - 原理
    - 将模型张量（权重、激活值、梯度）按维度拆分到多个 GPU，解决单设备内存不足问题，但增加跨GPU张量传输的通信开销
  - 相关优化：零冗余重分片和计算通信重叠
- 3D并行
  - 原理（同时使用流水线并行、张量并行和数据并行）
    - 模型拆分：用 PP 和 TP 将一个巨大的模型“拆分”到一组GPU上，形成一个可运行的模型实例
    - 提高效率：通过 DP 将这个模型实例复制多份，形成多个副本，在不同的数据子集上并行训练
模型放置策略
- 模型共置：多个小模型部署在同一组 GPU，共享 GPU 内存，通过 “分时调度” 执行（同一时间仅一个模型占用计算资源）
- 模型分置：模型部署在不同的GPU组，计算和显存资源完全隔离，可以并行执行
HybridFlow 中 RLHF 数据流的放置策略
- Dataflow Graph D：数据流图是典型的PPO三阶段
  - 生成Gen：Actor 模型生成回答
  - 计算Value ：Critic、Ref（参考模型）、RM（奖励模型）进行前向推理
  - 训练Training：Actor 和 Critic 进行训练（反向传播 + 优化器更新）
  - 注意：在RLHF数据流中，Actor 模型的训练和生成由两个节点表示，通过使用不同的并行策略来优化两个阶段中的吞吐量，但在运行时在两个阶段之间重新分片演员模型权重可能会产生显著的通信和内存开销
- Placement：展示模型在 GPU 设备上的物理放置方式
  - Actor -> A:0-1：Actor 模型放置在 GPU 0 和 1
  - Critic -> B:2-3：Critic 模型放置在 GPU 2 和 3
  - Ref 和 RM -> C:4-5：参考模型和奖励模型共同放置在 GPU 4 和 5（因为Ref 和 RM都只执行前向推理，内存占用小，可以共享GPU内存，并以分时的方式顺序执行）
- Execution Pattern：基于上述策略，各阶段的实际执行时序
  - Gen 阶段：只有 Actor 在 0-1 上运行
  - Value 阶段：Ref 和 RM 在 4-5 上并行运行，Critic 在 2-3 上运行
  - Training 阶段：Actor 在 0-1 上训练，Critic 在 2-3 上训练
- 结论：通过将模型放置在不同设备上，可以实现阶段间的并行执行，但也可能引入设备空闲时间（如 Actor 在 Value 阶段空闲），所以需要权衡设备空闲与通信开销，提高分布式模型的并行度
现有RLHF系统的局限性
- 分阶段策略优化
  - 思路：训练阶段将权重按使用数据并行优化策略ZeRO节省显存，但在生成阶段切换到模型并行策略TP以加速推理
- Zero-redundancy model resharding ：参数重分片技术
- 数字1‑6分别代表响应生成、奖励模型推理、参考模型推理、评论家推理、演员训练和评论家训练

RLHF系统	DeepSpeed-Chat	OpenRLHF	NeMo-Aligner	HybridFlow
训练方式	ZeRO	ZeRO	3D Parallelism	3D Parallelism, ZeRO, FSDP
生成方式	TP	TP	3D Parallelism	3D Parallelism
Actor模型权重的训练和生成	重新分片（reshard）模型权重，从 ZeRO 的数据维度分片，转为 TP 的张量维度分片	训练阶段不断更新主权重后，替换推理阶段的权重副本，即维护两份Actor权重	通过 LoRA 开关实现训练和推理对同一个Actor权重的时分复用	不再全局 all-gather 拼出完整权重再切分，通过对参数分片的放置策略，让同一个GPU训练阶段使用的参数分片在生成阶段直接复用，最后只需在微数据并行组”(micro-DP) 内部做一次性 all-gather即可
模型放置策略	所有模型共置在同一组设备上	每个模型放置在独立设备上	Actor/Ref 在部分 GPU 上共置，Critic/RM在其他GPU上共置	支持各种模型放置方式
执行策略				支持各种执行方式

系统架构

HybridFlow架构

HybridFlow的架构
- 输入层：用户的输入配置，作为框架运行的基础参数
  - RLHF 数据流图：定义具体 RLHF 算法的流程（如 PPO、Safe-RLHF 的三阶段逻辑），包含模型间的数据依赖关系。
  - 模型配置：指定模型的具体信息，如架构、规模及任务类型（训练 / 推理 / 生成）等
  - 设备配置：集群中硬件信息，如 GPU 的数量、单卡内存容量、设备间带宽
- 核心处理层：将用户配置转化为可执行的分布式任务
  - 混合编程模型（Hybrid Programming Model）
    - 底层调度：通过混合控制器范式，在节点间采用单控制器提高任务调度灵活性，节点内采用多控制器提高计算执行效率，从而实现
    - 中层封装：基于多控制器范式封装每个模型的分布式计算逻辑和多种并行策略，使得用户无需关注底层分布式计算细节。
    - 上层协同：通过预定义协议统一模型间数据重分片逻辑，从而能够基于单控制器范式自动处理不同并行策略模型间的数据传输
  - 3D-HybridEngine
    - 核心功能：支持actor 模型训练与生成阶段采用不同的 3D 并行配置（如训练用大 TP/PP 小 DP，生成用小 TP/PP 大 DP）
    - 原理：通过优化的并行组划分和权重重分片策略，实现零内存冗余和极低通信开销的阶段切换。
  - 自动映射算法（Auto Mapping）
    - 核心目标：根据用户配置和硬件信息，自动优化 “模型 - 设备” 的映射关系，最大化集群吞吐量。
    - 优化内容：
      - 模型放置（Model Placement）：决定哪些模型共置（Colocate）在同一组 GPU、哪些分置（Split/Standalone），平衡并行执行与内存占用。
      - 设备分配（Device Allocation）：为每个模型分配最优数量的 GPU（如给 actor 分配更多 GPU 降低生成 latency）。
      - 并行策略选择：为每个模型的不同阶段（训练 / 生成 / 推理）选择最优并行配置（如 TP/PP/DP 大小）
  - 资源层：将物理设备抽象成可调度的资源，从而支持模型的灵活放置
    - 同一资源池的 GPU 供一组模型共置使用，不同资源池的 GPU 相互隔离，避免内存冲突。
    - 核心处理层的组件通过资源池将任务调度到具体设备上
整体工作流程（需要通过源码确认执行顺序）
- 初始化：基于用户配置进行资源初始化
  - 资源虚拟化：将集群 GPU 抽象成资源池，即创建ResourcePool实例映射到物理 GPU
  - 模型创建
    - 根据输入的模型规格，基于模型类API初始化 Actor、Critic 等模型
    - 并行策略绑定：将执行不同任务的模型（自回归生成/推理/训练），绑定合适的3D并行策略
    - 传输协议绑定：为各模型操作绑定传输协议，统一模型间数据重分片逻辑
  - 设备分配：通过 Auto Device Mapping 算法，根据模型规模将各个模型动态部署到不同的资源池，如轻模型 Ref+RM 共置，重模型 Actor+Critic 分置
- 三阶段：生成→准备→训练
  - 阶段 1：Actor 生成响应
    - 中央控制器调用actor.generate_sequences(prompts)，下发生成任务；
    - Actor 的每个 GPU worker（多控制器）按 3D 并行策略执行自回归生成，通过本地并行组同步 KVCache 与权重
    - 生成完成后，3D_PROTO协议的collect函数聚合各 DP 组的响应数据，反馈给中央控制器。
  - 阶段 2：数据准备
    - 控制器调用critic.compute_values(responses)、reward.compute_reward(responses)
    - 控制器通过distribute函数将 Actor 生成的响应分片到 Critic 与 Reward 的 GPU 集；
    - Critic 与 Reward 的 worker（多控制器）并行执行前向计算，输出价值与奖励，再通过collect函数聚合数据到中央控制器
  - 阶段 3：Actor/Critic 训练
    - 控制器调用actor.update_actor(batch)、critic.update_critic(batch)
    - Actor/Critic 的 worker 执行前向 / 反向传播，通过多控制器同步梯度与权重（如 ZeRO 优化梯度分片）
    - 训练完成后，更新模型权重，准备下一轮迭代
- 结果反馈：控制器聚合各阶段 metrics（如生成吞吐量、训练损失），反馈给用户
  - 迭代触发：学习阶段完成后，单控制器检查是否达到预设迭代次数（如 1000 轮）或性能指标（如 Reward 分数≥0.9），未达标则返回生成阶段，使用更新后的 Actor 模型继续处理新的 prompt 批量数据。
  - 动态优化：每轮迭代后，Auto Device Mapping 算法重新评估系统负载，调整模型并行策略与设备分配（如随着 Actor 性能提升，动态增加生成批量）；同时 3D-HybridEngine 持续优化通信链路，确保吞吐量稳定提升。
  - 终止条件：当迭代次数达标，或连续 10 轮 Reward 分数稳定在阈值以上，框架停止迭代，输出最终优化后的 Actor 与 Critic 模型权重。
数据重分片和异步执行
- 数据重分片：指在分布式系统中，根据需求调整数据在节点间的分配和存储规则，从而将数据更高效地分配到指定存储节点，
- 异步执行：执行一个任务后，无需等待该任务完成，即可继续执行后续任务，待任务完成后通过 “轮询” 或 “通知” 机制处理结果
Actor模型的生成/训练切换问题
- 在 HybridFlow 框架中，actor 模型需在 “生成阶段”（小 TP + 大 DP）与 “训练阶段”（大 TP + 小 DP）间进行权重重分片，异步执行可优化这一过程
- 重分片与数据传输并行：actor 权重重分片（3D-HybridEngine 实现）在后台异步执行，同时 critic、奖励模型可异步接收 actor 生成的 “提示 - 响应对” 并执行前向推理，避免重分片阻塞数据流转
- 任务完成通知触发下阶段：重分片完成后，通过异步通知触发 actor 训练阶段的参数加载，无需训练线程轮询重分片状态，缩短阶段切换时间
代码架构
- 基类3DParallelWorker：
  - 作用：根据3D并行配置和放置策略，将模型的不同部分正确地放置到不同的GPU上，并初始化模型的权重
  - 继承自 3DParallelWorker的模型特化类
    - 系统为RLHF中的不同角色定义了专门的类：ActorWorker（演员）， CriticWorker（评论家）， RefWorker（参考模型）， RewardWorker（奖励模型）
    - 每个类都将对应模型的所有分布式计算操作，将带有数据依赖的复杂分布式代码与其他模型隔离开，只需要调用对应专用模型类的接口即可
- 基类ParallelWorker
  - 作用：以一致的方式管理和调度使用不同并行策略的模型
  - 继承类
    - 3DParallelWorker：3D混合并行策略，当单个GPU无法容纳整个模型时，进行LLM的切分
    - FSDPWorker： PyTorch Fully Sharded Data Parallel（完全分片数据并行），在数据并行的基础上，将每个模型的参数、梯度、优化器状态都进行分片，每个GPU只保留一部分。在需要时才从其他GPU收集所需的参数碎片
    - ZeROWorker：解决大模型训练时的显存瓶颈。ZeRO有不同的阶段（Stage 1, 2, 3），分别对优化器状态、梯度和参数进行分片
节点间的通信流程
- 原因：在RLHF流程中， 多模型 + 不同并行策略导致多对多广播，模型会被切分成不同的物理张量布局分布在不同的GPU上。传统的解决方式是将模型权重的不同部分通过all_gather汇聚起来，然后再根据策略重新分发scatter到目标上
- 优化
  - 通过使用 @register 装饰器，将每个模型的操作（如 update_actor）与一个传输协议（如 3D_PROTO）关联起来，每个传输协议由收集函数和分发函数组成
    - 收集函数：当一个模型完成计算后，此函数负责从其分布的多个GPU上，将输出数据聚合为一个逻辑上完整的、全局的数据视图。即收集的是描述了数据在源模型各GPU上的分布情况的元数据描述符
    - 分发函数：解析元数据描述符，目标模型的每个GPU根据自己的数据并行排名，直接向源模型中对应的GPU发起通信，仅拉取自己需要的那部分数据
    - 优化方式：这两个函数构成了数据格式转换的通用“适配器”，使得任何模型都能以自己熟悉的格式接收和发送自己所需的数据部分
- 作用
  - 去中心化：利用“数据未来/数据元描述符”的概念，将密集的数据传输从中心调度中解耦出来，转变为GPU间按需进行的点对点通信
  - 高效传输：通过点对点的、按需的数据拉取，避免了不必要的数据复制和中心瓶颈，最大限度地利用了集群的网络带宽，从而实现了在异构并行策略下的高效数据交换
解耦设计
- 模块化的API设计：为每个模型提供对应的功能类封装其复杂的分布式计算操作
- 混合控制器范式：单控制器主进程定义要执行的任务序列，多控制器子进程复杂高效的执行对应的分布式计算任务，两者通过清晰的接口设计进行交互，从而实现分布式框架和RLHF算法的解耦
- 统一的传输设计：当进行模型间的数据交换时，会自动触发对应注册的收集函数和分发函数，在后台完成可能涉及不同并行策略的、高效的数据重分片

混合编程模型（Hybrid Programming Model）

概述
- 定义：是一种针对 RLHF（基于人类反馈的强化学习）场景设计的分布式计算编程架构
- 原理：采用混合控制器范式和解耦优化
- 组成：模型通过分层 API、标准化传输协议与资源虚拟化机制，将 RLHF 数据流中复杂的分布式计算（如 LLM 训练 / 生成）与数据依赖（如多对多数据重分片）解耦，从而支持灵活调整 RLHF 算法逻辑，又能适配大规模 GPU 集群的高效执行需求
混合控制器范式
- 概述：在节点间（Inter-Node）采用单控制器范式、在节点内（Intra-Node）采用多控制器范式，形成 “全局协调 + 局部高效” 的双层控制模式
- 节点间：单控制器范式（灵活性保障）
  - 控制逻辑
    - 由一个中央控制器统一管理 RLHF 数据流的全局执行，包括：接收用户输入（模型规格、设备配置、并行策略）
    - 初始化模型与虚拟化资源池（ResourcePool）
    - 调度各模型的执行顺序（如先执行 Actor 生成、再执行 Critic 计算）；
    - 协调节点间数据重分片（通过传输协议实现）。
  - 原理优势
    - 拥有全局硬件与数据流视图，可灵活优化资源映射（如模型部署到不同 GPU 集）与执行顺序
    - RLHF 数据流节点数量较少，控制器调度开销远低于节点内分布式计算开销，不会成为性能瓶颈
- 节点内：多控制器范式（效率保障）
  - 控制逻辑：每个设备（如 GPU）作为独立 “worker”，拥有专属控制器，负责：
    - 执行本设备上的分布式计算（如推理、训练和自回归生成）
    - 遵循节点间控制器下发的并行策略（如 3D 并行、ZeRO），构建本地并行组
    - 通过 NCCL 等通信原语完成设备间局部数据同步（如模型权重聚合）
  - 原理优势
    - 多控制器避免了传统单控制器框架中 “中央调度所有算子” 的高开销问题，尤其适配 RLHF 中 LLM 的大规模计算场景（如数十亿参数模型的分布式训练）
    - 控制消息可通过 PCIe 快速在本地 CPU 与 GPU 间传输，调度延迟可忽略
关键解耦逻辑
- 模型的 “分布式计算” 与 “跨模型数据传输” 完全解耦：
- 节点内：仅关注本地计算（如 Actor 生成响应、Reward 计算分数），无需处理与其他模型的通信；
- 节点间：数据传输由中央控制器通过标准化协议自动处理数据格式转换，模型无需感知对方的并行策略
基本组成
- 分层 API：API 是用户与模型交互的核心接口，实现 “对内的分布式计算封装和对外的原子操作暴露”，分为
  - 基础类 API：3DParallelWorker、FSDPWorker、ZeROWorker 封装不同并行策略的底层分布式逻辑，包括设备初始化、并行组构建、权重分片等
  - 模型类 API：ActorWorker、CriticWorker、RewardWorker 继承基础类，提供 RLHF 场景下的原子操作，实现基于 vLLM 实现自回归生成，返回响应与 token 对数概率等操作
  - 传输协议API：3D_PROTO、DP_PROTO、ONE_TO_ALL 等（共 8 种）通过@register注解绑定到模型操作，定义模型间数据的 聚合-分发逻辑
- 资源虚拟化（ResourcePool）
  - 定义：ResourcePool是管理 GPU 设备的虚拟容器，用于实现模型的灵活部署。
  - 核心逻辑：
    - 同一ResourcePool实例对应一组 GPU 设备，模型绑定该实例即部署到这组设备（共置部署）；
    - 不同ResourcePool实例对应不重叠的 GPU 设备，模型绑定不同实例即分离部署；
    - 支持动态调整设备分配（如为 Actor 分配 64GPU、为 Critic 分配 32GPU），避免 OOM（共置模型按时间片执行，分离模型可并行执行）
- 异步数据流执行（Asynchronous Execution）
  - 触发逻辑：模型执行无需显式等待前序模型完成，当输入数据就绪时自动触发：
  - 分离部署的模型：若无数据依赖，可并行执行（如 Actor 生成与 Critic 计算在不同 GPU 集上同时进行）；
  - 共置部署的模型：按控制器调用顺序串行执行（如 Reference 与 Reward 共置时，先执行 Reference 计算对数概率，再执行 Reward 计算分数）
优点
- 高灵活性
  - 支持多算法适配：仅需增减 API 调用即可实现 PPO、Safe-RLHF、ReMax 等算法（如 ReMax 删除 Critic 代码、添加 1 次 Actor 生成）
  - 支持多并行策略：兼容 3D 并行、ZeRO、FSDP 等，可根据模型大小动态调整（如 7B 模型用 FSDP、70B 模型用 3D 并行）
  - 支持多部署方式：通过 ResourcePool 实现模型共置 / 分离部署，适配不同集群规模（小集群共置提升利用率，大集群分离支持并行执行）
- 高执行效率：
  - 节点内多控制器降低调度开销：避免传统单控制器框架中 “中央调度大量算子”造成的延迟
  - 节点间单控制器优化数据传输：通过标准化协议减少多对多数据重分片的通信量，比 DeepSpeed-Chat 等基线降低 55.2% 的传输延迟
  - 支持异步执行：分离部署的模型可并行执行，提升 GPU 利用率
- 低开发成本：
  - 封装分布式细节：用户无需编写集体通信（如 all-gather）、数据重分片代码，仅需调用高层 API
  - 复用现有框架：可无缝集成 Megatron-LM（训练）、vLLM（生成）、DeepSpeed（优化）等现有 LLM 工具，无需重写底层逻辑

3D并行混合引擎（3D‑HybridEngine）

背景
- 问题
  - RLHF 的典型流程需 Actor 模型在 “生成阶段（自回归生成响应）” 与 “训练阶段（基于反馈更新参数）” 间切换，但模型在不同阶段下对3D并行策略的需求不同，导致传统固定的并行策略无法同时兼顾两者需求
- 传统解决方法：
  - 多副本存储：为训练与生成阶段分别存储完整模型权重，但是双副本会大量占用显存导致内存溢出
  - 重分片：并行策略切换需重新拆分模型权重（参数重分片），但是全局通信开销太大
- HybridFlow 框架解决方案：3D-HybridEngine 以 “动态 3D 并行 + 零冗余重分片 + 局部通信优化” 为核心，在同一 GPU 组内实现训练与生成的高效切换
Actor 模型的两阶段（整理）
- 生成阶段：自回归生成提示响应对，计算密集型通常需要大模型并行(TP&PP)，即设置较大的张量并行（TP=8）与流水线并行（PP=4），将模型层与权重拆分到更多 GPU 上，加速前向 / 反向传播与梯度同步。偏好更强的模型并行能力（较大的PP和TP）来更好的拆分单个大模型
- 训练阶段：基于反馈更新参数，内存密集型通常需要大数据并行(DP)，即提升数据并行（DP）规模以处理批量 prompts，避免 GPU 闲置，偏好更强的模型并行能力（较大的PP和TP）来更好的拆分单个大模型
- 冲突后果：若采用固定 3D 并行配置，训练与生成共用同一 TP/PP/DP 参数，导致生成阶段 GPU 利用率低，或训练阶段计算延迟飙升。训练和推理对模型权重的物理布局要求不同
动态 3D 并行策略
- 并行维度设计：定义训练 3D 并行参数 $p_t-t_t-d_t$ 与生成 3D 并行参数 $p_g-t_g-d_g-d$ ，通过约束 $p_t-t_t-d_t = p_g-t_g-d_g-d$ ，确保两阶段使用同一组 GPU，避免跨设备数据迁移
  - 训练阶段：采用 “大 TP + 大 PP + 小 DP”（如 p=4, t=8, d=4），适配计算密集型需求，加速梯度更新；
  - 生成阶段：采用 “小 TP + 小 PP + 大微 DP”（如 p₉=1, t₉=2, d₉=4, d=4），小 TP 预留 KVCache 内存，微 DP（d₉）使总 DP 规模提升至 16，批量处理能力翻倍。
- 自动策略映射：结合 HybridFlow 的 Auto-Mapping 算法，根据模型规格与GPU数量自动生成最优并行参数，无需用户手动配置
具体示例
- 思路：让训练和生成尽可能共享模型权重，并且都运行在同一组物理GPU（𝑁𝑎个），减少切换策略导致的权重传输通信开销
  - 训练阶段：总的GPU数量是 𝑁𝑎 = p (流水线并行大小) × t (张量并行大小) × d (数据并行大小) ，此时 𝑁𝑎 个GPU被组织成了一个p-t-d的3D网格
  - 生成阶段：𝑁𝑎 = p × t × d = pg(生成PP大小) × tg (生成TP大小)× dg(“微数据并行”大小) × d（数据并行组数量），相当于d个小的3D网格：pg (生成PP) × tg (生成TP) × dg (微DP)，能同时处理d*dg个用户提示
拆分大DP
- 数据并行的核心逻辑：复制多份模型副本，各自处理不同数据子集，通过梯度同步保持参数一致
- 大DP的影响
  - 通信量：梯度同步的数据量 = 模型参数总量 × (DP 组大小 - 1)，所以DP越大，梯度同步的数据量越大
  - 通信延迟：随节点数增加会增加all-reduce的延迟，当 DP 规模超过节点数时，必须跨节点通信。而节点间的网络带宽远低于节点内的 PCIe 带宽，跨节点比例越高，通信瓶颈越明显
  - 内存资源浪费：每个副本需存储完整参数与梯度，大 DP 意味着更多模型副本，而每个副本需独立存储完整的模型参数、梯度和优化器状态，即使通过 ZeRO 等技术分片优化器状态 / 梯度，大 DP 仍会导致单卡内存压力过大
- 目的
  - 节点内：用 TP/PP 提升单机利用率（节点内 PCIe 带宽高，适合模型并行）
  - 节点间：用小 DP 组减少跨节点通信（节点间网络带宽低，适合小规模数据并行）
模型权重重分片示例
- 架构：使用2台机器，每台机器配备4个GPU进行Actor的训练和生成
- 并行分组策略
  - 传统张量分组方法：先进行All-Gather操作获取完整的权重副本，然后再根据不同GPU所需的权重分发，引入了显著的显存与通信开销
  - 3D-HybridEngine分组方法：每个GPU只需收集其除可重用的训练权重外的微 DP 组内的其他所需权重即可，通信量随并行度线性下降，显存峰值降低 30–50%

自动映射算法（Auto-Mapping algorithm）

概述
- 问题背景：现有 RLHF 系统（如 DeepSpeed-Chat、OpenRLHF）受限于固定的模型部署策略，无法根据模型规模、集群大小动态调整资源分配，导致资源利用率低、吞吐量瓶颈
- 解决方案：为给定的 RLHF 数据流，在指定 GPU 集群环境下自动搜索最优的模型部署方案（模型与 GPU 的映射关系）和并行策略配置（3D 并行的 PP/TP/DP 规模）
- 目标：最小化单次 RLHF 迭代的端到端延迟，即使得吞吐量最大化
自动映射算法
- 输入
  - RLHF数据流图：包含模型架构和规模、计算任务类型（训练 / 推理 / 生成）和节点间的依赖关系
  - 硬件资源：GPU的数量和内存容量等
- 输出
  - 模型部署配置：每个模型对应的 GPU 集合（如 actor 分配 64 卡、critic 分配 32 卡），支持 “模型共置”（多模型共享同一 GPU 集合）或 “模型独立”（多模型占用不同 GPU 集合）
  - 并行策略配置：每个模型在各阶段的并行参数（如 3D 并行的(p, t, d)，其中p=PP 规模、t=TP 规模、d=DP 规模），需适配模型计算类型（如 actor 生成阶段用 “小 TP + 大 DP”、训练阶段用 “大 TP + 小 DP”）
核心流程
- 枚举部署方案：生成所有可能的模型部署方案，以 PPO 的 4 个模型（actor、critic、reference、reward）为例，部署方案包含
  - 完全共置：4 个模型共享同一组 GPU，如DeepSpeed-Chat
  - 完全独立：4 个模型各占用独立的 GPU 组，如OpenRLHF
  - 部分共置：如 actor+reference 共享一组 GPU、critic+reward 共享另一组，如NeMo-Aligner
  - 其他组合：共 15 种可能
- 验证方案可行性：确定每组共置模型的最小 GPU 数量，避免因 GPU 内存不足导致 OOM 错误
  - 计算逻辑：累加同一 GPU 组内所有模型的内存占用（模型参数、梯度、优化器状态，如 actor 训练需存储参数 + 梯度 + 优化器，reward 推理仅需存储参数）
  - 约束条件：每组模型的总内存占用 ≤ 单 GPU 内存（Q）× 该组 GPU 数量，由此反推该组需分配的最小 GPU 数量
- 搜索最优并行策略：针对每个模型，调用auto_parallel子算法搜索可行策略空间中匹配的最优并行策略
  - 枚举可行并行配置：从最小并行规模（t_min、p_min）开始，枚举所有满足 “p×t×d = 模型GPU分配量” 的组合
  - latency 模拟评估：通过simu模拟器（含训练、推理、生成 3 类子模拟器），基于模型 workload 估算每种并行配置的执行延迟
  - 选择最优配置：选择延迟最小的并行策略，作为该模型在当前 GPU 分配下的最优方案
  - actor 并行策略优化：actor 需同时支持训练和生成，因此auto_parallel会额外验证。生成阶段的并行策略（如小 TP + 大 DP）是否能容纳 KVCache（基于 batch size 和序列长度计算）；若 KVCache 内存不足，则增大 TP 规模（减少单 GPU KVCache 占用），重新评估延迟
- 计算端到端延迟：累加 RLHF 三个阶段（生成、准备、训练）的延迟之和，保留总延迟最小的设备映射方案
  - 同 GPU 组模型：同一阶段内需顺序执行（避免 GPU 资源竞争），延迟为该组内所有模型的延迟之和
  - 不同 GPU 组模型：同一阶段内可并行执行（无数据依赖时），延迟为各组延迟的最大值
- 选择全局最优方案：
  - 对所有部署方案（步骤 1）、所有可行 GPU 分配（步骤 3）、所有最优并行策略（步骤 4）的组合，计算总延迟
  - 保留总延迟最小的组合，作为最终的 “设备映射方案”（best_mapping）
复杂度优化：缓存机制
- 算法的最坏时间复杂度为 $O ((N - 1)! / (k - 1)! (N - k)!)$ （k 为模型数量，N 为总 GPU 数），源于枚举所有部署方案和 GPU 分配。
- 缓存内容：某模型在 “M 个 GPU” 下的最优并行策略
- 缓存作用：当同一模型在不同部署方案中被分配 M 个 GPU 时，直接复用缓存结果，无需重复调用auto_parallel，将搜索时间缩短至 30 分钟以内（远低于 RLHF 训练总时长）

评估

实验设置

集群环境
- 硬件集群：16 台服务器（共 128 块 GPU），单台服务器配备 8 块 NVIDIA A100 80GB GPU，GPU 间通过 600GB/s NVLink 互联，服务器间带宽 200Gbps。
- 软件版本：CUDA12.1、PyTorch 2.1.2、Megatron‑core 0.6.0、NCCL 2.18.1和vLLM 0.3.1
- 核心指标：吞吐量（tokens/sec），计算方式为 “全局 batch 中 prompt 和 response 的总 token 数 ÷ 单次 RLHF 迭代时间”，结果取 10 次热身迭代后的 5 次迭代平均值
RLHF系统吞吐量对比
- 坐标：横坐标为GPU数量，纵坐标为吞吐量
- 颜色：为四种RHLF系统分别为括DeepSpeed‑Chat、Open‑ RLHF和NeMo‑Aligner
- 三组：分别是不同RHLF算法PPO 、 ReMax 和 Safe‑RLHF
- 结论：HybridFlow在8个GPU上实现了至少2.09× 加速。随着GPU数量的增加，HybridFlow在各种模型规模上的强扩展效率为66.8%
模型部署策略评估
- 基本策略
  - Colocate：所有模型共享 GPU，如 DeepSpeed-Chat
  - Standalone：各模型独立 GPU，如 OpenRLHF
  - Split：actor+reference 共享 GPU，critic+reward 共享 GPU，如 NeMo-Aligner
  - HybridFlow：根据自动映射算法优化的部署策略
- 同规格模型集群规模的部署对比
  - 小规模集群（16~64 GPUs）：Colocate 策略最优，因所有模型的计算可充分利用 GPU 资源，避免设备闲置
  - 中大规模集群（96~128 GPUs）：13B 模型采用 Standalone 策略最优（64 GPU 分配给 actor，32 GPU 给 critic，16 GPU 各给 reference 和 reward）；34B 模型采用 Split 策略最优（GPU 均匀分配给两组模型）
  - 核心结论：自动映射算法能根据模型规模和集群大小选择最优部署，吞吐量始终高于固定部署策略
异规格模型的部署对比（actor/reference 为 13B、critic/reward 为 70B）
- 64 GPU 以内，Colocate 策略仍最优（平均吞吐量高 44.8%）
- 96 GPU 时，Split 策略更优
- 128 GPU 时，自动映射算法选择 “actor+reference+reward 共享 64 GPU，critic 独占 64 GPU”，减少经验准备阶段的 GPU 闲置时间
3D-HybridEngine 效率评估
- Actor模型训练&生成切换时间对比（指actor 模型从训练并行策略重分片到生成并行策略的耗时）
  - DeepSpeed-Chat：70B 模型切换耗时达 90s，因需跨所有 GPU 聚合完整参数；
  - OpenRLHF：维护两套 actor 模型副本，切换需同步权重，70B 模型耗时约 85s；
  - HybridFlow：采用优化的并行分组方法，70B 模型切换耗时仅 6.8s，平均减少 55.2% 的切换时间，最大降幅 89.1%
自动映射算法运行时评估
- 概述：自动映射算法用于搜索最优的模型部署和并行策略，其运行时直接影响 RLHF 启动效率
- 运行时表现：随模型规模和 GPU 数量线性增长，70B 模型 + 128 GPU 时运行时间约 103s，远低于 RLHF 训练的总时长（数天）。
- 优化手段：缓存不同模型在不同 GPU 数量下的最优并行策略，避免重复搜索，将最大运行时间控制在 30 分钟内
结论
- 吞吐量：HybridFlow 通过混合编程模型、3D-HybridEngine 和自动映射算法，在各类 RLHF 算法和模型规模下实现 1.53×~20.57× 的吞吐量提升，尤其适合大模型（34B/70B）和大规模集群场景。
- 动态映射：模型部署策略需根据集群规模动态调整：小规模集群优先 Colocate，大规模集群优先 Split/Standalone，自动映射算法可自适应选择最优方案。
- 核心优化：3D-HybridEngine 解决了 actor 训练 - 生成切换的高开销问题，零内存冗余设计和优化的并行分组是核心效率保障。

🚩点此跳转到首行↩︎

参考博客

全球具身智能开发者社区

立足具身智能前沿赛道，致力于搭建全球化、开源化、全栈式技术交流与实践共创平台。

更多推荐

开源聚势·具身启智，杭州这场沙龙给出中国具身智能产业化新答案

全球具身智能开发者社区

YoMo安全机制详解：TLS v1.3如何保护你的AI代理通信

在当今AI驱动的分布式系统中，安全通信已成为不可忽视的核心需求。YoMo作为Serverless AI Agent Framework，采用TLS v1.3加密协议构建了强大的安全防护机制，确保AI代理在地理分布式边缘计算环境中的通信安全。本文将深入解析YoMo的TLS实现原理、配置方法及最佳实践，帮助开发者构建安全可靠的AI应用。## 为什么TLS v1.3是AI代理通信的理想选择TLS

全球具身智能开发者社区

InternScenes开源数据集

数据集介绍 InternScenes 是上海人工智能实验室发布的大规模、可模拟室内场景数据集，论文收录于 NeurIPS 2025。具身人工智能的发展高度依赖于具有场景多样性和逼真布局的大规模、可模拟3D场景数据集。然而，现有数据集通常存在以下不足：数据规模或多样性有限、布局经过"净化"处理导致小物体缺失，以及严重的物体碰撞问题。为解决上述问题，InternScenes 整合