Elke paar jaar verschijnt er een nieuwe oplossing die dezelfde droom belooft:
- behoud uw CUDA-codebase
- richt u op AMD (en eventueel andere accelerators)
- geen herschrijving van de bron
- geen HIP-porting
- “natieve prestatie”
Op papier klinkt dat perfect. Neem uw bestaande CUDA-applicaties, verwissel de toolchain en plotseling bent u ‘draagbaar’.
En eerlijk is eerlijk: als u onderzoekscode uitvoert of een interne tool op niet-NVIDIA-hardware wilt compileren, kan dat absoluut nuttig zijn.
Maar als u belang hecht aan echte prestaties op AMD, het soort prestaties dat:
- latency verlaagt,
- benchmarks wint,
- elke TFLOP uit accelerators van de MI***-klasse haalt,
- en mensen na één slecht experiment niet “terug naar NVIDIA” stuurt,
dan is een universele CUDA-compatibiliteitslaag de verkeerde langetermijnstrategie.
Niet omdat de ingenieurs achter deze toolchains niet slim zijn (dat zijn ze wel), maar omdat CUDA-first-compilatie altijd zal achterlopen op wat AMD native beschikbaar maakt via ROCm, HIP en door leveranciers afgestemde bibliotheken.
Waarom deze aanpak zo aantrekkelijk is
Deze pitches zijn buitengewoon overtuigend:
"Ontwikkel uw applicatie één keer met CUDA en implementeer deze op verschillende GPU-platforms."
Concreet doen deze toolchains meestal zoiets als dit:
- Zorg voor een nvcc-compatibele compiler die bestaande CUDA-code accepteert, soms inclusief inline PTX.
- Richt zich via LLVM-backends op AMD-GPU's in plaats van op de stuurprogramma's van NVIDIA.
- Implementeer de CUDA-runtime-, driver- en wiskundige API's boven op AMD's ROCm-stack.
- Lever wrapperbibliotheken die CUDA-X-API's (bijvoorbeeld cuBLAS/cuSOLVER) koppelen aan rocBLAS/rocSOLVER en vergelijkbare libraries.
- Onderhoud validatiesets waarin bekende CUDA-projecten worden gecompileerd en uitgevoerd op AMD-hardware.
Vanuit het perspectief van een ontwikkelaar voelt het magisch:
# Op NVIDIA
nvcc my_app.cu -o my_app_nvidia
# Op “alles”
nvcc my_app.cu -o my_app_other_gpu
Voor bestaande, sterk op CUDA gebaseerde HPC-code waarvoor een herschrijving naar HIP, SYCL of ROCm bijzonder ingrijpend zou zijn, is dit een goede optie.
Maar dat gebruiksvoorbeeld is heel anders dan:
"We willen state-of-the-art LLM-inferentie en trainingsprestaties op AMD, vergelijkbaar met of beter dan NVIDIA"
Dat is een fundamenteel ander probleem.
CUDA-semantiek ≠ AMD-semantiek
CUDA is ontworpen rond NVIDIA's hardwaremodel, met warps, een specifieke geheugenhiërarchie, intrinsics, PTX en CUDA-X-libraries. Een NVIDIA-warp telt 32 threads.
De AMD-architectuur werkt anders: op CDNA/GCN (Instinct-klasse) telt een wavefront 64 work-items. AMD ROCm-documentatie RDNA voor consumenten introduceerde een native wave32-modus, maar CDNA voor datacenters blijft wave64. Wikipedia
Als AMD vanaf dag één had besloten om CUDA-native hardware te bouwen, zou het leven er heel anders uitzien. Maar dat is niet de realiteit: AMD koos zijn eigen architectuur, softwarestack en optimalisatiepaden.
Moderne AMD-richtlijnen spreken expliciet over MI***-specifieke optimalisatie: kernelvormen, geheugentegels, GEMM-afstemming en precisiekeuzes afgestemd op de sterke punten van CDNA.
Als u CUDA als ‘bron van de waarheid’ neemt, vraagt u een vertaallaag om:
- CUDA te parsen, vaak inclusief inline PTX.
- De code om te zetten naar een IR zoals LLVM.
- Die IR te vertalen naar AMD's ISA en ROCm-stack.
- Code te genereren die kan concurreren met AMD-first kernels en libraries die specifiek voor ROCm zijn gebouwd.
Dat legt de lat bijzonder hoog.
Concreet voorbeeld #1, 32 versus 64 threads per warp of wavefront
- NVIDIA: warp = 32 threads.
- AMD CDNA/GCN: wavefront = 64 work-items.
Als de control flow, synchronisatie of geheugencoalescentie van een kernel impliciet op warp32 is afgestemd, kan een ongewijzigde uitvoering op wave64 rekenlanen onbenut laten. Ook kan de compiler of runtime extra masking en shuffles moeten toevoegen, wat de effectieve throughput vaak verlaagt. Met andere woorden: dezelfde kernel kan alleen al door een verschillende uitvoeringsbreedte tot ongeveer een factor twee onder de piek blijven, nog voordat cachegedrag of matrixbewerkingen een rol spelen. AMD-ontwikkelmateriaal benadrukt dat wave64 andere eigenschappen heeft voor resourcegebruik en occupancy dan wave32. gpuopen.com
Compileren alleen garandeert geen prestaties
Op papier zeggen deze toolchains vaak:
- “Compilatie vooraf, geen emulatie.”
- “Geen inherente overhead versus native paden.”
Voor sommige soorten toepassingen (klassieke, op CUDA afgestemde HPC zonder volwassen ROCm-poorten) kan dat redelijk waar zijn.
Maar bij moderne AI op AMD hangen prestaties af van veel meer dan alleen CUDA-syntaxis die succesvol compileert:
- Gefuseerde kernels ontworpen voor AMD's wavefront-, cache- en geheugensysteem.
- GEMM-afstemming over BF16/FP16/FP8 met AMD's bibliotheekpaden en MFMA-vormen.
- FP8-ondersteuning: gewichten en activaties kwantiseren voor AMD's FP8-formaten (E4M3/E5M2), plus FP8 KV-cache, schalingsbeleid en dataverpakking, geïntegreerd in frameworks zoals vLLM.
- Tensor-parallellisme en communicatie afgestemd op MI***-klasse topologie en ROCm-collectieven.
Dit zijn technische keuzes die vanuit AMD worden ontworpen. Een generieke vertaling van CUDA-front-end naar AMD-back-end levert die optimalisaties niet vanzelf op.
Concreet voorbeeld #2, FP8 is niet plug-and-play
Op AMD CDNA3 (MI300-klasse) gebruikt FP8 de E4M3/E5M2-formaten met de bijbehorende schaling en dataverpakking. AMD ROCm-documentatie Om LLM's efficiënt in FP8 uit te voeren, volstaat het niet om CUDA-code te compileren. Doorgaans moet u gewichten voorbewerken of kwantiseren en FP8 KV-cache en activaties inschakelen via AMD-specifieke workflows. De Quark-kwantisatietutorials en vLLM-handleidingen voor FP8 tonen bijvoorbeeld de expliciete stappen en configuratie om de snelle uitvoeringspaden te gebruiken. VLLM Docs+3AMD ROCm Documentation+3rocm.blogs.amd.com+3
Als een vertaalstack ontbrekend FP8-gedrag moet emuleren of terugvalt op niet-optimale verpakking/schaling, wordt het "draagbare" pad snel meetbaar langzamer dan AMD-native FP8-inschakeling.
Hoe wij het aanpakken (Paiton)
Dit is precies waarom we bij Eliovp de tegenovergestelde aanpak hebben gekozen met Paiton.
Paiton werd en wordt in de eerste plaats voor AMD gebouwd, niet als bijproduct van een CUDA-vertaler. Wij:
- werken rechtstreeks op ROCm/HIP,
- integreren met vLLM/SGLang in plaats van ze te vervangen,
- schrijven en tunen aangepaste kernels voor hardware van de MI***-klasse,
- combineren bewerkingen, tunen GEMM's en optimaliseren FP8-datapaden,
- optimaliseren tensorparallellisme en communicatie voor AMD-interconnects en -topologieën.
In ons openbare werk verslaat MI300X + Paiton de nieuwere NVIDIA-setups in echte LLM-inferentie terwijl u uw bestaande enginestack behoudt. Dat is het punt: een compatibiliteitslaag probeert AMD zich te laten gedragen als “CUDA-compatibele hardware”; Paiton onderzoekt wat AMD eigenlijk is en haalt er meer uit.
Kan een vertaalstack dat evenaren voor FP8, MoE, TP en echt verkeer? Alleen door diezelfde AMD-specifieke inspanning blijvend in de vertaler te implementeren.
Het ecosysteemrisico: slechte eerste indrukken
Typisch patroon:
- Een team met een CUDA-codebase probeert een kant-en-klare compatibiliteitstool voor AMD.
- Het team voert LLM- en visionworkloads uit en ziet suboptimale cijfers ten opzichte van de NVIDIA-basislijn.
- Interne conclusie: "We hebben AMD geprobeerd. Het is langzamer."
Ze controleren zelden of:
- de laag snelle AMD FP8-paden of de juiste kwantisering gebruikte,
- ROCm-native kernels betere prestaties zouden hebben geleverd,
- de frameworkdocumentatie andere AMD-specifieke flags aanbeveelt.
Ze zien alleen een dashboard. Het resultaat geldt dan als “bewijs” dat AMD langzamer is, zelfs wanneer AMD-first-stacks het tegenovergestelde laten zien.
De onderhoudsmolen
Om gelijke tred te houden met AMD-native tooling, moet een “CUDA-overal”-laag voortdurend:
- ROCm-releases volgen (nieuwe FP8-paden, GEMM-verbeteringen, bibliotheekupgrades), AMD ROCm-documentatie+1
- nieuwe Instinct-GPU's en hun tuningopties volgen, AMD ROCm Documentatie+1
- vergelijkbare technieken overnemen die in vLLM voor AMD verschijnen, zoals FP8 KV-cache en attentionbackends, VLLM Docs+1
- en compatibel blijven met de evoluerende CUDA-semantiek.
Dat is een onderhoudsintensieve, reactieve positie, altijd één stap verwijderd van de plaats waar AMD en zijn partners optimalisaties als eerste uitbrengen.
Waar deze tools wel zinvol zijn, met een kanttekening over consumenten-GPU's
- Grote bestaande CUDA/HPC-codebases die u snel werkend wilt krijgen.
- Functionaliteitsvalidatie tijdens het plannen van een goed ROCm/HIP-pad.
- Consumenten-/gaming-GPU's: RDNA introduceerde native wave32, in lijn met de warpbreedte van CUDA. Voor desktopgebruikers, waar de ROCm-installatie lastiger kan zijn of officieel beperkt kan zijn, kunnen deze lagen een pragmatische brug vormen voor experimenten.
Dit is een redelijk instappunt. Het is alleen niet de manier om te tonen wat AMD Instinct-hardware werkelijk met LLM's kan.
Waar het op neerkomt
We zeggen niet: "Gebruik nooit CUDA-op-AMD-compilers of CUDA-naar-HIP-vertalers".
We zeggen beoordeel AMD niet op basis daarvan.
Als u wilt zien wat AMD-GPU's daadwerkelijk voor AI kunnen presteren:
- gebruik AMD-first kernels en bibliotheken,
- voer ROCm-native tuning uit,
- configureer frameworks voor AMD FP8 en attentionbackends,
- kies parallellismestrategieën die passen bij de topologie van de MI***-klasse,
- werk met teams die vanaf het ontwerp voor AMD optimaliseren, niet via vertaling,
- of gebruik Paiton, waarin alle noodzakelijke optimalisaties zijn opgenomen.
Anders voegt u een compatibiliteitskost toe en geeft u de hardware de schuld van het resultaat. AMD heeft er niet voor gekozen een CUDA-kloon te zijn, en dat is prima.
Behandel AMD als een volwaardig platform met eigen sterke punten, en het resultaat zal u verrassen.
Dat is de stelling achter Paiton, en waarom we de verwachtingen blijven overtreffen met AMD-first engineering.