llm-torch-profiler-analysis

统一 LLM Torch Profiler 分析

概述

使用此技能分析以下框架的 torch.profiler 数据：

• sglang，包括来自 SGLang Omni（sglang-omni）工作负载的现有跟踪
• vllm
• TensorRT-LLM
• TokenSpeed

SGLang Omni 并非独立框架，而是通过 SGLang 运行时提供服务，因此请使用 --framework sglang，并通过 --input 或 --mapping-input 和 --formal-input 分析其跟踪。针对 Omni 服务的 SGLang 实时采集路径尚未经过验证。

只有一个公开工作流：

• triage

首选的统一入口：

• scripts/analyze_llm_torch_profile.py

向后兼容垫片（保留此垫片，以便旧版 docker exec ... analyze_sglang_torch_profile.py ... 调用仍能正常工作；它只会转发到统一入口）：

• scripts/analyze_sglang_torch_profile.py

Markdown 打包辅助脚本：

• scripts/render_triage_markdown_bundle.py

triage 始终会输出同样的三张表：

• 内核表
• 重叠机会表
• 融合模式表

默认情况下，三张表都只显示 GPU 累计耗时占比达到或超过 1.0% 的行。默认隐藏低于该阈值的行，除非用户要求使用更低的阈值。

融合模式表必须以源代码为依据，并且结果具有确定性。不要将它变成模糊匹配器。

如果基于源代码的精确匹配效果较弱，但某个内核集群仍与已知模式接近，请在表格后添加一条简短说明，且只能使用以下其中一个词：

• high
• medium
• low

能力矩阵

能力	SGLang	vLLM	TensorRT-LLM	TokenSpeed
现有跟踪分析	是	是	是	是
单跟踪实时采集	是	是，前提是服务端启用了 torch profiler	需要 profiler 控制端点	是，前提是公开了 /start_profile 和 /stop_profile
双跟踪 mapping+formal 分析	是	是	是	是
按阶段分离的实时工作负载	是	是	是，需要可写的共享跟踪目录或按阶段运行器	是，通过按工作负载分离的 HTTP 采集
--profile-by-stage 采集	是	否	否	否
--profile-prefix 控制	是	通常在 HTTP profiler 路由上会被忽略	通常在 HTTP profiler 路由上会被忽略	是，会映射到 profile_id

对于 TensorRT-LLM，只有在服务端公开了 /start_profile 和 /stop_profile，且部署已提供共享跟踪路径及所需的环境变量时，实时采集才会生效。

对于 TokenSpeed，此技能支持现有跟踪分析，也支持对当前公开了 /start_profile 和 /stop_profile 的服务进行实时采集。实时辅助脚本会在启动载荷中发送 output_dir、activities、with_stack、record_shapes 和 profile_id。TokenSpeed 也有自己的 profile_by_stage 原生字段，可用于手动采集；不过，统一辅助脚本默认会使用按工作负载分隔的 prefill/ 和 decode/ 目录，以便不同框架的表格保持可比。

真实 B200 验证

当前 B200 冒烟测试运行于 2026-06-27 在 GPUC5A6 （cirrascale-gpuc5a6）上的容器 sglang_bbuf 中采集，位于：

• /data/bbuf/ai_infra_skills_pr72_20260627/profiler/qwen25_0_5b_live

已验证的实时性能分析：

