How to Rent an AMD MI300X in 2026: Who Actually Has Them, What They Cost, and What Really Runs

If you want to rent an AMD MI300X, the hard part isn't the hardware, it's that half the vendors selling it won't publish a price and the other half quote numbers that differ by 7x for the same chip. Meanwhile every spec comparison you'll read gets the compute numbers wrong in AMD's disfavor, because NVIDIA's headline TFLOPs and AMD's headline TFLOPs are not measuring the same thing. I build the infrastructure layer under rented GPU boxes, so I went and pulled every number in this post from the vendor's own page on August 4, 2026. Where a vendor wouldn't show me a price, I've said so instead of repeating an aggregator's guess.

TL;DR: The MI300X has 192GB of HBM3 at 5.325 TB/s — more memory and more bandwidth than an H100 SXM (80GB, 3.35 TB/s) or an H200 (141GB, 4.8 TB/s). Verified on-demand rates run $1.71/GPU/hr (TensorWave) and $2.99/GPU/hr (Hot Aisle) at the specialist end, up to $6.00–$12.00/GPU/hr on Azure. It's the cheapest way to fit a 70B model in fp16 on a single GPU. The real risk isn't performance, it's whether your stack has a CUDA dependency that doesn't have a ROCm build.

The memory story, which is the whole reason to care

A single MI300X carries 192GB of HBM3 with 5.325 TB/s of bandwidth, on 304 compute units of CDNA 3 architecture, rated at 750W in its OAM form (AMD MI300X product page). It's normally sold as an 8-GPU platform on a UBB 2.0 baseboard totalling 1.5TB of HBM3 (AMD MI300X Platform).

Against NVIDIA's own published specs:

NVIDIA figures from the H100 and H200 product pages; AMD figures from AMD's product page and datasheet.

That table probably looks wrong to you, because you've read a dozen articles saying the H100 beats the MI300X on FP16. Here's why they say that.

The sparsity trap that makes every comparison wrong

NVIDIA's spec table lists H100 SXM at "1,979 teraFLOPS" for FP16 Tensor Core — with an asterisk. Scroll to the footnote on NVIDIA's own page and it reads, in full: "With sparsity." Every starred row on that table (TF32, BFLOAT16, FP16, FP8, INT8) is a 2:4 structured-sparsity number, which means it assumes half your weights are zeroed in a specific hardware-friendly pattern. Dense throughput — what you get running an ordinary model that hasn't been sparsified — is half that. So H100 SXM dense FP16 is 989 TFLOPS, not 1,979.

AMD's headline 1,307.4 TFLOPS for MI300X FP16 is a dense number. AMD quotes its sparsity figure separately (FP8 goes from 2,614.9 dense to 5,229.8 with sparsity).

So the comparison that circulates everywhere — AMD's dense 1,307 against NVIDIA's sparse 1,979 — compares two different measurements and concludes the H100 is 50% faster. Compare like for like and the MI300X leads on dense FP16 by about 32% and on dense FP8 by about 32%, on top of leading on memory capacity and bandwidth.

This is not an argument that the MI300X is a faster chip in practice. Real throughput is a software problem, and NVIDIA's software is more mature — that's the honest tradeoff and I'll get to it. It is an argument that if you dismissed the MI300X because the spec sheets looked bad, you dismissed it on a footnote you didn't read.

What 192GB actually buys you

Memory capacity is the least glamorous spec and the one most likely to decide whether a job runs at all.

A 70B-parameter model in fp16 needs roughly 140GB just for weights. On a single MI300X that fits, with ~50GB left for KV cache and activations. On an H100 you need two GPUs and a tensor-parallel split; on an H200 (141GB) you're at the line before you've stored a single token of context.

That single fact drives most MI300X adoption. Going from two GPUs to one removes the tensor-parallel communication path entirely, which for memory-bound autoregressive decoding is often where the latency was hiding. It also halves your unit of rental — you can rent 1x MI300X where you'd have needed 2x H100, which changes the price comparison well before you look at the hourly rate.

At the 8-GPU node level, 1.5TB of HBM3 puts a 405B model in fp8 (~405GB of weights) comfortably in memory with room for large batches.

The successors extend the same lead: the MI325X ships 256GB of HBM3E at 6.0 TB/s (AMD, October 2024), and the MI355X moves to CDNA 4 with 288GB of HBM3E, roughly 8 TB/s, and native FP6/FP4 support (AMD, June 2025).

