Was macht Nsight Compute Analyse?

NVIDIA Nsight Compute (ncu) profiliert einzelne CUDA-Kernel, um herauszufinden, warum sie langsam sind und was optimiert werden kann. Es misst den GPU-Durchsatz als Prozentsatz des theoretischen Spitzenwerts (Speed of Light / SOL%), was eine systematische Engpassklassifizierung und gezielte Optimierung ermöglicht.

Wann verwenden

Greifen Sie auf dieses Skill zu, wenn Sie auf Folgendes stoßen:

Auslöser: Benutzer möchte einen CUDA-Kernel profilieren, ncu-Ausgabe analysieren, .ncu-rep-Berichte interpretieren oder die GPU-Kernel-Leistung optimieren
Symptome: Kernel läuft langsamer als erwartet, geringe GPU-Auslastung, Bedarf, rechnergebundene vs. speichergebundene Engpässe zu klassifizieren, Belegungsprobleme
Schlüsselwörter: "ncu", "nsight compute", "SOL%", "speed of light", "Kernel- Profiling", "rechnergebunden", "speichergebunden", "latenzgebunden", "Belegung", "Roofline", "Warp-Stalls", "Cache-Trefferquote", "ncu-rep"

Verwenden Sie dieses Skill NICHT für:

Systemlevel-Profiling (verwenden Sie stattdessen Nsight Systems / nsys)
CUDA-API-Tracing oder CPU-GPU-Zeitleistenanalyse (verwenden Sie nsys)
GPU-Überwachung ohne Profiling (verwenden Sie nvidia-smi)

Anforderungen

Abhängigkeit	Version	Hinweise
CUDA Toolkit	>=11.0	Enthält `ncu`
`ncu`-Binärdatei	Eine, die der Treiber unterstützt	Nsight Compute 2026.3 benötigt einen Treiber, der mit CUDA 13 kompatibel ist. Oder setzen Sie die Umgebungsvariable `$NCU`
NVIDIA GPU	Turing+	Volta benötigt Nsight Compute 2025.2 oder älter

Berechtigungen: ncu erfordert möglicherweise sudo, CAP_SYS_ADMIN oder --privileged in Containern. ncu -v gibt nur die Version aus; fehlende Berechtigungen zeigen sich als ERR_NVGPUCTRPERM, wenn der erste Kernel profiliert wird.

Prinzipien

Datenintegrität

Dies ist ein datengesteuertes Analysesystem. Jede Zahl, die Sie präsentieren, muss eine autoritative Quelle haben. Befolgen Sie diese Regeln ausnahmslos:

Zitieren Sie, bevor Sie interpretieren. Wenn Sie Metriken aus der ncu-Ausgabe präsentieren, zeigen Sie immer den tatsächlichen ncu-Befehl, den Sie ausgeführt haben, UND die relevante Rohausgabe (CSV-Zeilen, Metrikwerte), bevor Sie eine numerische Schlussfolgerung ziehen.
Erfinden Sie niemals Metriken. Wenn ncu fehlschlägt, unerwartete Ausgaben liefert oder Sie es nicht ausführen können, sagen Sie dies explizit. Erfinden Sie keine plausibel aussehenden Zahlen. Ein ehrliches „Profiling fehlgeschlagen“ ist besser als erfundene Daten.
Weisen Sie jeden Wert zu. Für jede von Ihnen zitierte Metrik (SOL%, Dauer, Belegung, Durchsatz) muss der Leser sie auf eine bestimmte Zeile in der von Ihnen gezeigten ncu-Rohausgabe zurückverfolgen können.

SOL%-Denkmodell

Speed of Light (SOL%) misst, wie nah ein Kernel an den theoretischen Spitzenwerten der GPU läuft:

Rechnen SOL% (Compute (SM) Throughput) = der Durchsatz der am stärksten ausgelasteten SM-Einheit als Prozentsatz ihres Spitzenwerts
Speicher SOL% (Memory Throughput) = der Durchsatz der am stärksten ausgelasteten Speichereinheit (DRAM, L2, L1, Shared Memory) als Prozentsatz ihres Spitzenwerts

Die höhere Metrik zeigt normalerweise den Engpasstyp an. Verwenden Sie dies als primäres Klassifizierungssignal. Beide können gleichzeitig hoch sein: Der Kernel ist dann nahe der Hardwaregrenze für seinen Algorithmus.

Klassifizierungsschwellenwerte

Rechnen %	Speicher %	Engpass	Nächster Schritt
>60	<40	Rechnergebunden	Abschnitt ComputeWorkloadAnalysis
<40	>60	Speichergebunden	Abschnitt MemoryWorkloadAnalysis
<40	<40	Latenzgebunden	Abschnitte LaunchStats + Occupancy
40-60	40-60	Ausgeglichen	Tiefer profilieren mit detaillierten Abschnitten
>60	>60	Nahe Hardwaregrenzen	Algorithmische Änderung; beide Arbeitslastabschnitte prüfen

