For most of the AI boom, access to a datacenter GPU like the AMD MI300X meant buying a rack or not touching it at all. Hot Aisle changes the unit of access from reserved compute to rented minutes. Per-minute allocation means a solo developer or small team can use the exact datacenter accelerators usually locked up by enterprise budgets. You no longer need to own the resource to use it. Hot Aisle is already running near capacity, proving the pent-up demand for by-the-minute datacenter GPU access.
This access works because you do not need the big card for development. The same vllm serve command runs the AMD box under your desk and the rented MI300X. Your client never knows which one responded. You can prototype on a $2,000 Strix Halo, then burst to a rented MI300X for the minutes you need it. This is how a small team de-risks a six-figure GPU order. The same vLLM stack runs on both. The engine, model definitions, and the API remain identical, and that API speaks OpenAI, Ollama and Anthropic on the same surface. You only re-tune the performance recipe for the bigger hardware.
AMD’s hardware line runs from consumer RDNA to datacenter CDNA. On the RDNA side, you have the Radeon and Strix Halo class. On the CDNA side, you have the shipping MI300X and MI355X, with the MI400 series arriving in the second half of 2026. The MI455X leads that family on CDNA 5, with 432 GB of HBM4 and 19.6 TB/s of memory bandwidth; the MI450 is the volume part beneath it at a lower power envelope. Same engine, same API, more room. NVIDIA’s cheap on-ramp, the DGX Spark, is an ARM/Grace box scaling into x86 datacenter CUDA. AMD does not have an equivalent seam here.
We did not just theorize this bridge. We built the datacenter end and shipped it upstream. The llama.cpp gfx942 enablement merged into Lemonade on July 8th as the first CDNA contribution. Lemonade now serves models on an MI300X. The vLLM backend is conflict-resolved and mergeable. The last real friction just lifted because AMD published a CDNA vLLM wheel that fits against its leading-edge TheRock ROCm build, making the install path a repackage rather than a compile.
The short version
One engine. The code, model definitions, and API transfer between architectures unchanged. You only re-tune the performance recipe per architecture: precision, kernels, and parallelism. You develop cheap on RDNA, then burst to CDNA by the minute for heavy workloads. The case study below is a real port done on a rented MI300X, not a synthetic benchmark table.
The bridge
vLLM’s AMD support matrix lists both worlds. The MI300X and MI355X sit alongside the RX 7900, RX 9000 Radeons, and the Ryzen AI MAX APUs. You get one engine, one API surface that speaks OpenAI, Ollama and Anthropic, and day-0 Hugging Face checkpoints. This shared surface is the basis for prototyping locally and deploying remotely.
What carries over, and what you re-tune
What carries over unchanged: the vLLM engine, the model definitions, the OpenAI, Ollama and Anthropic endpoints, and Hugging Face checkpoints. If it runs on the Radeon, the behaviour and API are the same on the MI300X.
Precision. The re-tune is a staged quality experiment, and quantization is what makes the cheap end of it affordable. A GGUF runs a large model in a small memory footprint, so you can measure a model’s quality on hardware you already own before renting a datacenter card. A single Strix Halo tops out at 128 GB of unified memory. Cluster a few RDNA boxes and that ceiling lifts, which means the model you validate locally can be the model you actually intend to serve.
The ladder has three rungs. First, prototype quality with a GGUF on the small box to get a real perplexity reference. Second, validate the API surface at FP16 on the same Strix Halo to prove the integration, prompts, and tool calls behave. Third, deploy at low precision on the datacenter card. FP8 on the MI300X; FP4 on the MI355X, where CDNA4 adds it. A gfx1151 APU supports neither. The point of the first rung is that you establish a quality reference on hardware you already own, for pennies, before you rent anything. We are not going to tell you how an FP8 deployment compares to your Q4_K_M reference, because we have not measured it. FP8 carries more bits than a Q4_K_M quant, so we would not expect it to be worse, but an expectation is not a number and we are not publishing it as one. Measure your own delta on the rented card; that is a cheap experiment, and it is the one that matters to you.
Kernels. You run with eager execution on the Strix Halo today due to a HIP-graph capture bug. On CDNA, you turn that off and pick up the AITER kernel family.
Parallelism. On the Strix Halo, you answer one question: does the process produce the right result reliably for a single user? The datacenter card answers a different question: can that same process run for a thousand people at once? Tensor-parallelism, sequence limits, and prefix caching turn a one-user workflow into a service. The 192 GB of HBM and the 5,300 tokens per second we measured on the AITER path let a single-user process execute concurrently for the entire corporation. The code and API stay the same. The re-tune is the difference between a desk-side demo and a fleet-wide capability. The leverage lives in that re-tune.
The case study: building the CDNA port on rented hardware
To bring Lemonade’s vLLM backend to datacenter AMD, we did the work on a rented Hot Aisle MI300X.
The runtime divergence between a consumer APU and a datacenter GPU was about fifty lines of launch-flag conservatism to undo. The eager execution, fixed KV-cache cap, and kernel forcing made sense for a 16-to-32 GB APU, but were wrong for 192 GB of HBM. AMD publishes matched CDNA wheels against TheRock in the same channels Lemonade uses. The fear of forking and patching vLLM evaporated on contact. The repackaging layer is a clean repackager, not a patch set.
Hot Aisle supplied the one piece we did not own, the datacenter card, by the minute. The entire CDNA build plus hardware validation cost less than lunch in on-demand MI300X time. We tore down the instance between runs. You rent the datacenter card for the minutes you need, maintaining the same data privacy posture as the box under your desk. CDNA validation is a lunch-money experiment anyone can reproduce.
It ran. On real MI300X hardware, llama.cpp served a small Qwen model at roughly 500 tokens per second. We shipped that one upstream too, out of the same lunch money. It means your GGUFs now run on the enterprise GPU as well, so the quantized model you validated on the box under your desk is the same artifact the datacenter can serve. On the vLLM side, an FP8 plus speculative-decoding recipe on a 27B model reached about 80% draft acceptance. The AITER fused mixture-of-experts path topped out around 5,300 tokens per second at concurrency 256. These are the rented card’s real results.
One line, on Ubuntu
Here is what standing up vLLM on a datacenter AMD card used to cost you. Build ROCm against a matching kernel. Resolve the PyTorch version that agrees with both ROCm and vLLM. Compile vLLM from source. Discover a transitive dependency has moved. Repeat. Most teams lose a week to this before they serve a single token, and the result is a machine nobody else can reproduce.
On Hot Aisle you can skip much of that today. They deliberately keep pre-installed software to a minimum, for supply-chain reasons we think are the right call, and instead publish cloud-init templates that stand a machine up the way you want it. That beats a fat image, because you get a reproducible recipe instead of someone else’s dependency decisions baked into a disk.
But a template that builds a vLLM stack is still a script for the same reconciliation, and the reconciliation is the hard part. AMD’s vLLM container repository carries around thirty-four tags. To use it you have to pick the one that matches your architecture and your ROCm version and your Python and your PyTorch and your vLLM, and then pick again every time AMD moves. The complexity has been automated. It has not been removed, and somebody still has to know all of it.
Worse, scripted complexity does not just persist. It rots quietly. A template that pins a floating tag keeps working while the image underneath it drifts, and nothing announces the drift. The script still runs. It simply stops meaning what it meant when it was written.
Two things changed that. AMD now publishes a CDNA vLLM wheel that fits against its leading-edge TheRock ROCm build, which turns the gfx942 asset from a source compile into a repackage. Wire that asset into a Lemonade release and the entire serving stack arrives as a signed Debian package:
apt install lemonade-server
Which is what we want to contribute back. The cloud-init template stops being a build script and becomes that line. The template is written and it is four lines long. We are holding the pull request until a Lemonade release carrying the CDNA support reaches the package archive, because until then the template would install a server that does not recognise the card. A template that is broken on arrival is worse than no template, particularly in someone else’s repository.
The install command is the small part. What matters to an enterprise is where that install lands, and it lands inside the strict dependency graph of a Debian-based distribution. Change management does not ask whether you can install it. It asks what is deployed, whether you can reproduce it byte-for-byte, and whether you can stage, validate and roll it back on a schedule. A pip install of a vLLM wheel fails those questions on unpinned transitive dependencies and PyTorch conflicts. A Debian package answers all of them: the fragile ROCm, PyTorch and vLLM web is resolved once, pinned and signed, and the inference stack inherits the same apt-driven discipline as the rest of the estate.
That is the whole move. It takes vLLM-on-CDNA out of a data scientist’s environment and puts it into a managed dependency graph, which is the difference between something one person can run and something a change-management board will approve for the organization.
The people behind it
We build on other people’s work. The Lemonade maintainers carried the ground this stands on. Ramakrishnan Sivakumar at AMD authored the original vLLM backend, and Jeremy Fowers led the refactor. The CDNA pull requests were reviewed by fl0rianr and merged by superm1.
The Radeon side leans on the llama.cpp Vulkan backend, the long-running work of 0cc4m. Our RDNA recipes are migrating to it based on two independent measurements. Leonard Lin published HIP-versus-Vulkan numbers on the Strix Halo showing Vulkan winning decisively on throughput and by roughly 20% on real-world decode. Piotr Wilkin found a build flag in the ROCm path that wrecks long-context prefill on the same hardware, with a fix already in flight.
Where this leaves you
For a team weighing a six-figure AMD purchase, the $2,000 box is the cheapest insurance policy they will buy this year. They can prototype the workload, validate it, and rent the datacenter card by the minute to confirm it scales.
For a leader, this demonstrates an organization that ships upstream and de-risks infrastructure bets before signing the order. AMD’s RDNA-to-CDNA line is only one road. Lemonade’s constant API surface, speaking OpenAI, Ollama and Anthropic, carries you across the hardware map. With recent Apple support, a developer can start on a MacBook and travel to CUDA in the datacenter without the application noticing the API change. Crossing from macOS to Linux and NVIDIA gives up some apt-driven tidiness, but it is a road to the enterprise, and many businesses already stand on it.
If you want AI capability that is local-first, honest about tradeoffs, and cheap to prove, we should talk.
***
