Compiler-Grounded Hierarchical Diagnosis for LLM-Based Triton Kernel Optimization

Technische Samenvatting: Compiler-Gegronde Hiërarchische Diagnose voor LLM-gebaseerde Triton Kernel Optimalisatie

1. Probleemstelling

Hoewel Large Language Models (LLM's) de automatisering van kernelgeneratie en -optimalisatie hebben geavanceerd, vertrouwen bestaande benaderingen voornamelijk op "oppervlaktesignalen" zoals compilatiefouten, runtime-metrieken en profiling-data. Deze signalen geven aan dat een kernel traag is, maar verklaren zelden waarom de backend-compiler er niet in slaagt een winstgevende optimalisatie te realiseren. Dit is met name acuut op opkomende versnellers zoals NPU's (bijv. Ascend), waar de compiler-stack evoluerend, doel-specifiek en opaak is voor ontwikkelaars.

De kernuitdaging die wordt geïdentificeerd, is een semantische kloof tussen operator-niveau broncode en backend-prestatiegedrag. Prestatiefouten ontstaan vaak pas nadat de code door intermediaire representatie (IR)-stadia, scheduling-beslissingen en backend-specifieke compiler-passes is gegaan. Gevolgelijk gedragen LLM-agenten, die doorgaans zijn voorgetraind op GPU-gecentreerde patronen, zich als trial-and-error-optimizers: ze stellen plausibele broncode-wijzigingen voor, maar missen het bewijs om runtime-symptomen te koppelen aan specifieke compiler-niveau oorzaken.

2. Methodologie

Het artikel stelt een compiler-gegronde, hiërarchische optimalisatieframework voor dat kerneloptimalisatie behandelt als een progressief cross-layer diagnoseprobleem. In plaats van compiler-grounding als een altijd-aan functie te behandelen, escaleert het systeem van lichtgewicht bewijsvoering naar diepe compiler-analyse alleen wanneer dat nodig is.

De Hiërarchische Workflow:
Het systeem werkt via een closed-loop pijplijn georganiseerd in vier escalerende niveaus:

• L1: Pattern Triage: Het systeem controleert eerst op sterke, patroon-onderbouwde hypothesen met behulp van een gecureerde index van optimalisatiepatronen, heuristieken en expertregels (inclusief interne heuristieken gedestilleerd uit eerdere runs). Als een laag-risico herschrijving gerechtvaardigd wordt door bestaand bewijs, stopt het proces hier.
• L2: Profiling Diagnosis: Als patronen falen, verzamelt het systeem runtime-bewijs (latentie, throughput, hardware counters) om bottlenecks te lokaliseren (bijv. geheugenverplaatsing, scalaire activiteit, synchronisatie). Dit identificeert het symptom, maar niet noodzakelijkerwijs het mechanisme.
• L3: IR Attribution: Wanneer profiling onvoldoende is, inspecteert het systeem de Intermediate Representations (IR) om runtime-symptomen te vertalen naar structurele diagnoses (bijv. non-unit-stride loads, gemiste fusie, layout-geïnduceerde vectorisatie-fouten). Het reconstrueert het lowering-traject van de operator om stage-naar-stage transformaties te identificeren.
• L4: Compiler-Source Escalation: Als laatste redmiddel roept het systeem compiler-gegronde analyse aan om uit te leggen waarom een gediagnosticeerd patroon backend-optimalisatie blokkeert. Het raadpleegt compiler-kennis (pass-gedrag, lowering-regels, beperkingen) om de broncode-condities te herstellen die een succesvolle herschrijving moet vervullen.

Systeemarchitectuur & State Management:

• Agent-Centrisch Ontwerp: Geïmplementeerd als een agent-centrische omgeving (geïntegreerd in de CannBot skills repository) in plaats van een op maat gemaakte compiler-service. Het gebruikt een dunne execution harness om validatie, correctheid en bewijsverzameling te beheren, terwijl domeinspecifieke "skills" de optimalisatielogica afhandelen.
• Stateful Rounds: Het optimalisatieproces is georganiseerd in expliciete, controleerbare rondes. Elke ronde legt zijn hypothese, bewijsbronnen en validatie-uitkomst vast. Dit stateful ontwerp maakt het systeem hervatbaar en zorgt ervoor dat diepere analyses (IR/Compiler) worden toegevoegd als herbruikbaar bewijs in plaats van vluchtige observaties.
• Retrospective Synthesis: Naast de online loop voert het systeem een tragere, cross-operator synthese-pass uit. Het brengt gevalideerde optimalisatiegeschiedenissen in kaart met bestaande patroonfamilies of creëert nieuwe herbruikbare patronen, waardoor het "goedkoopste" niveau (Pattern Triage) in de loop van de tijd kan verbeteren.

3. Belangrijkste Bijdragen

1. Probleemformulering: De auteurs formuleren LLM-gebaseerde kerneloptimalisatie als een progressief cross-layer diagnoseprobleem, waarbij zij identificeren dat het gebrek aan compiler-gegronde bewijsvoering een primaire reden is waarom profiling-only agenten falen bij backend-specifieke optimalisaties.
2. Hiërarchische Workflow: Zij beschrijven een workflow die escaleert van pattern triage naar profiling, IR attribution en compiler-source escalation, waarbij zij alleen eveneens onderbouwde herschrijvingen op bronniveau voorstellen wanneer diepere bewijsvoering vereist is.
3. Evaluatiebewijs: Zij presenteren gestandaardiseerd, distributie-bewust evaluatiebewijs op een NPUKernelBench-afgeleide Ascend 950 benchmark, waarbij geaggregeerde winsten, best-round accounting en representatieve cross-layer traces worden gerapporteerd.

4. Experimentele Resultaten

Het systeem werd geïmplementeerd voor Triton voor Ascend NPU's en geëvalueerd op 37 succesvol geconverteerde operators van een gestandaardiseerde Ascend 950 benchmark (afgeleid van NPUKernelBench). Elke operator werd getest op 5 gevallen (185 gevallen in totaal).

• Prestatiewinsten:
  • Geometrisch Gemiddelde Versnelling: 4.35× (van initiële naar geoptimaliseerde Triton kernel).
  • Mediaan Versnelling: 2.73×.
  • Distributie: 22/37 vermeldingen overschreden een 2× versnelling; 13/37 overschreed 5×. De resultaten tonen een long-tail distributie, waarbij substantiële winsten naast bijna-baseline vermeldingen bestaan.
• Proces Verantwoording:
  • De mediaan van de best-round index was 10, wat aangeeft dat optimale resultaten vaak meerdere iteraties vereisten.
  • Bewijsdiepte: Hoewel 33 van de geselecteerde "beste" rondes werden toegeschreven aan Pattern Triage, toonde het systeem de bruikbaarheid van diepere lagen aan: 32 trajecten bereikten Profiling Diagnosis, 3 bereikten IR Attribution, en 4 bereikten Compiler-Source Escalation.
  • Casestudy: Een representatieve trace (Hyena FFT-size padding) liet zien hoe profiling een scalaire bottleneck identificeerde, IR attribution specifieke synchronisatiekosten in de lowering identificeerde, en compiler-source analyse de beperking verklaarde, wat leidde tot een robuuste 2.08× versnelling.

5. Betekenis en Claims

Het artikel beweert dat compiler grounding selectief moet zijn in plaats van altijd-aan. Door optimalisatie te behanden als een progressieve diagnose, maakt het systeem diepe compiler-redenering praktisch door het alleen aan te roepen wanneer lichter gewicht bewijs geen voldoende gegronde herschrijving kan produceren.

De auteurs benadrukken dat hun resultaten substantiële headroom laten zien op een subset van operators, maar zij beweren geen uniforme verbetering over alle gevallen. Zij stellen expliciet dat de huidige evaluatie geen causale isolatie biedt (bijv. het vergelijken van progressieve escalatie tegenover profiling-only of always-deep strategieën onder een bevroren toolchain). Het artikel positioneert zichzelf als een "systemen-argument" ondersteund door transparante benchmark- en procesbewijzen, waarbij de causale decompositie van de hiërarchie wordt voorbehouden aan toekomstige gecontroleerde experimenten.

Het werk benadrukt dat de relatie tussen broncode en runtime-prestaties wordt bemiddeld door onzichtbare compiler-transformaties, en dat het overbruggen van deze kloof met een hiërarchische, bewijsgestuurde aanpak essentieel is voor het optimaliseren van kernels op opkomende, opaak-gebaseerde versnellers zoals NPU's.