It's mind blowing seeing these multi exaflop single rack systems.
The world's first exaflop supercomputer was Frontier. It was launched only 4 years ago in 2022.
It's not a fair comparison of course. FP4 in Helios barely qualifies as floating point. Frontier was proper fp64, 16 times the bit width and probably 256x as many transistors.
> The basic GCN microarchitecture underpinned every single one of AMD’s compute accelerators for nearly 15 years [...]. With CDNA5 AMD has moved over to a microarchitecture that is based on the RDNA series putting a bookend to the long-lived line that was the GCN microarchitecture.
So everything is new again. Will this be another "buy now, have ROCM work in 3 maybe years if you are lucky"?
At least going forward, with both AMD's AI accelerators and Consumer GPUs using the same RDNA based IP, there will be less reason for AMD to drop RDNA GPUs from the ROCm/HIP support matrix! And so with both MI series accelerators and consumer GPUs/Graphics all using the same basic RDNA Micro-Architecture the ROCm/HIP code base developed for "CDNA5"/later will work for consumer RDNA as well with minor changes required! Polaris and Vega GPUs/Graphics both have been dropped from the ROCm/HIP support matrix. But with AMD's "The Rock" software stack making use of SPIR-V in the same manner as Nvidia/PTX there made be little issues getting that to work with older Vega/Polaris GPUs. even if AMD's not validated/verified that software stack with Consumer Vega/Earlier Consumer GPUs and Integrated Graphics. AMD's biggest issue has been dropping its older GPU micro-architectures from the ROCm/HIP support matrix too soon, and just look at Blender 3D's HIP Back End that requires RDNA2/Later GPUs and Graphics for any Radeon iGPU/dGPU Accelerated Blender 3D Cycles rendering support!
but you have to rewrite all your software to ROCm. And ROCm, to this day, still sucks.
ZLUDA basically crash on high memory demand, and only accounted for ~70% of CUDA API coverage (and it is still buggy).
But hey, at least it does run on Rust-CUDA. I'm one of the few who ported it and fixed a few bugs on ZLUDA. I used it to run a simple SHA256 kernel and it ran sure, but I gave it up because of those fundamental problems on AMD GPUs. You can't believe how messy ROCm is. I wonder if Vulkan compute kernel using SPIR-V would be a better choice.
> I think the thing that we were thinking about originally was whenever we're bringing up a new hardware platform, it's a big effort. It's like a huge thing. And so as we were thinking about this, we started doing our own evaluation of MI 355. You guys generously got us a rack to start working. And we expected this to be kind of a big process.
> Our actual experience was we had one engineer who start doing it. They spun up Claude, asked it, hey, bring up this machine, left it going over the weekend. And we ended up with a graph of the actual performance of our leading model on it, just going up and up and up over the weekend.
Using AI slop in software that runs ML models is like buying a Ferrari with a motorbike engine. Might be good for demos or as a proof of concept, but that can’t be used for serving LLMs at scale
It's mind blowing seeing these multi exaflop single rack systems.
The world's first exaflop supercomputer was Frontier. It was launched only 4 years ago in 2022.
It's not a fair comparison of course. FP4 in Helios barely qualifies as floating point. Frontier was proper fp64, 16 times the bit width and probably 256x as many transistors.
All the same just wow. Much compute.
> The basic GCN microarchitecture underpinned every single one of AMD’s compute accelerators for nearly 15 years [...]. With CDNA5 AMD has moved over to a microarchitecture that is based on the RDNA series putting a bookend to the long-lived line that was the GCN microarchitecture.
So everything is new again. Will this be another "buy now, have ROCM work in 3 maybe years if you are lucky"?
At least going forward, with both AMD's AI accelerators and Consumer GPUs using the same RDNA based IP, there will be less reason for AMD to drop RDNA GPUs from the ROCm/HIP support matrix! And so with both MI series accelerators and consumer GPUs/Graphics all using the same basic RDNA Micro-Architecture the ROCm/HIP code base developed for "CDNA5"/later will work for consumer RDNA as well with minor changes required! Polaris and Vega GPUs/Graphics both have been dropped from the ROCm/HIP support matrix. But with AMD's "The Rock" software stack making use of SPIR-V in the same manner as Nvidia/PTX there made be little issues getting that to work with older Vega/Polaris GPUs. even if AMD's not validated/verified that software stack with Consumer Vega/Earlier Consumer GPUs and Integrated Graphics. AMD's biggest issue has been dropping its older GPU micro-architectures from the ROCm/HIP support matrix too soon, and just look at Blender 3D's HIP Back End that requires RDNA2/Later GPUs and Graphics for any Radeon iGPU/dGPU Accelerated Blender 3D Cycles rendering support!
Arguably this might reduce it, because now ROCm won't be prioritised for the GCN-based systems?
I guess I submitted the link at the wrong time or something.
432 GB of RAM per chip. Tens of terabytes per rack. Clients queuing up to buy them.
RAM prices are not coming down any time soon.
Hey, they are only projected to cost about $5.5million a rack. Pocket change, really
Did anyone think RAM prices were coming down soon?
Of course. Wishful thinking is a true staple of human intelligence.
but you have to rewrite all your software to ROCm. And ROCm, to this day, still sucks.
ZLUDA basically crash on high memory demand, and only accounted for ~70% of CUDA API coverage (and it is still buggy).
But hey, at least it does run on Rust-CUDA. I'm one of the few who ported it and fixed a few bugs on ZLUDA. I used it to run a simple SHA256 kernel and it ran sure, but I gave it up because of those fundamental problems on AMD GPUs. You can't believe how messy ROCm is. I wonder if Vulkan compute kernel using SPIR-V would be a better choice.
Co-founder and Chief Compute Officer Anthropic:
> I think the thing that we were thinking about originally was whenever we're bringing up a new hardware platform, it's a big effort. It's like a huge thing. And so as we were thinking about this, we started doing our own evaluation of MI 355. You guys generously got us a rack to start working. And we expected this to be kind of a big process.
> Our actual experience was we had one engineer who start doing it. They spun up Claude, asked it, hey, bring up this machine, left it going over the weekend. And we ended up with a graph of the actual performance of our leading model on it, just going up and up and up over the weekend.
https://x.com/austinsemis/status/2080336781782753635
Using AI slop in software that runs ML models is like buying a Ferrari with a motorbike engine. Might be good for demos or as a proof of concept, but that can’t be used for serving LLMs at scale