训练途中突然崩了，无论是grpo还是reinforce++，出现nan

[chuangzhidan]

(main_task pid=63313) step:83 - global_seqlen/min:22900.000 - global_seqlen/max:23135.000 - global_seqlen/minmax_diff:235.000 - global_seqlen/balanced_min:23017.000 - global_seqlen/balanced_max:23018.000 - global_seqlen/mean:23017.500 - state_tokens/total:20560.000 - state_tokens/coverage:1.000 - actor/kl_loss:nan - actor/kl_coef:0.001 - actor/entropy_loss:nan - actor/pg_loss:nan - actor/pg_clipfrac:0.000 - actor/ppo_kl:nan - actor/grad_norm:nan - mfu/actor:0.041 - actor/lr:0.000 - critic/score/mean:-1.000 - critic/score/max:-1.000 - critic/score/min:-1.000 - critic/rewards/mean:-1.000 - critic/rewards/max:-1.000 - critic/rewards/min:-1.000 - critic/advantages/mean:0.000 - critic/advantages/max:0.000 - critic/advantages/min:0.000 - critic/returns/mean:-1.000 - critic/returns/max:-1.000 - critic/returns/min:-1.000 - critic/process_rewards/mean:0.000 - critic/process_rewards/max:0.000 - critic/process_rewards/min:0.000 - critic/process_rewards/count:0.000 - critic/format_score/mean:0.000 - critic/format_score/max:0.000 - critic/format_score/min:0.000 - critic/answer_score/mean:0.000 - critic/answer_score/max:0.000 - critic/answer_score/min:0.000 - turns/mean:0.000 - turns/max:0.000 - turns/min:0.000 - response_length/mean:257.000 - response_length/max:257.000 - response_length/min:257.000 - response_length/clip_ratio:1.000 - prompt_length/mean:318.438 - prompt_length/max:338.000 - prompt_length/min:306.000 - prompt_length/clip_ratio:0.000 - timing_s/gen:136.423 - timing_s/ref:10.226 - timing_s/adv:0.110 - timing_s/update_actor:38.082 - timing_s/step:193.018 - timing_per_token_ms/adv:0.002 - timing_per_token_ms/ref:0.222 - timing_per_token_ms/update_actor:0.827 - timing_per_token_ms/gen:6.635
(main_task pid=63313) ACTIVE_TRAJ_NUM: [80, 0]

export VLLM_ATTENTION_BACKEND=XFORMERS
export BASE_MODEL='/data/Qwen2.5-3B-Instruct'
export PROJECT_NAME='hotpotqa_qwen2.5-3b-instruct'
export EXPERIMENT_NAME=reinforce_plus_plus
export HYDRA_FULL_ERROR=1
export CUDA_LAUNCH_BLOCKING=1
export CUDA_VISIBLE_DEVICES=2,3
export WANDB_API_KEY='029a79963667cd```````````````````2de9a9'
export WANDB_PROJECT="agent-r1_0331"

python3 -m verl.trainer.main_ppo
algorithm.adv_estimator=reinforce_plus_plus
data.train_files=./data/hotpotqa/train.parquet
data.val_files=./data/hotpotqa/validation.parquet
data.train_batch_size=16
data.max_prompt_length=4096
data.max_response_length=2048
data.max_start_length=4096
data.max_tool_response_length=2048
actor_rollout_ref.model.path=$BASE_MODEL
actor_rollout_ref.actor.optim.lr=1e-6
actor_rollout_ref.model.use_remove_padding=True
actor_rollout_ref.actor.ppo_mini_batch_size=8
actor_rollout_ref.actor.ppo_micro_batch_size_per_gpu=2
actor_rollout_ref.actor.use_kl_loss=True
actor_rollout_ref.actor.kl_loss_coef=0.001
actor_rollout_ref.actor.kl_loss_type=low_var_kl
actor_rollout_ref.model.enable_gradient_checkpointing=True
actor_rollout_ref.actor.fsdp_config.param_offload=False
actor_rollout_ref.actor.fsdp_config.optimizer_offload=False
actor_rollout_ref.rollout.log_prob_micro_batch_size_per_gpu=2
actor_rollout_ref.rollout.tensor_model_parallel_size=2
actor_rollout_ref.rollout.name=vllm
actor_rollout_ref.rollout.gpu_memory_utilization=0.4
actor_rollout_ref.rollout.n_repeat=5
actor_rollout_ref.ref.log_prob_micro_batch_size_per_gpu=2
actor_rollout_ref.ref.fsdp_config.param_offload=True
algorithm.kl_ctrl.kl_coef=0.001
trainer.critic_warmup=0
trainer.logger=['console','wandb']
trainer.project_name=$PROJECT_NAME
trainer.experiment_name=$EXPERIMENT_NAME
trainer.n_gpus_per_node=2
trainer.nnodes=1
trainer.save_freq=-1
trainer.test_freq=10
trainer.total_epochs=1
tool.env='search' $@

[wcleithinking]

+1

[0russwest0]

verl本身就存在这个问题，目前还没有被很好的解决。verl-project/verl#891 中提到了一个可能的解决方案，我们也在积极探索这个问题，如果大家有所发现，欢迎与我们交流分享。

[LYMDLUT]

rf++应该用k1 reward，grpo应该用k2 loss。

