【Task 40】P3O / Adaptive Policy Optimization 论文复现进展

[DreamEnding]

任务信息

• 任务：Task40 - P3O / Adaptive Policy Optimization
• 认领人：@DreamEnding,@yulingma545-ctrl
• 论文：Trust the Batch, On- or Off-Policy: Adaptive Policy Optimization for RL Post-Training
• 参考实现：FeynRL/main@66cedcab17cfb16b1425043fb6d4bf4838d25ea0
• 开发分支：feature/p3o-adaptive-cap
• 当前提交：942ca60197fb760ef2b63da92e46a27c5b159091
• 对比基线：upstream/main@ce650113e01b2c0b1dabbfe3f35cdffd7f3be67d

当前进展

目前已完成 P3O 在 Relax 中的主要工程接入：

• 实现 normalized ESS、ESS adaptive cap 和 P3O loss；
• 使用 optimizer-step 两阶段计算，在全局有效 token 上汇总 S1/S2/N；
• 接入 DP/CP、padding、ragged/dummy micro-batch 和 PP context 传播；
• 将 P3O 接入 Megatron loss、GRPO-like advantage、参数解析和算法注册；
• 输出 ESS、adaptive cap、policy ratio、cap fraction、behavior KL proxy 和有效 token 数；
• 提供 P3O/GRPO 的 on-policy、T=0.6/1.2 temperature mismatch、sync interval=3 配置；
• 增加 rollout policy age、运行身份、resolved args 和失败退出码记录；
• 新增公式、mask、分区不变性、on-policy、分布式、配置及冒烟测试。

相对 upstream/main，当前 P3O diff 为 44 个文件，新增 4,853 行、删除 64 行。

已完成验证

• 当前 HEAD 可收集的 P3O 定向测试：158 passed, 2 warnings；
• ESS、cap、逐 token loss 和 gradient 与 FeynRL golden 值在 1e-6 容差内一致；
• tiny model on-policy 梯度 cosine >= 0.9999、relative L2 <= 1e-4；
• 逻辑 DP/CP/micro-batch、padding、ragged、dummy 和 zero-local-token 不变性测试通过；
• upstream/main...HEAD 全部 P3O 文件的 pre-commit hooks 通过；
• git diff --check upstream/main...HEAD 通过。

正式实验方案

正式复现计划统一使用：

• 模型：Qwen3-4B-Thinking-2507；
• 数据：DeepScaleR-Preview；
• Seeds：42、1234、2026；
• 主对照：Relax P3O、Relax GRPO/PPO、FeynRL P3O；
• 场景：on-policy、T=0.6、T=1.2、固定 policy lag；
• 主要参数：global batch 48、group size 16、response length 4096；
• 统计：三 seed 均值/方差、KL、loss spike、崩溃率、最终效果、吞吐和峰值显存。

正式实验当前状态

当前 HEAD 尚未完成正式实验矩阵，相关实验正在进行中，后续进度会同步更新。
旧版代码进行过历史实验，on-policy 质量、temperature mismatch 稳定性和真实 Qwen 精度门存在 FAIL。

因此目前不能证明：

• DP/CP/micro-batch 在真实 A100x4 生产链上的最终 loss、gradient 和参数更新不变；
• on-policy 训练曲线与 GRPO/PPO 基线处于约定容差内；
• rollout mismatch 下 P3O 至少一项稳定性指标优于 GRPO/PPO；
• 三 seed 均值/方差、吞吐与显存开销满足 Task40；
• 已复现论文稳定性主结果或核心消融表。

待完成

• 在完整 Linux 依赖环境运行全部 P3O 测试、全仓 pytest 和全仓 pre-commit；
• 完成真实 Megatron/NCCL 的 DP、CP、DP×CP、PP=2 和 micro-batch 不变性验证；
• 按上述方案完成 Relax P3O、GRPO/PPO、FeynRL P3O 三 seed 正式矩阵；
• 汇总原始曲线、均值/方差、稳定性、吞吐和显存，生成至少一张论文主结果或消融图；
• 基于最终提交创建 Draft PR，关联 Issue，取得 Python 3.10/3.11/3.12 CI 全绿和 Maintainer review。

交付判断

当前状态：PARTIAL。

核心代码已具备 Draft 工程审查条件，但实验验证、三 seed 统计、稳定性改善和 PR 验收门尚未完成。
当前不能标记为 Task40 完成交付，也不满足可合并条件。

[xiaoliang0601]

Hello，有 RFC 吗？我们先 review 下 RFC，不需要完整的具体实现进展。

[DreamEnding]

以下为RFC，请检阅 @xiaoliang0601

RFC 040：P3O（自适应策略优化）实现

Status: In Review
Authors: @DreamEnding, @yulingma545-ctrl
RFC ID: 040
Tracking: Task 40 - P3O / Adaptive Policy Optimization

执行摘要

文档记录了P3O（基于性能引导的节奏与审慎的策略优化，Policy optimization with Performance-guided Pace and Prudence）的实现，这是一种自适应策略优化算法，用基于Token级重要性比值的有效样本量（ESS，Effective Sample Size）导出的动态上限替代了GRPO/PPO的固定裁剪比率。P3O在同策略场景下以及在受控的推出策略偏差下均能保持训练稳定性。

背景

问题陈述

标准的GRPO/PPO算法使用固定的裁剪比率（例如，ε=0.2）来约束策略更新。这种方法：

• 无法区分同策略（ESS ≈ 1）和异策略（ESS < 1）批次
• 无论实际分布偏移如何，都应用相同的约束
• 在同策略情况下可能过于保守，在异策略情况下则可能审慎不足

P3O解决方案

P3O引入了：

1. 自适应上限：由归一化ESS导出，替代固定ε（论文 Algorithm 2）
2. 行为KL代理：由(1 - ESS)加权，形成自适应信任区域（论文 Eq. 12）
3. 全局ESS范围：在整个优化器步骤（所有微批次 × DP × CP）上计算（论文 Eq. 7）

论文引用：Fakoor et al., "Trust the Batch, On- or Off-Policy: Adaptive Policy Optimization for RL Post-Training" (arXiv:2605.12380v1)

设计原则

1. 分区不变性

约束：无论以下因素如何，ESS和最终损失必须相同：

• 每个优化器步骤的微批次数量
• DP（数据并行，Data Parallel）世界大小
• CP（上下文并行，Context Parallel）世界大小

解决方案：两阶段优化器步骤架构

阶段1（ESS预传递）：no_grad前向 → 局部S1/S2/N → 全局归约 → 冻结上下文
阶段2（训练传递）：相同数据，相同RNG → 使用冻结上限 → 反向传播

2. 最小框架侵入

约束：保持更改的局部化，并与现有Relax功能可组合。

实现：

• 新文件：relax/utils/training/p3o_utils.py、relax/backends/megatron/p3o_step.py
• 修改文件：loss.py、advantages.py、arguments.py、registry.py
• 复用：GRPO优势估计、现有CP工具、Megatron调度

3. 算法保真度

约束：所有公式必须与论文匹配。

关键方程（来自 Fakoor et al. 2026, arXiv:2605.12380v1）：

• ESS：e = sg((S1)² / (N * S2))，其中 S1 = Σρ，S2 = Σρ²，N = 有效令牌数
  （论文 Eq. 7：Effective Sample Size 定义）
• 自适应上限：cap = e（归一化ESS直接作为上限）
  （论文 Algorithm 2, Line 5：adaptive clipping threshold）
• 得分损失：-sg(min(ρ, cap)) * log π_θ * sg(A)
  （论文 Eq. 11：P3O policy gradient with adaptive cap）
