Vendored from NVIDIA/TensorRT-LLM under Apache-2.0. Only the description was extended with inference-server triggers; the body is verbatim. NVIDIA's copyright + license header is preserved in this fork's LICENSE-Apache-2.0.txt.
In this fork "delegate to perf-profiling-specialist" means: delegate to perf-nsight-systems for nsys timeline work, perf-nsight-compute-analysis for ncu kernel analysis, or model-perf-binary-search for QPS-vs-SLO binary search.
Performance Analysis
Principles
- Delegate profiling, own analysis. You coordinate the analysis workflow
but do not run profiling tools directly. Delegate all profiling and
measurement tasks to perf-profiling-specialist or other domain specialists.
- Metrics from tools, never invented. All performance numbers must come
from profiling tool output. Never fabricate metrics.
- Classify before recommending. Identify the bottleneck type before
suggesting optimizations. The wrong classification leads to wasted effort.
- Structured reports. Every analysis produces a report with Summary,
Metrics, Findings, and Recommendations.
Key Performance Metrics
- Throughput: samples/sec, tokens/sec, iterations/sec
- Latency: end-to-end time, kernel time, communication time
- MFU (Model FLOPs Utilization): actual FLOPs / theoretical peak FLOPs
- % of SOL (Speed of Light): current perf / hardware peak perf
- GPU Utilization: SM occupancy, tensor core usage
- Memory Bandwidth: DRAM bandwidth utilization vs peak
Analysis Workflow
- Understand: Clarify what metrics the user needs (MFU, SOL, latency, etc.)
- Plan: Plan your profiling and analysis steps before starting
- Profile: Delegate to perf-profiling-specialist for actual measurements
- Measure: Extract requested metrics from profiling results
- Classify: If diagnosing issues, determine primary bottleneck type
- Report: Generate performance analysis report with findings
Bottleneck Classification
When diagnosing performance issues, classify the primary bottleneck:
| Type |
Indicator |
Description |
| Compute-bound |
High GPU utilization, low memory bandwidth usage |
Limited by compute capacity (FLOPs) |
| Memory-bound |
High memory bandwidth, low compute utilization |
Limited by DRAM throughput |
| Launch-overhead |
Many small kernels, high CPU time |
CPU becoming bottleneck from kernel launch overhead |
| Communication-bound |
Significant time in collective operations |
Limited by inter-GPU or inter-node communication |
| Sync-bound |
Excessive CPU-GPU synchronization points |
Stalls from unnecessary synchronization |
Delegation Guidelines
When delegating to specialists, describe the desired outcome -- not the
tool methodology.
DO include:
- The workload: file path, code snippet, or command to profile
- Problem context: dimensions, dtypes, FLOPs calculations, batch sizes
- Desired metrics: SOL%, MFU, throughput, occupancy, bottleneck classification
- Any constraints: specific kernel to target, profiling region markers
DO NOT include:
- Specific tool flags or command patterns (e.g.,
--set=full, --section SpeedOfLight)
- Step-by-step tool usage instructions
- Fallback strategies for tool failures
- Example commands
- Output file paths or artifact locations (specialists create their own workspace artifacts)
Specialists have their own skills that encode best practices for tool usage
and their own workspace artifacts for output. Prescribing commands in the
delegation overrides their skills and may lead to suboptimal profiling
strategies (e.g., collecting 8000+ metrics with --set=full when a targeted
section analysis would be faster and more surgical).
Good Example
Profile the batched GEMM kernel in bmm_workload.py with NCU.
The workload uses cudaProfilerStart/Stop markers to isolate the region of interest.
Collect kernel-level metrics: SOL%, compute/memory throughput, DRAM bandwidth,
tensor core utilization, occupancy, warp stall reasons, and roofline classification.
The batched GEMM performs 68.72 GFLOP per call (B=32, M=512, N=1024, K=2048, FP16).
Calculate MFU against the GPU's peak FP16 tensor core TFLOP/s.
Bad Example
Run NCU with --set=full --profile-from-start off --target-processes all.
If --set=full fails, try --set=detailed. Parse the CSV output for
sm__throughput.avg.pct_of_peak_sustained_elapsed.
Save raw NCU output to /workspace/.../ncu_output.txt.
Remote Profiling
When profiling on a remote SLURM cluster, include the
Remote Execution Context block in the delegation prompt with the SSH+srun
wrapper for the target cluster. The perf-profiling-specialist will prefix its
commands (nsys, ncu, nvidia-smi) with this wrapper.
The perf-profiling-specialist does not need the remote-slurm skill — the
context block provides everything it needs to execute remotely.
Available Specialists
Delegate profiling and domain-specific analysis to these specialists:
- perf-profiling-specialist: Runs nvidia-smi, nsys, ncu, torch.profiler. Use for ALL profiling tasks.
- perf-torch-cuda-graph-specialist: Analyzes CUDA Graph compatibility and applies capture workflows
Report Format
Structure every analysis report with these four sections:
- Summary: High-level performance status or bottleneck classification
- Metrics: Key performance numbers from profiling
- Findings: Detailed observations with evidence
- Recommendations: Prioritized list of optimizations (if applicable)
Example Report
## Summary
Training at 42% MFU, memory-bound due to large attention tensors.
## Metrics
- Throughput: 1,247 samples/sec
- MFU: 42% (vs 65% theoretical for this model)
- % of SOL: 58% (room for 1.7x improvement)
- GPU Utilization: 45%
- Memory Bandwidth: 850 GB/s (89% of peak)
- Kernel Count: 1,247 per iteration
## Findings
1. Self-attention consumes 60% of memory bandwidth
2. Optimizer step has 3 unnecessary synchronizations
3. Batch size could be increased by 2x
## Recommendations
1. Enable FlashAttention (expected: +15% MFU)
2. Remove synchronizations in optimizer (expected: +5% throughput)
3. Increase batch size to improve GPU utilization
1---2name: perf-analysis3description: Performance analysis coordination workflow. Guides profiling delegation, bottleneck classification (compute / memory / launch / communication / sync), and structured report generation. Use when the user asks to analyze performance, profile a workload, check MFU / SOL, diagnose bottlenecks, understand why a vLLM / SGLang / TRT-LLM serve / lmdeploy run is slower than expected, or interpret an existing .nsys-rep against an SLO. Triggers also include "分析性能瓶颈" / "MFU 多少" / "瓶颈是 compute 还是 memory" / "诊断推理慢"4license: Apache-2.05---67> **Vendored from [NVIDIA/TensorRT-LLM](https://github.com/NVIDIA/TensorRT-LLM/tree/main/.claude/skills/perf-analysis) under Apache-2.0.** Only the `description` was extended with inference-server triggers; the body is verbatim. NVIDIA's copyright + license header is preserved in this fork's `LICENSE-Apache-2.0.txt`.8>9> **In this fork "delegate to perf-profiling-specialist" means: delegate to `perf-nsight-systems` for nsys timeline work, `perf-nsight-compute-analysis` for ncu kernel analysis, or `model-perf-binary-search` for QPS-vs-SLO binary search.**1011# Performance Analysis1213## Principles14151. **Delegate profiling, own analysis.** You coordinate the analysis workflow16 but do not run profiling tools directly. Delegate all profiling and17 measurement tasks to **perf-profiling-specialist** or other domain specialists.182. **Metrics from tools, never invented.** All performance numbers must come19 from profiling tool output. Never fabricate metrics.203. **Classify before recommending.** Identify the bottleneck type before21 suggesting optimizations. The wrong classification leads to wasted effort.224. **Structured reports.** Every analysis produces a report with Summary,23 Metrics, Findings, and Recommendations.2425## Key Performance Metrics2627- **Throughput**: samples/sec, tokens/sec, iterations/sec28- **Latency**: end-to-end time, kernel time, communication time29- **MFU (Model FLOPs Utilization)**: actual FLOPs / theoretical peak FLOPs30- **% of SOL (Speed of Light)**: current perf / hardware peak perf31- **GPU Utilization**: SM occupancy, tensor core usage32- **Memory Bandwidth**: DRAM bandwidth utilization vs peak3334## Analysis Workflow35361. **Understand**: Clarify what metrics the user needs (MFU, SOL, latency, etc.)372. **Plan**: Plan your profiling and analysis steps before starting383. **Profile**: Delegate to **perf-profiling-specialist** for actual measurements394. **Measure**: Extract requested metrics from profiling results405. **Classify**: If diagnosing issues, determine primary bottleneck type416. **Report**: Generate performance analysis report with findings4243## Bottleneck Classification4445When diagnosing performance issues, classify the primary bottleneck:4647| Type | Indicator | Description |48|------|-----------|-------------|49| **Compute-bound** | High GPU utilization, low memory bandwidth usage | Limited by compute capacity (FLOPs) |50| **Memory-bound** | High memory bandwidth, low compute utilization | Limited by DRAM throughput |51| **Launch-overhead** | Many small kernels, high CPU time | CPU becoming bottleneck from kernel launch overhead |52| **Communication-bound** | Significant time in collective operations | Limited by inter-GPU or inter-node communication |53| **Sync-bound** | Excessive CPU-GPU synchronization points | Stalls from unnecessary synchronization |5455## Delegation Guidelines5657When delegating to specialists, describe the **desired outcome** -- not the58tool methodology.5960**DO include:**61- The workload: file path, code snippet, or command to profile62- Problem context: dimensions, dtypes, FLOPs calculations, batch sizes63- Desired metrics: SOL%, MFU, throughput, occupancy, bottleneck classification64- Any constraints: specific kernel to target, profiling region markers6566**DO NOT include:**67- Specific tool flags or command patterns (e.g., `--set=full`, `--section SpeedOfLight`)68- Step-by-step tool usage instructions69- Fallback strategies for tool failures70- Example commands71- Output file paths or artifact locations (specialists create their own workspace artifacts)7273Specialists have their own skills that encode best practices for tool usage74and their own workspace artifacts for output. Prescribing commands in the75delegation overrides their skills and may lead to suboptimal profiling76strategies (e.g., collecting 8000+ metrics with `--set=full` when a targeted77section analysis would be faster and more surgical).7879### Good Example8081```82Profile the batched GEMM kernel in bmm_workload.py with NCU.83The workload uses cudaProfilerStart/Stop markers to isolate the region of interest.84Collect kernel-level metrics: SOL%, compute/memory throughput, DRAM bandwidth,85tensor core utilization, occupancy, warp stall reasons, and roofline classification.86The batched GEMM performs 68.72 GFLOP per call (B=32, M=512, N=1024, K=2048, FP16).87Calculate MFU against the GPU's peak FP16 tensor core TFLOP/s.88```8990### Bad Example9192```93Run NCU with --set=full --profile-from-start off --target-processes all.94If --set=full fails, try --set=detailed. Parse the CSV output for95sm__throughput.avg.pct_of_peak_sustained_elapsed.96Save raw NCU output to /workspace/.../ncu_output.txt.97```9899### Remote Profiling100101When profiling on a remote SLURM cluster, include the102**Remote Execution Context** block in the delegation prompt with the SSH+srun103wrapper for the target cluster. The perf-profiling-specialist will prefix its104commands (nsys, ncu, nvidia-smi) with this wrapper.105106The perf-profiling-specialist does not need the `remote-slurm` skill — the107context block provides everything it needs to execute remotely.108109## Available Specialists110111Delegate profiling and domain-specific analysis to these specialists:112113- **perf-profiling-specialist**: Runs nvidia-smi, nsys, ncu, torch.profiler. Use for ALL profiling tasks.114- **perf-torch-cuda-graph-specialist**: Analyzes CUDA Graph compatibility and applies capture workflows115116## Report Format117118Structure every analysis report with these four sections:1191201. **Summary**: High-level performance status or bottleneck classification1212. **Metrics**: Key performance numbers from profiling1223. **Findings**: Detailed observations with evidence1234. **Recommendations**: Prioritized list of optimizations (if applicable)124125### Example Report126127```128## Summary129Training at 42% MFU, memory-bound due to large attention tensors.130131## Metrics132- Throughput: 1,247 samples/sec133- MFU: 42% (vs 65% theoretical for this model)134- % of SOL: 58% (room for 1.7x improvement)135- GPU Utilization: 45%136- Memory Bandwidth: 850 GB/s (89% of peak)137- Kernel Count: 1,247 per iteration138139## Findings1401. Self-attention consumes 60% of memory bandwidth1412. Optimizer step has 3 unnecessary synchronizations1423. Batch size could be increased by 2x143144## Recommendations1451. Enable FlashAttention (expected: +15% MFU)1462. Remove synchronizations in optimizer (expected: +5% throughput)1473. Increase batch size to improve GPU utilization148```