aoti-debug

aoti-debug ist ein offizieller Skill aus dem PyTorch-Quellrepository für die Untersuchung von Fehlern und Abstürzen in AOTInductor, kurz AOTI. Er richtet sich an Entwicklerinnen und Entwickler, die mit Ahead-of-Time kompilierten PyTorch-Modellen arbeiten und bei aot_compile, aot_load, aoti_compile_and_package oder aoti_load_package unerwartete Laufzeitfehler sehen. Laut Anbieter deckt die Anleitung unter anderem Segmentation Faults, Gerätefehler, Probleme beim Laden von Konstanten, falsche Ausgaben, CUDA-Fehler und Triton-Assertions ab. Der Katalogeintrag beschreibt deshalb einen fokussierten Diagnoseleitfaden für Claude Code im PyTorch-Quellbaum und kein eigenständiges Laufzeitpaket, keinen Compiler und keine automatische Reparatur.

Zweck und Einordnung

Die wichtigste erste Prüfung ist laut Anbieter unabhängig vom konkreten Fehlerbild die Übereinstimmung von Kompiliergerät, Ladegerät, Eingabegeräten und Eingabeformen. Ein auf CUDA erzeugtes AOTI-Artefakt darf nicht einfach auf CPU geladen werden, während ein CPU-Artefakt auf CPU bleiben muss. Unterschiedliche Geräteindizes können je nach aktuellem API-Pfad möglich sein, ein Wechsel des Gerätetyps ist jedoch nicht vorgesehen. Ebenso müssen Eingaben die beim Kompilieren erwarteten Formen, Datentypen und Strides einhalten oder durch ausdrücklich modellierte dynamische Formbedingungen abgedeckt sein. Diese Reihenfolge verhindert, dass ein offensichtlicher Vertragsbruch vorschnell als tiefer Compilerfehler analysiert wird.

Diagnose von Laufzeitfehlern

Bei Eingabefehlern empfiehlt die Primärquelle die Laufzeitprüfung über AOTI_RUNTIME_CHECK_INPUTS. Sie kann Abweichungen bei Gerätetyp, Datentyp, Größe und Stride verständlicher melden. Bei CUDA Illegal Memory Access schlägt der Anbieter zunächst zusätzliche Prüfungen wie TORCHINDUCTOR_NAN_ASSERTS vor und empfiehlt anschließend Maßnahmen, die asynchrone oder nichtdeterministische Fehler besser eingrenzen. CUDA_LAUNCH_BLOCKING kann die Kernel-Ausführung synchronisieren. PYTORCH_NO_CUDA_MEMORY_CACHING kann die Wirkung des Caching Allocators aus dem Fehlerbild herausnehmen. Diese Einstellungen gehören in eine kontrollierte Entwicklungsumgebung und müssen mit dem konkreten PyTorch-Stand, dem Backend und der vorhandenen Hardware abgeglichen werden.

Kernel und Zwischenwerte

Für die Lokalisierung eines problematischen Kernels verweist der Skill auf den AOTInductor Intermediate Value Debugger. AOT_INDUCTOR_DEBUG_INTERMEDIATE_VALUE_PRINTER kann erzeugte Kernel schrittweise sichtbar machen. Mit einem passenden Filter lassen sich bestimmte Kernel und ihre Eingaben untersuchen. Zusätzlich können TORCH_LOGS mit Inductor- und Output-Code-Informationen sowie TORCH_SHOW_CPP_STACKTRACES weitere Kontextdaten liefern. Laut Anbieter sind dynamische Formen und eigene C++-Operatoren häufige Ausgangspunkte für Fehler; bei eigenen Operatoren kann insbesondere die Meta-Funktion für SymInt-Anforderungen geprüft werden. Diese Hinweise sind Diagnosewege, keine Garantie, dass eine einzelne Umgebungsvariable die Ursache behebt.

Triton und dynamische Formen

Ein mitgelieferter Unterleitfaden behandelt Triton-Assertions mit dem Muster index out of bounds. Dafür wird das AOTI-Paket beziehungsweise das extrahierte Archiv mit seiner Wrapper-Datei benötigt. Die Untersuchung verbindet die fehlgeschlagene Assertion mit dem generierten Kernel, dem dynamischen Größenparameter, dem zugehörigen Modelleingang und den Quellknoten. Leere Tensoren, fehlende untere Schranken und nicht getestete Randfälle sind typische Hypothesen. Der Leitfaden empfiehlt, leere und minimale Formen bereits beim Export zu berücksichtigen oder den Modellpfad für leere Eingaben ausdrücklich abzusichern. Änderungen müssen anschließend mit relevanten PyTorch-Tests und fachlicher Prüfung bestätigt werden.

API-Stand und Grenzen

Die Primärquelle unterscheidet veraltete APIs wie torch._export.aot_compile und torch._export.aot_load von den aktuellen Funktionen torch._inductor.aoti_compile_and_package und torch._inductor.aoti_load_package. Der neue Paketpfad speichert laut Anbieter Gerätemetadaten und wählt dadurch den passenden Gerätetyp beim Laden; ein Wechsel des Gerätetyps bleibt ausgeschlossen. Der Skill ersetzt keine Release- oder Backend-Prüfung und garantiert weder numerische Gleichheit noch identische Laufzeit. Er setzt einen kontrollierten Arbeitsbaum, reproduzierbare Eingaben, Kenntnisse über PyTorch-Compilation und eine Prüfung generierter Artefakte voraus. Secrets, private Modelle und sensible Eingabedaten gehören nicht in Logs oder Beispielmaterial.

Quelle, Sicherheit und Kompatibilität

Die Primärquelle ist https://github.com/pytorch/pytorch/tree/main/.claude/skills/aoti-debug. Ergänzend beschreibt die offizielle PyTorch-Dokumentation unter https://docs.pytorch.org/docs/main/user_guide/torch_compiler/torch.compiler_aot_inductor.html den AOTInductor-Kontext für exportierte Modelle. PyTorch veröffentlicht seinen Quellbaum unter BSD-3-Clause. Diese Beschreibung wurde am 9. September 2026 geprüft. GitHub-Sterne werden nicht gespeichert, weil das Skill-Modell kein github_stars-Feld besitzt. Die Kompatibilität mit Claude Code folgt aus der Veröffentlichung unter .claude/skills; technische Ergebnisse hängen vom PyTorch-Commit, Betriebssystem, Backend und Gerät ab. Laut Anbieter sollte jede Diagnose mit minimalen, reproduzierbaren Eingaben erfolgen und Änderungen sollten vor dem Übernehmen geprüft werden.