• 行为KL代理：K = l + exp(clip(-l, -C, C)) - 1，其中 l = log(π_θ/π_b)，C = 10
  （论文 Eq. 12：behavior KL proxy for sampled tokens）
• 自适应KL损失：(1 - ESS) * K
  （论文 Eq. 11：adaptive trust region weighted by off-policy degree）

架构

组件层次结构

relax/utils/training/p3o_utils.py          # 纯PyTorch原语
├── P3OSufficientStats                     # S1、S2、N数据类
├── P3OStepContext                         # 不可变冻结上限
├── P3OTokenTerms                          # 逐元素损失分量
├── compute_p3o_log_ratio()                # 掩码对数重要性比值
├── compute_p3o_sufficient_stats()         # ESS统计量累积
├── finalize_p3o_step_context()            # 全局统计量 → 冻结上下文
└── compute_p3o_token_terms()              # 得分 + KL损失

relax/backends/megatron/p3o_step.py        # 优化器步骤编排
├── compute_p3o_step_context()             # 两阶段ESS计算
├── synchronize_p3o_stats()                # DP × CP × PP归约
└── p3o_step_context_published()           # 训练传递的上下文管理器

relax/backends/megatron/loss.py            # 损失集成
└── compute_policy_loss()中的p3o分支       # 从args读取冻结上限

relax/components/advantages.py             # 优势估计
└── GRPO路径被P3O复用                      # 组相对优势（仅在 GRPO_STYLE_ADVANTAGE_ESTIMATORS 中添加 "p3o"）

数据流

ESS预传递（no_grad）：

对于每个微批次：
    前向（模型，批次）→ logits
    获取log_probs（logits）→ 当前log_probs
    compute_p3o_sufficient_stats（当前，推出策略）→ （S1_local，S2_local，N_local）
    局部累积

在DP × CP上进行all_reduce（S1，S2，N）（仅流水线最后阶段）
在PP上进行broadcast（S1，S2，N）（从流水线最后阶段）
finalize_p3o_step_context（S1，S2，N）→ 冻结的P3OStepContext

训练传递（with_grad）：

在args上发布冻结上下文
对于每个微批次：
    前向（模型，批次）→ logits
    获取log_probs（logits）→ 当前log_probs
    compute_p3o_token_terms（当前，推出策略，优势，冻结上限）→ terms
    loss = （terms.score_loss + terms.adaptive_kl_loss）.sum（） / global_N
    反向传播（loss）

分布式语义

ESS范围：一个优化器步骤 = 所有DP/CP ranks上的所有微批次

归约策略：

• 流水线最后阶段：all_reduce（stats， SUM， group=DP×CP）
• 所有阶段：broadcast（stats， src=last_stage， group=PP）
• TP副本：独立但等价的组（无跨TP通信）

填充处理：

• 有效掩码排除：提示令牌、填充令牌、CP填充、被掩码的令牌
• ESS仅在 loss_mask == 1 的有效响应令牌上计算

动态CP：每个微批次可以有不同的CP大小；有效掩码尊重每个批次的 dynamic_cp_size 和 dynamic_cp_rank。

实现细节

1. 核心原语（p3o_utils.py）

设计理念：纯PyTorch，无Megatron/mpu依赖，拥有公式和停止梯度边界的所有权。

关键特性：

• Float64统计量以防止归约过程中的精度损失
• 设备常驻无效比值标志（每个微批次无GPU→CPU同步）
• 显式形状检查（无静默广播）
• CUDA张量的异步断言（无流水线停顿）

Epsilon放置：与参考实现匹配

ESS_DENOM_EPS = 1e-8  # 应用为：S1² / （N * （S2 + eps））

行为KL代理：k3风格的采样令牌近似

BEHAVIOR_KL_EXP_CLAMP = 10.0  # 防止数值溢出
K = log_ratio + exp（clip（-log_ratio， -10， 10）） - 1

核心算法代码示例

ESS充分统计量计算（compute_p3o_sufficient_stats_unchecked）：

# 计算重要性比值 ρ = π_θ / π_b
log_ratio = log_probs - behavior_log_probs
log_ratio = torch.where(valid_mask, log_ratio, torch.zeros_like(log_ratio))

# 转换为float64并求指数
ratio = torch.exp(log_ratio.to(torch.float64))
ratio = torch.where(valid_mask, ratio, torch.zeros_like(ratio))

# 非有限值检测（保持在设备上）
invalid_flag = (~(torch.isfinite(log_ratio).all() & torch.isfinite(ratio).all())).to(torch.float64)

# 累积充分统计量：S1 = Σρ, S2 = Σρ², N = 有效令牌数
keep = 1.0 - invalid_flag
return P3OSufficientStats(
    sum_ratio=ratio.sum() * keep,
    sum_ratio_sq=ratio.pow(2).sum() * keep,
    valid_token_count=valid_mask.sum().to(torch.float64) * keep,
), invalid_flag

全局ESS最终化（finalize_p3o_step_context）：

# 从归约后的统计量计算归一化ESS
sum_ratio = stats.sum_ratio.to(torch.float64)
sum_ratio_sq = stats.sum_ratio_sq.to(torch.float64)
count = stats.valid_token_count.to(torch.float64)

# 论文公式：e = (Σρ)² / (N * (Σρ² + ε))
raw_ess = sum_ratio.pow(2) / (count * (sum_ratio_sq + ESS_DENOM_EPS))
ess = raw_ess.clamp(min=0.0, max=1.0)

# 比值的均值和标准差
ratio_mean = sum_ratio / count
variance = (sum_ratio_sq / count) - ratio_mean.pow(2)
ratio_std = variance.clamp(min=0.0).sqrt()

P3O令牌损失项（compute_p3o_token_terms）：

# 计算重要性比值（无梯度）
with torch.no_grad():
    log_ratio = log_probs.detach() - behavior_log_probs
    ratio = torch.exp(log_ratio)
    # 完整的min(ρ, cap)系数被detach
    coefficient = torch.minimum(ratio, cap)
    cap_hits = (valid_mask & (ratio > cap)).float()

# 得分损失：-sg(min(ρ, cap)) * log π_θ * sg(A)
score_loss = -(coefficient * log_probs.float() * advantages.detach().float())

# 行为KL代理：l + exp(clip(-l, -10, 10)) - 1
exponent = torch.clamp(-log_ratio, min=-10.0, max=10.0)
behavior_kl = log_ratio + torch.exp(exponent) - 1.0

# 自适应KL损失：(1 - ESS) * KL_proxy
adaptive_kl_loss = (1.0 - ess) * behavior_kl

2. 优化器步骤编排（p3o_step.py）

重放要求：

• 迭代器位置：预传递前保存，训练传递前恢复
• RNG状态：torch.get_rng_state（） + torch.cuda.get_rng_state_all（）
• 模型状态：必须是确定性的（无dropout，无FP8 amax更新）

上下文管理器：

with preserved_iterator_positions（data_iterator）， \
     preserved_rng_state（）， \
     torch.no_grad（）：
    # ESS预传递
    
with p3o_step_context_published（args， frozen_context）：
    # 训练传递

虚拟微批次处理：

• 虚拟批次（用于DP对齐）贡献 （0， 0， 0） 给统计量
• 通过 batch.get（"__is_dummy__"， False） 检测

两阶段优化器步骤代码示例

ESS预传递与全局归约（compute_p3o_step_context）：