Zusätzliche Signale:

Dauer <10us mit vielen Starts -> Startaufwandsgebunden (zuerst nsys verwenden)
Beide <40% aber Belegung >50% -> Befehlsgebunden (InstructionStats prüfen)

SOL%-Leistungsstufen

SOL%	Stufe	Aktion
>80%	Ausgezeichnet	Nur kleinere Optimierungen
60-80%	Gut	Gezielte Optimierung
40-60%	Ausreichend	Signifikante Optimierung erforderlich
<40%	Schlecht	Grundlegende Überarbeitung erforderlich

Abschnitt-zuerst-Profiling

Verwenden Sie immer gezielte --section-Flags anstelle einer massiven --set-Sammlung. Einzelne Abschnitte sind schneller und chirurgischer. Eskalieren Sie nur zu --set basic oder --set detailed, wenn eine breite Erkundung erforderlich ist.

ncu vs. nsys

Werkzeug	Umfang	Overhead	Zweck
nsys	Systemebene	5-10%	Finden, welche Kernel optimiert werden sollen
ncu	Kernel-Ebene	10-100x langsamer	Verstehen, warum ein Kernel langsam ist

Verwenden Sie zuerst nsys, um die wichtigsten Kernel nach GPU-Zeit zu identifizieren, dann ncu für die detaillierte Analyse dieser spezifischen Kernel.

Arbeitsablauf

Wählen Sie Ihren Pfad basierend auf der Anfrage:

Wissensabfrage (welche Metriken zu verwenden sind, --section vs. --set, wie Kernel gefiltert werden): Antworten Sie direkt aus den Prinzipien, der Befehlsreferenz und den folgenden Referenzen. Führen Sie ncu NICHT aus.
Schnelldiagnose (Engpass klassifizieren, SOL% prüfen): Nur Schritt 1. Eskalieren, wenn der Benutzer mehr wünscht.
Spezifische Diagnose (Bankkonflikte, Registerdruck, Belegung): Schnelle SOL%-Prüfung (Schritt 1), dann direkt zum relevanten Abschnitt in Schritt 2 gehen.
Tiefenanalyse (detaillierter Bericht, Optimierungsempfehlungen): Vollständige Schritte 1-5. Präsentieren Sie den vollständigen strukturierten Bericht mit allen Schlüsselmetriken (SOL%, Dauer, Belegung) in Ihrer endgültigen Antwort – teilen Sie den Bericht nicht über mehrere Nachrichten auf oder ersetzen Sie ihn durch eine kurze Zusammenfassung.

Schritt 0: ncu überprüfen

ncu -v
# Oder: $NCU -v

Wenn nicht gefunden, stellen Sie sicher, dass das CUDA Toolkit installiert ist, oder setzen Sie die Umgebungsvariable NCU auf den Binärpfad.

Schritt 1: SOL%-Diagnose

Starten Sie immer mit SpeedOfLight, um den Engpass zu klassifizieren:

ncu --section SpeedOfLight --csv \
    --kernel-name regex:"KERNEL" \
    --launch-skip 5 --launch-count 3 \
    -- COMMAND

Lesen Sie Compute (SM) Throughput und Memory Throughput aus der Ausgabe. Klassifizieren Sie mit den obigen Schwellenwerten.

Schritt 2: Mit gezielten Abschnitten eskalieren

Basierend auf der Klassifizierung aus Schritt 1 fügen Sie Abschnitte hinzu:

Klassifizierung	Hinzuzufügende Abschnitte
rechnergebunden	`ComputeWorkloadAnalysis`
speichergebunden	`MemoryWorkloadAnalysis`
latenzgebunden	`LaunchStats`, `Occupancy`
Warp-Stalls	`WarpStateStats`, `SchedulerStats`
Benötigt Befehlsaufschlüsselung	`InstructionStats`

Fügen Sie bei der Diagnose latenzgebundener Kernel immer LaunchStats und Occupancy hinzu. Diese decken Registerdruck, Shared-Memory-Grenzen und Blockgrößenprobleme auf.

Beispiel – tiefer Einstieg speichergebunden:

ncu --section SpeedOfLight --section MemoryWorkloadAnalysis --csv \
    --kernel-name regex:"embedding_lookup" \
    --launch-count 3 \
    -- python script.py

Beispiel – tiefer Einstieg rechnergebunden:

ncu --section SpeedOfLight --section ComputeWorkloadAnalysis --csv \
    --kernel-name regex:"gemm|nvjet" \
    --launch-count 3 -- python script.py

Beispiel – Belegungsuntersuchung:

ncu --section SpeedOfLight --section LaunchStats --section Occupancy --csv \
    --kernel-name regex:"small_kernel" \
    -- python script.py

Schritt 3: Roofline-Analyse (Optional)

Für das visuelle Verständnis des Gleichgewichts zwischen Rechnen und Speicher. Die Roofline-Abschnitte sind Diagramme: In der CLI werden sie nur mit --print-details all ausgegeben, was die Zahlen hinter dem Diagramm auflistet (erreichter und Spitzenarbeit und -verkehr). Um das Diagramm zu sehen, speichern Sie einen Bericht mit -o und öffnen Sie ihn in der Nsight Compute-Benutzeroberfläche.

ncu --section SpeedOfLight_RooflineChart --print-details all \
    --kernel-name regex:"KERNEL" -- COMMAND

Für eine präzisionsspezifische hierarchische Roofline:

# FP16 Kernel
ncu --section SpeedOfLight_HierarchicalHalfRooflineChart --print-details all \
    --kernel-name regex:"KERNEL" -- COMMAND

# Tensor-Core-Kernel
ncu --section SpeedOfLight_HierarchicalTensorRooflineChart --print-details all \
    --kernel-name regex:"KERNEL" -- COMMAND

Interpretation: Kernel links vom Roofline-Punkt = speichergebunden; rechts = rechnergebunden; weit unter beiden Dächern = Latenz-/Belegungsproblem. Siehe references/roofline-analysis.md.

Schritt 4: Interpretieren und Optimieren

Identifizieren Sie den dominanten Engpass aus der SOL%-Klassifizierung
Schlagen Sie detaillierte Analyse- und Optimierungsstrategien in references/bottleneck-guide.md nach
Wenden Sie zuerst die Optimierung mit der höchsten Auswirkung an
Wiederholen Sie das Profiling, um die Verbesserung zu validieren und Engpassverschiebungen zu erkennen

Schritt 5: Validieren

Profilerstellen Sie denselben Kernel nach der Optimierung erneut:

ncu --section SpeedOfLight --csv \
    --kernel-name regex:"optimized_kernel" \
    --launch-count 3 \
    -- python optimized_script.py

Vergleichen: Ist der Durchsatz % gestiegen? Ist die Dauer zurückgegangen? Hat sich der Engpasstyp verschoben?

Profiling von JIT-kompilierten Kerneln (Triton/cuTile/CuTeDSL)

JIT-kompilierte Kernel lösen beim ersten Aufruf eine automatische Optimierung aus. Isolieren Sie die tatsächliche Ausführung:

Zuerst aufwärmen: Führen Sie den Kernel 3-5 Mal aus, um die JIT-Kompilierung und automatische Optimierung abzuschließen, dann torch.cuda.synchronize().
Profiler-Marker verwenden: Klammern Sie den gemessenen Bereich mit cudaProfilerStart()/cudaProfilerStop() ein.
--profile-from-start off verwenden, damit ncu nur den markierten Bereich erfasst:

# Aufwärmen (JIT + Autotuning)
for _ in range(5):
    result = kernel(inputs)
torch.cuda.synchronize()

# Nur stationären Zustand profilieren
torch.cuda.cudart().cudaProfilerStart()
for _ in range(3):
    result = kernel(inputs)
    torch.cuda.synchronize()
torch.cuda.cudart().cudaProfilerStop()

ncu --profile-from-start off --section SpeedOfLight --csv \
    --kernel-name regex:"target_kernel" \
    --launch-count 3 -- python script.py

Alternative: Verwenden Sie --launch-skip N, um Autotuning-Starts zu überspringen. Siehe references/advanced-profiling.md für NVTX-Bereichs- und Wiedergabemodus-Alternativen.

Programmatische Berichtsanalyse

Extrahieren Sie Metriken aus .ncu-rep- oder .ncu-repz-Dateien mit dem Python-Modul ncu_report (im Verzeichnis extras/python/ der Nsight Compute-Installation):

import ncu_report

ctx = ncu_report.load_report("report.ncu-rep")
for rng in ctx:
    for action in rng:
        name = action.name()
        # SpeedOfLight's "Compute (SM) Throughput" and "Memory Throughput"
        compute = action["sm__throughput.avg.pct_of_peak_sustained_elapsed"].as_double()
        memory = action["gpu__compute_memory_throughput.avg.pct_of_peak_sustained_elapsed"].as_double()
        duration = action["gpu__time_duration.sum"].as_uint64()

        if compute > 60:
            classification = "rechnergebunden"
        elif memory > 60:
            classification = "speichergebunden"
        else:
            classification = "latenzgebunden"

        print(f"{name}: {classification} (rechnen={compute:.1f}%, speicher={memory:.1f}%, {duration}ns)")