Who actually rents MI300X, and for how much

Every price below came off the vendor's own page or API on August 4, 2026. Where a vendor wouldn't show one, that's recorded as-is rather than filled in from a third party.

Azure figures come from Microsoft's own Retail Prices API, which is the authoritative source and returns per-VM rates for the 8-GPU SKU; the per-GPU numbers above are that rate divided by 8. Region spread is real and large — the same VM is exactly twice the price in Brazil South as in East US 2, so region selection is worth more than most negotiation.

Two things worth naming about this table. First, the spread between the cheapest specialist and the most expensive hyperscaler region is about 7x for an identical chip. Second, three of the seven vendors won't publish a number at all, which is itself the signal: MI300X supply is still sold heavily through sales conversations rather than a checkout button, and public pricing is a competitive act.

Ignore the $1.99/hr Vultr figure that circulates on comparison sites. I couldn't retrieve a price from Vultr's own page, and a number nobody can point to on the vendor's site isn't a price, it's a rumour.

The part that actually decides it: does your stack run?

Hardware is the easy half. The question that should drive your decision is whether your dependency tree has a CUDA-only link in it.

What works well. ROCm is on the 7.2.x production line, with MI300X (gfx942) and the MI350 series (gfx950) both listed in AMD's compatibility matrix. PyTorch treats ROCm as a first-class backend on its official install matrix, and AMD publishes a maintained rocm/pytorch image as a Docker Hub verified publisher. vLLM has a documented ROCm install path, and AMD mirrors its own vLLM on ROCm guide. If your workload is "serve a Hugging Face model with vLLM" or "fine-tune with stock PyTorch," you are on a well-trodden path.

What's a real cost. Custom CUDA kernels need porting through AMD's HIPIFY tooling, and AMD's own docs are clear that translation isn't fully automatic for performance-tuned code or anything leaning on an unsupported CUDA library. Budget engineering time, not an afternoon.

What to check before you commit. flash-attention on ROCm lives in AMD's fork rather than upstream, so verify the specific variant your model needs is present. bitsandbytes is the one that bites hardest: Hugging Face's installation docs classify ROCm support as experimental/preview rather than official, requiring ROCm 6.4+ and a manual HIP build. If your workflow is built on bitsandbytes 4-bit quantization, that's the dependency most likely to stall you — and note the irony that with 192GB you often don't need aggressive quantization in the first place.

I could not find current first-party documentation on xFormers or DeepSpeed ROCm support, so I'm not going to claim either way. Check them against your own model before you book a month of compute.

The practical rule: spend an hour on a rented MI300X testing your actual imports before you commit to anything longer. By-the-minute billing on a 1x VM makes that test cost roughly the price of a coffee, and it answers the only question that matters far better than any blog post can.

When the MI300X is the right rental

Rent one when your bottleneck is memory rather than raw math: serving a 70B-class model where fitting on one GPU removes a tensor-parallel hop, long-context inference where KV cache is eating your capacity, or batch inference where more resident memory means bigger batches. Rent one when the H100 supply in your region is gone and the job needs to run this week — availability is a legitimate reason on its own, and MI300X capacity is frequently sitting idle while people queue for NVIDIA.

Don't rent one when you have hand-written CUDA kernels you can't afford to port, when your pipeline depends on a library whose ROCm support is preview-grade, or when you need a specific NVIDIA-only feature. And don't rent one purely on the sticker price without checking region — an MI300X in the wrong Azure region costs more than an H100 almost anywhere.

The lock-in problem nobody mentions

Here's the thing that makes AMD rentals awkward in practice, and it isn't AMD's fault.

Because so few providers carry MI300X, the moment you build your environment on one you've narrowed your escape routes to a handful of vendors — and if the cheapest MI300X capacity moves, or your provider runs out, rebuilding a working ROCm environment somewhere else is a genuinely painful afternoon. The ROCm stack, the patched flash-attention build, the pinned library versions you fought to get working: none of that is in your checkpoint. It's on the box.

That's the problem we work on. Rather than rebuilding the environment on each new provider, the approach is to snapshot the whole box — filesystem, environment, installed packages at their exact versions, model files at their real paths — and restore it on whatever provider has capacity. We've written up the general version in our guide to moving a GPU workload to another cloud provider and the mechanics in snapshot and restore across providers. It matters more on AMD than on NVIDIA precisely because the ROCm environment took more work to get right.

