dyl-joseph/DiT-Autoresearch

DiT AutoResearch A5500 Skill

Verwende diesen Skill bei der Optimierung der Diffusion Transformer Inferenz auf RTX A5500/Ampere Hardware.

Nicht verhandelbare Regeln

• Lies program.md vor dem Handeln.
• Behandle knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md als Projektüberschreibung für generische Hardware/Präzisionsratschläge.
• Qualität ist eine harte Einschränkung, kein gewichtetes Ziel.
• Quantisierung darf nur getestet werden, wenn die festgelegte Benchmark-Suite keine erforderliche Genauigkeits-/Qualitätsverschlechterung zeigt. Behalte niemals einen quantisierten Kandidaten mit einer niedrigeren erforderlichen Benchmark-Punktzahl.
• Ändere während einer Sitzung nicht den Benchmark-Korpus, den Qualitätsbewerter, das Leistungsmessungs-Setup oder andere fixed_paths.
• Bearbeite nur Pfade, die in mutable_paths aufgeführt sind.
• Erstelle zuerst die unveränderte Basislinie.
• Vergleiche die Kandidatenqualität mit der ursprünglichen Basislinie, nicht mit dem vorherigen Kandidaten.
• Vergleiche die Leistung mit dem aktuell besten Kandidaten im Ziellane des Branches.
• Eine kausale Hypothese pro Commit.
• Bevorzuge exakte Implementierungsoptimierungen vor numerischen oder algorithmischen Näherungen.
• Miss auf der A5500. Importiere keine H100/B200-Beschleunigungszahlen als erwartete A5500-Ergebnisse.
• FlashAttention-2/SDPA sind relevante Ampere-Attention-Pfade; FA3/FA4 und Hopper/Blackwell-spezifische Funktionen sind Forschungsreferenzen, keine zielnativen Pfade.

Erforderlicher Start

1. Lies program.md vollständig.
2. Lies die folgenden Handbuchdateien:
   • knowledge/handbook/00_foundations/04_target_hardware_and_quality_contract.md
   • knowledge/handbook/00_foundations/02_benchmarking_and_quality_gates.md
   • knowledge/handbook/03_single_gpu/08_a5500_optimization_ladder.md
   • knowledge/handbook/02_bottlenecks/05_nsight_a5500_profiling_workflow.md
   • knowledge/handbook/09_reference/09_a5500_benchmark_runbook.md
   • knowledge/handbook/09_reference/10_reproducibility_and_claims_standard.md
3. Führe dit-ar --config config/autoresearch.json doctor aus.
4. Stelle sicher, dass der Forschungsbranch autoresearch/<tag> ist und der Arbeitsbaum sauber ist.
5. Führe dit-ar ... init aus, wenn dies eine neue Sitzung ist.
6. Führe dit-ar ... baseline aus, bevor du optimierten Code änderst.

Wissensabruf

Vor einem nicht-trivialen Experiment durchsuche das Handbuch:

dit-ar --config config/autoresearch.json search "<Mechanismus + Engpass + Modell/Hardware-Begriffe>"

Lies die relevanten Markdown-Dateien. Verwende das Handbuch als primären lokalen Forschungsspeicher. Wenn es eine Hypothese nicht unterstützt, kennzeichne die Idee als externe/neue Forschungshypothese, anstatt so zu tun, als ob das Handbuch sie empfiehlt.

Experimentklassifizierung

Verwende eine der folgenden:

• exact: Implementierungs-/Layout-/Scheduling-/Speicheränderungen, die den Algorithmus bewahren sollen;
• numerical: Änderungen des Arithmetikmodus, wie FP16↔BF16 oder TF32-Verhalten;
• approximate: Geänderte/übersprungene Modellberechnungen, wie weniger Schritte, approximative Caches, Guidance-Cutoff, sparse Approximation;
• quantization: Jeder Low-Bit-Pfad für Gewichte/Aktivierungen/Aufmerksamkeit/Speicher.

Quantisierung erhält automatisch ein striktes Null-Regressions-Qualitätsgate.

Keep/Discard-Loop

Für jede Hypothese:

1. Prüfe die aktuellen besten Metriken und kürzlichen Fehlschläge.
2. Durchsuche/lese relevantes Handbuchmaterial.
3. Formuliere die Hypothese und die erwartete Engpassänderung.
4. Bearbeite nur mutable Pfade.
5. Führe eine einfache Syntax-/Rauchprüfung durch, wenn nützlich.
6. Committe den Kandidaten.
7. Führe aus:

dit-ar --config config/autoresearch.json experiment \
  --classification <Klasse> \
  --description "<kurze kausale Hypothese>"

8. Bei KEEP bleibe auf dem Commit und fahre fort.
9. Bei DISCARD behalte die .autoresearch/-Logs, dann git reset --hard HEAD^, um zum vorherigen Besten zurückzukehren.
10. Bei CRASH behebe nur, wenn die Implementierung trivial falsch ist; sonst verwerfen und weitermachen.
11. Fahre fort, bis manuell gestoppt.

Forschungsprioritäten auf A5500

Bevorzuge, grob in dieser Reihenfolge:

• End-to-End-Profiling und Phasenzuordnung;
• Attention-Backend-Auswahl für exakte Formen;
• Compile/regionales Compile und Entfernung von Graph-Breaks;
• Fusion von Normalisierungen/Modulation/Pointwise-Operationen;
• CUDA-Graphen für stabile Form-Buckets;
• GEMM-Algorithmus/Layout-Tuning;
• Übertragungsvermeidung und Komponentenlebenszyklus-Scheduling;
• 24 GB VRAM-Engineering mit Auslagerung/Verdrängung/Tiling;
• Topologie-bewusste Zwei-A5500-Strategien, falls verfügbar;
• Benutzerdefiniertes Triton/CUDA/CUTLASS nur nach Profiler-Beweisen;
• Näherungen und Quantisierung nur hinter der vollständigen Qualitäts-Firewall.

Optimiere niemals eine Metrik, die das Zielprodukt nicht interessiert, nur weil sie leicht zu verbessern ist.