AMD zverejnilo postup pre custom diffusion attention kernel vo FlyDSL na ROCm

AMD 17. septembra 2026 publikovalo na blogu ROCm technický postup pre implementáciu a optimalizáciu vlastného diffusion attention kernela vo FlyDSL. Nejde o oznámenie hotového produktu ani o nezávislý výkonnostný test, ale o odborný návod od výrobcu, zameraný na vývojárov GPU kernelov a tímy pracujúce s ROCm a AMD akcelerátormi.1

Čo AMD konkrétne popisuje

Text vysvetľuje, prečo diffusion modely kladú na attention kernel iné nároky než tradičné autoregresívne transformery. AMD uvádza potrebu podpory flexibilných rozložení KV cache, vrátane stránkovaného cache a dočasného priestoru pre špekulatívne generované tokeny, a zároveň potrebu vysokej konfigurovateľnosti aj výkonu.1

Praktické jadro článku je postup „krok za krokom“. AMD odporúča začať základmi FlyDSL, pozrieť si verejné príklady attention kernelov a následne prispôsobiť implementáciu rozdielom medzi generáciami GPU.1 Pre vývojára je dôležité najmä to, že blog neostáva pri všeobecných radách, ale uvádza konkrétne miesta, kde sa výkon a správnosť typicky lámu: rozloženie operandov v MFMA operáciách, tlak na registre, konflikty v LDS a zber profilerových čítačov.1

Mechanizmus optimalizácie

AMD osobitne rozoberá architektonické rozdiely medzi GPU generáciami. Podľa blogu majú MI350 a MI355 (gfx950/CDNA 4) viac LDS na výpočtovú jednotku než MI300 a MI325 (gfx942/CDNA 3), pridávajú špecializované inštrukcie na transpozíciu pri načítaní z LDS do registrov a zavádzajú nové varianty MFMA s vyššou priepustnosťou než staršie inštrukcie uvedené pre predchádzajúcu generáciu.1

Dôležitý praktický detail sa týka poradia operandov pri QK výpočte. AMD tvrdí, že na gfx942 môže použitie K ako operandu A a Q ako operandu B vytvoriť rozloženie fragmentov vhodné pre nadväzujúci výpočet P×V, čím sa dá odstrániť transpozícia pravdepodobnostného fragmentu cez LDS, synchronizačná bariéra aj súvisiaca LDS prevádzka.1 To je konkrétny mechanizmus, nie všeobecný sľub: blog opisuje, kde sa má optimalizácia prejaviť a prečo.

Debug, profiling a integrácia

AMD odporúča použiť implementáciu v Tritone ako referenčný baseline správnosti a porovnávať medzivýsledky, napríklad výpočet log-sum-exp alebo stav pred a po registrových operáciách, ako sú permutácie a XOR redukcie.1 Pri analýze generovaného kódu blog uvádza premenné prostredia na dump IR a finálneho ISA a menuje metriky, ktoré majú vývojári sledovať: počet VGPR a AGPR, veľkosť LDS či prípadné spills do pamäte.1

Na výkon AMD odporúča použiť rocprofv3 a konkrétne hardvérové čítače pre L2 cache, HBM prevádzku, vyťaženie MFMA, aktivitu VMEM a LDS aj konflikty bánk v LDS.1 Pri integrácii s graph capture zároveň upozorňuje, že keďže FlyDSL používa JIT kompiláciu, kernel treba aspoň raz spustiť pred začiatkom graph capture.1

Čo z toho vyplýva a čo nie

Praktický význam blogu je v tom, že dáva vývojárom ROCm pomerne konkrétny rámec, ako postupovať pri vlastnom attention kerneli pre diffusion workloady: od baseline správnosti až po profilovanie nízkoúrovňových úzkych miest.1 Zároveň však treba zachovať odstup od tvrdení výrobcu. AMD síce píše, že takýto workflow testovalo s LLM agentom a že výsledná implementácia „fungovala dobre“, no v texte nie sú zverejnené reprodukovateľné benchmarky, metodika merania ani nezávislé porovnanie s inými implementáciami.1

Preto ide o užitočný odborný rozbor postupu, nie o dôkaz dosiahnutého výkonu v širšej praxi.1