Welcome to read and quote our article. We have proven that in GRPO, the k2 loss is an analytical expression, which is better than the k3 loss. When the model generates a low probability, the gradient of the k3 loss will experience exponential growth, causing the model to collapse. However, the k2 loss does not have this problem. We have also provided additional correction methods for off-policy and std in GRPO.
[k2 loss就是比k3 loss好，以及grpo off-policy、clip_std()]https://zhuanlan.zhihu.com/p/1892008158626546312

@misc{Liu2025KL,
author = {YiMing Liu},
title = {Rethinking KL Divergence in RLHF: From Single Sample to Mini-Batch to Expectation},
year = {2025},
url = {https://www.notion.so/Rethinking-KL-Divergence-in-RLHF-From-Single-Sample-to-Mini-Batch-to-Expectation-1c18637cdeb3800ab47cd01d3fa33ea5},
note = {Notion Blog}
}

[chuangzhidan]

怎么在verl中改呢，verl没看到什么k1 reward ,k2 loss

[LYMDLUT]

怎么在verl中改呢，verl没看到什么k1 reward ,k2 loss

kl_pental="mse"
请向我反馈您的实验结果，如果有其它问题，可以在主页找到我的邮箱

[Xia723]

依旧不行

[wcleithinking]

still not work

[scewiner]

+1 ，用7B的模型，rollout 16的设置，基本20几步就崩了； 然后用官方脚本，1.5B的模型，确实能复现REAMDE的曲线，但是到90步左右还是会出现崩溃； 感觉reward计算有点问题，下面是崩了之后的得分为1的example：

或许用模型来评判比较合适

[chuangzhidan]

verl本身就存在这个问题，目前还没有被很好的解决。volcengine/verl#891 中提到了一个可能的解决方案，我们也在积极探索这个问题，如果大家有所发现，欢迎与我们交流分享。

想使用openrlhf吧，不知道怎么指定字段，因为没有openrlhf的input_key,output_key这样

[qinkevin]

我是突然在几轮后 think 和 llm的response 乱码，各种异常字符。

[0russwest0]

经过多轮实验与复现，我们已成功定位了导致训练崩溃的根本原因。通过对模型在崩溃前的pg_loss和kl_loss的实时监控，发现训练崩溃主要发生在两个关键计算节点：compute_policy_loss()和kl_penalty()中的ratio计算过程。

这一发现与 verl-project/verl#891 中的观察结果高度一致。虽然在compute_policy_loss()中添加torch.clamp可以在一定程度上缓解问题，但这只是治标不治本。ratio爆炸的原因是参考策略的概率分布和当前策略的概率分布之间差距过大，那究竟是什么导致模型输出的概率分布发生了突变呢？

进一步的，我们对输出的具体logit进行了监控，找到了导致损失爆炸的具体token。这个token是<|im_end|>!!!

原因分析

经过深入分析，我们认为问题的根源在于rollout阶段的人为干预机制与训练过程之间存在的不一致性：

1. 在rollout阶段，为了确保模型在输出工具调用指令后能够正确终止，我们在</tool_call>后强制截断了模型输出，并手动附加了<|im_end|>标记。

2. 然而在训练阶段，为了让模型学会自主输出<|im_end|>，我们并未对该token添加loss mask。

这种采样阶段与训练阶段的行为不对齐最终导致了训练的崩溃。

解决方案

我们提出的初步解决方案是：对<|im_end|>token同样施加loss mask。目前该方案正在测试验证中，我们会持续跟进测试结果。

欢迎社区成员一起参与讨论，共同探索更优的解决方案。如有任何新的发现或建议，请随时分享。

[chuangzhidan]

让模型学会自主输出<|im_end|>没毛病，而强制截断了模型输出，并手动附加了<|im_end|>标记反而怪怪的

[chuangzhidan]

经过多轮实验与复现，我们已成功定位了导致训练崩溃的根本原因。通过对模型在崩溃前的pg_loss和kl_loss的实时监控，发现训练崩溃主要发生在两个关键计算节点：compute_policy_loss()和kl_penalty()中的ratio计算过程。

这一发现与 volcengine/verl#891 中的观察结果高度一致。虽然在compute_policy_loss()中添加torch.clamp可以在一定程度上缓解问题，但这只是治标不治本。ratio爆炸的原因是参考策略的概率分布和当前策略的概率分布之间差距过大，那究竟是什么导致模型输出的概率分布发生了突变呢？

进一步的，我们对输出的具体logit进行了监控，找到了导致损失爆炸的具体token。这个token是<|im_end|>!!!

原因分析

经过深入分析，我们认为问题的根源在于rollout阶段的人为干预机制与训练过程之间存在的不一致性：

1. 在rollout阶段，为了确保模型在输出工具调用指令后能够正确终止，我们在</tool_call>后强制截断了模型输出，并手动附加了<|im_end|>标记。
2. 然而在训练阶段，为了让模型学会自主输出<|im_end|>，我们并未对该token添加loss mask。

这种采样阶段与训练阶段的行为不对齐最终导致了训练的崩溃。

解决方案

我们提出的初步解决方案是：对<|im_end|>token同样施加loss mask。目前该方案正在测试验证中，我们会持续跟进测试结果。

欢迎社区成员一起参与讨论，共同探索更优的解决方案。如有任何新的发现或建议，请随时分享。

这个已经有公开的初步解决方案了吗，可以一试？

[0russwest0]

初步解决方案已更新：https://github.com/0russwest0/Agent-R1/tree/debug_nan