Siehe references/python-report-api.md für die vollständige API (IContext-, IRange-, IAction-, IMetric-Klassen).

Ausgabeformate

CSV-Ausgabe (für Skripterstellung und automatisierte Analyse):

ncu --csv --section SpeedOfLight --kernel-name regex:"KERNEL" -- COMMAND
ncu --csv --page raw --section SpeedOfLight -- COMMAND   # Alle Metriken flach

Das Standard-CSV hat eine Zeile pro Metrik. Seine Spalten enthalten ID (den profilierten Start), Kernel Name, Section Name, Metric Name, Metric Unit und Metric Value; Regelergebnisse sind Zeilen, die stattdessen Rule Name, Rule Description und Estimated Speedup ausfüllen. Ein Metric Name kann sich über Abschnitte hinweg wiederholen (Memory Throughput ist % in SpeedOfLight und Byte/s in MemoryWorkloadAnalysis), also filtern Sie auch nach Section Name. --page raw ergibt eine Zeile pro Start, eine Spalte pro Metrik und eine zweite Zeile mit Einheiten. Werte sind in Basiseinheiten (ns, hz, %).

Während des Profilings teilen sich die ==PROF==-Zeilen von ncu und die eigene Ausgabe der Anwendung stdout mit dem CSV. Für sauberes CSV schreiben Sie einen Bericht und lesen ihn zurück:

Berichtsdateien (für spätere Analyse):

ncu -o report.ncu-rep --section SpeedOfLight -- COMMAND
ncu --import report.ncu-rep --csv                       # Eine Zeile pro Metrik
ncu --import report.ncu-rep --csv --page raw            # Eine Zeile pro Start

Geben Sie -o die Erweiterung: Ohne Erweiterung schreiben Nsight Compute 2026.3 und neuer die zstd-komprimierte report.ncu-repz, und ältere Versionen schreiben report.ncu-rep. --import und ncu_report lesen beide.

Wichtige Metrikzeilen (Metric Name-Werte):

Metric Name	Abschnitt	Bedeutung
`Duration`	SpeedOfLight	Ausführungszeit
`Compute (SM) Throughput`	SpeedOfLight	% des Spitzenrechnens
`Memory Throughput`	SpeedOfLight	% des Spitzenwerts der am stärksten ausgelasteten Speichereinheit
`SM Frequency`	SpeedOfLight	Takt, mit dem das Profil lief
`Achieved Occupancy`	Occupancy	Aktive Warps / max. Warps (%)

Erfolgsindikatoren:

SOL%-Werte in der Ausgabe vorhanden -> Profiling erfolgreich
Dauerwerte sinnvoll (nicht 0 oder extrem groß)
Mehrere Starts erfasst, wenn --launch-count > 1

Beispiele

Beispiel: Einen GEMM-Kernel klassifizieren

cuBLAS-GEMM-Kernel auf Blackwell heißen nvjet_*, also beide Namen abgleichen:

ncu --section SpeedOfLight --csv \
    --kernel-name regex:"gemm|nvjet" \
    --launch-skip 5 --launch-count 3 \
    -- python train.py

Ausgabe für eine FP16 4096x4096 Matmul auf B200 (Spalten und Zeilen gekürzt):

"ID",...,"Kernel Name",...,"Section Name","Metric Name","Metric Unit","Metric Value",...
"0",...,"nvjet_sm100_hsh_128x256_64x6_2x2f_2cta_h_bz_NNT",...,"GPU Speed Of Light Throughput","Memory Throughput","%","38.38",
"0",...,"nvjet_sm100_hsh_128x256_64x6_2x2f_2cta_h_bz_NNT",...,"GPU Speed Of Light Throughput","Duration","ns","97600",
"0",...,"nvjet_sm100_hsh_128x256_64x6_2x2f_2cta_h_bz_NNT",...,"GPU Speed Of Light Throughput","Compute (SM) Throughput","%","77.11",

Interpretation: rechnergebunden (77,1 % Rechnen, 38,4 % Speicher). Nächster Schritt: Tensor-Core-Auslastung mit --section ComputeWorkloadAnalysis prüfen.

Beispiel: Einen speichergebundenen Embedding-Kernel diagnostizieren

PyTorchs Embedding-Lookup führt vectorized_gather_kernel aus, also gleichen Sie auch das ab:

ncu --section SpeedOfLight --section MemoryWorkloadAnalysis --csv \
    --kernel-name regex:"gather|index|embedding" \
    --launch-count 3 -- python train.py

Überprüfen Sie die L1/L2-Cache-Trefferquoten in der Ausgabe: Niedrige Trefferquoten deuten darauf hin...

Nsight Compute Analyse

Was ist Nsight Compute Analyse?

In Ihrer bevorzugten KI fragen

Dokumentation