Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
The forward step includes GPU kernel execution (GEMM, attention, normalization, allreduce) plus host-side preparation. The inter-step gap includes host-side work between forward steps (scheduling, request fetching, broadcasting, sampling, response handling).
Host overhead only hurts performance when it is exposed -- the GPU is idle waiting for work. When host prep overlaps with GPU execution, it is hidden and free. See references/metrics.md (M3 section) for diagrams and the exposed/hidden computation.
Forward Step Isolation
In TP configurations, forward steps are isolated via allreduce kernel grouping (deterministic count per transformer layer). For TP=1, NVTX _forward_step ranges are used directly. See references/iteration-isolation-techniques.md for the full algorithm.
Phase Classification (Context vs Generation)
Iterations are classified by NVTX marker text into context (eager, no CUDA graphs) and generation (CUDA graph replay). Per-phase analysis is critical because aggregate metrics can mask phase-specific bottlenecks. See references/phase-classification.md.
Phase 1: Detection (YES/NO Verdict)
Determine whether host overhead is the primary bottleneck.
Detection Metrics
Six metrics in four categories. See references/metrics.md for full definitions, formulas, and SQL queries.
#
Metric
Threshold
What it answers
M1
GPU idle ratio
> 0.30
Is the GPU starved for work?
M2
Launch overhead ratio
> 0.10
Is kernel launch itself expensive?
M3a
Host prep exposed ratio
> 0.50
How well is host prep pipelined?
M3b
Host prep perf impact
> 0.05
How much throughput does exposed prep cost?
M3c
Host prep idle attribution
> 0.50
Is host prep the main cause of GPU idle?
M4
GPU utilization
< 0.60
Is GPU utilization too low?
M5
NCCL ratio (caveat)
> 0.20
Is communication a confounding factor?
Host prep confirmation rule: Host prep is a confirmed bottleneck only when both M3b AND M3c cross their thresholds.
The script computes M1, M2, M4, M5 from SQL, optionally M3 via range intersection, applies the verdict logic, and outputs structured JSON. See references/output-format.md for the output schema.
Kernels per step (launched): 6.2 (baseline) vs 21.9 (target) +253%
More individual launches = more host-side launch overhead.
Step 5: Kernel-Level Drill-Down (Optional)
When the NVTX breakdown identifies a regressing operation but does not reveal why (the overhead is inside the GPU dispatch, not between NVTX ranges), drill below NVTX operations into individual GPU kernel launches.
Start with Inter-Kernel Gap Analysis — bucket the gap distribution to understand the dominant overhead type (graph dispatch, Python interpreter, host-device sync)
If piecewise graph is in use, run Eager vs Graph Classification to measure graph coverage and identify unnecessary eager kernels
For per-layer overhead, use Repeating-Pattern Mapping to isolate the highest-overhead functional group within a single layer
For multi-rank setups, run Straggler Detection if per-step wall time varies across ranks
Kernel-Level Findings to Optimization Patterns
Finding
Optimization Pattern
Large gaps from Python tensor view chains
CUSTOM_OP — replace with C++ custom op
Graph-capturable kernels running eagerly
GRAPH_EXPAND — fix partition poisoning
Monolithic custom op blocking graph capture
GRAPH_SPLIT — split into capturable + eager parts
Host-device sync (.item()) in per-layer code
SYNC (Pattern 1: pre-compute on CPU) + HOIST (Variant B: pass from step level)
Per-layer buffer allocation
ALLOC — pre-allocate at init
Straggler rank with extra host work
Apply targeted optimization to coordinator-only code paths
Common Patterns and Root Causes
Pattern 1: Request Management Refactor
Symptom: _fetch_new_requests regressed 5-10x, new broadcast_requests operation.
Cause: Request fetching refactored for multi-rank broadcasting in TP.
Mitigation: Optimize broadcast path; batch request state updates.
Pattern 2: Increased Kernel Launch Count
Symptom: 3-5x more cudaLaunchKernel calls per step, similar GPU time.
Cause: Operations that were fused or graph-captured are now individual launches.
Mitigation: Re-fuse kernels; extend CUDA graph capture scope.
Pattern 3: New Bookkeeping Operations
Symptom: New NVTX ranges like _write_finish_reasons, handle_additional_outputs.
Cause: New features added to the inference loop without overhead budgeting.
Mitigation: Defer non-critical bookkeeping to async paths; batch updates.
Pattern 4: Flashinfer JIT Warmup Masquerading as Inference
Symptom: Massive elementwise/reduce kernel counts in "steady state" analysis.
Cause: Analysis window includes flashinfer JIT compilation phase.
Fix: Use allreduce-based iteration isolation, not kernel density or time windows.
Pattern 5: Context-Only Bottleneck (Masked by Aggregate)
Symptom: Aggregate metrics below threshold, but context iterations have 50% GPU idle.
Cause: Generation iterations dilute the context-phase bottleneck.
Fix: Per-phase analysis in Detection phase catches this.
Pitfalls
1. shortName is an Integer ID
In CUPTI_ACTIVITY_KIND_KERNEL, shortName is an integer referencing StringIds.id. Always join. See references/nsys-schema.md.
2. NVTX textId vs text
Most NVTX events have textId (integer) but NULL text. Join with StringIds. See references/nsys-schema.md.
3. Duplicate NVTX Ranges from TP Ranks
In TP configurations, each rank reports NVTX ranges independently. De-duplicate by grouping entries within 100us of each other.
4. Negative Inter-Step Gaps
When TP ranks report overlapping NVTX ranges, gap = next_start - prev_end can be negative. Use the maximum end time when de-duplicating.
5. Benchmark Window Selection
The allreduce-based window captures context+generation phases; steady-state NVTX filtering captures generation-only. Both are valid; use the appropriate one for your comparison goal.
Handoff to Optimization
When analysis is complete and the verdict is YES, hand off to the perf-host-optimization skill with:
Detection verdict and evidence: Which metrics crossed thresholds (M1-M5), whether host prep was confirmed (M3b+M3c), and per-phase breakdown.
NVTX-based triage (from Root Cause): Top regressing operations by absolute delta (us/step). Map NVTX range names to source functions -- see references/trtllm-nvtx-ranges.md.
Handoff data block: Include structured data from references/output-format.md (see "Handoff to Optimization" section).
Kernel-level findings (from drill-down, if performed): Inter-kernel gap distribution, graph coverage ratio, per-group overhead map, and straggler rank identification. Map findings to optimization patterns using the table in the Root Cause kernel-level drill-down section above.