模型	GPU	工作负载	结果
Qwen/Qwen2.5-0.5B-Instruct	1x B200	预填充 128->1，解码 32->8	生成了分开的 prefill/*.trace.json.gz 和 decode/*.trace.json.gz；内核、重叠和融合表均已渲染，并分别包含 extend/prefill 和 decode 部分

同一次运行通过一次小型 CUDA 矩阵乘法验证了 Nsight Compute 可用：

• /data/bbuf/ai_infra_skills_pr72_20260627/profiler/ncu_smoke_qwen_matmul.ncu-rep
• /data/bbuf/ai_infra_skills_pr72_20260627/profiler/ncu_smoke.log

清理服务端和 ncu 后，8 张 B200 GPU 的显存占用均为 0 MiB。

2026-08-23 的源代码刷新未重新采集实时预填充/解码跟踪数据，也未运行 ncu --set basic 冒烟测试：指定的 B200 主机关闭了 22 端口上的 SSH 连接。请将 2026-06-27 的产物保留为最近一次基于 GPU 的性能分析证据。

真实 H100 验证

当前参考运行是于 2026-04-23 在 h100_sglang 上采集的 4x H100 矩阵，位于：

• /data/bbuf/validate/unified_llm_profiler_skill/runs/20260423_h100_large_model_matrix_v3

已渲染的 Markdown 套件：

• /data/bbuf/validate/unified_llm_profiler_skill/runs/20260423_h100_large_model_matrix_v3/h100_large_model_matrix_v3_bundle.md

已验证的模型目录：

• mixtral_8x7b_instruct
• qwen2_5_32b_instruct
• qwen3_32b

每个模型目录均包含：

• analysis_sglang.txt
• analysis_vllm.txt
• analysis_trtllm.txt
• 特定框架的跟踪数据根目录和探测产物

已验证的矩阵：

模型	SGLang	vLLM	TensorRT-LLM	结果
mistralai/Mixtral-8x7B-Instruct-v0.1	4x H100	4x H100	4x H100	三个表格均在所有三个框架上正确渲染；基准测试探测直接返回了非空文本
Qwen/Qwen2.5-32B-Instruct	4x H100	4x H100	4x H100	三个表格均在所有三个框架上正确渲染；基准测试探测直接返回了非空文本
Qwen/Qwen3-32B	4x H100	4x H100	4x H100	三个表格均在所有三个框架上正确渲染；vLLM 和 TensorRT-LLM 聊天探测经常输出 <think> 前缀

请将此运行用作主要的 H100 参考。 较早的 2026-04-22 单卡 Qwen3 矩阵仍适用于初始设置，但不再是默认参考。 TokenSpeed 支持是在之后添加的，现有跟踪数据排查和 HTTP 性能分析控制功能涵盖了该支持，但目前尚未纳入这份较早的 H100 验证矩阵。

于 2026-05-01 在 h100_sglang 上采集的分阶段工作负载验证数据：

• /data/bbuf/validate/unified_llm_profiler_skill/runs/20260501_stage_split_validation
• /data/bbuf/validate/unified_llm_profiler_skill/runs/20260501_stage_split_validation_large

已验证的模型：

模型	GPU	工作负载	结果
Qwen/Qwen2.5-0.5B-Instruct	1x H100	预填充 4090->1，解码 1->2048	生成了独立的 prefill/*.trace.json.gz 和 decode/*.trace.json.gz；内核、重叠和融合表分别呈现 extend/prefill 和 decode 部分
Qwen/Qwen2.5-1.5B-Instruct	1x H100	预填充 4090->1，解码 1->2048	生成了独立的 prefill/*.trace.json.gz 和 decode/*.trace.json.gz；内核、重叠和融合表分别呈现 extend/prefill 和 decode 部分
Qwen/Qwen2.5-7B-Instruct	1x H100	预填充 4090->1，解码 1->2048	生成了独立的跟踪；预填充内核表记录了 28 层 GEMM/FA3/RMSNorm 工作，解码记录了 5 步图启动，融合行按阶段拆分
Qwen/Qwen2.5-14B-Instruct	1x H100	预填充 4090->1，解码 1->2048	生成了独立的跟踪；预填充内核表记录了 48 层 GEMM/FA3/RMSNorm 工作，解码记录了 5 步图启动，融合行按阶段拆分
Qwen/Qwen3-8B	2x H100，TP=2	预填充 4090->1，解码 1->2048，预热 10/捕获 5	生成了独立的预填充/解码跟踪和全部三张表；独特的探测提示词避免了前缀缓存污染预填充表
mistralai/Mistral-7B-Instruct-v0.3	2x H100，TP=2	预填充 4090->1，解码 1->2048，预热 10/捕获 5	生成了独立的预填充/解码跟踪和全部三张表；服务日志显示，在活跃的预填充时间段内，没有因重复提示词而触发前缀缓存捷径

此验证还涵盖了针对较旧 SGLang 分析器状态机的兼容性修复：按工作负载拆分的实时捕获会根据输出目录标记阶段，并避免在每个工作负载中嵌套 SGLang 内部的 profile_by_stage 状态机。由于 SGLang 会在检查分析器是否应停止之前递增 forward_ct，该辅助程序会添加一个内部调度器保护步骤；没有此保护时，num_steps=1 的预填充捕获可能会在实际的预填充前向计算之前停止。其他模型在 2026-05-01 进行双卡验证时生成的产物如下：

• /data/bbuf/validate/core_skill_validation_20260501/qwen3_8b/profiler
• /data/bbuf/validate/core_skill_validation_20260501/mistral_7b_instruct_v03/profiler

要将已验证的运行结果渲染为一份 markdown 文档：

python3 scripts/render_triage_markdown_bundle.py \
  --analysis-root /data/bbuf/validate/unified_llm_profiler_skill/runs/20260423_h100_large_model_matrix_v3 \
  --output /data/bbuf/validate/unified_llm_profiler_skill/runs/20260423_h100_large_model_matrix_v3/h100_large_model_matrix_v3_bundle.md

该套件按模型分组，并为每个框架保留三张表。

H100 说明：

• 现在，如果跟踪中包含清晰的阶段划分，三个框架都会将内核、重叠和融合表格分别按 extend/prefill 和 decode 两个部分呈现
• SGLang 实时采集已通过验证，现会直接调用服务器分析器 API，而不是通过 shell 调用 sglang.profiler
• SGLang 刷新跟踪可能会延迟远超几秒，因此运行器等待生成分析文件的时间比早期实现更长
• SGLang 内核位置重建在映射路径中会保持采样禁用，以免优化后的解析器影响 SGLang 表格输出；针对 Mixtral-8x7B-Instruct-v0.1、Qwen3-32B 和 nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-FP8 的相等性复查均匹配
• vLLM 实时采集要求 --output-dir 与服务器的 torch_profiler_dir 一致；经过验证的 H100 流程使用 --profiler-config {"profiler":"torch","torch_profiler_dir":"..."}，然后调用 /start_profile 和 /stop_profile
• TensorRT-LLM 验证仍使用 --backend pytorch；H100 流程通过 TLLM_TORCH_PROFILE_TRACE 写入跟踪，然后分析保存的跟踪
• TensorRT-LLM 当前主线于 2026-08-23 在 da38c1d2e0dffd073b7dfb6d69e15ee7b45d84a9 重新检查；PyTorch 分析仍使用 record_shapes=True 和 with_modules=True，但不使用 with_stack=True；除非目标镜像证明无需覆盖，否则保留用于提升表格中 Python 位置质量的覆盖路径
• SGLang v0.5.18 默认启用 DSV4 融合 MHC post+pre 路径，包括 SM12x。如果解码跟踪仍显示拆分的 MHC post 和 pre 内核，现在更可能是该路径被禁用或发生回归，而非新的融合方案
• TokenSpeed 实时采集仍采用 HTTP 分析器控制加现有跟踪排查；它不属于较早的 H100 验证矩阵
• 跟踪分析已为原生 TokenSpeed CuTe DSL MLA、MLA KV 打包 + FP8 量化、融合 top-k/top-p 采样、持久化 lm_head GEMM，以及 NVFP4 GEMM + SwiGLU + 量化提供一等注册表条目；在目标 TokenSpeed 镜像提供受支持的分析器 API 之前，实时采集仍需要现有的 torch-profiler 跟踪
• 在此主机上，所有跟踪根目录都应位于 /data/... 下，而非 /home/...

适用场景

• 检查来自 sglang、vllm、TensorRT-LLM 或 TokenSpeed 的 torch.profiler 跟踪或分析目录
• 分析现有 SGLang Omni 跟踪，并将 GPU 时间归因到 sglang_omni/ 或 sglang_omni_router/ Python 源码
• 分析实时服务端点并分析结果
• 总结哪些内核系列主导预填充或解码
• 将内核映射回 Python 代码路径
• 判断代码路径是否仍有重叠机会
• 检查已知的融合或重叠路径是否本应生效

扩散后端门控

对于扩散基准测试或分析工作，只分析由原生 SGLang 扩散后端生成的跟踪。

如果生成跟踪的运行日志中出现以下任一内容：

• Falling back to diffusers backend
• Using diffusers backend
• Loaded diffusers pipeline

请停止工作流，不要分析该跟踪。 应将其视为后端选择问题，而不是原生内核分析器的证据。

主要流程

按阶段拆分的实时采集约定

实时采集默认不得使用混合提示词。 默认情况下，analyze_llm_torch_profile.py --url ... 会采集两个带标签的工作负载， 随后按独立阶段区段呈现相同的三个表格：

• 预填充（prefill）：合成输入长度为 4090，输出长度为 1
• 解码（decode）：合成输入长度为 1，输出长度为 2048

每条实时性能分析路径都会先预热 10 步，再启动性能分析器；默认情况下， 随后采集 5 个活跃步骤。在比较内核表格之前，请确保 SGLang、vLLM 和 TensorRT-LLM 的预热与活跃步骤划分一致。

当基准测试工作负载已知时，可使用以下选项覆盖此约定：

--profile-workload both \
--warmup-steps 10 --num-steps 5 \
--prefill-input-len 4090 --prefill-output-len 1 \
--decode-input-len 1 --decode-output-len 2048

允许的 --profile-workload 值：

• both：默认值；分别采集预填充和解码
• prefill：仅采集长输入／单 token 工作负载
• decode：仅采集单输入／长输出工作负载
• legacy：保留旧版 --probe-prompt／--probe-max-new-tokens 行为

对于 sglang-sota-humanize-loop，如果已知 SGLang 慢速基准测试场景的输入／输出分布， 请勿使用默认值。 应根据该慢速场景设置性能分析器的长度：预填充使用慢速输入长度，输出设为 1； 解码使用输入长度 1，输出设为慢速输出长度。对于混合数据集，请分析最具代表性的 最慢分桶，例如基准测试报告中使用的 p50 或 p95 输入／输出组合，并在产物备注中 记录该分桶。

1. 使用现有性能分析目录或跟踪文件进行单跟踪排查

python3 scripts/analyze_llm_torch_profile.py \
  --input /path/to/profile_dir_or_trace.json.gz

当一个跟踪文件足以完成分析时使用此方式。 单跟踪模式下的重叠表会保持保守，并提示何时需要映射／正式配对。

2. 从 SGLang 实时采集单个跟踪文件

python3 scripts/analyze_llm_torch_profile.py \
  --framework sglang \
  --url http://127.0.0.1:30000 \
  --output-dir /data/bbuf/validate/unified_llm_profiler_skill/runs/example/sglang_profile_live \
  --num-steps 5 \
  --warmup-steps 10 \
  --profile-by-stage \
  --profile-workload both

该脚本会直接向 SGLang 服务发送 POST /start_profile。 请将 --output-dir 放在 /data/... 下，以便后续分析和文档能够查看跟踪文件。 该脚本会写入 server_args.json，按相同的工作负载形态进行预热， 在性能分析启动后发送活跃探测请求，默认分别采集 prefill/ 和 decode/ 性能分析根目录， 并等待比早期实现更长的时间，以便跟踪文件完成刷新。 对于默认的按工作负载拆分采集，目录名称会标明阶段；每个工作负载内部不会使用 SGLang 的 profile_by_stage 模式。这样可以避免将单 token 预填充探测与单独的解码性能 分析混在一起。该辅助程序仍会额外添加一个内部保护步骤，因为较旧的 SGLang 性能分析器 会在执行下一次前向传播之前检查目标计数器。

3. 从 vLLM 实时采集单个跟踪文件

启动启用了 torch profiler 的 vLLM，例如：

vllm serve meta-llama/Llama-3.1-8B-Instruct \
  --profiler-config '{"profiler":"torch","torch_profiler_dir":"/data/bbuf/validate/unified_llm_profiler_skill/runs/example/vllm_profile"}'

然后运行：

python3 scripts/analyze_llm_torch_profile.py \
  --framework vllm \
  --url http://127.0.0.1:8000 \
  --output-dir /data/bbuf/validate/unified_llm_profiler_skill/runs/example/vllm_profile \
  --num-steps 5 \
  --warmup-steps 10 \
  --no-profile-by-stage \
  --profile-workload both

对于 vLLM，--output-dir 必须指向服务使用的同一个 torch_profiler_dir。 当前的 vLLM 性能分析器配置已默认启用 torch_profiler_with_stack=true， 因此运行器只需设置 torch_profiler_dir。 在 h100_sglang 上，外部 vLLM 容器应挂载以下两个目录：

• /data/.cache/huggingface:/root/.cache/huggingface
• /data/bbuf/validate/unified_llm_profiler_skill:/data/bbuf/validate/unified_llm_profiler_skill

4. 从 TensorRT-LLM 单条跟踪记录实时采集

仅当服务提供 POST /start_profile 和 POST /stop_profile， 且跟踪文件路径与当前机器共享时，才使用此方法。

典型的环境变量预期如下：

• TLLM_PROFILE_START_STOP=<start>-<stop>，例如 10-20
• TLLM_TORCH_PROFILE_TRACE=/shared/path/trace.json 或 .json.gz

然后运行：

python3 scripts/analyze_llm_torch_profile.py \
  --framework trtllm \
  --url http://127.0.0.1:8000 \
  --output-dir /shared/path \
  --num-steps 5 \
  --no-profile-by-stage \
  --profile-workload both

如果部署未提供性能分析器控制端点，请改为分析现有跟踪记录， 而不要尝试实时采集。 如果 TensorRT-LLM 跟踪输出配置为固定文件路径，请使用 scripts/run_trtllm_pytorch_profile_host.sh --stage prefill 和 --stage decode， 而不是直接使用 --profile-workload both，这样每个阶段都会有独立的跟踪文件。

在当前 TensorRT-LLM 主线中，py_executor.py 创建的 torch 性能分析器 启用了 record_shapes=True 和 with_modules=True，但未启用 with_stack=True。 若要进行表格质量验证，请使用覆盖生成器：

python3 scripts/make_trtllm_py_executor_override.py \
  --source /path/to/original/py_executor.py \
  --output /data/bbuf/validate/unified_llm_profiler_skill/overrides/trtllm/py_executor_with_stack.py

矩阵运行器会在 H100 上自动执行此操作，并在开始 TensorRT-LLM 采集前完成。

以下是已在 h100_sglang 上验证的 TensorRT-LLM 流程：

1. 使用 TLLM_PROFILE_START_STOP=<start>-<stop> 和 TLLM_TORCH_PROFILE_TRACE=/data/.../trace.json 启动 trtllm-serve
2. 运行若干基准测试请求
3. 使用 --input /data/.../trace.json 分析生成的跟踪记录

5. 从 TokenSpeed 单条跟踪记录实时采集或进行问题初步排查

对于提供性能分析器路由的运行中 TokenSpeed 服务，统一辅助工具可以执行实时采集：

python3 scripts/analyze_llm_torch_profile.py \
  --framework tokenspeed \
  --url http://127.0.0.1:8000 \
  --output-dir /data/bbuf/validate/unified_llm_profiler_skill/runs/example/tokenspeed_profile \
  --num-steps 5 \
  --warmup-steps 10 \
  --no-profile-by-stage \
  --profile-workload both \
  --profile-prefix ts-triage

该辅助工具会发送 POST /start_profile，并传入：

• output_dir：--output-dir 路径
• activities：["CPU", "GPU"]
• with_stack：true
• record_shapes：false
• profile_id：--profile-prefix；按工作负载分开采集时，会追加 -prefill 或 -decode

随后，它会发送兼容 OpenAI 的探测请求，并调用 POST /stop_profile。 TokenSpeed 会在输出目录下写入诸如 ts-triage-prefill-TP-0.trace.json.gz 的文件。 如果服务以多个 TP rank 启动，则每个 rank 都会生成一条跟踪记录。

也可以直接分析现有的 TokenSpeed torch 性能分析器跟踪记录：

python3 scripts/analyze_llm_torch_profile.py \
  --framework tokenspeed \
  --input /path/to/tokenspeed_profile_dir_or_trace.json.gz

也可以使用 TokenSpeed 自带的手动性能分析器控制接口：

curl -X POST http://127.0.0.1:8000/start_profile \
  -H 'Content-Type: application/json' \
  -d '{"output_dir":"/data/bbuf/profiles/tokenspeed","activities":["CPU","GPU"],"with_stack":true,"record_shapes":false,"profile_id":"ts-manual"}'

# send representative workload here

curl -X POST http://127.0.0.1:8000/stop_profile

如需在服务端自动停止，请传入 num_steps。如需按 TokenSpeed 原生的 EXTEND/DECODE 阶段拆分，请传入 profile_by_stage: true；生成的文件会带有 -EXTEND 和 -DECODE 等阶段后缀。

TokenSpeed 的基准测试驱动程序也可以采集跟踪记录：

tokenspeed bench serve \
  --base-url http://127.0.0.1:8000 \
  --model <model> \
  --dataset-name random \
  --random-input-len 4090 \
  --random-output-len 1 \
  --num-prompts 64 \
  --profile \
  --profile-num-steps 5 \
  --extra-body '{"output_dir":"/data/bbuf/profiles/tokenspeed","activities":["CPU","GPU"],"with_stack":true,"profile_id":"ts-bench"}'

如果省略 output_dir，TokenSpeed 会依次回退到 TOKENSPEED_PROFILER_DIR 和 /tmp。

在采集跟踪记录之前或之后，可使用 scripts/probe_llm_server.py 并传入 --framework tokenspeed，对兼容 OpenAI 的端点进行简单探测：

python3 scripts/probe_llm_server.py \
  --framework tokenspeed \
  --url http://127.0.0.1:8000 \
  --requests 6 \
  --max-tokens 48

对于 sglang-sota-humanize-loop，TokenSpeed 性能分析器的证据应与基准测试结果中的同一慢速场景分桶对齐。尽可能优先使用按工作负载分开的统一实时采集；如果只有混合型 Agentic 跟踪记录，请在与 SGLang 的 prefill/decode 跟踪记录进行比较前，在 analysis/root-cause.md 中注明此限制。

6. 从现有性能分析目录或跟踪记录进行双跟踪问题初步排查

python3 scripts/analyze_llm_torch_profile.py \
  --mapping-input /path/to/graph_off_profile_dir \
  --formal-input /path/to/graph_on_profile_dir

当需要更有力地判断重叠情况并将内核映射到源代码时，请使用此方法。

7. 从运行中的服务进行双跟踪问题初步排查

python3 scripts/analyze_llm_torch_profile.py \
  --framework sglang \
  --mapping-url http://127.0.0.1:31025 \
  --formal-url http://127.0.0.1:31026 \
  --num-steps 5 \
  --profile-by-stage

对于 vllm 或 TensorRT-LLM，请使用相同的格式，但传入：

• --framework vllm 或 --framework trtllm
• --mapping-output-dir ...
• --formal-output-dir ...
• --no-profile-by-stage

对于 TokenSpeed，可对提供 /start_profile 和 /stop_profile 的服务使用 --mapping-url 和 --formal-url，也可传入两个现有的跟踪目录，并使用 --mapping-input 和 --formal-input。

--framework auto 会根据跟踪记录、路径、服务参数和端点签名进行判断。 如果没有明确结论，分析器会停止并要求明确指定 sglang、vllm、trtllm 或 tokenspeed；切勿默认将未知跟踪记录解释为 SGLang。

profile_by_stage

--profile-by-stage 只适用于 SGLang 实时采集路径。

• 使用 --profile-workload both / prefill / decode 时，工作负载目录就是阶段标签；实时采集辅助程序会针对每个工作负载禁用 SGLang 内部阶段分析器，先预热，再为选定的工作负载采集指定数量的活动步骤。
• 在旧版或手动采集的 SGLang 服务中，内部 profile_by_stage 仍然很有用，因为 prefill 和 decode 通常有截然不同的瓶颈。
• 在 SGLang 当前的 profile-v2 路径中，基于阶段的分析实际上就是常规路径。
• PD 解耦服务还有一条额外规则：必须分别对 prefill 工作进程和 decode 工作进程进行分析。这比普通的 profile_by_stage 更严格。
• 对于 vllm、TensorRT-LLM 和 TokenSpeed，请使用 --no-profile-by-stage 将其禁用。

如何选择诊断方式

单跟踪诊断

适用于希望以最低成本生成报告的情况：

• 已有一条跟踪记录
• 主要想了解内核占比和融合线索
• 想并排比较两次运行，因此对每条跟踪分别运行一次诊断

通常优先使用这种方式。

双跟踪诊断

适用于需要以下内容的情况：

• 更可靠的重叠分析
• 关闭图模式时的源码映射，以及开启图模式时的最终行为
• 中间表中更可信的重叠建议

1. 映射跟踪：关闭图模式，或使用融合程度较低、可读性更强的配置
2. 正式跟踪：启用实际服务优化

不要把映射阶段称为“快速分析”。 它的用途是还原 kernel -> cpu_op -> python scope。

工作流

单跟踪工作流

1. 如果用户只想要诊断，一条跟踪记录就足够了。
2. 只要分析器同时生成了单 rank 和合并跟踪，就优先使用单 rank 跟踪。
3. 对于实时服务，仅当满足框架特定的前置条件时，才让脚本驱动分析器。
4. 优先使用 --profile-workload both；只有在复现旧的跟踪契约时才使用 legacy。
5. 优先使用按工作负载分开采集的 SGLang 跟踪；对于 legacy 或手动采集的跟踪，才主要使用内部 --profile-by-stage。
6. 使用 h100_sglang 时，通过 docker exec sglang_bbuf ... 创建或清理目标跟踪目录，以确保该路径在 /data 下可写。

双跟踪工作流

1. 首先生成映射跟踪，关闭图模式或使用融合程度较低的配置。
2. 然后使用实际服务优化生成正式跟踪。
3. 运行 triage 生成三张表的报告。
4. 按以下顺序查看结果：
   • 内核表
   • 重叠机会表
   • 融合模式表
5. 在提出“新”优化想法之前，将顶部条目与 references/fuse-overlap-catalog.md 和 references/overlap-catalog.md 中的内容进行比较。先检查主线条目，再检查经状态审查的 PR 证据。优先报告：
   • 本应已适用于当前场景的现有融合或重叠路径
   • 在此跟踪中似乎被禁用、不受支持或出现回退的现有路径
   • 在其他地方已进入主线、但本地缺失或仍在上游等待处理的模式
   • 只有在没有任何目录条目匹配时，才报告真正的新机会
6. 如果没有完全匹配的具体模式，但跟踪仍接近某个已知类别，请在表格后添加一条简短的相似性说明。 仅使用 high、medium 或 low。 说明应基于完整的模式形态，而非单个内核名称。 优先依据语义线索，例如生产者—消费者链、源码位置、CPU op 名称、TP 上下文以及特定模型的结构。 不要改写脚本表格来加入这些启发式判断。

参考资料

仅在需要时加载：

• references/source-map.md
  • 上游 SGLang 分析器入口和追踪写入路径；对于后续查找 SGLang 特定源代码仍最有用
• references/heuristics.md
  • 重叠标签、依赖风险解读及其局限
• references/fuse-overlap-catalog.md
  • 现有融合与重叠模式的混合型、有来源依据的目录，包含主线条目以及明确标注的开放、已合并和已关闭但未合并的 PR 证据
• references/vllm-torch-compile-fusions.md
  • 当前 vLLM torch.compile 融合过程及其针对的源代码模式
• references/overlap-catalog.md
  • 涵盖 LLM、VLM、扩散、解耦、HiSparse 和推测式调度的仅限重叠查询表

输出约定

返回：

• 追踪路径或生成的分析文件路径
• 框架
• 可用时提供模型／服务端参数
• 内核表
• 重叠机会表
• 融合模式表
• 精确匹配无法确定时，可选附上相似度说明，标注 high / medium / low
• 简短总结运行中的主要开销
• 说明重叠分析来自单追踪初步排查，还是映射／正式的双追踪排查