Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse

[HansBug]

TL;DR

在和 issue #1 同一台 8× H200（143 GB/卡）上跑了一次 terminal-rl GRPO outcome-only（dense pass-rate reward，无 PRM、无 process reward），把模型换成 Qwen3-8B，启动脚本与上游官方 terminal-rl/terminal-rl_qwen3-8b.sh 在 args/算法配置上完全一致——只在 wrapper 层加了 4 处与本机环境相关的兼容补丁（conda activate / .env / LD_LIBRARY_PATH / --no-gradient-accumulation-fusion），并复用了 issue #1 列出的 7 处源码补丁（无新增）。

• W&B run：https://wandb.ai/hansbug/openclaw-terminal-rl/runs/dvu9eexe
• runtime：~45 h（44h 59m，主动 kill 收尾）
• 训练量：1107 wandb step / 1093 reported rollout / 最后 ckpt = iter_0001095，约 num_rollout=2000 目标的 55 %
• 峰值：terminal/accuracy 在 ~iter 120–180 段 25 步桶均值跨过 0.45（单 batch 0.59 / 全程 max=1.0），rollout/raw_reward 同期翻正最高 +0.40
• 退化收尾：到 iter 1000+ 段 grad_norm 近 0、non_trainable_ratio 飙到 0.92、response_len 从 97 token 塌缩到 7 token——典型的 outcome-only RL 后期 mode-collapse；issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 在 4B / ~270 步预演过同款 plateau，8B 在更大 step 数尺度上把这条路完整走了一遍

---

1 期望训练结果

terminal-rl 至今没有官方公开的 expected accuracy / reward 曲线，issue #1 已经把这一点穷举调研过（arxiv/2603.10165 Table 4 terminal 行为空、blog openclawrl1 / openclawrl2 的表格也只有 GUI/tool-call、伴生 paper arxiv/2602.02488 不含 terminal、main repo gh issue list -S "terminal" 至今没有数字回复、HF Papers 讨论区也没有），不重复展开。

唯一仍有指导性的参考是 Tech Report Table 4 / Table 3：

来源	setting	outcome-only
Table 4	tool-call (250 step)	0.17
Table 4	GUI (120 step)	0.31
Table 4	terminal	空
Table 3	personal-agent Binary RL (8/16 step)	0.25 / 0.23

把本次 8B 全程 terminal/accuracy 均值 0.349 / 峰值桶 0.45+ 对照这两条只能说：量级合理，介于 GUI outcome-only（0.31）和 GUI integrated（0.33）之间，超出 tool-call outcome-only 基线（0.17）。仍然不能判断"达标"或"不达标"——这只是没有对照组的自我度量。

---

2 启动顺序和命令

完整可运行脚本：run_qwen3_8b_experiment.sh (gist)。该脚本对 上游官方 8B 脚本 的修改全部为 wrapper 层环境兼容，结构（cleanup_prev → start_router → check_router → check_gpus → detect_nvlink → start_ray_head → submit_job）和算法 args 完全保持。

2.1 4 处 wrapper 层 compat add

#	修改	为什么需要
1	conda activate tbench-rl（set +u 包围）	activate 脚本访问 unset 变量，set -u 会炸
2	source $REPO_ROOT/../.env	注入 WANDB_API_KEY/WANDB_PROJECT/WANDB_GROUP/WANDB_ENTITY
3	LD_LIBRARY_PATH=$CONDA_PREFIX/lib/python3.12/site-packages/nvidia/{cudnn,nvtx,cusparse,nccl,...}/lib	TE 2.13 运行时找不到 libcudnn_graph.so.9 / NVTX / NCCL
4	MISC_ARGS+=( --no-gradient-accumulation-fusion )	防御性保留：尽管本机最终装上了 Apex（pip install -v "git+...NVIDIA/apex" --no-build-isolation --build-option="--cpp_ext" --build-option="--cuda_ext"），保留该 flag 可在 Apex 更新失败时仍能跑（性能损失约 2–3 %）

diff 的算法 args 部分0 行变更——其它差异都是 wrapper 默认值（HF_CKPT=/nfs/models/Qwen3-8B / REF_LOAD=... / SAVE_CKPT=... / RAY_TMPDIR=/tmp/ray_tbench_8b）。

2.2 前置依赖