Aquanode brokers MI300X capacity through Hot Aisle, and because rates move we don't quote a number here — the live figure is on the marketplace and the pricing page, alongside NVIDIA options if you want to compare cost-per-GB-of-VRAM rather than cost-per-hour.

FAQ

How much does it cost to rent an MI300X per hour? Verified published rates on August 4, 2026 range from $1.71/GPU/hr (TensorWave, "starting at") and $2.99/GPU/hr (Hot Aisle VMs) up to $6.00–$12.00/GPU/hr on Azure depending on region. Several vendors, including Vultr and Crusoe, don't publish a price.

Is the MI300X faster than an H100? On paper it leads on memory (192GB vs 80GB), bandwidth (5.325 vs 3.35 TB/s), and dense FP16/FP8 throughput. In practice the gap narrows or reverses depending on how well-optimized your software path is on ROCm. It wins most clearly on memory-bound inference.

Can I run PyTorch and vLLM on an MI300X? Yes. ROCm is a first-class PyTorch backend with official install wheels and an AMD-maintained Docker image, and vLLM has a documented ROCm path. Stock model-serving and fine-tuning workflows generally work.

What won't work on an MI300X? Custom CUDA kernels need porting via HIPIFY, flash-attention comes from AMD's fork rather than upstream, and bitsandbytes ROCm support is documented as experimental rather than official. Test your imports on an hourly rental before committing.

Can I rent a single MI300X, or do I have to take all 8? Both exist. Hot Aisle sells 1x, 2x, and 4x VMs billed by the minute; the 8-GPU bare-metal node has a one-month minimum. Azure's ND MI300X v5 is an 8-GPU VM only.

How much model fits in 192GB? Roughly a 70B-parameter model in fp16 (~140GB of weights) with ~50GB left for KV cache — a size that needs two H100s. An 8-GPU node's 1.5TB holds a 405B model in fp8.

What I'd tell someone deciding today

If you're memory-bound and running stock PyTorch or vLLM, the MI300X is underrated and the specialist providers are pricing it well below the NVIDIA equivalent for the memory you get. Rent one by the minute, run your imports, and find out in an hour rather than arguing about spec sheets.

If you've got custom kernels or a quantization stack pinned to bitsandbytes, the port is real work and you should price that in honestly rather than discovering it on day three.

And whichever way you go, be careful about where the environment lives. The reason AMD capacity is cheap right now is that fewer people can be bothered to set it up — which is a great reason to rent one, and a terrible reason to leave the only working copy of that setup on a box someone else can reclaim.

About the author

I'm Ansh Saxena. I work on the infrastructure layer under rented GPU boxes — mostly the unglamorous problem of making a machine's whole state portable across providers, so a better price somewhere else doesn't cost you a rebuild. I don't have a horse in the AMD-versus-NVIDIA race; I do think a spec-sheet footnote shouldn't be the thing that decides which one you rent.

Sources

• AMD Instinct MI300X product page. 192GB HBM3, 5.325 TB/s, 304 CUs, CDNA 3, 750W; dense FP16 1,307.4 TFLOPS and FP8 2,614.9 TFLOPS.
• AMD Instinct MI300X Platform. 8-GPU UBB 2.0 baseboard, 1.5TB aggregate HBM3.
• AMD MI325X announcement and MI350 series blog. 256GB HBM3E at 6.0 TB/s; 288GB HBM3E at ~8 TB/s on CDNA 4.
• NVIDIA H100. 80GB, 3.35 TB/s; tensor-core rows marked "With sparsity" at 1,979 TFLOPS FP16 and 3,958 TFLOPS FP8, i.e. 989 and 1,979 dense.
• NVIDIA H200. 141GB, 4.8 TB/s, TDP up to 700W, same sparsity-footnoted tensor figures.
• Hot Aisle pricing, checked August 4, 2026. $2.99/GPU/hr VMs, $3.39/GPU/hr 8x bare metal with one-month minimum, $1.99 grandfathered.
• TensorWave MI300X, checked August 4, 2026. Starting at $1.71/GPU/hr.
• Azure Retail Prices API, checked August 4, 2026. Standard_ND96isr_MI300X_v5 Linux on-demand $48.00/hr (East US 2, West US 3) to $96.00/hr (Brazil South); spot from $8.87/hr.
• ROCm compatibility matrix, PyTorch install matrix, AMD vLLM on ROCm, HIPIFY, ROCm flash-attention, bitsandbytes installation.