# 阶段1：ESS预传递（无梯度）
local_stats = P3OSufficientStats.zeros()
with preserved_iterator_positions(data_iterator), \
     preserved_rng_state(), \
     torch.no_grad():
    for _ in range(num_microbatches):
        batch = get_batch(data_iterator)
        output_tensor = forward_step(batch, model)
        log_probs = get_log_probs_and_entropy(output_tensor, batch)
        
        stats, invalid = compute_p3o_sufficient_stats_unchecked(
            log_probs, batch["rollout_log_probs"], batch["loss_mask"]
        )
        local_stats = local_stats + stats

# 全局归约：DP×CP all_reduce → PP broadcast
global_stats = synchronize_p3o_stats(
    local_stats, invalid_flag,
    dp_cp_group=mpu.get_data_context_parallel_group(),
    pp_group=mpu.get_pipeline_model_parallel_group(),
    is_pipeline_last_stage=mpu.is_pipeline_last_stage()
)

# 最终化为冻结上下文
return finalize_p3o_step_context(global_stats)

分布式统计量同步（synchronize_p3o_stats）：

# 将统计量与无效标志堆叠为[4]向量
vector = torch.cat([stats.as_vector(), invalid_flag.reshape(1)])

if is_pipeline_last_stage and dp_cp_group:
    # 流水线最后阶段：跨DP×CP归约
    dist.all_reduce(vector, op=dist.ReduceOp.SUM, group=dp_cp_group)

if pp_group and dist.get_world_size(pp_group) > 1:
    # 所有流水线阶段：从最后阶段广播
    src = dist.get_world_size(pp_group) - 1
    dist.broadcast(vector, src=src, group=pp_group)

# 检查全局无效标志
if vector[3] > 0:
    raise ValueError("P3O: non-finite importance ratio")

return P3OSufficientStats.from_vector(vector[:3])

3. 损失集成（loss.py）

分支点：compute_policy_loss（） 在 args.advantage_estimator 上分派

P3O损失分量：

terms = compute_p3o_token_terms（log_probs， rollout_log_probs， advantages， valid_mask， frozen_cap）
token_loss = terms.score_loss + terms.adaptive_kl_loss  # 逐元素
loss = token_loss.sum（） / global_valid_token_count      # 令牌求和归一化

与PPO/GRPO的关键差异：

• 无双侧裁剪（无下界，无 eps_clip）
• 完整的 min（ρ， cap） 系数是分离的（REINFORCE风格）
• 优势始终是分离的（无值函数梯度路径）
• KL项为 （1 - ESS） * proxy，由异策略程度加权

P3O损失集成代码示例

损失函数分派（loss.py 中的 compute_policy_loss）：

if args.advantage_estimator == "p3o":
    # 从冻结上下文读取自适应cap
    step_context = P3OStepContext(
        normalized_ess=args.p3o_normalized_ess,
        adaptive_cap=args.p3o_adaptive_cap,
        valid_token_count=args.p3o_valid_token_count,
        ratio_mean=args.p3o_ratio_mean,
        ratio_std=args.p3o_ratio_std,
    )
    
    # 计算P3O令牌项
    terms = compute_p3o_token_terms(
        log_probs, rollout_log_probs, advantages,
        loss_mask, step_context
    )
    
    # 总损失：得分损失 + 自适应KL损失
    token_loss = terms.score_loss + terms.adaptive_kl_loss
    policy_loss = token_loss.sum() / step_context.valid_token_count
    
    # 记录指标
    metrics = {
        "policy_ratio_mean": terms.ratio.mean(),
        "clip_fraction": terms.cap_hits.mean(),
        "behavior_kl_proxy_mean": terms.behavior_kl_proxy.mean(),
    }

4. 参数和验证

新参数：

--advantage-estimator p3o          # 选择P3O损失
--use-rollout-logprobs             # 重要性比值所需
--calculate-per-token-loss         # 分区不变性所需

验证规则（_validate_p3o_args）：

1. 必须使用推出策略对数概率（无非行为策略的比值）
2. 必须使用按令牌归一化（按样本均值破坏分区不变性）
3. 不能与TIS堆叠（两者都修正相同的偏差）
4. 无Critic（P3O是得分函数估计器）
5. 无Dropout（破坏重放确定性）
6. 无FP8（amax历史在前向时发生变化）
7. 无完全异步模式（预传递需要完整窗口）
8. 无MTP、OPSM、路由重放（不安全于重放）

5. 推出策略滞后

特性：通过 rollout_policy_lag.py 提供可选的可控推出策略偏差

机制：

--rollout-policy-lag-max-staleness 5    # 保留最后5个快照
--update-weights-interval 3              # 每3次推出刷新一次

实现：

• 推出服务每隔刷新周期对策略权重进行快照
• 快照存储在环形缓冲区中（大小 = max_staleness + 1）
• 年龄指标：rollout_policy_age_rollouts（单位：推出次数，非步骤数）

用例：为P3O与GRPO的比较创建可重现的异策略场景。

推出策略滞后实现代码示例

快照管理（rollout_policy_lag.py）：

class RolloutPolicyLagManager:
    def __init__(self, max_staleness: int):
        self.max_staleness = max_staleness
        self.snapshots = []  # 环形缓冲区
        self.rollout_count = 0
    
    def maybe_snapshot(self, model, interval: int):
        self.rollout_count += 1
        if self.rollout_count % interval == 0:
            # 保存当前策略权重
            snapshot = {k: v.cpu().clone() for k, v in model.state_dict().items()}
            self.snapshots.append(snapshot)
            
            # 限制缓冲区大小
            if len(self.snapshots) > self.max_staleness + 1:
                self.snapshots.pop(0)
    
    def get_snapshot_age(self) -> int:
        # 返回最旧快照的年龄（以推出次数为单位）
        return len(self.snapshots) - 1 if self.snapshots else 0

测试覆盖

单元测试

test_p3o_utils.py（423行）：

• ESS计算正确性与参考值对比
• 充分统计量的算术运算（加法、向量化）
• 非有限比值检测（有效位置中的NaN、Inf）
• 填充掩码正确性
• 行为KL代理公式
• 令牌项计算

test_p3o_step.py（390行）：

• 单rank统计量直通
• DP×CP归约正确性
• 从流水线最后阶段的PP广播
• 无效比值标志传播
• 迭代器位置保持
• RNG状态恢复

test_p3o_distributed.py（212行）：

• 多rank ESS聚合（模拟集合通信）
• CP局部有效掩码对齐
• 动态CP元数据处理

test_p3o_partition_invariance.py（110行）：

• ESS对微批次数量不变
• 损失对DP/CP划分不变
• 黄金参考比较

test_p3o_loss.py（119行）：

• P3O损失与手动计算对比
• 上限应用正确性
• 优势梯度阻断

test_p3o_on_policy.py（70行）：

• 当当前 == 推出策略对数概率时 ESS → 1
• 同策略时 P3O损失 → REINFORCE
• 无虚假裁剪

集成测试：

• test_p3o_model_step.py：使用P3O的完整model.step（）周期
• test_p3o_observability.py：指标报告（ESS、cap、比值统计量、裁剪分数）
• test_rollout_policy_lag.py：快照轮转和年龄跟踪

示例配置：

• test_configs.py（507行）：验证启动脚本能解析正确的参数

冒烟测试

位置：examples/algorithms/p3o/run_p3o_smoke.sh

覆盖：

• 一次推出，最小批次大小
• 在4×A100上 <5分钟完成
• 涵盖：ESS预传递、训练传递、指标发射、检查点

用法：

bash examples/algorithms/p3o/run_p3o_smoke.sh p3o_on_policy

实验设置

场景

用于P3O与GRPO比较的四个匹配场景：