# /nfs/terminal-rl-workspace/  (NFS 工作区)
conda env 'tbench-rl'  (Python 3.12)
  torch 2.9.1+cu128
  sglang 0.5.10.post1
  ray 2.55.1
  mbridge 0.15.1
  transformer-engine 2.13.0     (prebuilt cu12 wheel)
  flash-attn 2.8.3              (prebuilt cu12torch2.9 wheel)
  apex (cpp_ext + cuda_ext)     (本次相比 issue #1 4B 跑新增)
  + slime -e .                   (editable install)

.env：
  WANDB_API_KEY=<key>
  WANDB_PROJECT=openclaw-terminal-rl
  WANDB_GROUP=qwen3-8b-terminal-rl
  WANDB_ENTITY=hansbug
  WANDB_MODE=online

ckpt：

HF_HUB_DISABLE_XET=1 hf download Qwen/Qwen3-8B --local-dir /nfs/models/Qwen3-8B

cd slime && source scripts/models/qwen3-8B.sh
python tools/convert_hf_to_torch_dist.py "${MODEL_ARGS[@]}" \
    --hf-checkpoint /nfs/models/Qwen3-8B --rotary-base 1000000 \
    --no-gradient-accumulation-fusion \
    --save /nfs/models/Qwen3-8B_torch_dist

2.3 Pool server（与 issue #1 共用，不重启）

docker run -d --name openclaw_pool_server --restart unless-stopped \
    -p 18081:18081 \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /nfs/terminal-rl-workspace/OpenClaw-RL:/nfs/terminal-rl-workspace/OpenClaw-RL \
    -e DATASET_DIR=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/dataset \
    -e TBENCH_OUTPUT_ROOT=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs \
    -e TBENCH_DOCKER_IMAGE_SOURCE=build \
    -e ENV_SERVER_PORT=18081 \
    openclaw_pool_server:v1 \
    bash -c "cd /nfs/terminal-rl-workspace/OpenClaw-RL && \
        python -m terminal-rl.remote.pool_server --host 0.0.0.0 --port 18081 \
            --max-tasks 8 --max-runs-per-task 4 \
            --output-root /nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs"

2.4 启动训练

cd /nfs/terminal-rl-workspace/OpenClaw-RL
source /home/ubuntu/miniconda3/etc/profile.d/conda.sh && conda activate tbench-rl
: > terminal-rl/logs/training_8b.log
nohup bash terminal-rl/run_qwen3_8b_experiment.sh > terminal-rl/logs/training_8b.log 2>&1 &

# ckpt 保留守护（保留最新 KEEP_N=2 个 iter_*）
SAVE_CKPT=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/ckpt/qwen3-8b-terminal-rl \
KEEP_N=2 nohup bash terminal-rl/ckpt_retention.sh \
    > terminal-rl/logs/ckpt_retention_8b.log 2>&1 &

2.5 和官方 terminal-rl_qwen3-8b.sh 在算法 args 上的差异

0 项——MISC_ARGS / OPTIMIZER_ARGS / GRPO_ARGS / ROLLOUT_ARGS / DISTRIBUTED_ARGS / WANDB_ARGS / CKPT_ARGS / EVAL_ARGS / PERF_ARGS 与上游 terminal-rl/terminal-rl_qwen3-8b.sh 完全相同（除去 --no-gradient-accumulation-fusion 这一条防御性附加）。

---

3 源码修改清单

与 issue #1 完全一致的 7 处仓库内 + 1 处 site-packages 补丁（继承自上次 4B 跑，未删未改）。完整 diff 内容、必要性、不打的后果、风险都在 issue #1 §4 详细列过，这里只列汇总并在右侧标注对本次 8B + TE + 8-GPU + 装 Apex 跑法是否仍严格必需：

 Megatron-LM/megatron/core/utils.py                                        |  7 +++++--
 slime/slime/backends/megatron_utils/initialize.py                         |  4 +++-
 slime/slime/backends/megatron_utils/megatron_to_hf/qwen2.py               | 11 +++++++++++
 slime/slime/backends/megatron_utils/update_weight/update_weight_from_distributed.py | 22 ++++++++++++++++++----
 slime/slime/backends/sglang_utils/sglang_engine.py                        |  6 ++++++
 terminal-rl/remote/docker_compose_utils.py                                |  5 ++++-
 terminal-rl/remote/terminal_env.py                                        |  5 ++++-
 7 files changed, 51 insertions(+), 9 deletions(-)

#	修改	本次跑法严格必需	备注
4.1	Megatron-LM/.../utils.py：TE 未装时 is_te_min_version 安全回退	❌	本次装了 TE 2.13，永远不进入 None 分支；保留无副作用
4.2	slime/.../initialize.py：numpy 2.x 硬 assert → warning	✅	sglang ≥ 0.5 把 numpy 拉到 2.3.5；不打补丁 0 步即崩
4.3	slime/.../megatron_to_hf/qwen2.py：补 local-impl 命名	❌	本次走 TE 路径，不会撞到 local-impl 名字
4.4	slime/.../update_weight_from_distributed.py：NCCL Duplicate-GPU catch	❌	本次 8 GPU 不会 dup；保留对 1-GPU debug 模式有用，对生产有风险（吞掉真实 NCCL 错）
4.5	slime/.../sglang_engine.py：HTTP 端的 NCCL Duplicate-GPU catch	❌	同 4.4
4.6	terminal-rl/remote/docker_compose_utils.py：build(timeout=) try/except	✅	terminal-bench 0.2.18 砍掉了 timeout kwarg；不打补丁 pool_server /reset 全 500
4.7	terminal-rl/remote/terminal_env.py：Terminal.start(timeout=) try/except	✅	同 4.6
4.8	mbridge/models/qwen2.py（site-packages，非 git 追踪）：补 local-impl mapping	❌	走 TE 路径不撞；对 local 路径是 bug fix

本次 8-GPU + TE + Apex 跑法严格必需的仍是 4.2 / 4.6 / 4.7 三条。 其它五处沿用，对当前路径 0 副作用，但 4.4 / 4.5 在生产环境应改为 env-var gate 或彻底删除。

---

4 关键指标曲线

单指标图（浅蓝原始 + 橙 EMA(α=0.1)）：

terminal/accuracy（pytest 通过率）

terminal/reward_mean（= 2·accuracy − 1）

rollout/raw_reward（训练 batch 均值）

train/grad_norm

train/kl_loss

train/entropy_loss

terminal/non_trainable_ratio（无学习信号 group 比例）

rollout/response_len/mean（agent 输出 token 数）

---

5 全程指标统计（first20 / mean_all / last20）

指标	n	min	max	first20	mean_all	last20
terminal/accuracy	1093	0.000	1.000	0.221	0.349	0.276
terminal/reward_mean	1093	-1.000	1.000	-0.559	-0.302	-0.447
rollout/raw_reward	1096	-1.000	1.000	-0.357	-0.261	-0.492
train/grad_norm	1107	0.000	3.804	0.847	0.326	0.008
train/kl_loss	1107	0.000	2.491	0.012	0.151	0.073
train/entropy_loss	1107	0.000	0.539	0.064	0.103	0.066
terminal/non_trainable_ratio	1096	0.235	1.000	0.346	0.731	0.920
rollout/response_len/mean	1096	1.154	339.3	97.07	57.00	7.01

完整 summary_stats.json：

{
  "wandb_run_id": "dvu9eexe",
  "wandb_url": "https://wandb.ai/hansbug/openclaw-terminal-rl/runs/dvu9eexe",
  "runtime_sec": 161973,
  "runtime_min": 2699,
  "runtime_h": 44.99,
  "lastStep": 0,
  "state": "crashed",
  "terminal/accuracy":         {"n":1093,"min":0.0,"max":1.0,    "mean_all":0.3487,"mean_first20":0.2207,"mean_last20":0.2764},
  "terminal/reward_mean":      {"n":1093,"min":-1.0,"max":1.0,   "mean_all":-0.3025,"mean_first20":-0.5587,"mean_last20":-0.4472},
  "rollout/raw_reward":        {"n":1096,"min":-1.0,"max":1.0,   "mean_all":-0.2611,"mean_first20":-0.3565,"mean_last20":-0.4917},
  "train/grad_norm":           {"n":1107,"min":0.0,"max":3.8038, "mean_all":0.3256,"mean_first20":0.8465,"mean_last20":0.0083},
  "train/kl_loss":             {"n":1107,"min":0.0,"max":2.4909, "mean_all":0.1511,"mean_first20":0.0119,"mean_last20":0.0726},
  "train/entropy_loss":        {"n":1107,"min":0.0,"max":0.5387, "mean_all":0.1034,"mean_first20":0.0638,"mean_last20":0.0659},
  "terminal/non_trainable_ratio":{"n":1096,"min":0.2353,"max":1.0,"mean_all":0.7306,"mean_first20":0.346,"mean_last20":0.9195},
  "rollout/response_len/mean": {"n":1096,"min":1.1538,"max":339.27,"mean_all":57.0029,"mean_first20":97.068,"mean_last20":7.0105}
}

---

6 训练阶段叙事（按时间序）

Phase A · iter 0 – 30 / 0–1.5h（冷启动）

• accuracy 0.07 → 0.43，单步 max 抓到 1.0
• raw_reward -0.65 → +0.40，首次出现 batch 内整体翻正
• grad_norm 1.0–1.7 / kl 0.03–0.20 / response_len ~150 token
• 表现极好，issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 4B 在 25 步桶里峰 0.385，本 8B 一开始就能跨过同样位置

Phase B · iter 30 – 200 / 1.5–8h（爬升 + 第一段平台）

• accuracy 25 步桶在 0.30–0.49 摆动，三次跨过 0.45
• raw_reward 维持 -0.20 ~ +0.10 区间
• KL 短暂飙到 0.39（25 min 内回落到 0.27），同期 reward 反而上升 → 是有效大步策略更新，不是发散
• non_trainable_ratio 0.33–0.47，仍有充足学习信号

Phase C · iter 200 – 600 / 8–25h（plateau）

• accuracy 桶均值长期 0.30–0.45 区间，没有持续突破峰值
• raw_reward 开始系统性下滑：mean_all 从早期的 +0.05 缓慢退到 -0.20
• non_trainable_ratio 慢慢从 0.4 涨到 0.7
• KL 持续低位（0.10–0.20），未越过 0.3 警戒，没有发散

Phase D · iter 600 – 1000 / 25–40h（学习信号枯竭）

• non_trainable_ratio 锁死 0.85–0.95：每个 batch 8 个 sample 几乎全同结果（要么全过要么全失败），advantage = 0，没梯度可回传
• grad_norm 跌到 0.01 数量级，模型实际上停止更新
• response_len 从 ~100 token 单调下滑到 ~30 token

Phase E · iter 1000 – 1095 / 40–45h（mode collapse + 主动停）

• response_len 进一步坍缩到 ~7 token——agent 几乎只输出空字符串 / 单个 token 的退化策略
• accuracy 跌回 0.20–0.28
• raw_reward 跌到 -0.50 区间
• 26 日 09:42 主动 kill（pkill -SIGTERM parent + ray stop --force），ckpt 守护保留 iter_0001087 + iter_0001095

最佳 ckpt 出现在 Phase A → B 转折期（约 iter_0000127–iter_0000183，单步 accuracy 跨 0.45+ / raw_reward 翻正首例）。该段已被 ckpt retention 守护淘汰（守护只保留最新 2 个）。这是和 issue #1 4B 跑同样的教训：outcome-only GRPO 的最佳 ckpt 出现在中前段，retention 策略需要换成"保留 best-by-eval-acc"而不是"保留最新"。

Phase C → E 的根因分析见本 issue 后续 comment——把 wandb / 训练日志 / 源码 / dataset / rollout trace 串起来定位。

---

7 与 issue #1（4B / 270 step）的对比

维度	issue #1（4B）	本次（8B）
runtime	10 h	45 h（×4.5）
训练量	~270 wandb step / 261 rollout	1107 wandb step / 1093 rollout
accuracy 全程均值	0.345	0.349（基本持平）
accuracy peak（25 步桶）	0.385（step 60–79）	0.45+（iter 120–180 段，单步 1.0）
raw_reward 全程均值	-0.177	-0.261（更差）
raw_reward peak	+0.572	+1.000（单 batch）
KL 漂移峰	0.54（279 步桶，主动停）	0.39（瞬时，自行回落）
grad_norm 末段	4.4（仍在更新）	0.008（事实停止更新）
non_trainable 末段	n/a（无该指标）	0.92
response_len 末段	~150 token	~7 token
收尾原因	KL 漂移 0.54 主动停	non_trainable 锁死 + response 坍缩，主动停
最佳 ckpt 是否保留	否（retention=2 淘汰）	否（同前）

核心结论：把 4B 跑了 270 步看到的 plateau，在 8B 上以 4× 时长走得更深，最终走到了 mode collapse——response 从 100 token 塌缩到 7 token，accuracy 从早期峰值 0.45 跌回 0.27。这不是发散（KL 一直在合理区间，grad 单调降到 0），而是 GRPO 在稀疏 outcome 信号 + 87% non-trainable 数据下的退化吸引子：既然几乎 ⅞ 的 prompt 拿不到学习信号，剩下 ⅛ 内出现的极端短输出（终端命令 1–2 token 就能 pytest pass 的简单题）会被反复加权，最后压垮其它行为。

issue #1 末尾对上游的建议（pin terminal-bench 版本 / --save-max-to-keep / 加大 --kl-loss-coef 或建议早停）继续成立；本次新增建议见 §9。

---

8 异常现象与诊断

8.1 SETA env /allocate 429 / /reset 500 风暴

训练中段（约 1h 左右）出现密集的 429 Too Many Requests 和 500 Internal Server Error 在 RolloutManager 日志里刷屏。诊断后是 SETA env 的 docker compose pool 短时拥塞，rollout 内部已重试，并未阻塞训练步。把诊断 Monitor 的 grep 收紧（去掉 Error|429|500 这些关键字，只保留 Timer train end | saving checkpoint | Killed | OOM | RayActorError | Traceback 等致命签名）即可避免噪音洗版。不是真故障，但需要在文档里说一句（issue #1 没遇到，因为 4B 跑得短）。

8.2 grad_norm 单调下降到 0.01

4B 跑 270 步 grad_norm 仍在 4 量级，本 8B 1000+ 步后跌到 0.01 量级。直接原因是 advantage = 0 的 batch 占比 92%——GRPO 对 advantage 用组内 z-score normalize，组内全成功或全失败时 advantage 全 0，不向上回传梯度。这不是数值错误，是数据信号问题。

8.3 response_len 从 97 → 7 token

最 surprise 的现象。个别简单 SETA task 的 pytest pass 标准非常宽松（"打印一行特定字符串"或"创建一个文件"），agent 在这部分用极短输出就能拿到 +1 reward。GRPO 在 ⅞ batch 没有信号、只有 ⅛ batch 有信号时，反复加权这些极短输出策略，长期累积压垮了其它行为模式。这是 outcome-only RL + 难度极不均匀数据集 + GRPO 的 well-known failure mode——issue #1 4B 跑没有撞到只是因为步数不够。详见后续 comment 的实证分析。

---

9 给上游的建议（在 issue #1 § 8 基础上新增）

1. --save-max-to-keep N 或 --save-best-by <metric>：本次同样因为只保留最新 2 个 ckpt 而丢失 phase A→B 的最佳权重。slime 至今没这两个 flag。
2. non_trainable_ratio 早停 hook：当前 GRPO 实现下，如果 non_trainable_ratio 长期 > 0.7，训练实际上停止学习；建议默认加一个 patience-based 早停（比如连续 N 个 step 越过阈值就 abort）。
3. 数据集难度自适应 / curriculum：SETA 1376 个任务难度极不均匀（最简单的是 echo / touch，最难的需要多步 shell + python 脚本），outcome-only 信号下天然让简单题主导梯度。建议给 terminal-rl/dataset/seta_env_convert/train.jsonl 配套一个难度分级或 reweight。
4. 响应长度下界保护：在 reward 上叠加一个对极短输出的轻惩罚（或 length-normalized advantage），防止 mode collapse。
5. README 加一条"已知失败模式"段落，把 §8.3 写进去——下游用户撞到 response 坍缩时无处对照。
6. issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 §8 的 5 条建议（pin terminal-bench 版本 / inspect.signature 自适应 / --save-max-to-keep / KL coef 保护 / single-node 跳过 router_server）继续成立。

---

10 Attachments

• 8 张单指标图 + 1 张 dashboard：见 §4，全部走 GitHub user-attachments CDN（无 commit / branch）
• summary_stats.json：内联于 §5
• 完整启动脚本：run_qwen3_8b_experiment.sh (gist)（375 行，含 4 处 wrapper compat add 注释）

[HansBug]

Phase C–E 见鬼现象的根因解剖（实证）

把 wandb 数据 / 训练日志（623 MB） / slime + terminal-rl 源码 / SETA dataset / pool_server 实现串起来挖了一遍，先给结论再看证据：

non_trainable_ratio 从早期 0.35 涨到末段 0.92，主因不是"GRPO advantage 塌陷"，而是 SETA env pool 的 /allocate 端点从训练第 11 秒开始就一直在返 429。 模型"看起来在学"是因为 rollout 有 retry 把残余能力榨干；当 rollout 平均时长随训练进展拉长（更多 turn / 更深探索），单次 rollout 占用 lease 的时间变长，pool 的 32-lease 容量越来越不够分，successful rollout 的吸收率从 ~50 % 降到 ~10 %，模型实际上是在越来越稀薄的有效信号上喂梯度——直到末段几乎全部 sample 在 env.allocate 这一步就死了，grad_norm 滑到 0.008，模型停止更新。response 长度坍缩则是次生效应：剩余的 ⅛ 有效信号被两类极简单任务垄断（task #690 ffmpeg 单行 / task #1102 sed 单行 / 等），GRPO 反复把这些"短输出 + 1.0 reward"的轨迹塞回梯度，长期累积压垮其它行为模式。

下面所有数字 / 引用都可在仓库 / wandb run / 本机训练日志中复现。

---

1 non_trainable_ratio 真正在数什么——源码确认

terminal-rl/rollout_log.py:25-26（这个 metric 的产出函数）：

trainable     = [s for s in samples if not getattr(s, "remove_sample", False)]
non_trainable = [s for s in samples if     getattr(s, "remove_sample", False)]

remove_sample = True 在四条路径上被设置：

路径	文件:行	触发条件
(a) eval crash	terminal-rl/sample_builders.py:127	output_sample.status in {Sample.Status.FAILED} ⇐ eval_error is not None
(b) outcome=None	terminal-rl/sample_builders.py:39, 59-63	runner 创建失败 / runner.run_episode 抛异常 / env.allocate 抛异常
(c) 空 interactions	terminal-rl/sample_builders.py:67-73	rollout 返回但 outcome.interactions == []（reset 阶段炸）
(d) step-wise 全裁	slime/.../ray/rollout.py:591	step-wise normalize 后所有 step entry 都在 constant 桶里被裁（仅 advantage_estimator==step_wise 时启用）

本次 --advantage-estimator grpo，路径 (d) 不进入。

关键时序：rollout_log.py 是在 slime/ray/rollout.py:148-158 中通过 _log_rollout_data() 调用，调用点早于 _drop_constant_reward_groups（同文件 :650）。换句话说 non_trainable_ratio 不包含 GRPO 因为组内 reward 全相同而丢的样本，只统计 (a)+(b)+(c) 这三种 env / runner 故障。

直接含义：non_trainable_ratio = 0.92 ⇒ 92 % 的 sample 根本没生成出可训练的 trajectory——和 GRPO 怎么算 advantage 无关，是 SETA env pool 这一层挂了。

---

2 实证：env.allocate 一直在返 429，从训练第 11 秒起到 kill 那一刻为止

623 MB 的 training_8b.log 里 env.allocate failed (HTTPStatusError): 429 Too Many Requests 的出现总数：

$ grep -cE "env.allocate failed.*429" training_8b.log
109844

按 100 MB 滑窗划分（log 大致按时间顺序写入）：

log 偏移	env.allocate failed 数	大致对应训练阶段
0–100 MB	15 162	Phase A–B 早期
100–200 MB	14 013	Phase B 末–C 早
200–300 MB	16 507	Phase C
300–400 MB	17 856	Phase C–D
400–500 MB	18 295	Phase D
500–600 MB	18 624	Phase D 末
600–623 MB	9 387	Phase E（含 kill 收尾）

第一条 429：训练启动 11 秒后

[2026-04-24 12:47:55] generate.py:63 - [task=1329 uid=6bbf003b group_idx=13 sample_idx=105]
    env.allocate failed (HTTPStatusError):
    Client error '429 Too Many Requests' for url 'http://127.0.0.1:18080/allocate'

最后一条 429：kill 命令发出那一刻

[2026-04-26 09:42:41] env.allocate failed (HTTPStatusError): ...

——换句话说，整整 45 小时，env pool 一直没空闲过。"Phase A 看起来好" 不是因为 env 当时不忙，而是因为 (1) rollout 重试 / (2) 每个 rollout 的 lease 占用时间还算短 / (3) 模型一开始没学到啥所以单次 rollout 提早收敛或撞 iteration_limit，反而让 lease 早些归还。

---

3 容量 vs 需求——为什么从第一秒起 429 就在洗

Pool 容量（terminal-rl/remote/pool_server.py:84-92, 197-208）

启动命令固定为 --max-tasks 8 --max-runs-per-task 4。源码逻辑：

# pool_server.py:197-208
if len(self._tasks) >= self.max_tasks:
    raise CapacityError(
        ...,
        f"Worker at task capacity: {len(self._tasks)}/{self.max_tasks}",
    )
...
raise CapacityError(
    ...,
    f"Task {task_key} at run capacity: {len(task_slot.runs)}/{self.max_runs_per_task}",
)
# pool_server.py:397-400
except CapacityError as exc:
    return JSONResponse(
        {"ok": False, "error": exc.message, "code": exc.code}, status_code=429
    )

理论上限：8 个不同 task 同时活跃 × 每个 task 4 个并发 run = 32 个并发 lease。

Rollout 端需求（run_qwen3_8b_experiment.sh / 上游 terminal-rl_qwen3-8b.sh）

• --rollout-batch-size 16 × --n-samples-per-prompt 8 = 每个 rollout round 需要 128 个 lease
• 16 个 task_id 全不重复，每个想要 8 个并发 run，但 pool 单 task 上限 = 4 → 每个 rollout round 一开始就有 16 × (8-4) = 64 个 sample 必然在 task 内 run-cap 上撞 429
• 即便假设 16 个 task 全部抢到 task slot（用完 max_tasks 全部 8 个 + 8 个排队），也至少有 8 个 task_id 因为 max_tasks=8 撞死

32 lease 容量 vs 128 sample 需求 ≈ 4 倍 over-subscribe。Pool 完全没有 queue/wait 机制，超额直接 429——这是设计选择，但和上游 8B 默认配置完全不匹配。

issue #1 的 4B 跑的是同一个 pool，需求量也是 16×8=128，但 4B 训练步数少（270 vs 1107）+ accuracy 没塌缩到 mode collapse，所以同样的 429 风暴没有把训练拖进 phase D-E。

---

4 失败率 → trainable 样本数 → grad_norm 的因果链

把 train/grad_norm 和 terminal/non_trainable_ratio 放到一起看（数据来自 wandb run dvu9eexe）：

Phase	时间段	non_trainable last10	grad_norm last10	accuracy last10	response_len last10
A	0–1.5h	~0.40	~1.5	0.30	~150
B	1.5–8h	~0.45	~1.0	0.40	~130
C	8–25h	~0.65	~0.45	0.30	~80
D	25–40h	~0.85	~0.05	0.27	~30
E	40–45h	~0.92	~0.008	0.27	~7

核心相关性：每当 non_trainable 上升一格，grad_norm 就掉一档；accuracy 跟着掉是结果不是原因。

原因链：rollout 单次时长拉长（accuracy 提升 → agent 跑更多 turn 才完成 / 撞 iteration_limit）→ lease 占用时间变长 → 32-lease 池更长时间满载 → 后续 allocate 撞 429 概率更高 → 单 rollout round 里非 FAILED 的 sample 更少 → trainable 样本数从早期 ~80/128 跌到末段 ~10/128 → GRPO 内 group 更容易出现 "全 reward=0" 或 "全 reward=1"（因为只剩极少数好走的简单任务）→ _drop_constant_reward_groups（slime/.../rollout.py:400-451）触发警告 774 次：

$ grep -cE "Dropped constant-reward groups" training_8b.log
774

样本日志（中段）：

[2026-04-26 09:18:14] rollout.py:443 - Dropped constant-reward groups for grpo:
    dropped=[17269] kept=[17264] samples 20 -> 10

注意：这个 dropped 不计入 non_trainable_ratio（见 §1），是 GRPO 的二级效应——把已经稀少的 trainable 样本再砍掉一刀。

---

5 为什么 response_len 从 97 → 7 token——次生效应

rollout_log.py:42 计算 non_trainable_ratio，rollout/response_len/mean 是 slime 内置 metric（slime/.../rollout.py:1209 compute_metrics_from_samples），它统计的是经过 _drop_constant_reward_groups 过滤后送入训练的 sample 的 response 长度。

末段 92 % sample FAILED + 剩余样本里又被 GRPO 砍掉 constant-reward group → 真正进入梯度的样本数从早期 ~70/128 跌到末段 ~5–8/128。

把这剩下的 5–8 个 sample 看作"模型实际看到的世界"——它们高度倾斜地集中在 SETA dataset 里"短答案就能 pass" 的 task：

$ grep -E "Evaluation completed reward=1" training_8b.log | grep -oE "task=[0-9]+" \
  | sort | uniq -c | sort -rn | head -5

   12 task=690     # extract audio from video → ffmpeg -i sample_video.mp4 output.mp3
   12 task=435     # systemd service file → 单行 sed/cat 改配置
   11 task=1226    # systemd-resolved.conf → 单行 sed
   11 task=1203    # locale 配置 → 一两行 locale-gen
   10 task=519     # bash history audit → 几行 .bashrc 追加

随便抽 task=690 的描述（dataset/seta_env_convert/train.jsonl）：

Your task is to extract the audio from this video file and save it as an MP3 file at /app/output.mp3. Requirements: The output file must be at /app/output.mp3, the file must be a valid MP3 audio file, use command line tools.

单条命令 ffmpeg -i /app/sample_video.mp4 /app/output.mp3 即可 pass。GRPO 把这种 ~10 token 输出 + reward=1 的轨迹反复放进梯度，response_len 朝它单调收敛是必然——直到末段连 ffmpeg 命令本身都不会写完整、模型只输出几个 token 就停（依然碰巧能撞中部分简单 task），形成 mode collapse。

reward 分布（全程 7757 次 evaluate）也支持这一推论：

   3193 reward=0.0    (pytest 全挂)
   1227 reward=1.0    (pytest 全过)   ← 模型最终学到的"目标分布"
   1294 reward=0.3333 (单 unit test 过)
    901 reward=0.6667
    429 reward=0.5
    420 reward=0.25
    220 reward=0.75

reward=1.0 只占 16 %，但因为大部分非 1.0 的 sample 进入 constant-group（全 0.0）被砍掉，幸存到梯度的样本里 reward=1.0 的占比非常高——完美的 reward hacking 培养土壤。

---

6 为什么 KL 没炸 / 不是发散

issue #1（4B）末段 KL 漂到 0.54 主动停。本次（8B）KL 全程没破 0.4，末段 last10 = 0.07。原因：

• 没梯度可走 → policy 在 ref 周围做的更新极小 → KL(policy ‖ ref) 自然低
• 反过来这也是为什么早期 KL 短暂飙到 0.39 那次能"自动回落"（issue body §6 phase B 提到的事件）：当时还有充足学习信号、grad_norm 在 1.0 量级，KL 涨高的同时 reward 在改善 → KL coef 0.01 的轻保护把 policy 拉了回来
• 本次的失败模式不需要 KL 报警；它是"信号枯竭式静默死亡"——这也是 issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 §8 我建议加 non_trainable_ratio 早停的根本理由

---

7 ckpt retention 为什么也没救回来

ckpt_retention.sh 守护 KEEP_N=2，每 5 min 扫一次只留最新 2 个。phase A→B 转折期（约 iter_0000127–iter_0000183，accuracy 桶峰 0.45+）那段最佳权重被它在 iter 200 出现时就清掉了。

末段保留下来的 iter_0001087 / iter_0001095，对应 accuracy=0.27 / response_len=7 token / grad=0.008 的废权重。

issue #1 已经踩过同一个坑（4B peak 也没保下来），本次 retention 策略没改 → 同样后果。这条要在 ckpt_retention.sh 加 best-by-eval 的逻辑或 slime 上游加 --save-best-by accuracy。

---

8 给上游的具体修复建议（issue body §9 的进一步细化）

按可操作性排序：

1. pool_server 加 queue/wait 模式，而不是 over-subscribe 直接 429。当前 pool_server.py:197 抢不到 task slot 就直接 raise CapacityError → 429。改成有界 queue + timeout，对调用方语义友好。或者上游官方 8B 脚本默认调小 --rollout-batch-size（从 16 降到 4-8）匹配 32-lease 容量。
2. generate.py:97-115 加 retry 退避。看现在的代码，allocate 失败一次就直接 outcome=None 进 build_non_trainable_sample。429 是临时性错误，应该带指数退避重试 N 次。这一处改动能直接把 92 % 拉回 50 % 量级。
3. non_trainable_ratio 早停（patience-based）。当前 GRPO 实现下，连续 100 个 step 该值 > 0.7 就 abort——这是性价比最高的"不让训练在僵尸状态烧 GPU 30 小时"机制。
4. --save-best-by-metric eval/accuracy + 默认 --save-max-to-keep 5。slime 至今没有这俩 flag，每次 issue（包括本 issue / issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 / 上游 tool call training question Gen-Verse/OpenClaw-RL#62）都因为 retention 简单粗暴而丢失最佳权重。
5. dataset 难度 reweight / curriculum。SETA 的 1376 task 里短答案就能 pass 的（如 #690 / #435 / #1226）和长链推理才 pass 的（如 task #437 / #532 那种 Java 配置 + 多步 debug）放在一个 batch 里跑 binary GRPO，简单题被反复加权 → mode collapse。建议给 train.jsonl 配套一个 difficulty bucket，rollout 阶段做难度均衡采样。
6. 响应长度 hard floor。在 reward 上叠加 min(1, response_len / 30) * raw_reward 类的轻惩罚，防止 7-token 答案吃满梯度。
7. README 写一段"已知失败模式：env saturation → mode collapse"——本现象至今上游没有任何文档提示，下游用户碰到只能像我这样从 6.4 M 行 log 里挖。

---

9 一句话复盘

不是模型不会学，不是 GRPO 公式有问题，不是 KL 漂移——是 32-lease 的 docker compose pool 配 128-sample/round 的 rollout 配置，从训练第一秒起就 over-subscribe 4×，模型靠 retry/侥幸吃下来的 ⅛ 信号培养出了一个对极简单 task 过拟合的退化策略，最终在 grad ≈ 0、response ≈ 7 token 的 mode collapse 中被我手动 kill。

[HansBug]

追加：为什么"用官方脚本"还是会撞 pool 不够——是部署 mismatch，不是脚本 bug

回答上面那个疑问。我去把官方源码 + README 全部翻了一遍，结论很硬：

官方 8B 默认是 N-worker 部署、每 worker 128 lease；我们装成了 1-worker、缩到 32 lease。是部署没按文档走，不是脚本配错。

下面证据。

---

1 官方明确假设的是 N-worker 部署，不是单机

terminal-rl/README.md:8-10：

• Training machine: runs task router + Ray + training scripts. Requires a GPU environment and the training dependencies. Connects to workers via WORKER_URLS.
• Remote workers: run the pool server and execute tasks inside Docker. Requires Docker and network reachability from the training machine (default port 18081).

terminal-rl/README.md:53-55：

0. Start remote workers (pool server)

Follow remote/README.md on each worker to start pool_server ...

terminal-rl/README.md:95-97（"Run training"段）：

# Dataset + workers
export ROLLOUT_PROMPT_DATA="/path/to/train.jsonl"
export WORKER_URLS="http://worker1:18081,http://worker2:18081"

注意是逗号分隔的多个 worker，README 自己的示例写的就是 2 个。

terminal-rl/router_server.py 的设计完全围绕这一点：把 WORKER_URLS 拆成 self.workers 数组，按 task_key 一致性 hash 到不同 worker（参见 Router.select_worker），primary 失败 fallback 到下一个 worker（参见 _log_rollout_data 上方的 iter_worker_candidates 调用）。整个 router 层就是 N-worker fan-out 设计。

---

2 官方默认每 worker 容量 = 128 lease，是我们改小了

terminal-rl/remote/run_pool_server.sh（官方提供的 worker 启动脚本）：

exec python -m terminal-rl.remote.pool_server \
  --host 0.0.0.0 \
  --port "${ENV_SERVER_PORT:-18081}" \
  --max-tasks "${WORKER_MAX_TASKS:-16}" \
  --max-runs-per-task "${WORKER_MAX_RUNS_PER_TASK:-8}" \
  --output-root "${TBENCH_OUTPUT_ROOT}"

terminal-rl/remote/README.md 表格：

Variable	Default
WORKER_MAX_TASKS	16
WORKER_MAX_RUNS_PER_TASK	8

官方默认 = 16 × 8 = 128 lease／worker。

我们的实际部署（docker inspect openclaw_pool_server 输出的 cmdline）：

python -m terminal-rl.remote.pool_server \
    --host 0.0.0.0 --port 18081 \
    --max-tasks 8 --max-runs-per-task 4 \
    --output-root /nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs

=8 × 4 = 32 lease／worker，仅为官方默认的 1/4。

而且我们只起了 1 个 worker（部署时直接装到训练机本地 docker 里），所以总容量 = 1 × 32 = 32 lease，对照官方期望 N×128：

• 单 worker 默认：128 lease
• 2 worker 默认（README 示例）：256 lease

---

3 训练侧 demand 完全没改、就是上游官方默认

terminal-rl_qwen3-8b.sh 的 ROLLOUT_ARGS 里：

--rollout-batch-size 16
--n-samples-per-prompt 8

每个 rollout round 同时打开 16 prompts × 8 samples = 128 个并发 lease 需求。

128 demand 和 N-worker × 128/worker 的容量在多机部署下刚好平衡（甚至有冗余）。我们用 32 lease 去吃 128 demand：

demand / capacity = 128 / 32 = 4×

——这就是 issue body 和上一条 comment 里 "from training second 11 onwards 429 storm" 的算式来源。

---

4 8B / 8B-PRM-2nodes 两版脚本里 GPU 和 worker 的关系

把两版脚本里的资源拓扑列出来：

脚本	GPU 总数	actor GPUs	rollout GPUs	PRM GPUs	env worker
terminal-rl_qwen3-8b.sh	8（单 node）	4	4	0	必须由 WORKER_URLS 外部提供，未启动 = 没法跑
terminal-rl_qwen3-8b_prm_2nodes.sh	16（2 node × 8）	4	4	8	同上，外部

两个脚本都没有"自动起 pool_server"的代码——START_ENV_POOL_SERVER 这个 env var 在两版脚本里都默认 0。官方明确要求 worker 是另起独立机器，跟 GPU 训练机分开，原因是：

• pool_server 跑 docker compose 起 1376 种 task 镜像，每种 task 起来要几百 MB RAM + 几 GB tmpfs，128 个并发 task 需要约 32 GB RAM + ~200 GB tmp。如果还跟 8 GPU 训练（actor 4 卡、sglang 4 卡）抢同一台机器，CPU + RAM + 磁盘都会打架。
• docker-in-docker / docker socket 共享在生产是 risk，单机部署等于把 RL 训练和子任务容器混在一个 docker daemon 里。

---

5 那"为什么我们当时只设 32 lease"——这是我们做的 trade-off，不是脚本逼的

我们最初装 pool_server 走的是 issue #1 4B 跑前的 setup：把 pool_server 装成本机 docker 容器（图省事，避开 N-worker 多机部署），并且 --max-tasks 8 --max-runs-per-task 4 是当时为了"避免 docker compose 把单机 200GB tmpfs 打爆"压下来的。这当时就和上游 128-demand 的默认 ROLLOUT 配置不匹配，4B 跑只是因为训练步数少 + accuracy 没跑到 mode collapse 才没暴露这个问题；8B 跑 45 h 把它的所有后果完整放大了一遍。

所以严格地讲，issue body §8 / 上一条 comment §8 里我说的"上游问题"，这一条要修正：上游配置本身没问题，问题是我们没按 README §0 起多 worker、又把 WORKER_MAX_TASKS / WORKER_MAX_RUNS_PER_TASK 调到了官方默认的 1/4。

---

6 修复路径（按代价从小到大）

如果想在当前单机 8 H200 上把这个问题解决到不撞 429，三档选择：

选项 A — 把 pool 调回官方默认，单机硬扛

# kill 老 pool
sudo docker rm -f openclaw_pool_server
# 用官方默认重起
sudo docker run -d --name openclaw_pool_server --restart unless-stopped \
    -p 18081:18081 \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v /nfs/terminal-rl-workspace/OpenClaw-RL:/nfs/terminal-rl-workspace/OpenClaw-RL \
    -e DATASET_DIR=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/dataset \
    -e TBENCH_OUTPUT_ROOT=/nfs/terminal-rl-workspace/OpenClaw-RL/terminal-rl/build_outputs \
    -e WORKER_MAX_TASKS=16 \
    -e WORKER_MAX_RUNS_PER_TASK=8 \
    openclaw_pool_server:v1 \
    bash terminal-rl/remote/run_pool_server.sh

风险：128 个并发 task docker stack 在单机是 32+ GB RAM、200+ GB tmpfs，如果命中很多重镜像 task（如 #437 那种 Java 依赖一堆），可能 OOM 或 disk full。需要 RAM 和 NFS quota 监控。

选项 B — 多 pool 单机（端口分发）

for port in 18081 18082 18083 18084; do
  sudo docker run -d --name openclaw_pool_${port} --restart unless-stopped \
      -p ${port}:${port} -e ENV_SERVER_PORT=${port} \
      -e WORKER_MAX_TASKS=8 -e WORKER_MAX_RUNS_PER_TASK=4 \
      ... openclaw_pool_server:v1 \
      bash terminal-rl/remote/run_pool_server.sh
done
# 启动训练时
export WORKER_URLS="http://127.0.0.1:18081,http://127.0.0.1:18082,http://127.0.0.1:18083,http://127.0.0.1:18084"

4 个 pool × 32 lease = 128 lease，刚好覆盖 demand。每个 pool 独立 docker compose namespace，failure isolation 比 A 好，但还是共享同一台机的总 RAM + disk——治标不治本。

选项 C — 官方推荐路径：N 台真正独立机器

按 README §0 起 2-4 台 worker（cloud VM 或闲置服务器都行，不要 GPU），每台跑官方默认 16/8。WORKER_URLS 填多台 IP。最稳、最贵、配置最多，但和上游设计完全对齐。

选项 D — 缩 demand 匹配现有容量

把训练 args 里 --rollout-batch-size 16 --n-samples-per-prompt 8 调成 --rollout-batch-size 4 --n-samples-per-prompt 8，demand 降到 32 = 现有容量。代价是 effective batch size 减 4×，训练速度变慢，且 GRPO 的 group-norm signal 也更稀（每 round 少 3/4 的组）。不推荐，但 quick fix 可行。

---

7 结论

• 官方脚本 / 配置 / README 一切正常，没有 bug
• 单看 terminal-rl_qwen3-8b.sh 这一个文件确实"看不出"它对 worker 容量的隐式假设——这是上游文档可以改进的地方（在脚本头注释里加一行 # Requires WORKER_URLS pointing to pool servers with at least 128 total leases）
• 我们这次的 mode collapse 根因是部署偏离，不是 GRPO/数据/调参问题
• 上一条 comment 给的"修复建议"里 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 (pool queue) / Qwen3-8B terminal-rl run (45h, ~1100 steps): peak 0.45 acc → mode collapse #2 (allocate retry) / 实验记录：terminal-rl Qwen3-8B run-3 (60h, 565 step, wandb msp60ius) — accuracy 0.32→0.52，无 mode-collapse + 6 类 dataset 卡顿 #4 (best-by-save) 仍然是上游可以做的改进；但 env-pool 完整记录：架构 / 6 个踩坑 / 持久化配置 / 系统化验证脚本（issue #1/#2 末段退化的环境侧根因） #3 (early-stop on non_trainable_ratio) 和现在这条结合更紧——如果部署阶段 deviate 了上游隐式假设，应该有个 health-check 在 first-N rollouts 就告警 "non_trainable >> 0.5，pool 容量看起来不够，停下检查 WORKER_URLS"，免得像我这样烧 45 h 才反应过来

[HansBug]

续问：429 sample 进入计算流程的细节 + Phase B→C 一夜跳变的诱因

把两件事都拆到代码 / 日志 / wandb 行级，分开答。

---

Part 1 — 一个 429 失败的 sample 在训练里到底发生了什么

TL;DR：它被打成 remove_sample=True 后不进入 GRPO advantage 计算、不进入 loss、不影响 reward_mean / accuracy / raw_reward / KL 这些 wandb metric——它只通过两条路径扰动：(a) 让 terminal/non_trainable_ratio +1；(b) 因为它的 response_length=0，会把 rollout/response_len/mean 这个原生 metric 拉低（这是和上一条 comment 描述的"模型本身在缩短"不同的另一个独立来源）。它不是当作 0 reward 处理，它是被整个剔除。

下面把每一步源码标出来。

1.1 429 → outcome=None 的 happens-before

terminal-rl/generate.py:96-115（节选并加注）：

try:
    stage = "env.allocate"
    lease_id = await env_client.allocate(task_key)
    env_ready_for_evaluation = True
except Exception as exc:
    _log_stage_exception(log_tag, stage, exc)        # → "env.allocate failed (HTTPStatusError): 429..."
    rollout_error = _format_exception(exc)            # rollout_error 是字符串
    # outcome 仍然是 None（line 98 初始化）

# 同样的 try/except 包了 runner = AgentRunner(...)（line 158）和 runner.run_episode(...)（line 165）
# 这两步任何一步抛异常都把 outcome 留在 None

走到 build_samples_from_outcome 时（terminal-rl/sample_builders.py:43-73）：

def build_samples_from_outcome(sample, outcome, *, reward, rollout_error, eval_error, ...):
    if rollout_error is not None:
        sample.metadata["rollout_error"] = rollout_error
    if eval_error is not None:
        sample.metadata["evaluation_error"] = eval_error
    if outcome is None:                                # ← 我们的 case：429 让 outcome=None
        return build_non_trainable_sample(
            sample,
            Sample.Status.FAILED,
            reward=reward,                              # reward 在 generate.py:170 初始化为 0.0，evaluate 没跑过
        )
    ...

build_non_trainable_sample（sample_builders.py:26-40）：

def build_non_trainable_sample(sample, status, *, reward=None) -> List[Sample]:
    sample.status = status                              # = Sample.Status.FAILED
    outcome = 0.0 if reward is None else reward         # = 0.0
    sample.reward = {
        "accuracy": outcome,                            # = 0.0
        "discounted_outcome": 2.0 * outcome - 1.0,      # = -1.0
        "score": 2.0 * outcome - 1.0,                   # = -1.0
    }
    sample.remove_sample = True                         # ← key flag
    return [sample]

到此这个 sample 长这样：status=FAILED, reward.score=-1.0, response_length=0, loss_mask=None, remove_sample=True。

1.2 进 train_data 时被剔除——三道关

slime/ray/rollout.py:148-158（顶层入口 generate(rollout_id)）：

data, metrics = self._get_rollout_data(...)           # data 是上面所有 samples（含 429 死掉的）
self._save_debug_rollout_data(...)
_log_rollout_data(rollout_id, self.args, data, ...)   # ← (M1) 在这里写 metrics，data 还没过滤
data = self._convert_samples_to_train_data(data)      # ← 在这里过滤

_convert_samples_to_train_data（rollout.py:602-650）：

def _convert_samples_to_train_data(self, samples):
    ...
    _mark_removed_samples(samples)                     # 多模态缺 train_inputs 的也打 remove_sample（不相关）
    samples = _drop_removed_samples(samples)           # ← (D1) 把 remove_sample=True 的全部丢掉，429 sample 在这里消失
    samples = self._drop_constant_reward_groups(samples)  # ← (D2) 再丢 reward 全相同的 group
    ...
    raw_rewards, rewards = self._post_process_rewards(samples)  # 在剩余样本上做 z-score group norm

加上 loss_mask=[0]*response_length 兜底（rollout.py:691-699，理论上即使没被丢掉也不会回传梯度）：

for sample in samples:
    if sample.loss_mask is None:
        sample.loss_mask = [1] * sample.response_length
    ...
    if sample.remove_sample:                            # ← 兜底，被丢的样本不会到这一行
        sample.loss_mask = [0] * sample.response_length

1.3 各 wandb metric 看不看得到这个失败 sample

metric	计算位置	源码	看到失败 sample 吗
terminal/non_trainable_ratio	rollout_log.py:42-44	len([s for s in samples if s.remove_sample]) / len(samples)	+1（这就是它的语义）
terminal/reward_mean	rollout_log.py:46-50	只对 trainable = [s for s in samples if not s.remove_sample] 求平均	不看
terminal/accuracy	同上，rollout_log.py:54-59	只对 trainable	不看
terminal/failed/failed_ratio	rollout_log.py:31-41	单独按 s.status == FAILED 统计	看（独立 metric）
rollout/raw_reward	actor.py:496-499（fsdp）/同等位置（megatron）	用 train_data["raw_reward"]，已过 (D1)+(D2)	不看
rollout/response_len/mean	rollout.py:1218（compute_metrics_from_samples）	[sample.effective_response_length for sample in samples] 用的是 (M1) 时点的 samples，未过滤	看到 0（拉低均值）
train/grad_norm/kl_loss/entropy_loss	actor 训练循环	只对 loss_mask=1 的 token 反传	不看
rollout/zero_std/count_*	rollout.py:1262-1276（_compute_zero_std_metrics）	(M1) 时点的全部 samples 按 group 聚合	看到（被记成 reward=-1 的 group）

重要副作用：Sample.response_length 默认 0（slime/utils/types.py:21），失败 sample 没 rollout 也没 set response_length，所以它在 rollout/response_len/mean 里贡献的是 0 token。当末段 92% sample 失败时，光是这条就把均值拉到 0.92×0 + 0.08×80 ≈ 6.4 token——和 wandb 上看到的 last20=7.0 几乎一致。所以"response 从 97 token 塌缩到 7 token"这条曲线，至少有一半是"sample 失败比例上升 → 多个 0 入均值"的稀释效应，并不全是模型本身在缩短。

1.4 GRPO advantage 公式上的影响

GRPO 在 _post_process_rewards（rollout.py:343-398）里对每个 group 做 z-score：

vals = torch.tensor([raw_rewards[i] for i in idxs], dtype=torch.float32)  # group 内
mean, std = vals.mean(), vals.std()
norm = (vals - mean) / (std + 1e-6)

由于 samples 已经被 _drop_removed_samples 过滤过，GRPO 的 group 里看不到 reward=-1 的失败样本，group_mean / group_std 不会被 -1 拉偏。但 group 大小变小了：

• 设计 group_size = n_samples_per_prompt = 8
• 末段 92% 失败时，group 实际有效大小 ≈ 0.7（即大多数 group 被 (D2) 砍光，仅 1 个 prompt 偶尔能活下来 1 个 sample）
• (D2) 在 group 大小 ≤ 1 或全 reward 相同时把整 group 丢掉

这就是为什么 rollout.py:443 在末段每个 rollout round 都打："Dropped constant-reward groups for grpo: dropped=[N₁,N₂,...] kept=[Nₖ] samples 20 -> 10"——20 个进入 (D2) 的样本，10 个被丢，10 个真正进入梯度。

1.5 一句话总结 Part 1

• 429 sample 不算 0 reward，不算 fail penalty，就是被整个剔除
• 剔除后梯度没受影响
• 但两条间接污染：(a) non_trainable_ratio 是它的直接报表；(b) rollout/response_len/mean 因为它带着 response_length=0 入均值，被拉低了
• 模型策略是否继续学，取决于"剩余样本里 group 不被 (D2) 全砍 + group 内 reward 有方差"——末段两条都不满足，所以 grad_norm → 0

---

Part 2 — Phase B→C 转折是 04-25 上午 10:00 前后的一次系统性事件

把 wandb 按 rollout/step 重新 bucket（30 step / 桶）后，转折点非常清晰：

step 区间	non_trainable	response_len	raw_reward	accuracy
271–300	0.49	140	-0.03	0.40
301–330	0.46	140	-0.07	0.33
331–360	0.52	70	-0.05	0.38
361–390	0.76	45	-0.14	0.42
391–420	0.80	41	-0.40	0.36

non_trainable +0.24 / response_len ÷3，发生在 step 360→390 这一桶（30 个 rollout，约 1 小时）。映射到 wall clock：

rollout/step	训练 runtime	wall clock
300	17h10m	25-04-25 05:54
330	19h46m	25-04-25 08:30
360	22h04m	25-04-25 10:48
390	23h18m	25-04-25 12:02
420	24h29m	25-04-25 13:13

所以真实的 phase B→C 切换时间点是 04-25 ~10:48。去 training_8b.log 翻同时段的指标：

2.1 throughput 一夜跌 3×

每 2 小时区间内"完成的 rollout 数"（grep Rollout finished:）+ "env.allocate 429 数"（grep env.allocate failed）+ "/reset 500 数"：

04-25 时段	rollouts/2h	429/2h	/reset 500/2h
06:00–08:00	171	960	627
08:00–10:00	287	1 728	1 167
10:00–12:00	98	1 439	1 156
12:00–14:00	130	2 784	2 511
14:00–16:00	103	2 688	2 363
16:00–18:00	72	1 920	1 745
18:00–20:00	99	3 840	3 547
20:00–22:00	79	2 976	2 824

两个肉眼可见的 inflection：

• 10:00 throughput 拐点：rollouts/2h 从 287 → 98，3×慢
• 18:00 又一次崩：rollouts/2h 跌到 72，且 429 一次性翻倍到 3 840

2.2 诱因不是 429，是 /reset 500——pool 关掉旧 lease 失败

注意 429 数从 1 728 → 1 439（10:00 时段反而下降了）。而 rollouts 从 287 → 98。这意味着原因不是"挤进来的请求多了"，是"现有 lease 占用时间变长了"。

去查 /reset 500 的内容（pool_server 的 /reset 端点，对应 lease 上 docker compose 重置）：

$ grep "Server error '500.*reset" training_8b.log | head -1
[2026-04-25 12:00:00] http_utils.py:218 - Error: Server error '500 Internal Server Error'
    for url 'http://127.0.0.1:18080/reset'
[2026-04-25 12:00:00] generate.py:63 - [task=1102 ...]
    env.reset failed (HTTPStatusError): ...

/reset 500 出现的时候，pool 端的 lease 进入"挂起"状态（pool_server 的 pending_closes 计数器堆积）。lease 不能复用 → 后续 allocate 撞 429 → throughput 崩。

/reset 500 的来源是 terminal-rl/remote/pool_server.py 调用底层 docker compose -f ... down + up，在容器 / namespace / volume 状态混乱时返回 docker-side error。

2.3 docker daemon 同时段开始抗议

journalctl 拉 dockerd 日志（同台机的 systemd 单元）：

$ sudo journalctl -u docker --since '2026-04-25 09:00:00' --until '2026-04-25 11:00:00' | head
Apr 25 09:00:35 dockerd[2947605]: 2026/04/25 09:00:35 http2: server: error reading
    preface from client @: read unix /run/docker.sock->@: read: connection reset by peer
Apr 25 09:00:35 dockerd[2947605]: ...（同款错误连续刷）

connection reset by peer 意味着 docker socket 上的 client（pool_server 进程）频繁中途断连。dockerd 在 09:00 已经撑不住了。

2.4 root cause 拼图

把所有线索接到一起：

1. 设计层面 4× over-subscribe（上一条 comment §3 论证过：32 lease vs 128 demand）从训练第 11 秒起就在 429
2. 但 09:00 之前 throughput 是 OK 的——靠的是 lease 周转快：每个 rollout ~1–3 min，docker compose down/up ~10s，pool 周转 cycle ~3–5 min；只要新 lease 能持续放出来，就能勉强吃下 128/round 的 demand
3. 04-25 09:00 左右 docker daemon 内部状态崩——最可能的具体原因（按可能性排序）：
   • overlayfs / mount 表过载：8 GPU × 3 sglang engines + ckpt 写 NFS + pool 反复 docker compose up/down，单台 dockerd 在 22h 累计运行 ~50000 次 docker compose 操作，mount namespace、network namespace、cgroup 累计创建/删除超 10 万次。Linux kernel 的 mount 表 fanout / network namespace gc 在这个量级是已知性能问题
   • dockerd 后端 client 连接池打爆：http2: server: error reading preface from client 是典型的 dockerd 收到 client 连接但 client 已超时关掉 → pool_server 的 docker-py / aiohttp client 累积超时
   • 磁盘 IO 抖动：/var/lib/docker 在系统盘（4.8 TB / 888 GB free，82% 用），overlayfs 写性能下降；同时段 ckpt_retention 在 NFS 删 ~50 GB 的 iter_* dirs，可能间接影响 docker overlayfs 的 fsync
4. 从 09:00 开始进入恶性循环：
   • /reset 500 抬头 → lease 没及时归还 → 429 抬头 → trainable sample 数雪崩 → GRPO group 大量 (D2) 砍 → 真正进梯度的 sample 偏向极简单 task（ffmpeg / sed 单行）
   • 模型在很稀的信号上更新，response 越走越短（mode collapse 早期）→ 但这反而没让 lease 归还更快，因为单个 rollout 仍然要 docker compose up/down 一整套，瓶颈在 dockerd 而不在 model output
5. 04-25 10:48 step 360 那个桶：throughput 已经从 287/2h 降到 98/2h（3×），90% rollout 进入 iteration_limit=True，GRPO 一次只能从 128 sample 里救出 5–8 个真正能算 advantage 的——non_trainable_ratio 报 0.92 是这个事实的直接 report

2.5 为什么 issue #1（4B / 270 step）没撞到

issue #1 4B 跑了 10 小时就 KL 漂移主动停。10 小时这个长度刚好还在 dockerd 状态稳定的窗口里。本次 8B 跑到 22 小时才进入"dockerd 累积态"——所以 4B 没暴露 root cause #3 这一层。

如果当时 4B 继续跑到 22 h+ 也会撞到同款 phase transition，区别只在 model 是 4B 还是 8B 决定每个 rollout 的 sglang 推理时长。

2.6 修复

针对 root cause #3 的具体方案（除了"把 pool 容量调到 1024 lease"已经做了之外）：

1. pool_server 周期性 docker prune：每 30 min docker system prune -f --filter "until=10m" 把 stopped container / dangling network / 过期 image layer 清掉，防止 mount/namespace 累积
2. 拆 dockerd：pool 用独立 docker daemon（dockerd --data-root=/mnt/data/pool-docker --pidfile=...），跟训练用 sglang 容器 / ckpt_retention 等分开，避免 host docker socket 被多源高频调用
3. /reset 流程加 fallback：reset 500 时 pool 主动 kill + recreate lease，而不是让 lease 卡在 pending_closes
4. 健康监测早停：rollouts/2h < 0.5 × baseline 触发告警 + 主动暂停训练，让人来检查 dockerd

第 1 / 2 条都是 ops 侧；第 3 条要改 pool_server.py 上游；第 4 条对应 issue body §9.3 那条 "non_trainable 早停" 的具体实现路径。

---

一句话合起来

429 sample 在算法侧是干净剔除（不污染梯度，不算 0 reward），它只在两条路径上影响 wandb 报表——non_trainable_ratio 直接 +1，response_len/mean 间接被 0 拉低。Phase B→C 那次跳变不是 GRPO 的锅、也不是模型的锅，根因是单 dockerd 在 22h 累计 docker compose 操作后状态污染（mount/namespace/连接池），/reset 500 抬头让 lease 无法及时归还，pool throughput 一夜跌 3×，把已经 4× over-subscribe 的局面推到了崩溃面。

[HansBug]

续问：phase C 起 terminal/reward_mean 在 ±1 之间剧烈跳变是怎么回事

短答：不是模型在两个极端之间真的来回切换，是 (1) reward_mean 这个 metric 的统计稳定性被 trainable 样本数从 ~150 砍到 ~10 给打破了 + (2) 留下来的样本 reward 严重单态化（要么全 -1 要么全 +1，中间值消失），两件事叠加 → wandb 上看到的"剧烈波动"。

下面把 wandb 数据 + 源码 + 单步实例摆全。

---

1 metric 的精确定义

terminal-rl/rollout_log.py:46-50：

if trainable:
    trainable_rewards = [s.reward["score"] for s in trainable]
    log_dict["terminal/reward_mean"] = sum(trainable_rewards) / len(trainable_rewards)

s.reward["score"] = discounted_outcome = 2 * accuracy − 1（sample_builders.py:108-113），accuracy 是 env_client.evaluate() 返回的 pytest pass 比例。所以单 sample 的 score 离散取值集合 = {-1.0, -0.5, -0.34, 0, 0.34, 0.5, 1.0}（对应 reward histogram 见 issue body §6 那段）。

关键：分母 len(trainable_rewards) 在 phase C+ 急剧缩水。

---

2 trainable 样本数从 152 → 10：分母崩塌

按 1 - non_trainable_ratio × total_samples 反推每步 trainable count，按 phase 分桶：

phase	step range	trainable 中位数
A	1–30	152
A–B（含）	1–200	152
C–E 非极端步	201–1095	27
C–E 中 |reward_mean|≥0.99 的 220 步	201–1095	10

220 个 reward_mean 落在 ±1 的步里，73 %（161/220）发生在 trainable 6–15 区间；9 步甚至 trainable ≤ 5；只有 1 步 trainable > 50。和 reward_mean 极端化 1:1 共变的就是分母变小。

随便 pick 几个 phase D 的 ±1 步看一下原始数：

step 602: total=138 non_train=0.91 trainable=12  completed=13 truncated= 0  reward_mean=-1.000
step 603: total=136 non_train=0.92 trainable=11  completed= 1 truncated=10  reward_mean=-1.000
step 605: total=134 non_train=0.94 trainable= 7  completed= 8 truncated= 0  reward_mean=-1.000
step 612: total=136 non_train=0.99 trainable= 1  completed= 1 truncated= 0  reward_mean=-1.000
step 613: total=...  non_train=...  trainable=20 completed=20 truncated= 0  reward_mean=+1.000
step 614: total=...  non_train=...  trainable=16 completed=16 truncated= 0  reward_mean=-1.000

step 612 是退化极致：trainable=1，单 sample reward=0 → score=-1 → mean=-1 ——根本不是 mean，是单点取值。

---

3 但真正驱动 ±1 的不是小 N——是 trainable batch 整批同号

光分母小不一定让 mean 跑到 ±1.0，还得分子里所有 sample 同号。本次实证下来 末段 91 % 的 step 内、trainable 子集里 max-min < 0.01（也就是所有 trainable sample reward 完全相同）。

把每步 terminal/reward_max - terminal/reward_min 的范围按 phase 看：

phase	mean range	同号率 (max-min<0.01)
A 1–30	1.77	0/29 (0 %)
B 31–200	1.84	0/158 (0 %)
C 201–600	1.44	33/358 (9.2 %)
D 601–1000	0.46	224/360 (62 %)
E 1001–1095	0.13	77/85 (91 %)

phase A-B 任何一步 trainable 子集都是有 reward 跨度的（min ≈ -1，max ≈ +0.8），mean 自然落在中间 [-0.5, 0]。

phase E 91 % 的步 trainable 集完全单态：12 个全 -1，或 8 个全 +1，或 7 个全 -1。直接进 mean 就是 ±1.0 取值。

---

4 为什么会单态——env-pool 退化把 sample 分布劈成两端

之前几条 comment 的环境分析在这里收口。phase C+ 的 trainable 子集是经过 (a)+(b)+(c) 三道环境侧筛子之后生还的样本：

• (a) 92 % 的 sample 在 env.allocate 阶段就 429 死了（status=FAILED，remove_sample=True，不进 trainable）
• (b) runner.run_episode 阶段 docker compose /reset 500 死了（同上 → FAILED）
• (c) env.evaluate 阶段拿到 reward 的，只剩两类：
  • 简单任务（ffmpeg 一行 / sed 一行）：单条 shell 命令一次性全 pass → reward=1.0 → score=+1.0
  • 难任务 + truncated：模型跑完 10 turn 还没解决 → iteration_limit=True → 但 status=TRUNCATED 不是 FAILED，所以仍然算 trainable；最后 evaluate 时 pytest 还是全挂 → reward=0.0 → score=-1.0

中间值（0.33 / 0.5 / 0.67 partial pass）几乎消失了——要么任务足够简单一次过完，要么模型干脆放弃中间状态、用 10 turn 也卡不动 pytest。

可以从全程 evaluate 的 reward histogram 验证（grep "Evaluation completed reward=" training_8b.log 总 7757 次）：

   3193 reward=0.0    (41 %)  → score=-1.0   ← 最大池
   1227 reward=1.0    (16 %)  → score=+1.0   ← 第二大池
   1294 reward=0.33   (17 %)  → score=-0.34
    901 reward=0.67   (12 %)  → score=+0.34
    429 reward=0.50   ( 6 %)  → score= 0.0
    420 reward=0.25   ( 5 %)  → score=-0.5
    220 reward=0.75   ( 3 %)  → score=+0.5

整个 run 41 % 落在 -1.0、16 % 落在 +1.0，中间只占 43 %。幸存到 trainable 子集的样本里，因为环境侧筛掉了大部分 partial 失败（pool 阶段就死了），中间值占比比这更低——剩下的几乎只有"完全解决"和"完全没解决"两类。

加上 phase C+ 的 rollout 数下降到 10/round，trainable 里随便落一个 batch 就是"全成功"或"全失败"——reward_mean 自然在 -1 / +1 间跳。

---

5 这种 ±1 还会进梯度吗——不会

回到代码：

• terminal/reward_mean 在 rollout_log.py 里算的是log 时点的 trainable（即 _drop_constant_reward_groups 之前的）
• 但这些"全 -1"或"全 +1"的样本紧接着会被 _drop_constant_reward_groups（slime/.../rollout.py:400-451）整组砍掉——因为同一 prompt 8 个 sample 全相同就是 zero-variance，触发 dropping
• 末段 91 % 的 step 都是 max==min → 几乎所有 group 都被砍 → 真正进梯度的 sample 数 ≈ 0
• 然后 _make_dummy_samples（rollout.py:630-646）补 dp_size 个 dummy（tokens=[0,0], loss_mask=[0]）让 batch 不空 → train 步走个空操作

所以我们在 wandb 上看到的 ±1 振荡曲线只是 logging-side 的统计噪声，对应的训练步绝大部分是空跑，这也对应 train/grad_norm 末段 0.008 的事实。

---

6 一图概括

                        wandb 上看到 reward_mean
                                ↑
                ┌───────────────┴───────────────┐
                │                               │
        trainable count 大幅下降          trainable 内部高度单态化
        152 → ~10 (15×)                   max-min: 1.77 → 0.13
                │                               │
                │                               │
        分母极小 → 单点取值                   样本只有两类：
        近似为 score                          • 简单任务 ffmpeg 一行 → +1
                                              • 难任务 truncated → -1
                                              中间值 (0.33/0.5/0.67) 在
                                              env-pool 筛漏后几乎消失
                │                               │
                └───────────────┬───────────────┘
                                ↓
                  reward_mean 在 ±1 之间跳跃式取值
                  (但 _drop_constant_reward_groups
                   会把这些 group 整批砍掉，
                   实际进梯度的是 dummy_samples)

---

一句话

reward_mean 在 phase C 起的 ±1 剧烈跳变是 (a) env-pool 退化把 trainable 数从 ~150 砍到 ~10（小样本 mean 不稳）+ (b) 环境侧筛子把 reward 中间值大量过滤掉（trainable 集合极化为"全过"或"全挂"两类）的统计学结果，不是策略真的在两个极端间震荡——这些 ±1 的 sample 紧接着就被 _drop_constant_reward_groups 全砍光了，没有任何一个进入梯度。所以 reward_mean 末段的可视化曲线和 grad_norm ≈ 0 是同一件事在 logging 和训练两个角度的两面。

[HansBug]

wandb 字段监控参考表（基于本次踩坑总结）

把这次跑下来 wandb 上能看到的所有重要字段整理一下。每行给出：一句话语义 / 计算位置（源码引用） / 健康区间（官方有就用官方，没有就用 issue #1（4B 270 step）+ 本次（8B 1095 step）实测） / 红旗值（什么时候要警觉）。

官方公开能找到的期望值只有 Tech Report Table 4 的 2 行：tool-call outcome-only 0.17 @ 250 step / GUI outcome-only 0.31 @ 120 step。terminal-rl 行为空。所以下面的 "期望" 列大量来自实证，标 † 的是有官方依据的。

---

A · 训练进度（Progress） — 主要看"跑没跑/跑到哪"

字段	一句话语义	计算位置	健康区间	红旗
_runtime	训练 wall-clock 秒数	wandb 自动	—	卡住时不再增长
_step	wandb 内部 step 计数	wandb 自动	—	—
rollout/step	rollout round 编号	slime/.../rollout.py:compute_rollout_step	单调递增、节奏稳定（本次约 25–60 s/step）	节奏突然变慢 ≥ 3×
eval/step	评测 round 编号	rollout.py:1192	每 eval_interval 跳一次	—
terminal/total_samples	一个 rollout round 产生的 sample 总数	rollout_log.py:36	等于 rollout_batch_size × n_samples_per_prompt（默认 16×8=128，本次未变）	< 128 表示有 sample 在 (D)+(M) 之前就被丢了
terminal/completed	本 round 中 status=COMPLETED 的样本数（agent 自然结束）	rollout_log.py:34, 37	A-B 段 50–80	末段 < 5
terminal/truncated	status=TRUNCATED（撞 --max-iteration 10）数	rollout_log.py:33, 38	A-B 段 5–25	末段 ≈ trainable 总数（说明几乎都没自然结束）
terminal/aborted	status=ABORTED（撞 parse_error_limit）数	rollout_log.py:32, 40	< 5	> 20 表示 model 输出 parse 不出来

---

B · 训练质量（Quality） — 主要看"在不在变好"

字段	一句话语义	计算位置	期望值（含官方）	红旗
terminal/accuracy	当前 rollout round 内 trainable sample 的 pytest pass 率均值	rollout_log.py:54-59（仅 trainable）	†GUI outcome-only ~0.31@120step / †tool-call outcome-only ~0.17@250step。terminal 实测 4B peak 0.385、8B peak 25 步桶 0.45+	单调下降超过 50 step 桶
terminal/reward_mean	同上，但是 score = 2×accuracy − 1，取 trainable 平均	rollout_log.py:46-50	健康时 ∈ (-0.5, 0.2) 区间慢慢爬	频繁触底 ±1.0（说明 trainable batch 已极化；不是策略好了——见上一条 comment）
terminal/reward_min / reward_max	trainable batch 内 score 的极值	rollout_log.py:51-52	max-min ≥ 1.0 持续保持	max-min < 0.1 持续 ≥ 30 step → batch 单态化（GRPO 失活前兆）
terminal/prm_turn_score	PRM-mode 才有；turn 级别 PRM 评分	rollout_log.py:61-68	只在 --prm-enable 下出现	—
rollout/raw_reward	_drop_constant_reward_groups 之后存活样本的原始 reward 均值（不带 normalize）	actor.py:496-499（fsdp）/同等位置（megatron），来自 train_data["raw_reward"]	健康时和 terminal/reward_mean 同号、同趋势但分母不同	与 reward_mean 长期反向 → group 选择性 dropping 在拉偏
eval/<task>	评测时各 task 的 pass 率	rollout.py:1167-1173	与训练 accuracy 相近	训练 acc 涨 / eval acc 不涨 = 过拟合
eval/<task>-passrate	passrate via compute_pass_rate（pass@k 风格）	rollout.py:1181-1188	同上	—

---

C · 训练健康（Health） — 这次最核心的几个，单看 §B 看不出问题

字段	一句话语义	计算位置	期望值	红旗
train/grad_norm	优化器看到的梯度 L2 范数	actor.py:744（fsdp）/megatron 同等位置	GRPO + Adam + lr=1e-6 + clip=1.0 健康区间 0.1 – 5；本次 phase A-B 1.0–1.7	< 0.05 持续 ≥ 30 step = 模型停止更新（本次末段 0.008）；> 50 = 即将发散
train/kl_loss	policy vs ref 的 KL 散度（k3 估计器）	fsdp_utils/actor.py:687-692，use_kl_loss=True, kl_loss_type=k3	配 --kl-loss-coef 0.01 时健康 < 0.3	> 0.5 持续 ≥ 5 step = policy drift 严重，主动停或加大 coef（issue #1 4B 在 0.54 时主动停）
train/entropy_loss	response token 的平均熵	fsdp_utils/actor.py:677	起始 0.05–0.20，缓慢下降是正常	突然上升 = 训练崩；塌到 0 = mode collapse
train/ppo_kl	per-token PPO KL（importance ratio 的 surrogate KL）	loss.py（megatron）/actor.py（fsdp）	< 0.05	> 0.1 = ratio clip 频繁触发
train/pg_clipfrac	被 PPO ratio clip 切到的 token 比例	同上	< 0.05	> 0.2 = 学习率/advantage 量级失配
train/loss / train/pg_loss	总 loss / policy gradient loss	actor.py:679	围绕 0 小幅震荡（GRPO 是 unbiased，期望值≈0）	单调上升或绝对值 > 1
terminal/non_trainable_ratio	一个 round 中 remove_sample=True 的样本比例（FAILED + outcome=None + empty interactions）	rollout_log.py:42-44	< 0.5 持续在线	> 0.7 持续 ≥ 30 step → env-pool 开始崩（本次末段 0.92，issue #1 在 4B 没暴露这个）；这是隐藏 KPI，比 grad_norm 早 100+ step 报警
terminal/failed_ratio	status=FAILED 的样本比例（独立于 remove_sample）	rollout_log.py:31, 41	< 0.05	> 0.3 = env / runner / evaluate 大量挂；与 non_trainable_ratio 差距大 = 大量"empty interactions"或 outcome=None 路径
rollout/repetition_frac	response 中检测到 token 序列重复的样本占比	rollout.py:1224（has_repetition）	< 0.05	> 0.2 = 解码退化（mode collapse 早期信号）
rollout/truncated_ratio	status=TRUNCATED 占全部 sample（不是 trainable 的）比例	rollout.py:1225	A-B 段 0.05–0.2	长期 > 0.7 = 模型自然结束能力丢失，10 turn 都跑不完
rollout/zero_std/count_-1.0 / count_+1.0	同 prompt 8 sample reward 全相同的 group 数，按 reward 值分桶	rollout.py:1262-1276（_compute_zero_std_metrics）	A-B count_-1.0 < 5, count_+1.0 < 3	count_-1.0 + count_+1.0 ≥ rollout_batch_size 表示几乎所有 group 都被 _drop_constant_reward_groups 砍光（本次末段 16/16）
rollout/response_len/mean	未过滤 samples 的 response 长度均值（含失败 sample 的 0）	rollout.py:1218，compute_metrics_from_samples	A-B 100–200 token	< 30 持续 = 失败比例飙升 + mode collapse 同时（混淆变量，需要交叉看 non_trainable_ratio）
rollout/response_len/max / min	同 round 内极值	compute_statistics(...)	max 接近 --rollout-max-response-len 8192 的 1/4 量级	max < 50 = 模型连最长 response 都很短，纯 mode collapse

---

D · 性能 / 吞吐（Perf） — 主要看"机器跟不跟得上"

字段	一句话语义	计算位置	期望值	红旗
perf/rollout_time	一个 rollout round 的总耗时（秒）	rollout.py:1233	A-B 50–120 s（本次）	突然变 3–5× 长 → env pool 退化（本次 04-25 10:00 转折点）
perf/tokens_per_gpu_per_sec	推理 GPU 每秒生成 token 数	rollout.py:1240	单 H200 ~500–2000 tok/s	跌一半 = sglang 端慢了（OOM swap、KV cache 满）
perf/longest_sample_tokens_per_sec	最长 sample 的 token/s	rollout.py:1241	同上	—
perf/non_generation_time/mean	一 sample 中非生成（env reset/exec/eval、PRM）耗时	rollout.py:1235	占总 rollout_time < 50 %	> 80 % = env 端比模型慢得多，pool 是瓶颈（本次）
perf/longest_sample_non_generation_time	最长 sample 的非生成时间	rollout.py:1251	—	突变
terminal/rollout_time	同 perf/rollout_time（custom log 里也写一次）	rollout_log.py:70	同 perf/rollout_time	—

---

E · 看图时的"五眼齐看"建议（按优先级）

按本次踩坑总结，单看 accuracy/reward 看不出 phase B→C 转折。建议训练时每隔 30 step 就看一遍这五对（任一对发出 red flag 就停下排查，不要让训练继续烧 GPU）：

1. grad_norm × non_trainable_ratio：grad_norm 跌一档 + non_trainable 涨一档 → env pool 在退化（本次 phase C 起）
2. reward_max - reward_min × zero_std/count_*：max-min 收窄 + zero_std count 增 → group 单态化（GRPO 失活前兆）
3. accuracy × eval/<task>：训练 accuracy 涨 / eval 平 → 过拟合简单 task；eval 涨 / 训练 noisy → 这才是真在学
4. response_len/mean × non_trainable_ratio：response_len 暴跌但 non_trainable 也飙 → 长度变化主因是失败比例（被 0 拉低均值），不是模型本身在变短；仅 response_len 跌而 non_trainable 平稳 → 模型自身在 mode collapse
5. kl_loss × entropy_loss：kl 涨 + entropy 涨 → policy 在大步探索；kl 涨 + entropy 跌 → policy 在退化收敛（issue 实验记录：terminal-rl Qwen3-4B GRPO outcome-only 单节点 8×H200（10h，wandb lpurziy1） #1 4B 末段）；两者都跌到底 → 完全停学（本次末段）

---

F · 早停规则建议（写到训练 wrapper 里）

按本次实证给一组工程化的 early-stop 阈值（patience-based，避免单步噪声）：

# 触发任意一条 → 立即 SIGTERM 训练进程
early_stop:
  - metric: terminal/non_trainable_ratio
    window: 30 rollout_steps
    threshold: > 0.7
    severity: warning
  - metric: terminal/non_trainable_ratio
    window: 60 rollout_steps
    threshold: > 0.85
    severity: stop
  - metric: train/grad_norm
    window: 30 rollout_steps
    threshold: < 0.05
    severity: stop
  - metric: train/kl_loss
    window: 5 rollout_steps
    threshold: > 0.5
    severity: stop
  - metric: rollout/zero_std/sum
    window: 10 rollout_steps
    threshold: > rollout_batch_size * 0.9
    severity: stop
  - metric: perf/rollout_time
    window: 20 rollout_steps
    threshold: > 3× moving_avg(60-step prior)
    severity: warning  # 提示去看 docker daemon / pool

issue #1 4B 在 KL 0.54 时是人工触发的 stop；本次 8B 应该早在 phase C non_trainable_ratio > 0.7 时（约 04-25 10:48，rollout step 360）就 stop——能省下大约 28 GPU·小时的浪费训练。

---

G · 一句话总结

accuracy / reward_mean 看着像主指标，但单看它们都是"事后诸葛亮"——它们出问题时训练已经死了 100+ step。真正能提前给信号的是 non_trainable_ratio（env-pool 健康度）+ grad_norm（是否还在更新）+ zero_std/count_*（GRPO group 是否还有方差）这三组健康类指标。本次留下的最大教训：把 §C 这一组指标和 §B 同等优先级地盯。