尧图网页设计 
slime 训练可观测性实践WB/TensorBoard 指标、SGLang Prometheus 抓取与 Trace 时间线回放【免费下载链接】slimeslime is an LLM post-training framework for RL Scaling.项目地址: https://gitcode.com/GitHub_Trending/slime12/slimeslime 是一个面向 RL Scaling 的 LLM 后训练框架其默认可观测性路径刻意保持精简训练指标继续上报 WB / TensorBoardSGLang 的高频 serving 指标不再上云而是通过 Prometheus 就近抓取每个请求的耗时明细则从 SGLang responsemeta_info写入 sample trace按 rollout step 聚合成紧凑的perf/...指标并可由 trace viewer 做逐请求的时间线回放。读完本文你将掌握 slime 中训练指标与 serving 指标的分工边界、perf/...指标的来源与含义、Prometheus 的正确启动与数据持久化方式以及如何用 debug rollout dump 还原单条请求的 Prefill/Decode 分段时间线。一、slime 可观测性的整体设计slime 的可观测性遵循分层采集、就近存储、按需回放的原则整体分为三条互补路径训练指标路径reward、loss、KL、entropy、eval 等训练过程指标继续进入 WB 与 TensorBoardServing 指标路径SGLang / router 暴露/metrics与/engine_metrics两个 Prometheus HTTP endpoint由 Prometheus 周期性 scrape 并写入自己的 TSDBslime 本身不保存这些每秒级高频指标也不会把它们上传到 WB请求级时序路径SGLang response 中的meta_info携带每个请求的排队、prefill、decode 等耗时字段slime 将其写入 sample trace并在每个 rollout step 结束时聚合成少量perf/...指标debug rollout dump 保存的 sample trace 则可以通过 trace viewer 逐请求回放。这样的设计保证了高频 serving 数据不会拖垮 WB需要深入排查单请求耗时时有 trace 级数据兜底需要观察 serving 实时状态时有 Prometheus/Grafana 支撑。二、WB / TensorBoard 中会看到什么perf/...指标详解WB 与 TensorBoard 仍然接收 reward、loss、KL、entropy、eval 等全部训练指标。除此之外SGLang 的 request timing 会被聚合到perf/前缀下例如perf/request/e2e_latency/mean perf/request/queue_time/median perf/request/count perf/request/profiled_count perf/decode/throughput/mean perf/prefill/bootstrap_queue_duration/mean perf/prefill/bootstrap_duration/mean perf/prefill/alloc_wait_duration/mean perf/prefill/forward_duration/max perf/prefill/transfer_speed_gb_s/mean perf/decode/prealloc_duration/mean perf/decode/bootstrap_duration/mean perf/decode/alloc_wait_duration/mean perf/decode/transfer_duration/max perf/decode/forward_duration/mean2.1 聚合方式与上报时机这些指标每个 rollout step 聚合一次而不是每个 request 上报一次因此不会像直接上传完整 Prometheus 原始指标那样显著拖慢 WB。其实现位于 slime/observability/rollout_metrics.pycompute_perf_metrics_from_samples(args, samples, rollout_time)计算 rollout 整体吞吐tokens_per_gpu_per_sec、longest_sample_tokens_per_sec等并调用_compute_sglang_request_perf_metrics(samples)_compute_sglang_request_perf_metrics遍历每个 sample trace 中的sglang_generatespan 的attrs从 SGLang 返回的字段中取值并调用compute_statistics(values)见 slime/observability/metric_utils.py对每个指标计算mean / median / max / min四类统计量统计后的字典在log_rollout_data中被统一加上perf/前缀后经 slime/observability/logging_utils.py 的log()分发到 WBargs.use_wandb与 TensorBoardargs.use_tensorboard。2.2 字段映射meta_info→perf/指标指标与 SGLang 返回字段的映射关系定义在_SGLANG_REQUEST_PERF_FIELDS、_SGLANG_PREFILL_PERF_FIELDS、_SGLANG_DECODE_PERF_FIELDS三组元组中slime/observability/rollout_metrics.pyperf/指标键来源字段SGLangmeta_info说明request/e2e_latencye2e_latency请求端到端耗时request/queue_timequeue_time排队等待时长decode/throughputdecode_throughputDecode 阶段吞吐prefill/bootstrap_queue_durationpd_prefill_bootstrap_queue_durationPrefill 启动队列时长PD 场景prefill/bootstrap_durationpd_prefill_bootstrap_durationPrefill bootstrap 时长prefill/alloc_wait_durationpd_prefill_alloc_wait_durationPrefill 分配等待时长prefill/forward_durationpd_prefill_forward_durationPrefill 前向时长prefill/transfer_queue_durationpd_prefill_transfer_queue_durationPrefill 传输队列时长prefill/transfer_speed_gb_spd_transfer_speed_gb_sKV 传输速度GB/sprefill/transfer_total_mbpd_transfer_total_mbKV 传输总量MBprefill/retry_countpd_prefill_retry_countPrefill 重试次数decode/prealloc_durationpd_decode_prealloc_durationDecode 预分配时长decode/bootstrap_durationpd_decode_bootstrap_durationDecode bootstrap 时长decode/alloc_wait_durationpd_decode_alloc_wait_durationDecode 分配等待时长decode/transfer_durationpd_decode_transfer_durationDecode 传输时长decode/forward_durationpd_decode_forward_durationDecode 前向时长2.3 是否出现取决于 PD 配置不开 PDPrefill/Decode 分离时通用的perf/request/...指标与可用的perf/decode/throughput/...依然存在而perf/prefill/...与更细粒度的perf/decode/...duration只有在 SGLang 返回对应pd_*timing 字段时才会出现。此外代码中对取值做了严格校验只有int/float且非布尔、数值有限的字段才会进入统计not isinstance(value, (int, float)) or isinstance(value, bool) or not np.isfinite(value)会被跳过只有至少携带一个有效 perf 字段的请求才会计入profiled_request_count因此perf/request/count与perf/request/profiled_count的差异可以反映能被剖析的请求比例。2.4meta_info是如何进入 trace 的在 rollout 端非流式路径 slime/rollout/sglang_rollout.py 在拿到output[meta_info]后调用build_sglang_meta_trace_attrs(...)将 timing 写入 span attrs流式路径 slime/rollout/sglang_streaming_rollout.py 则在最后一个 chunk 携带finish_reason时同样调用该函数。这正是request timing 从meta_info写进 sample trace的代码级落点。三、Prometheus 数据存在哪里slime 与 Prometheus 的职责边界slime不存储按秒采样的 Prometheus 数据。SGLang / router 只暴露两个 HTTP endpoint/metrics/engine_metricsPrometheus 周期性 scrape 这些 endpoint并把时间序列写入Prometheus 自己的 TSDB。slime 在启动 SGLang 服务时总是显式开启enable_metrics: True见 slime/backends/sglang_utils/sglang_engine.py确保 router 的/engine_metrics随时可被外部抓取。由此可以明确三条结论没有启动 Prometheus 时serving 指标只存在于当前 SGLang 进程内存与 endpoint 的即时输出中不会形成历史记录训练结束后也无法补回启动 Prometheus 后历史数据存放在--storage.tsdb.path指定的目录slime 不把这些高频指标上传到 WB避免拖慢训练实验管理平台。3.1 值得关注的 SGLang serving 指标在 Prometheus / Grafana 中下面这些指标对观察 serving 侧状态最有价值sglang:num_queue_reqs sglang:num_running_reqs sglang:num_prefill_bootstrap_queue_reqs sglang:num_prefill_inflight_queue_reqs sglang:num_decode_prealloc_queue_reqs sglang:num_decode_transfer_queue_reqs sglang:kv_transfer_speed_gb_s_bucket sglang:kv_transfer_latency_ms_bucket sglang:kv_transfer_total_mb_bucket它们适合在 Prometheus / Grafana 面板中观察实时的 queue buildup队列堆积、transfer speed传输速度、latency histogram延迟直方图、失败计数等 serving 侧症状是训练指标之外诊断 serving 瓶颈的第一手数据。四、如何启动 Prometheus配置、命令与数据持久化Prometheus必须在训练运行时保持运行——它只能 scrape 当前正在暴露的 endpoint训练结束后无法从 SGLang endpoint 补回过去的数据。它不需要放进训练 Python 进程推荐作为同一台机器或同一个作业里的旁路进程运行。4.1 最小抓取配置global: scrape_interval: 10s scrape_configs: - job_name: slime-sglang metrics_path: /engine_metrics static_configs: - targets: - ROUTER_IP:ROUTER_PORT把ROUTER_IP:ROUTER_PORT替换为 slime 日志打印的 router 地址或者用户通过--sglang-router-ip/--sglang-router-port显式指定的地址。这两个参数由 slime/backends/sglang_utils/arguments.py 注册分别用于指定 SGLang router 的 IP 与端口。4.2 启动命令与持久化prometheus \ --config.file/path/to/prometheus.yml \ --storage.tsdb.path/path/to/prometheus-data \ --storage.tsdb.retention.time7d \ --web.listen-address0.0.0.0:9090slime 镜像内已内置prometheus二进制因此可以直接在容器里运行上述命令也可以从同一镜像再起一个旁路容器只要它能访问 router 地址并把/path/to/prometheus-data挂载到持久化目录即可--storage.tsdb.retention.time7d设置 7 天保留期可按需调整。持久化的关键如果--storage.tsdb.path指向容器本地盘容器被回收后数据也会丢失如果指向 NFS、持久化卷或作业输出目录训练结束后可以重新启动 Prometheus 指向同一个 TSDB 目录再用 Prometheus UI 或 Grafana 查询历史时间段。需要强调这里的回放是时间序列回放与图表分析不是 per-request trace 的完整重放。逐 sample 的 request timing 仍然来自 sample trace / debug rollout 数据这正是下一节 trace viewer 的用武之地。五、Trace viewer从 debug rollout dump 回放单请求时间线5.1 生成 debug rollout dump在训练命令中传入--save-debug-rollout-data即可保存 debug rollout 数据参数定义见 slime/utils/arguments.py--save-debug-rollout-data /path/to/debug/rollout_{rollout_id}.pt该参数支持{rollout_id}占位符文件会保存到按 rollout_id 展开的路径保存的 sample trace 中包含 SGLangmeta_info里的全部 timing 字段。5.2 启动 trace viewerpython tools/trace_timeline_viewer.py /path/to/debug/rollout_0.ptviewer 脚本位于 tools/trace_timeline_viewer.py它直接读取 debug dump 中的 sample trace 事件重建 span 与点事件并在源文件旁边生成一个轻量 JSON cache*.trace_timeline_cache.json与自包含的 HTML viewer*.trace_timeline_viewer.html随后本地起 HTTP 服务供浏览器交互查看。该默认路径不需要单独保存ReqTimeStats(...)日志也不需要Loki 或 compact 工具——数据全部来自 sample trace 自身。5.3[P]/[D]虚拟 lane 的渲染原理viewer 之所以能渲染出 Prefill / Decode 虚拟 lane依赖的是 trace 中写入的pd_*字段。在 rollout 端slime/observability/trace_utils.py 的build_sglang_meta_trace_attrs负责从meta_info抽取通用字段prompt_tokens、completion_tokens、cached_tokens、queue_time、e2e_latency、decode_throughput、finish_reason、sglang_request_id对应常量SGLANG_TRACE_META_KEYS依据SGLANG_PD_PREFILL_SEGMENTSpd_prefill_bootstrap_queue_duration→sglang_pd_prefill_bootstrap_queue等 5 段与SGLANG_PD_DECODE_SEGMENTSpd_decode_prealloc_duration→sglang_pd_decode_prealloc等 5 段构建父子 span 结构的 trace children将pd_transfer_speed_gb_s、pd_transfer_total_mb、pd_prefill_retry_count汇总为sglang_pd_summary事件。在 viewer 端_build_items_from_trace中的pd_lane_specstools/trace_timeline_viewer.py把包含pd_prefill_*/pd_decode_*attrs 的 span 追加为名为{span_name} [P]/{span_name} [D]的虚拟 lane span从而在时间线上并排展示同一条请求在 Prefill 与 Decode 两个阶段的耗时切片。配合 viewer 提供的过滤、按 attempt 查看、排序、缩放与 tooltip 等交互能力可以非常直观地定位单个样本的排队、bootstrap、alloc_wait、transfer、forward 各环节瓶颈。六、三条路径的选择建议场景推荐路径数据来源观察训练收敛与整体吞吐趋势WB / TensorBoard 的perf/...、rollout/...指标slime/observability/rollout_metrics.py 聚合观察 serving 侧实时队列、传输与失败计数Prometheus Grafana抓取/engine_metricsSGLang router endpoint训练结束后回放单请求 Prefill/Decode 分段时间线tools/trace_timeline_viewer.py debug rollout dumpsample trace 中的meta_infotiming 字段实际使用中建议在训练开始前就同时规划好 Prometheus 的持久化挂载NFS / 持久化卷与--save-debug-rollout-data的输出目录训练结束后用同一 TSDB 目录重启 Prometheus 做历史查询再用 trace viewer 对可疑样本做逐请求定位即可形成宏观趋势 → 实时 serving 状态 → 单请求耗时的完整排查闭环。【免费下载链接】slimeslime is an LLM post-training framework for RL Scaling.项目地址: https://gitcode.com/GitHub_Trending/slime12/slime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 slime 训练可观测性实践：WB/TensorBoard 指标、SGLang Prometheus 抓取与 Trace 时间线回放
slime 训练可观测性实践WB/TensorBoard 指标、SGLang Prometheus 抓取与 Trace 时间线回放【免费下载链接】slimeslime is an LLM post-training framework for RL Scaling.项目地址: https://gitcode.com/GitHub_Trending/slime12/slimeslime 是一个面向 RL Scaling 的 LLM 后训练框架其默认可观测性路径刻意保持精简训练指标继续上报 WB / TensorBoardSGLang 的高频 serving 指标不再上云而是通过 Prometheus 就近抓取每个请求的耗时明细则从 SGLang responsemeta_info写入 sample trace按 rollout step 聚合成紧凑的perf/...指标并可由 trace viewer 做逐请求的时间线回放。读完本文你将掌握 slime 中训练指标与 serving 指标的分工边界、perf/...指标的来源与含义、Prometheus 的正确启动与数据持久化方式以及如何用 debug rollout dump 还原单条请求的 Prefill/Decode 分段时间线。一、slime 可观测性的整体设计slime 的可观测性遵循分层采集、就近存储、按需回放的原则整体分为三条互补路径训练指标路径reward、loss、KL、entropy、eval 等训练过程指标继续进入 WB 与 TensorBoardServing 指标路径SGLang / router 暴露/metrics与/engine_metrics两个 Prometheus HTTP endpoint由 Prometheus 周期性 scrape 并写入自己的 TSDBslime 本身不保存这些每秒级高频指标也不会把它们上传到 WB请求级时序路径SGLang response 中的meta_info携带每个请求的排队、prefill、decode 等耗时字段slime 将其写入 sample trace并在每个 rollout step 结束时聚合成少量perf/...指标debug rollout dump 保存的 sample trace 则可以通过 trace viewer 逐请求回放。这样的设计保证了高频 serving 数据不会拖垮 WB需要深入排查单请求耗时时有 trace 级数据兜底需要观察 serving 实时状态时有 Prometheus/Grafana 支撑。二、WB / TensorBoard 中会看到什么perf/...指标详解WB 与 TensorBoard 仍然接收 reward、loss、KL、entropy、eval 等全部训练指标。除此之外SGLang 的 request timing 会被聚合到perf/前缀下例如perf/request/e2e_latency/mean perf/request/queue_time/median perf/request/count perf/request/profiled_count perf/decode/throughput/mean perf/prefill/bootstrap_queue_duration/mean perf/prefill/bootstrap_duration/mean perf/prefill/alloc_wait_duration/mean perf/prefill/forward_duration/max perf/prefill/transfer_speed_gb_s/mean perf/decode/prealloc_duration/mean perf/decode/bootstrap_duration/mean perf/decode/alloc_wait_duration/mean perf/decode/transfer_duration/max perf/decode/forward_duration/mean2.1 聚合方式与上报时机这些指标每个 rollout step 聚合一次而不是每个 request 上报一次因此不会像直接上传完整 Prometheus 原始指标那样显著拖慢 WB。其实现位于 slime/observability/rollout_metrics.pycompute_perf_metrics_from_samples(args, samples, rollout_time)计算 rollout 整体吞吐tokens_per_gpu_per_sec、longest_sample_tokens_per_sec等并调用_compute_sglang_request_perf_metrics(samples)_compute_sglang_request_perf_metrics遍历每个 sample trace 中的sglang_generatespan 的attrs从 SGLang 返回的字段中取值并调用compute_statistics(values)见 slime/observability/metric_utils.py对每个指标计算mean / median / max / min四类统计量统计后的字典在log_rollout_data中被统一加上perf/前缀后经 slime/observability/logging_utils.py 的log()分发到 WBargs.use_wandb与 TensorBoardargs.use_tensorboard。2.2 字段映射meta_info→perf/指标指标与 SGLang 返回字段的映射关系定义在_SGLANG_REQUEST_PERF_FIELDS、_SGLANG_PREFILL_PERF_FIELDS、_SGLANG_DECODE_PERF_FIELDS三组元组中slime/observability/rollout_metrics.pyperf/指标键来源字段SGLangmeta_info说明request/e2e_latencye2e_latency请求端到端耗时request/queue_timequeue_time排队等待时长decode/throughputdecode_throughputDecode 阶段吞吐prefill/bootstrap_queue_durationpd_prefill_bootstrap_queue_durationPrefill 启动队列时长PD 场景prefill/bootstrap_durationpd_prefill_bootstrap_durationPrefill bootstrap 时长prefill/alloc_wait_durationpd_prefill_alloc_wait_durationPrefill 分配等待时长prefill/forward_durationpd_prefill_forward_durationPrefill 前向时长prefill/transfer_queue_durationpd_prefill_transfer_queue_durationPrefill 传输队列时长prefill/transfer_speed_gb_spd_transfer_speed_gb_sKV 传输速度GB/sprefill/transfer_total_mbpd_transfer_total_mbKV 传输总量MBprefill/retry_countpd_prefill_retry_countPrefill 重试次数decode/prealloc_durationpd_decode_prealloc_durationDecode 预分配时长decode/bootstrap_durationpd_decode_bootstrap_durationDecode bootstrap 时长decode/alloc_wait_durationpd_decode_alloc_wait_durationDecode 分配等待时长decode/transfer_durationpd_decode_transfer_durationDecode 传输时长decode/forward_durationpd_decode_forward_durationDecode 前向时长2.3 是否出现取决于 PD 配置不开 PDPrefill/Decode 分离时通用的perf/request/...指标与可用的perf/decode/throughput/...依然存在而perf/prefill/...与更细粒度的perf/decode/...duration只有在 SGLang 返回对应pd_*timing 字段时才会出现。此外代码中对取值做了严格校验只有int/float且非布尔、数值有限的字段才会进入统计not isinstance(value, (int, float)) or isinstance(value, bool) or not np.isfinite(value)会被跳过只有至少携带一个有效 perf 字段的请求才会计入profiled_request_count因此perf/request/count与perf/request/profiled_count的差异可以反映能被剖析的请求比例。2.4meta_info是如何进入 trace 的在 rollout 端非流式路径 slime/rollout/sglang_rollout.py 在拿到output[meta_info]后调用build_sglang_meta_trace_attrs(...)将 timing 写入 span attrs流式路径 slime/rollout/sglang_streaming_rollout.py 则在最后一个 chunk 携带finish_reason时同样调用该函数。这正是request timing 从meta_info写进 sample trace的代码级落点。三、Prometheus 数据存在哪里slime 与 Prometheus 的职责边界slime不存储按秒采样的 Prometheus 数据。SGLang / router 只暴露两个 HTTP endpoint/metrics/engine_metricsPrometheus 周期性 scrape 这些 endpoint并把时间序列写入Prometheus 自己的 TSDB。slime 在启动 SGLang 服务时总是显式开启enable_metrics: True见 slime/backends/sglang_utils/sglang_engine.py确保 router 的/engine_metrics随时可被外部抓取。由此可以明确三条结论没有启动 Prometheus 时serving 指标只存在于当前 SGLang 进程内存与 endpoint 的即时输出中不会形成历史记录训练结束后也无法补回启动 Prometheus 后历史数据存放在--storage.tsdb.path指定的目录slime 不把这些高频指标上传到 WB避免拖慢训练实验管理平台。3.1 值得关注的 SGLang serving 指标在 Prometheus / Grafana 中下面这些指标对观察 serving 侧状态最有价值sglang:num_queue_reqs sglang:num_running_reqs sglang:num_prefill_bootstrap_queue_reqs sglang:num_prefill_inflight_queue_reqs sglang:num_decode_prealloc_queue_reqs sglang:num_decode_transfer_queue_reqs sglang:kv_transfer_speed_gb_s_bucket sglang:kv_transfer_latency_ms_bucket sglang:kv_transfer_total_mb_bucket它们适合在 Prometheus / Grafana 面板中观察实时的 queue buildup队列堆积、transfer speed传输速度、latency histogram延迟直方图、失败计数等 serving 侧症状是训练指标之外诊断 serving 瓶颈的第一手数据。四、如何启动 Prometheus配置、命令与数据持久化Prometheus必须在训练运行时保持运行——它只能 scrape 当前正在暴露的 endpoint训练结束后无法从 SGLang endpoint 补回过去的数据。它不需要放进训练 Python 进程推荐作为同一台机器或同一个作业里的旁路进程运行。4.1 最小抓取配置global: scrape_interval: 10s scrape_configs: - job_name: slime-sglang metrics_path: /engine_metrics static_configs: - targets: - ROUTER_IP:ROUTER_PORT把ROUTER_IP:ROUTER_PORT替换为 slime 日志打印的 router 地址或者用户通过--sglang-router-ip/--sglang-router-port显式指定的地址。这两个参数由 slime/backends/sglang_utils/arguments.py 注册分别用于指定 SGLang router 的 IP 与端口。4.2 启动命令与持久化prometheus \ --config.file/path/to/prometheus.yml \ --storage.tsdb.path/path/to/prometheus-data \ --storage.tsdb.retention.time7d \ --web.listen-address0.0.0.0:9090slime 镜像内已内置prometheus二进制因此可以直接在容器里运行上述命令也可以从同一镜像再起一个旁路容器只要它能访问 router 地址并把/path/to/prometheus-data挂载到持久化目录即可--storage.tsdb.retention.time7d设置 7 天保留期可按需调整。持久化的关键如果--storage.tsdb.path指向容器本地盘容器被回收后数据也会丢失如果指向 NFS、持久化卷或作业输出目录训练结束后可以重新启动 Prometheus 指向同一个 TSDB 目录再用 Prometheus UI 或 Grafana 查询历史时间段。需要强调这里的回放是时间序列回放与图表分析不是 per-request trace 的完整重放。逐 sample 的 request timing 仍然来自 sample trace / debug rollout 数据这正是下一节 trace viewer 的用武之地。五、Trace viewer从 debug rollout dump 回放单请求时间线5.1 生成 debug rollout dump在训练命令中传入--save-debug-rollout-data即可保存 debug rollout 数据参数定义见 slime/utils/arguments.py--save-debug-rollout-data /path/to/debug/rollout_{rollout_id}.pt该参数支持{rollout_id}占位符文件会保存到按 rollout_id 展开的路径保存的 sample trace 中包含 SGLangmeta_info里的全部 timing 字段。5.2 启动 trace viewerpython tools/trace_timeline_viewer.py /path/to/debug/rollout_0.ptviewer 脚本位于 tools/trace_timeline_viewer.py它直接读取 debug dump 中的 sample trace 事件重建 span 与点事件并在源文件旁边生成一个轻量 JSON cache*.trace_timeline_cache.json与自包含的 HTML viewer*.trace_timeline_viewer.html随后本地起 HTTP 服务供浏览器交互查看。该默认路径不需要单独保存ReqTimeStats(...)日志也不需要Loki 或 compact 工具——数据全部来自 sample trace 自身。5.3[P]/[D]虚拟 lane 的渲染原理viewer 之所以能渲染出 Prefill / Decode 虚拟 lane依赖的是 trace 中写入的pd_*字段。在 rollout 端slime/observability/trace_utils.py 的build_sglang_meta_trace_attrs负责从meta_info抽取通用字段prompt_tokens、completion_tokens、cached_tokens、queue_time、e2e_latency、decode_throughput、finish_reason、sglang_request_id对应常量SGLANG_TRACE_META_KEYS依据SGLANG_PD_PREFILL_SEGMENTSpd_prefill_bootstrap_queue_duration→sglang_pd_prefill_bootstrap_queue等 5 段与SGLANG_PD_DECODE_SEGMENTSpd_decode_prealloc_duration→sglang_pd_decode_prealloc等 5 段构建父子 span 结构的 trace children将pd_transfer_speed_gb_s、pd_transfer_total_mb、pd_prefill_retry_count汇总为sglang_pd_summary事件。在 viewer 端_build_items_from_trace中的pd_lane_specstools/trace_timeline_viewer.py把包含pd_prefill_*/pd_decode_*attrs 的 span 追加为名为{span_name} [P]/{span_name} [D]的虚拟 lane span从而在时间线上并排展示同一条请求在 Prefill 与 Decode 两个阶段的耗时切片。配合 viewer 提供的过滤、按 attempt 查看、排序、缩放与 tooltip 等交互能力可以非常直观地定位单个样本的排队、bootstrap、alloc_wait、transfer、forward 各环节瓶颈。六、三条路径的选择建议场景推荐路径数据来源观察训练收敛与整体吞吐趋势WB / TensorBoard 的perf/...、rollout/...指标slime/observability/rollout_metrics.py 聚合观察 serving 侧实时队列、传输与失败计数Prometheus Grafana抓取/engine_metricsSGLang router endpoint训练结束后回放单请求 Prefill/Decode 分段时间线tools/trace_timeline_viewer.py debug rollout dumpsample trace 中的meta_infotiming 字段实际使用中建议在训练开始前就同时规划好 Prometheus 的持久化挂载NFS / 持久化卷与--save-debug-rollout-data的输出目录训练结束后用同一 TSDB 目录重启 Prometheus 做历史查询再用 trace viewer 对可疑样本做逐请求定位即可形成宏观趋势 → 实时 serving 状态 → 单请求耗时的完整排查闭环。【免费下载链接】slimeslime is an LLM post-training framework for RL Scaling.项目地址: https://gitcode.com/GitHub_Trending/slime12/slime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考