场景	--update-weights-interval	推出温度	目标
on_policy	1	（标准）	基线：同步策略
periodic_sync_interval_3	3	（标准）	仅策略滞后
temperature_0p6	1	0.6	仅温度偏差
temperature_1p2	1	1.2	仅温度偏差

所有场景共通：

• 模型：Qwen3-0.6B（来自 scripts/models/qwen3-0.6B.sh）
• TP=2， PP=1（可配置）， DP=2（共4 GPU）
• 全局批次：48个样本，微批次：1
• 优化器：AdamW
• 推出：top-p=0.95， top-k=50
• 最大响应长度：4096个令牌

指标

ESS和上限：

• train/p3o/ess：原始ESS值
• train/p3o/normalized_ess：ESS / N（应与 adaptive_cap 匹配）
• train/p3o/adaptive_cap：本步骤的冻结上限

策略比值：

• train/p3o/policy_ratio_mean：平均重要性比值
• train/p3o/policy_ratio_max：最大重要性比值（检测异常值）
• train/p3o/policy_ratio_std：比值的总体标准差

裁剪和KL：

• train/p3o/clip_fraction：ρ > cap 的令牌比例
• train/p3o/behavior_kl_proxy_mean：采样令牌KL代理
• train/p3o/adaptive_kl_loss_mean：（1 - ESS） * KL_proxy

推出元数据：

• train/p3o/rollout_policy_age_rollouts：以推出为单位的陈旧度
• train/p3o/num_valid_tokens：全局有效响应令牌数

基线（GRPO）：

• train/ppo/approx_kl：标准KL散度
• train/ppo/policy_loss：裁剪的PPO损失
• train/ppo/clipfrac：固定ε下的裁剪比例

验收标准

同策略（ESS ≈ 1）：

• P3O自适应上限应接近1.0
• P3O损失应在容差范围内与GRPO匹配（KL < 0.01）
• 训练曲线应收敛到相似的最终奖励

异策略（ESS < 1）：

• P3O自适应上限应 < 1.0 并跟踪ESS
• 至少一个指标显示改进：更低的KL尖峰、更少的损失尖峰或更好的最终奖励
• 无训练发散或NaN损失

分区不变性：

• 更改 --micro-batch-size 不得改变最终损失（相同全局批次）
• 更改DP/CP划分不得改变ESS或自适应上限

可重现性：

• 每个场景3+个种子
• 报告最终奖励和最大KL的均值/标准差
• 比较吞吐量（令牌/秒）和内存（峰值分配）

实施状态

已完成：

• 核心算法实现（p3o_utils.py, p3o_step.py, p3o_replay.py）
• 损失函数集成（loss.py）
• 参数验证（arguments.py）
• 算法注册（registry.py, advantages.py）
• 推出策略滞后支持（rollout_policy_lag.py）
• 单元测试（13个测试文件，2196行）
• 冒烟测试脚本（5个场景）
• 示例配置（README + 启动脚本）

待完成：

• 完整实验验证（4个场景 × 3+ seeds）
• 性能基准测试（吞吐量、内存占用）
• 与GRPO的对比结果（训练曲线、KL spike、最终奖励）
• 论文复现验证（至少一张主结果图或消融表）

下一步：

1. 运行冒烟测试确认基本功能
2. 执行完整的4场景对比实验
3. 收集性能数据和训练曲线
4. 根据实验结果更新RFC状态为 Accepted 或 Implemented

代码变更摘要

新文件

relax/utils/training/p3o_utils.py              408行  # 纯原语
relax/utils/training/p3o_replay.py              96行  # 迭代器/RNG保持
relax/backends/megatron/p3o_step.py            330行  # ESS编排
relax/backends/megatron/rollout_policy_lag.py  102行  # 快照轮转
                                               ------
                                               936行  # 新增核心代码总计

tests/backends/megatron/test_p3o_*.py          919行  # 9个测试文件
tests/utils/training/test_p3o_*.py             617行  # 2个测试文件
tests/components/test_p3o_advantages.py         62行
tests/examples/algorithms/p3o/test_*.py        598行  # 2个测试文件
                                               ------
                                              2196行  # 测试代码总计

