verl 分布式训练性能剖析：PyTorch Profiler 配置与实战指南

verl 分布式训练性能剖析PyTorch Profiler 配置与实战指南【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl本文系统讲解 verlHybridFlow中如何使用原生 PyTorch Profiler 对 RL 后训练任务进行性能剖析覆盖全局与角色级配置体系、整步收集 / 离散模式 / mini-batch 调度三种采集策略、trace 文件命名与磁盘布局、NVTX 注入冲突排查以及结果可视化与上传。读完本文你可以为 Actor/Critic/Rollout 等任意角色按需开启 profiling精确到 stage 与 mini-batch 粒度定位训练瓶颈。一、profiling 的整体架构两层配置体系verl 的 profiling 由两层配置协同控制均位于训练器配置文件如 ppo_trainer.yaml中全局层global_profiler决定何时哪些 RL step以及在哪输出目录进行 profiling并承载面向所有角色的公共选项如结果搬迁、finish 钩子。角色层actor_rollout_ref.actor.profiler/.rollout.profiler/.critic.profiler等决定谁哪个角色、哪些 rank以及用什么工具进行 profiling每个 RL 角色Actor、Critic、Ref 等各自独立。两层之间通过继承与合并关联relocate_results、finish_hook_cmd、finish_hook_all_ranks、finish_hook_ranks等公共选项配置在global_profiler上后会被每个角色的 profiler 继承而DistProfiler的 rank 选择逻辑则在 profile.py 中实现——all_ranks为真时全部 rank 参与否则匹配ranks列表若两者都未设置但enable为真则默认只剖析全局 rank 0。从源码结构看DistProfiler是一个按config.tool分发的调度器见 profile.py支持nsys、npu、torch、torch_memory、precision_debugger多种后端。当tooltorch时实际由 torch_profile.py 中的Profiler类接管底层封装torch.profiler.profile并通过export_chrome_trace导出 trace。本文聚焦torch工具。二、配置详解2.1 全局控制global_profiler参数说明默认值tool剖析工具可选nsys/npu/torch/torch_memory/precision_debugger为null时由各角色继承自己的profiler.toolnullsteps需要剖析的 RL step 编号列表如[1, 2, 5]剖析第 1、2、5 步设为null关闭nullprofile_continuous_steps为True时将连续多个被剖析的 step 合并到一个文件中此时角色级discrete必须为False为False时每个 step 各自成文件Falsesave_pathtrace 结果保存目录outputs/profilerelocate_results剖析结束后把后端写到框架固定位置如 rollout 引擎的 per-replica 子目录的产物搬迁进save_path本身Falsefinish_hook_cmd在最后一个被剖析的 step 之后只运行一次的 shell 命令用于把结果一次性送出节点nullfinish_hook_all_ranks/finish_hook_ranks控制哪些 rank 执行 finish 钩子均未设置时回退到被剖析的 rank 集合False/[]以上默认值可在 ppo_trainer.yaml 与 profiler.yaml 中核对。profile_continuous_steps的开关逻辑在 ray_trainer.py 与 V1 训练器的 trainer_base.py 中均有对应实现连续步共享一个文件[1,2]一个文件、[5]另一个非连续步则每步独立成文件。2.2 角色级控制profiler每个角色的 profiler 配置结构一致默认值见 profiler.yamltool工具名默认继承全局profiler.toolenable是否为该角色开启 profilingall_ranks为True时剖析全部 rankranksall_ranks为False时列出要剖析的 rank为空列表时默认剖析 rank 0save_path结果保存路径默认outputs/profiletool_config.torchPyTorch Profiler 专属参数见下节。注意各角色的save_path默认指向同一个outputs/profile目录但由于文件命名中编码了角色与 rank见第四节不同角色的结果不会互相覆盖。2.3tool_config.torch专属选项tool_config.torch支持以下字段对应 config.py 中TorchProfilerToolConfig的校验逻辑contents要采集的内容列表默认空列表表示采集一切。合法值为cuda、cpu、memory、shapes、stack传入其他值会触发断言。各选项含义cpu剖析 CPU 活动。无论是否列出都会被采集——算子名和 verl 的各 stage 标记update_actor、compute_log_prob等都是 CPU 侧事件纯设备 trace 只剩裸 kernel、无法区分属于哪个 stage因此显式列出它是冗余的其余contents按原样生效cuda剖析 CUDA 活动memory跟踪张量内存分配/释放对应profile_memoryshapes记录算子输入的形状对应record_shapesstack记录源码文件与行号对应with_stack。底层映射见 torch_profile.pycuda映射到activitiesshapes到record_shapesmemory到profile_memorystack到with_stack且 CPU activity 无条件加入activities。discrete为False默认时一个进程在一次被剖析的 step 内所有内容写入同一份连续 trace为True时每个 stage 单独保存一个 trace 文件适合细粒度分析且在使用 Agent Loop 时是强制要求见 3.2 节。profile_token_start/profile_token_end仅对 rollout 角色生效定义 rollout 解码采集的 response token 区间。profile_token_start是起始 token 索引0-basedprofile_token_end是结束索引开区间。只有当两者同时有效0-based、profile_token_end profile_token_start、且在 response 长度范围内时才生效config.py的__post_init__会校验stop start。未设置时采集整个 rollout 阶段。该参数通过build_vllm_profiler_args/build_sglang_profiler_args见 config.py转换为引擎侧 APIvLLM 映射为delay_iterations/max_iterationsSGLang 映射为start_step/num_steps。schedule可选的torch.profiler.schedule作用于更新循环的 mini-batch粒度用于在 mini-batch 数量众多时对更新阶段降采样避免 trace 膨胀。仅在active 0时生效verl 每次更新一个 mini-batch 就推进一次prof.step()而 log-prob forward 和 rollout 阶段永不被降采样。完整字段为skip_first/wait/warmup/active/repeat定义见 config.py 中TorchProfilerScheduleConfig均为非负整数。详细语义见 3.3 节。三、三种采集模式实战3.1 整步收集continuous 模式不设置discrete默认False时每个被剖析的 RL step 内每个进程运行的所有内容写入一个trace 文件。注意这是单个 worker 视角下的整个 step而非整个 RL 系统的整步参见 4.2 节磁盘上的一次 RL step。global_profiler: steps: [1, 2, 5] save_path: ./outputs/profile actor_rollout_ref: actor: profiler: enable: True all_ranks: True tool_config: torch: discrete: False contents: [cpu, cuda] # rollout ref 跟随 actor 的设置3.2 离散模式discrete: True离散模式下每个 stage 单独保存一份 trace 文件适合对单个 stage 做深入分析并且在使用 Agent Loop 时必须开启详见 Agent Loop 文档。此时 Profiler 由推理引擎后端触发。actor_rollout_ref: actor: profiler: enable: True # True 表示剖析训练Actor all_ranks: False ranks: [0] # 全局 Rank 0 tool_config: torch: discrete: True contents: [cpu, cuda] rollout: profiler: enable: True # True 表示剖析推理Rollout all_ranks: False ranks: [0] # 全局 GPU rank每个 rank 会被映射到拥有它的 replica tool_config: torch: discrete: True # 必须为 True # 可选的 rollout 引擎侧采集 token 窗口不设置则采集整个 rollout 阶段 # 采集 [12, 46)即 token 索引 12~45 profile_token_start: 12 profile_token_end: 46 # ref 跟随 actor 的设置Agent Loop 模式要点Rank 定义Rollout 配置中的ranks是全局 GPU rank与训练角色一致你会精确拿到这些 GPU 的 trace。一个 rollout replica 驱动一个推理引擎覆盖world_size tensor_model_parallel_size * data_parallel_size * pipeline_model_parallel_size个 GPUreplicar拥有全局 rank 区间[r*world_size, (r1)*world_size)。每个列出的 rank 映射到拥有它的 replicareplica rank // world_size并对该 replica 的引擎进行剖析。由于 tensor-parallel 组无法按单个 GPU 剖析引擎会 trace replica 内每一个GPU但只保留你列出 rank 的 trace见Trace 位置其余留在子目录中。例如tp2时ranks: [0, 8]精确对应全局 GPU 0 和 8来自 replica 0 和 4而不是它们的 tp 伙伴 1 和 9落在不存在 replica 上的 rank 会被静默忽略。all_ranks: True剖析并保留每个 replicaranks留空则剖析拥有全局 rank 0 的 replica 并保留其全部 GPU。该映射逻辑在 profile.py 的build_rollout_dist_profiler中实现。推理引擎支持目前 vLLM 与 SGLang 引擎无需额外设置即可支持vLLM 引擎自动采集 AsyncLLM 调度栈与推理进程性能数据。verl 通过build_vllm_profiler_args同时兼容 vLLM 0.13.0 的新参数 API 与旧版VLLM_TORCH_PROFILER_*环境变量见 config.pySGLang 引擎自动采集推理进程性能数据但contents中的memory选项不支持build_sglang_profiler_args会发出警告并忽略见 config.py。采集窗口rollout replica 在整个训练 step 期间都被剖析。V1 训练器中生成与 step 解耦prompt 异步服务、从回放缓冲区消费因此不存在单个可包裹的 generation 调用。Trace 位置引擎接收的是输出目录而非文件名因此每个 replica 写入托管它的节点上的save_path/agent_loop_rollout_replica_n/。设置global_profiler.relocate_results: True后被请求 GPU 的 trace 会在 step 结束时被搬移到save_path本身使同一个 step 的所有 trace 都在你配置的那一个目录里这是不做子目录遍历的后处理所依赖的。搬迁后的文件命名为rollout-replican-globalrankg_引擎自己的文件名其中n是 replica 索引、g是该文件的绝对全局 GPU rankreplica * world_size tp_rank因此与你在ranks中配置的全局 rank 一一对应——例如tp2、ranks: [0, 8]时save_path中只会出现rollout-replica0-globalrank0_...和rollout-replica4-globalrank8_...引擎同样 trace 了的 tp 伙伴此处为全局 GPU 1 和 9留在 per-replica 子目录中。搬迁依赖从引擎自己的文件名中读取每个 GPU 的 tensor-parallel rankvLLM 写...-rank-k...SGLang 写...-TP-k...。当无法无歧义地读取该 rank例如引擎按 host/pid 命名或 SGLang 使用额外并行维度-DP-/-PP-/-EP-导致 GPU 线性偏移与布局相关时trace 会被保留绝不丢弃仅命名为rollout-replican_引擎自己的文件名因此你可能会看到该 replica 的其他 GPU。该搬迁逻辑含正则匹配与keep_global_ranks过滤在 config.py 中完整实现。Rollout 引擎自身不执行finish_hook_cmd由同一节点上共存colocated的训练 worker 在运行结束时一次性上传save_path此时已包含搬迁来的 trace。3.3 更新循环 mini-batch 调度scheduleglobal_profiler.steps选择的单位是一个 RL step。默认情况下被剖析的 step 会被整体采集worker 运行的所有内容落入一份 trace每个 stage 与每个更新 mini-batch 在内部被标注更新循环把每次迭代包裹在嵌套于update_actor/critic_update下的mini_batchi行中step 内从 0 编号引擎再把每个 mini-batch 拆分为梯度累积 micro-batch显示为内嵌的micro_batchj行纯前向 stagecompute_log_prob、compute_ref_log_prob、critic values是单个以 stage 命名的行引擎把它的 batch 拆分为内部的micro_batchj行每次 forward 一行。如果只看到一个micro_batch0说明 batch 在一个 micro-batch 内放得下常见于推理 token 预算log_prob_max_token_len_per_gpu/*_micro_batch_size_per_gpu较大时调低它即可把 forward 拆成更多 micro-batch。当更新循环有大量相同 mini-batch 时全部记录会让 trace 膨胀。tool_config.torch.schedule对其进行降采样它只会收窄更新阶段的 mini-batchprof.step()只在那里推进log-prob forward 和 rollout 上从不推进且仅在active 0时生效它从不写 torch 的ProfilerStep#n行——这里的 step() 是单个 mini-batch并非有意义的 RL step那些行只会增加噪声。降采样行为取决于discretediscrete: False每进程一份连续 traceschedule 决定保留哪些更新 mini-batchskip_first/wait/warmup跳到更靠后的 mini-batchactive设置记录多少个。因为step()每 mini-batch 推进一次窗口边界总是落在 mini-batch 之间被捕获的 mini-batch 保持完整。代价是 torch 只持久化以RECORD_AND_SAVE结尾的窗口因此向前跳过也会丢掉位于 active 窗口之前运行的 rollout/log-prob 阶段。把skip_first/wait/warmup保持为 0默认值可以从头开始记录完整保留前面所有 stage 加上前active个更新 mini-batch。不设置 schedule或active: 0则保留每个 mini-batch。actor_rollout_ref: actor: profiler: enable: True all_ranks: True tool_config: torch: discrete: False # 每进程一份连续 trace schedule: active: 1 # 完整保留前面所有 stage再加上更新循环的 mini_batch0 # skip_first: 1 # ...或者向前跳只捕获 mini_batch1前面的 stage 会被丢弃discrete: True每 stage 一份 trace更新阶段被隔离剖析因此完整 schedule 作用于它的 mini-batchskip_first/wait/warmup丢弃前导 mini-batch只保留active窗口并重复repeat次0表示持续到循环结束。log-prob、rollout 和 ref 阶段各自拥有完整 trace不受 schedule 影响。更新阶段的文件会标注其含有的 mini-batch 窗口例如..._mb3-4。actor_rollout_ref: actor: profiler: enable: True all_ranks: True tool_config: torch: discrete: True schedule: skip_first: 1 wait: 1 warmup: 1 active: 2 # actor_update trace 只包含 mini_batch3..4log-prob/ref trace 保持完整 repeat: 0两种模式下 trace 都不含ProfilerStep#n行应依据 stage 行和更新循环内的mini_batchi行导航。discrete: False下 schedule 从skip_first/wait/warmup指向的位置开始保留active个更新 mini-batch向前跳会丢弃更早的 stage把它们留 0 则完整保留所有更早 stage或干脆不设 schedule 保留每个 mini-batch。global_profiler.profile_continuous_steps: True时一段连续的被剖析 step 共享一个文件。底层实现中连续模式由 torch_profile.py 的start/step/stop驱动_resolve_continuous_schedule_kwargs会把repeat默认收敛为单个窗口离散模式则由annotate装饰器在 stage 函数周围起停 profiler_flush_partial_window负责在更新循环于窗口中途结束时把RECORD提升为RECORD_AND_SAVE保证短 trace 而非无 tracerecord_steps False关闭了ProfilerStep#n行的生成见 torch_profile.py。如果某个 step 的 trace 过大无法处理可用discrete: True收窄为每 stage 一个文件并用schedule对其更新循环降采样或通过ranks/all_ranks剖析更少的 rank。四、输出文件命名与磁盘布局4.1 命名规则由于 profiling 在每个训练进程中运行每个 trace 文件按如下 stem 命名以便不打开文件就能归属到具体进程生成逻辑见 torch_profile.py 的build_trace_basename[role_][scope_][stepS_]rankr[-of-world][_tp..-pp..-dp..-cp..]_pidpid_timestamp.json.gzroleworker 角色如actor、ref、critic 的value-model使相同 rank 下不同角色的结果可区分。共置colocated混合 worker 报告其合并角色actor-rollout-ref标签中的下划线变为连字符因为下划线是字段分隔符。scope传给start_profile/annotate的被剖析区域——训练 worker 整步窗口为train离散模式下为 stage 名如actor-update。stepS被剖析的 RL stepglobal_steps即global_profiler.steps之一启用profile_continuous_steps时它是该文件所含 step 段的第一个 step。rank/world全局torch.distributedrank 与 world size。tp/pp/dp/cp张量/流水线/数据/上下文并行 rank仅在 Megatron 并行状态初始化后包含纯 FSDP 数据并行只报告rank。该拓扑信息由get_dist_topology()尽力采集见 torch_profile.py。4.2 磁盘上的一次 RL step 长什么样没有任何单份 trace 文件能端到端覆盖整个 RL step因为 step 不在单一进程中运行。一个被剖析的 step 会留下训练侧 tracescope train由 actor/ref/critic worker 写入包含这些 worker 实际运行的工作log-prob forward 与 actor 更新的 forward/backward/optimizer。这就是 scope 叫train而不是e2e的原因。Rollout trace由推理引擎自身写入save_path/agent_loop_rollout_replica_n/或启用relocate_results: True后写入save_path位于托管每个 replica 的节点上。生成过程从不出现在训练侧 trace 中使用 Agent Loop 时引擎运行在独立进程中在 V1 训练器中生成与 step 完全解耦训练器从回放缓冲区采样已生成数据因此 rollout 发生时 actor 进程只是空闲。要理解完整 step请结合训练器记录的阶段耗时gen、old_log_prob、ref、update_actor等与你要深挖部分的各进程 trace 一起分析。trace 时间戳是墙钟时间因此同一 step 的训练与 rollout trace 可以在 Perfetto 中并排对齐。4.3 区分 stage在训练侧 trace 内部discrete决定 stage 出现在文件名中还是 trace 内部discrete: True每 stage 一个文件stage 落在scope中actor-rollout-ref_actor-update_step2_rank0-of-8_pid123_ts.json.gz以及actor-compute-log-prob、ref-compute-log-prob、train-batch等兄弟文件。适合仅凭文件名就完成 stage 归因。discrete: False默认把 worker 的整个 step 收集到一份 trace因此scope是train无法只凭文件名命名单个 stage。stage 在 trace内部仍是分离的每个 stage 被包裹在携带其 stage 标签的torch.profiler.record_function中标签同时命名角色与函数——actor_compute_log_prob、ref_compute_log_prob、actor_update——在 Perfetto/Chrome tracing 中搜索该标签即可得到该 stage 的时间窗口。未声明角色的 stage如内部引擎的train_batch以方法名出现更新循环的每次迭代增加一个mini_batchi行。注意 verl 要求 profiler 精确写出stem.json.gz。如果你的文件带额外段如stem.json.1785391501.gz那是finish_hook_cmd之类的后处理/上传流程在事后追加的。4.4 缺失角色或 stage 的排查如果每个 rank 只看到一个actor...文件、没有单独的 reference/critic 文件、任何地方都找不到compute_log_prob通常是下面某一种情况而不是 trace 丢失每进程一个文件而非每角色一个文件。PyTorch Profiler 是进程全局的共置混合 worker 会把 actor 和 reference 的工作记录到同一份以合并角色命名的 traceactor-rollout-ref中。只有独立进程运行的角色如未共置的 criticvalue-model或 reference 模型才会出现单独文件。混合 worker 跟随actor.profiler。它从actor_rollout_ref.actor.profiler构建自己的 profiler因此单独设置ref.profiler.enable: True不会剖析任何内容关掉 actor 的 profiler 也会丢掉共享进程的 reference 阶段。该角色可能不存在。不使用 value model 的算法GRPO 及其同类没有 critic不需要 KL 项时没有 reference 模型。schedule 只能对更新循环降采样永远不能降采样 log-prob forward。tool_config.torch.schedule只收窄更新阶段的 mini-batchstep()只在那里推进。discrete: False下它选择保留哪些更新 mini-batchskip_first/wait/warmup为 0 时从头记录完整保留所有更早 stagerollout、log-prob但向前跳到更晚的 mini-batch 会丢掉这些更早的 stagetorch 只持久化以RECORD_AND_SAVE结尾的窗口。discrete: True下 schedule 只作用于被隔离的更新阶段log-prob/rollout 阶段保持各自完整 trace。因此如果一份连续 trace 只显示更新 forward/backward 而没有 log-prob forward先检查 schedule 是否向前跳了否则确认 log-prob 阶段确实运行过例如 reference 模型是否存在以及 CPU 活动是否被采集见下一条。CPU 活动变为无条件采集之前的旧 trace。纯设备运行旧版 verl 的contents: [cuda]没有record_function区间也没有算子名因此即使每个 stage 的 kernel 都在也无法在其中定位任何 stagelog-prob forward 看起来只是更新的前向半段。compute_log_prob可以被合法跳过。设置algorithm.rollout_correction.bypass_modeTrue时训练器复用 rollout 的 log probs 而不重新计算actor forward 从不运行使用 LoRAref_in_actor时 reference forward 由 actor worker 上的compute_log_prob承担因此它出现在该名称下而非compute_ref_log_prob。五、trace 中没有 GPU kernel 的排查如果 trace 只包含 CPU 算子而没有 CUDA kernel很可能是 profiler 的 CUPTI 订阅输掉了竞争。CUPTI 每个进程只接受一个订阅者而某些 CUDA 镜像安装了启动钩子把NVTX_INJECTION64_PATH指向libcupti.so。进程内第一个 NVTX 区间于是把 libcupti 作为 NVTX handler 加载并占用了该名额此后 Kineto 以CUPTI_ERROR_MULTIPLE_SUBSCRIBERS_NOT_SUPPORTED失败并丢弃所有 CUDA 活动。verl 自身会发出 NVTX 区间因此NCCL_NVTX_DISABLE1无法规避。因此当global_profiler.tooltorch时verl 会把所有 worker 的NVTX_INJECTION64_PATH指向一个不可加载的路径并在这样做时打印警告实现见 constants_ppo.py 中的NVTX_INJECTION_ENV处理。设置VERL_KEEP_NVTX_INJECTION1可保留继承的值——例如当你依赖该注入服务其他工具、并接受没有 CUDA 活动的 trace 时。六、可视化与结果上传6.1 trace 的存放采集到的 trace 文件通常为.json或.json.gz平铺存放在配置的save_path中每个角色、rank 和 scope 都直接写入该目录因为上述命名规则已保证文件唯一且自描述。Rollout 引擎 trace 是唯一例外——引擎拿到的是目录relocate_results: True会把它们也拉入save_path。6.2 用 finish_hook_cmd 一次性送走结果要跨节点搬走 trace在global_profiler上设置一次钩子每个角色都会继承。它只在最后一个被剖析的 step 之后、在每个被选中的 rank 上运行一次——不是每 step 一次。对应实现见 profile.py搬迁relocate_results每步都执行用户的命令只在最后一次stop(run_commandTrue)时执行。save_path是一个不断累积每个被剖析 step 的 trace 的扁平目录后端stop()和relocate_results每步仍会执行因此到最后一步时一切都在。因为命令只运行一次而非每步一次上传整个目录的命令会把每份 trace 恰好发送一次global_profiler.save_path$PROFILE_SAVE_PATH \ global_profiler.relocate_resultsTrue \ global_profiler.finish_hook_cmdmy-upload-tool $VERL_PROFILE_SAVE_PATH只运行一次也正是避免N 份相同 trace 副本问题的关键如果命令每步都跑目录上传会在 step 2 重新发送 step 1 的文件、step 3 再发一次……verl 每份 trace 只写一次但上传会重复发送旧文件按上传时间做版本管理的上传器于是把同一份 trace 存成仅尾部时间戳不同的多个*.gz。最后一次性上传则每份 trace 只发一次不会产生重复版本。save_path通常是节点本地的因此命令会在每个被选中的 rank/节点上运行。选择 finish-hook rank 时应让每个节点恰好一个 rank上传该节点的目录否则共享同一节点目录的多个 rank 会各自上传一次。未设置时finish-hook rank 默认等于被剖析的 rank可用finish_hook_ranks[...]收窄如何选择 rank 参见 Nsight Systems profiling。命令通过 shell 执行因此上下文变量VERL_PROFILE_SAVE_PATH、VERL_PROFILE_TOOL、VERL_PROFILE_RANK、VERL_PROFILE_PID和VERL_PROFILE_ROLE全部可用用单引号包裹它们避免你的 shell 提前展开。Hydra 的 override 解析器会拒绝包含自身引号的值因此需要引号的命令应放进一个小脚本由钩子调用。钩子会把命令、其输出与退出码打印到 worker 日志中。Rollout replica 不自己执行命令它们通过relocate_results把 trace 搬进save_path由共存训练 worker 在运行结束时的一次性上传一并覆盖。钩子的完整描述含如何选择执行 rank参见 Nsight Systems profiling。6.3 可视化工具Chrome Tracing在 Chrome 浏览器打开chrome://tracing并加载 JSON 文件Perfetto打开 ui.perfetto.dev 并加载文件推荐用于大 traceTensorBoard使用 PyTorch Profiler 的 TensorBoard 插件。七、与源码的对应关系速查关注点相关文件Torch Profiler 封装与文件命名verl/utils/profiler/torch_profile.py各类工具/调度配置 dataclass 与校验verl/utils/profiler/config.pyDistProfiler 分发、rank 选择、finish 钩子verl/utils/profiler/profile.py角色级默认配置enable/ranks/tool_configverl/trainer/config/profiler/profiler.yaml全局默认配置steps/save_path/finish_hookverl/trainer/config/ppo_trainer.yamlNVTX 注入冲突处理verl/trainer/constants_ppo.py训练器对 profile steps 的开关逻辑verl/trainer/ppo/ray_trainer.py、verl/trainer/ppo/v1/trainer_base.py单元测试tests/utils/test_torch_profile.py上手建议先以global_profiler.steps: [1]、单 rankranks: [0]、discrete: False跑通最小配置确认能在outputs/profile下看到命名完整的.json.gz文件再逐步启用discrete: True、schedule与profile_token_start/end精确裁剪采集窗口最后配置relocate_results与finish_hook_cmd打通结果收集链路。【免费下载链接】verlverl/HybridFlow: A Flexible and Efficient RL Post-Training Framework项目地址: https://gitcode.com/GitHub_Trending/ve/verl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考