examples/algorithms/p3o/*.sh                   344行  # 启动脚本
examples/algorithms/p3o/README.md               62行
examples/algorithms/p3o/rollout.py              54行
                                               ------
                                               460行  # 示例配置总计

修改的文件

核心集成：

• relax/backends/megatron/loss.py：+79行（P3O分支 - p3o_loss_function()）
• relax/components/advantages.py：+3行（在 GRPO_STYLE_ADVANTAGE_ESTIMATORS 中添加 "p3o"）
• relax/core/registry.py：+6行（P3O算法条目 - ALGOS["p3o"] 映射到 Actor/Rollout/Advantages/ActorFwd）

参数和验证：

• relax/utils/arguments.py：+79行（P3O验证、推出滞后参数）
• relax/utils/utils.py：+21行（P3O指标日志记录）

模型步骤：

• relax/backends/megatron/model.py：+156行（两阶段步骤包装器）
• relax/backends/megatron/actor.py：+114行（推出策略滞后集成）

差异分析

与官方 Relax 仓库（E:\relax\Relax）的对比：

总体增量：

• 新增核心代码：936 行（4 个文件）
• 修改集成代码：458 行（7 个文件）
• 新增测试代码：2196 行（13 个文件）
• 示例配置：460 行（5 个脚本 + README + rollout.py）
• 总计：约 4050 行

P3O所需的更改：

1. ESS计算和步骤编排（新文件 p3o_utils.py, p3o_step.py, p3o_replay.py）
2. 损失函数分派（loss.py 中的 p3o_loss_function() 函数）
3. 参数验证（arguments.py 中的 _validate_p3o_args() 独立函数）
4. 模型步骤包装器（model.py 中的两阶段逻辑）
5. 注册表条目（registry.py 中的 ALGOS["p3o"] 字典条目）
6. 优势估计器集成（advantages.py 中将 "p3o" 加入 GRPO_STYLE_ADVANTAGE_ESTIMATORS）
7. 推出策略滞后支持（新文件 rollout_policy_lag.py，actor.py 中的集成逻辑）

未修改的关键文件（确认最小侵入）：

• ❌ relax/core/trainer.py（训练循环主逻辑）
• ❌ relax/distributed/ray/*.py（Ray 分布式层）
• ❌ relax/engine/rollout_generator.py（推出生成核心，除 rollout_policy_lag.py 外）
• ❌ relax/backends/megatron/optimizer.py（优化器配置）
• ❌ relax/backends/megatron/data.py（数据加载器）
• ❌ relax/components/rollout.py（Rollout 组件基类）
• ❌ relax/components/critic.py（Critic 组件 - P3O 无需价值函数）

已知限制

1. 两阶段开销

代价：ESS预传递每优化器步骤增加约1×前向时间

缓解措施：

• 预传递为 forward_only=True（无反向传播）
• 与训练传递共享流水线调度
• 在每步多次推出中摊销

测量影响：在4×A100上约10-15%的墙上时钟开销（Qwen3-0.6B， batch=48）

理由：两阶段设计是分区不变性的必需代价。论文的参考实现按微批次计算ESS，会导致cap随梯度累积因子变化。Relax的全局ESS方法确保无论DP/CP划分和微批次数量如何，最终loss和cap都保持一致。

2. 重放约束

不能使用：

• Dropout（破坏确定性）
• FP8（amax历史在前向时变化）
• 步骤内的动态批次大小
• 完全异步流式模式

解决方法：这些在 _validate_p3o_args() 中作为硬错误进行验证

理由：预传递和训练传递必须产生相同的 log-probs，否则冻结的cap会基于不同的数据。显式验证优于静默失败。

3. KL代理近似

问题：behavior_kl_proxy 仅使用采样令牌的对数概率，而非完整词汇分布。

影响：不是论文中的精确KL（π_θ || π_b），而是一个一致的替代。

理由：推出重放仅存储采样令牌，而非完整logits（存储完整logits会增加数倍内存开销）。该代理梯度仍能指导自适应信任区域，与论文中 k3 风格的采样令牌近似一致（论文 Eq. 12 注释）。

4. 内存占用

推出策略滞后：在actor内存中存储 max_staleness + 1 个策略快照。

典型：5个快照 × 模型大小。对于Qwen3-0.6B：约3GB额外开销。

理由：可控的rollout mismatch对于验证P3O的稳定性优势是必需的。这是实验设施，不是生产默认配置。

参考文献

Fakoor, R., et al. (2026). "Trust the Batch, On- or Off-Policy: Adaptive Policy Optimization for RL Post-Training." arXiv:2605.12380v1.

关键贡献：

• Eq. 7：Effective Sample Size (ESS) 定义，基于令牌级重要性比值
• Eq. 11：P3O 策略梯度损失，使用自适应cap和(1-ESS)加权的KL项
• Eq. 12：采样令牌的行为KL代理
• Algorithm 2：P3O训练循环伪代码

实现差异：

1. ESS 范围：Relax 在整个优化器步骤上计算全局ESS（跨所有微批次和DP/CP rank），而参考实现按微批次计算。这确保了分区不变性。
2. KL 代理：Relax 使用采样令牌的KL代理（与论文Eq. 12一致），而非完整词汇分布的KL（因推出重放仅存储采样令牌）。

[xiaoliang0601]

审查意见：

1. 当前有 2 个公式实现的不匹配：
   • 论文和 FeynRL 是 per-microbatch ESS；Relax 当前实现是整个 optimizer-step ESS。
   • 论文是 full-vocabulary forward KL；Relax 当前实现是 sampled-token k3 proxy。
2. 风险告知：
   • KL proxy 在极端负 log-ratio 下，梯度方向疑似是错误的。
   • 多模态 token replacement，疑似会破坏 token/logprob 配对。
3. 实现建议：
   • 短期可以拒绝 P3O + OPD 的组合，P3O 独立 loss dispatch 不走普通 compute_policy_opd_loss() 路径。
   • 标注 FeynRL 和原始论文实现不一致的地方，然后说明 Relax 的复现采取的是哪种实现。

[DreamEnding]

任务信息（本次更新）

• 当前工程审阅分支：feature/p3o-adaptive-cap-clean
• 当前工程审阅提交：3313cf569407ad3f75ec29174e2c0c4814c4386e
• P3O Draft PR：【Task 40】Feat(p3o): add ESS-adaptive policy optimization #272（Closes #233；合并前不会自动关闭本 issue）
• 独立 SGLang Draft PR：fix(sglang): clamp deterministic sampler endpoints #271（Related to #233，不单独关闭本 issue）
• 实验冻结版本：a06f465d607ccfc521104ba27ddbb8759b3b04a9

本次已将原组合 PR #234 拆为 P3O 与 SGLang 两个独立 Draft PR；#234 已关闭但原分支保留。

当前进展

目前完成的工程性工作：

• P3O 已接入 ESS、自适应 cap、专用 policy loss、GRPO-style advantage、Megatron loss/actor 路径、参数校验、算法注册和可观测性指标；
• P3O/GRPO A100×4 配方已覆盖 on-policy、T=0.6、T=1.2 和 periodic-sync interval=3 场景；
• 已补齐英文算法文档、中文算法文档、中文 A100×4 配方 README，并把生产 --p3o-kl-mode 收敛为 proxy / proxy_safe；全词表 exact 只保留为纯验证辅助函数；
• 训练 pass 与 P3O 统计 pass 已共用 build_rl_forward_kwargs，统一普通 token、unsplit token、THD VL bridge 和 multimodal kwargs 的选择；动态 CP 合并元数据也已改为语义化命名；
• SGLang 0.5.12.post1 的确定性采样端点修复已独立至 fix(sglang): clamp deterministic sampler endpoints #271，P3O diff 不包含该修复的 4 个 SGLang 文件。

审查意见跟进

针对前述审查意见，当前实现与证据边界如下：

1. ESS scope：旧 RFC 只描述了 optimizer-step ESS。当前生产配方默认使用论文/参考实现兼容的 micro-batch scope；step scope 仍保留为可 replay 的能力验证路径。两种 scope 都存在，不能互相外推实验结论。
2. 全词表 KL：生产运行仍使用 sampled-token proxy / proxy_safe，而不是 full-vocabulary forward KL；该差异已在 PR、双语文档和本 issue 中显式披露，未宣称为论文精确 KL 复现。
3. 极端负 log-ratio：正式配方使用 proxy_safe；它保持 proxy 的前向值，并针对极端负 log-ratio 的梯度进行保护。真实模型端到端效果仍需独立验证。
4. 多模态配对与 OPD：统计/训练前向输入已共享构造 helper，P3O 与 --use-opd 互斥；真实多模态端到端验证尚未完成，不能将该工程性收敛视为完整证明。

已完成验证

当前工程审阅提交（3313cf5）

本地 Windows CPU 环境已通过：

python -m pytest -q \
  tests/backends/megatron/test_data_vpp.py \
  tests/backends/megatron/test_p3o_step.py \
  tests/utils/test_p3o_arguments.py \
  tests/examples/algorithms/p3o/test_configs.py \
  tests/examples/algorithms/p3o/test_rollout.py

python -m pytest -q \
  tests/backends/megatron/test_p3o_cp_metadata.py \
  tests/backends/megatron/test_p3o_step.py

git diff --check upstream/main...HEAD

结果：第一组 101 passed, 2 warnings；CP 元数据回归 24 passed, 2 warnings；git diff --check 通过。独立 SGLang 端点测试为 6 passed。

历史冻结实验（a06f465）

归档证据显示：

• FeynRL CPU formula oracle 通过：ESS 绝对误差 1.05e-9、loss sum 差 0、gradient 最大绝对差 1.19e-7；
• 最小化 on-policy 诊断中，P3O DP4 的 ESS mean/min 为 0.9993836590 / 0.9989917435，GRPO DP4 为 0.9993828089 / 0.9989861105，两者每步均不低于 0.99；
• 五个真实模型拓扑 run 均 exit 0，均有 30/30 metric steps 与 30/30 rollout files；这证明链路可以执行，但不等价于数值分区不变性通过。

正式实验当前状态

2026-08-11 的正式矩阵包含 4 个场景 × 2 个算法 × 3 个 seed，共 24/24 execution-valid run；但质量门后 P3O 为 0/12 quality-eligible run，四个 family 均为 VALID_FAIL，因此没有可用于声明 P3O mismatch 稳定性改善的质量合格 matched pair。

2026-08-12/13 的较晚真实模型分区验证优先于早期合成/NCCL 结论。Qwen2.5-1.5B-Instruct、4×A100-40GB 的冻结结果为：

指标	冻结相对容差	最大相对误差	判定
p3o_global_ess	1e-3	0.000189463	PASS
p3o_behavior_kl_proxy	1e-3	0.211947	FAIL
lm_loss	1e-2	1.975972	FAIL
gradient_l2_norm	5e-3	0.999919	FAIL

共 506/720 pair/step/metric 比较失败。step 0 的 rollout 在各拓扑间字节一致，但 DP2CP2 的 KL proxy 与 loss 已越过容差，随后生成内容从 step 2 开始分叉。现有材料支持 BF16 CP 前向数值差异与严格相对容差放大的解释，但这不是已修复根因，也不满足 Task40 的分区不变性验收。

资源受限导致未完成的范围

以下说明只覆盖有冻结运行证据或当前资源状态支撑的阻塞项；它解释“为何缺少规模/端到端证据”，不把已实际执行后的科学或数值失败重写为算力问题。

未交付项	已完成到的边界	资源证据与当前状态	归类
论文规模的 Qwen3-4B-Thinking 持续训练、三 seed 主结果/核心消融	4B 仅完成单步 capacity check；正式矩阵按预注册资源阶梯降至 Qwen2.5-1.5B-Instruct。	4×A100-40GB 上已依次尝试 PP2、GBS64、全层 activation recompute、log-prob chunk=1024、降低 SGLang static-memory；三步 P3O 仍在 step 1 OOM。	直接资源阻塞；1.5B 结果不能替代论文 4B/更大算力规模结论。
canonical FeynRL 端到端参考（6 train + 2 rollout）	已完成 formula oracle，以及 2 train + 2 rollout 的 degraded 单步 GRPO endpoint。	canonical 映射需要 8 GPU，原分配节点只暴露 4 张 A100-40GB，因此裁决为 NOT_RUN_RESOURCE_LIMIT。	直接资源阻塞；degraded endpoint 仅证明接口可运行，不替代 canonical P3O 对照。
H100/FP8 吞吐、显存和论文规模成本对齐	仅有 4×A100-40GB / BF16 的资源记录。	论文目标为 Qwen3-4B / 8×H100；本次没有 H100 或 FP8 实跑。	硬件资源缺口；不能从 A100 指标外推 H100 FP8 结果。
当前工程审阅提交 3313cf5 的 GPU 闭环复验	已完成静态审阅和定向 CPU 测试；历史 GPU 证据冻结于 a06f465。	截至本更新，没有可用 GPU 算力重跑 CP 拓扑、NCCL smoke 和质量合格的三 seed 矩阵。	资源导致的证据缺口，不是对当前代码已失败的判定。

全词表 exact KL 需要单独界定：代码中已有小词表验证 helper，但生产 rollout payload 只保存所选 token 的行为 logprob，未携带完整 behavior logits；大词表 logits 的存储/计算成本是未接入生产路径的设计约束。不过没有一次真正启用 exact KL 后 OOM 的归档运行，故不能写成“exact KL 已被算力实验否定”。

相反，下面两项不能归因于资源不足：真实模型 CP 分区不变性已在五个 30-step A100 run 中执行并出现 KL/loss/gradient 超容差；正式 24-run 矩阵也已完整执行，只是 P3O 为 0/12 quality-eligible。因此，更多算力能支持复验和更大规模实验，但不会自动使这些已有验收失败变为 PASS。

待完成

• 在固定 step-0 rollout 上完成 CP1 与 CP2 的 FP32 一步 replay，定位 KL/loss/gradient 差异；在原冻结阈值下复验，而不是只调整阈值；
• 对当前工程审阅提交重新运行 CPU oracle、DP/CP/PP 最小化验证和多节点 NCCL smoke，不能以 a06f465 的 A100 结果替代；
• 在质量门通过的相同模型/数据/response 配置下，完成 P3O、GRPO/PPO、FeynRL P3O 的三 seed mismatch 矩阵，汇总均值/方差、KL/loss spike、最终效果、吞吐与峰值显存；
• 在完整 Linux 依赖环境运行全仓 pytest tests/ 与 pre-commit run --all-files，并补齐 PP>1 / CP>1 的真实硬件验证；

交付判断

当前状态：PARTIAL。

核心公式、工程接入、当前 HEAD 的定向 CPU 测试和文档/PR 拆分均已完成

[xiaoliang0601]

感谢这次更新。

整体上，P3O 的公式接入、专用 loss dispatch、ESS scope 区分、CP metadata 收敛以及文档/测试补充，方向是合理的；当前 CPU CI 也已通过。但是仍然有些问题。

历史实验已经明确出现以下问题：

• p3o_global_ess 最大相对误差为 0.000189463，通过门槛；
• p3o_behavior_kl_proxy 最大相对误差为 0.211947，失败；
• lm_loss 最大相对误差为 1.975972，失败；
• gradient_l2_norm 最大相对误差为 0.999919，失败；
• 总计 506/720 项比较失败；
• step 0 的 rollout 在各拓扑间字节一致，但 DP2CP2 的 KL proxy 和 loss 已经超出容差；
• rollout 从 step 2 开始分叉，此后的 loss、gradient 和采样结果已经互相影响。

我认为，真正适合定位首个差异的是 step 0。step 2 之后的多数失败是在不同参数和不同 rollout 上继续训练的结果，不能视为 506 个彼此独立的分区错误。

对于这些错误可能的原因：

• Behavior-KL proxy 的误差，优先排查：
  • CP1/CP2 的 current-policy logprob 是否仅有 BF16 数值漂移；
  • token、position、mask、behavior logprob 与 current logprob 是否逐项对齐；
  • KL 归一化前的 token sum 和 global valid-token count 是否一致；
  • 当前相对误差是否由接近零的原值放大。
• Loss 的误差，可能有 2 个方向的影响：
  • 上述 current logprob、mask 或 token ledger 差异；
  • 不同拓扑下 micro-batch ESS 的逻辑分组不同。如果实验确实采用 MBS=1 + micro-batch ESS，DP4CP1 的一次 physical micro-batch 包含 4 条独立序列，而 DP2CP2 只包含 2 条独立序列。由于 ESS/cap 是非线性 batch statistic，两边的 loss 本来就不保证严格相同。
• Gradient norm 的误差，Gradient 既会继承 step-0 loss 差异，也会在 step 2 后被不同 rollout 继续放大，没有太多参考价值。

代码风险：

• Dummy micro-batch 污染 micro-batch ESS：当前 ESS 的 DP×CP 统计发生在 is_dummy 处理之前，而 dummy 是真实 batch 的拷贝，会把非零 S1/S2/N 带入其他 real rank 使用的 cap。所有 rank 仍应参加 collective，但 dummy rank 必须贡献全零统计；请补 DP2 一侧 real、一侧 dummy 的 loss/gradient oracle 测试。
• Global zero-valid-token 未定义：P3O 可能向 Megatron 返回精确的零 normalizer，导致指标除零，并且 optimizer weight decay、scheduler 仍可能推进。应基于全局 token count 做 rank-consistent fail-fast 或完整 no-op，不能在各 rank 独立 clamp 到 1。
• Loss recompute 会重放 ESS collective：recompute-loss-function checkpoint 包含 micro-batch ESS all-reduce，reentrant backward 可能再次执行并与 PP/CP/DDP backward collective 交错。短期应拒绝该参数组合，或将冻结 context/collective 移到 checkpoint 外。
• Behavior logprob 配置契约不完整：P3O 必须使用实际采样分布的 logprob。正式 recipe 的 top_p=1、top_k=-1 是安全的，但公共 CLI 仍允许 truncation；固定 SGLang 版本返回的可能是过滤前 logprob。建议 hard-gate 不支持的 top-p/top-k/min-p/original-logprob 配置，或者实现过滤并重新归一化后的 behavior logprob。
• Periodic rollout snapshot 无法跨 checkpoint 精确恢复：当前没有持久化 snapshot 权重、版本和 interval phase，中途 resume 会静默改变 behavior policy。若该场景声明支持 resume，需要补齐持久化和 uninterrupted-vs-resume 一致性测试；否则应明确标为 unsupported。

[yulingma545-ctrl]

【Task 40】P3O / Adaptive Policy Optimization

任务信息（本次更新）

• 任务：Task40 - P3O / Adaptive Policy Optimization
• 认领人：@DreamEnding，@yulingma545-ctrl
• 论文：Trust the Batch, On- or Off-Policy: Adaptive Policy Optimization for RL Post-Training（arXiv:2605.12380v1）
• 参考实现：FeynRL
• 开发分支：feature/p3o-adaptive-cap-clean
• 工程审阅提交：3313cf569407ad3f75ec29174e2c0c4814c4386e
• P0 集群验证提交：6c7a3d2c0cd9e714d96a15e52a7d542a422230b5
• 当前提交（HEAD）：cd020f101e41779216c740d5249266fc897fe8ff
• 实验冻结版本：a06f465d607ccfc521104ba27ddbb8759b3b04a9
• P3O Draft PR：#272（Closes #233）
• 独立 SGLang Draft PR：fix(sglang): clamp deterministic sampler endpoints #271（Related to #233）

---

整体介绍

本次任务为 Relax 新增了 P3O 强化学习训练算法（参照论文与参考实现 FeynRL），并尽力做到能通过工程审查、能跑实验验证的程度。

1. 实现算法：按论文公式实现 P3O，用 rollout 策略与当前策略的差异（ESS）自适应控制训练强度，不新增裁剪超参数；
2. 接入工程：命令行参数、算法注册、loss 计算、分布式统计、指标上报、示例配方和文档全部接入，且不影响原有 GRPO/PPO；
3. 验证与打磨：公式与 FeynRL 对照误差 1e-9 量级；回应 review 的 5 个代码风险点与 S2 数值先决并全部加固；真实集群分布式边界实验全部通过。

最终状态 PARTIAL：工程与边界验证已闭环，可进入 Draft 工程审查；论文复现（分区不变性定级、正式对比矩阵、论文主结果）待GPU 资源到位后完成。

审查意见跟进

针对上一次更新后提出的 5 个代码风险点及 P0 先决条件，加固已全部落地；并完成了 P0 两个实验包（Step-0 + FP32 对照、分布式边界
smoke）。关键结果：P0-2 全部通过；P0-1 的 FP32 对照存在 attention-backend 混淆（BF16=flash、FP32=unfused，且经未跟踪 hook 注入精度），mismatch 既不否定BF16 数值噪声假设、也不确认生产 CP bug。

审查意见跟进（Reviewer 反馈 → 修复 → 证据）

#	Reviewer 意见	代码修复	验证证据
1	Dummy micro-batch 污染 micro-batch ESS（统计发生在 __is_dummy__ 处理前，dummy 会带入非零 S1/S2/N）	补 real/dummy 双侧 loss/gradient oracle；dummy 贡献全零统计，所有 rank 仍参加 collective	P0-2 00_real_dummy_w2_cp1 PASS（聚合 loss/gradient 与 real-only oracle 一致，无 NaN/hang）
2	Global zero-valid-token 未定义，不能各 rank 独立 clamp 到 1	基于全局 token 数做 rank 一致 fail-fast，optimizer/scheduler 均不推进	P0-2 01_zero_tokens_w2_cp1 PASS
3	Loss recompute 会重放 ESS collective，reentrant backward 与 PP/CP/DDP collective 交错	relax/utils/arguments.py::_validate_p3o_args 拒绝 --recompute-loss-function + micro-batch scope 组合（提示改用 --p3o-ess-scope step）	参数校验单测覆盖
4	Behavior logprob 配置契约不完整（截断采样改变行为策略；固定 SGLang 可能返回过滤前 logprob）	hard-gate --rollout-top-p != 1.0 / --rollout-top-k != -1；统一要求 --use-rollout-logprobs；正式 recipe 全部为 top_p=1.0 / top_k=-1	P0-2 正常未截断 rollout PASS（真实 rollout_log_probs 被训练端消费）
5	Periodic rollout snapshot 无法跨 checkpoint 精确恢复	明确声明 unsupported，配方与文档同步标注；不做等价性长跑	文档/校验单测
先决	S2 = sum(rho^2) 溢出退化为 ESS=1	relax/utils/training/p3o_utils.py：新增 ratio_sq 有限性/可表示性检查（exp(500) 溢出、exp(-500) 精确为零）、local-sum 溢出检查、同步 invalid_flag、torch.where 清零；p3o_step.py 对归约后非有限 S1/S2/N 做 all-rank 拒绝	S2 focused 单测 48 passed；P0-2 02/03/04/05 极端 ratio（±500，DP2+CP2）PASS

其余加固（22635d4、cd020f1 及中间提交）：

• _configure_megatron_checkpoint_loading：统一 Megatron 原生 checkpoint 直载 / HF cold-load 判定，避免直接 iter_0000000 路径被静默降级为 cold start；
• --p3o-ess-scope help 明确语义：micro-batch = 论文/参考实现兼容但拓扑相关；step = 分区不变的 adaptive cap；消除「既精确 FeynRL 又分区不变」的模糊表述；
• step scope 要求 dropout=0（预扫描与梯度扫描一致），非确定性 replay 被拒；
• 测试隔离加固：Megatron stub 隔离、reward worker actor pool 隔离、import-cache 保护。

---

P0 集群验证结果（commit 6c7a3d2）

P0-1 固定 Step-0 + FP32 对照 —— FAIL

最小矩阵 DP4×CP1 vs DP2×CP2，同一 fixture（64 samples / 13,635 valid tokens / seed 42），BF16 与 FP32 各一组：

precision	current logprob max-abs	ESS 相对误差	loss 相对误差	grad-L2 相对误差
BF16	0.2499070	1.07e-5	3.72e-2	2.63e-3
FP32	0.7002048	1.15e-3	2.50e-3	3.70e-1

• 两组中 behavior logprob max-abs 差 = 0，valid-token keys 完全一致 → 排除输入/replay 差异；
• FP32 对照存在 attention-backend 混淆：FP32 运行 --attention-backend unfused、BF16 运行
  --attention-backend flash，且均经未跟踪 hook p0_oracle_hook.configure_bf16/configure_fp32 注入精度 → 对比同时改变精度与注意力算法，不是 precision-only；
• 因此「FP32 下 CP1/CP2 不对齐」既不能否定「BF16 数值噪声」假设，也不能确认生产 CP bug；
• 判定：cp_forward_mismatch_confounded；分区不变性保持未闭环，冻结阈值不放宽；
• DP1/DP2 与 MBS2/4 为 strict-closure 扩展，不在最小 P0 矩阵内，明确记录为 NOT RUN。

P0-2 分布式边界 smoke —— 全部 PASS

runs/boundary_nccl_a2/verdict.json overall_passed=true：

case	配置	结果
real + dummy micro-batch	DP2，一 rank real、一 rank __is_dummy__	PASS
全局零 valid token	DP2	PASS（全 rank 一致 fail-fast，optimizer/scheduler 零推进）
极端 ratio / S2（正）	DP2 与 CP2，log_ratio=+500	PASS（全 rank 一致报错，不产生 ESS=1 更新）
极端 ratio / S2（负）	DP2 与 CP2，log_ratio=-500	PASS
正常未截断 rollout	DP2，top_p=1.0 / top_k=-1 / --use-rollout-logprobs	PASS（真实训练一步完成）

正常 rollout 关键指标：64/64 samples，response length 72–401，13,637 valid tokens，loss
0.00284698，normalized ESS 0.99939，gradient L2 0.60823；rollout-logprob 与 mask 长度
完全匹配、全部有限。

P0 收尾

• 容器最终 focused 回归：67 passed, 28 warnings in 318.51s；
• targeted pre-commit hooks 通过；Ray / 进程 / 端口（6379/8265/8000）/ 4×A100 清理确认（GPU 回到 14 MiB / 0%）。

---

已完成验证

当前工程审阅提交（3313cf5）与后续加固

• 本地 Windows CPU 定向测试：101 passed, 2 warnings + CP 元数据回归 24 passed；git diff --check 通过；
• P3O focused 测试（a06f465 冻结点）：187 passed；
• P0 集群（6c7a3d2）：S2 先决 48 passed、最终 focused 回归 67 passed、pre-commit 通过。

历史冻结实验（a06f465）

• FeynRL CPU formula oracle 通过：ESS 绝对误差 1.05e-9、loss sum 差 0、gradient 最大绝对差 1.19e-7；
• 最小化 on-policy 诊断：P3O DP4 ESS mean/min 0.9993836590 / 0.9989917435，GRPO DP4 0.9993828089 / 0.9989861105，每步均不低于 0.99；
• 五个真实模型拓扑 run 均 exit 0，30/30 metric steps 与 30/30 rollout files——链路可执行，但不等价于数值分区不变性。

---

正式实验当前状态

真实模型分区不变性

2026-08-11 正式矩阵对合成/NCCL 证据曾给出过 partition invariance PASS，但 2026-08-12/13 较晚的真实模型复验（Qwen2.5-1.5B-Instruct、4×A100-40GB）直接测得 byte-identical step-0 上 DP2CP2 即超容差：

指标	冻结相对容差	最大相对误差	判定
p3o_global_ess	1e-3	0.000189463	PASS
p3o_behavior_kl_proxy	1e-3	0.211947	FAIL
lm_loss	1e-2	1.975972	FAIL
gradient_l2_norm	5e-3	0.999919	FAIL

共 506/720 pair/step/metric 比较失败。2026-08-14 P0-1 的 FP32 对照存在 attention-backend 混淆（BF16=flash、FP32=unfused），不能正式排除「BF16 数值噪声」解释，也不能确认生产 bug；
分区不变性的归因重开，须在同路径（thd+flash）FP32 或独立 per-token FP32 oracle 下重跑后定级。

mismatch 质量门 

2026-08-11 正式矩阵 4 场景 × 2 算法 × 3 seed 共 24/24 execution-valid run；质量门后 P3O 为0/12 quality-eligible，四个 family 均 VALID_FAIL，不存在可判定 P3O 稳定性改善的 matched pair。
Qwen3-4B-Thinking 持续训练（3 seed 主结果/核心消融）未完成。

未完成但不可归因于资源

• 真实模型 CP 分区不变性已在五个 30-step A100 run 中执行并超容差；P0-1 FP32 对照存在attention-backend 混淆，归因重开，不能据此把差异归为 BF16 噪声或生产 bug；
• 正式 24-run 矩阵已完整执行，只是 P3O 0/12 quality-eligible；
• 更多算力可支持复验与更大规模实验，但不会自动把上述既有失败改为 PASS。

---

资源受限导致未完成的范围

以下只列出有冻结运行记录或当前资源状态支撑的阻塞项，不把已实际执行后的科学/数值失败重写为算力问题。

未交付项	已完成到的边界	资源证据与当前状态	归类
论文规模的 Qwen3-4B-Thinking 持续训练、三 seed 主结果/核心消融	4B 仅完成单步 capacity check；正式矩阵降至 Qwen2.5-1.5B-Instruct	4×A100-40GB 上依次尝试 PP2、GBS64、全层 activation recompute、log-prob chunk=1024、降低 SGLang static-memory；三步 P3O 仍在 step 1 OOM	直接资源阻塞；1.5B 结果不能替代论文 4B 结论
canonical FeynRL 端到端参考（6 train + 2 rollout）	formula oracle + 2+2 degraded 单步 GRPO endpoint	canonical 需 8 GPU，分配节点只暴露 4 张 A100-40GB，裁决 NOT_RUN_RESOURCE_LIMIT	直接资源阻塞；不替代 canonical P3O 对照
H100/FP8 吞吐、显存和论文规模成本对齐	仅有 4×A100-40GB / BF16 记录	论文目标 Qwen3-4B / 8×H100；无 H100/FP8 实跑	硬件资源缺口
当前 HEAD cd020f1 的 GPU 闭环复验	P0 已在 6c7a3d2 完成；cd020f1（P0 之后的分布式校验加固）尚无 A100 证据	现有 GPU 配额已用于并完成 P0 包	资源导致的证据缺口，不是对当前代码已失败的判定

全词表 exact KL 单独界定：已有小词表验证 helper，但生产 rollout payload 只保存所选 token 的
behavior logprob，未携带完整 behavior logits；大词表 logits 的存储/计算成本是未接入生产路径的设计
约束。没有一次真正启用 exact KL 后 OOM 的归档运行，故不写成「exact KL 已被算力实验否定」。

---

待完成

1. 修正 P0-1 FP32 对照混淆并重跑：删除/固化未跟踪 hook；FP32 与 BF16 走同一条 thd+flash 路径（只改 compute dtype）。若 TE DPA 不支持 FP32+CP2，改用独立 per-token FP32oracle（单卡、全序列、不分区）。在冻结 1e-7 判据下闭环，不放宽阈值。
2. 把 step-0 current log-prob 差异按 token 位置输出，观察是否集中在 chunk 边界，判别「BF16 flash 数值噪声」还是「位置/rotary 边界 bug」；
3. 对当前 HEAD cd020f1 重新运行 CPU oracle、四拓扑最小化验证与多节点 NCCL smoke（P0 已覆盖 6c7a3d2）；
4. 在质量门通过的相同模型/数据/response 配置下，完成 P3O、GRPO/PPO、FeynRL P3O 的三 seed mismatch矩阵，汇总均值/方差，KL/loss spike、最终效果、吞吐与峰值显存；
5. 在完整 Linux 依赖环境运行全仓 pytest tests/ 与 pre-commit run --all-files，补齐 PP>1 / CP>1真实硬件验证；
6. 论文主结果 / 核心消融需论文规模资源（4B / DeepScaleR-Preview / 8×H100）与论文协议。

---

交付判断

当前状态：PARTIAL。

已完成：

1. 算法：P3O 根据 rollout 策略和当前策略的差异（ESS 统计）自适应地控制训练强度，不需要额外调裁剪超参数；核心公式、loss 计算和梯度语义都接进了训练主链路。
2. 工程：命令行参数、算法注册、指标上报、示例配方和文档都补齐，和 GRPO/PPO 相互独立，不影响原有算法。
3. 审查意见：上一轮 review 提的 5 个代码风险点（dummy 批次污染统计、全局零 token 处理、loss 重算、行为 logprob 契约、快照断点续训）和 S2 数值溢出问题，全部做了加固，并在真实集群上验证通过。
4. 集群实验：分布式边界场景（real+dummy、零 token、极端 ratio、正常 rollout）全部通过

整体收尾

这次任务是为Relax新增 P30强化学习训练算法。算法实现、工程接入(参数/loss/分布式/文档)和审查加固均已完成，公式与FeynRL 对照误差达 1e-9量级，分布式边界实验全部通过。但论文复现未完成:真实模型分区不变性需修正重跑定级，正式配对矩阵无质量合格结果，QWwen3-4B训练与FeynRL端到端受GPU资源限制。当前状态PARTIAL:工程已闭环可进 Draft，科学验证需要资源到位后继续。