AMD Instinct MI350X for LLM inference
CDNA 4 adds FP4 and FP6 and raises bandwidth to 8 TB/s. On eight MI350X, plow’s time per token grows 1.40 to 1.52 times from 1k to 128k context, against 1.9 to 2.9 times for vLLM. On GLM-5.3-Flash, plow’s p99 time to first token is 0.28 to 0.62 times vLLM’s in four of five cells, while vLLM leads on throughput.
Specs
- Architecture
- CDNA 4, 256 compute units
- Memory
- 288 GB HBM3E
- Bandwidth
- 8 TB/s
- BF16
- 2.3 PFLOPS (4.6 with sparsity)
- FP8
- 4.6 PFLOPS (9.2 with sparsity)
- FP4
- 9.2 PFLOPS (MXFP4)
- FP32
- 144.2 TFLOPS
- Power
- 1,000 W, passive cooling
- Launched
Peak figures as the vendor states them, from the AMD product page (checked 3 Nov 2026).
What fits
Weights take about 2 bytes a parameter in BF16 and 1 in FP8. 288 GB holds the weights of a model up to about 144B parameters in BF16, or 288B in FP8, on one card. The KV cache for each live request needs room on top, so long contexts and many requests need headroom.
Measured on the MI350X
Showing all results for throughput, all GPUs.
How to read the charts
plow wins shows workloads where plow leads on the selected metric. All results includes ties and vLLM wins. Each bar is one workload: right of parity, plow is ahead; left, vLLM is. Throughput counts input and output tokens. Latencies are displayed as speed ratios. Bars use a logarithmic scale capped at 4x; labels show the full ratio. The table shows all metrics for the same filtered workloads.
GLM-5.3-Flash on 8x AMD MI350X
No results match these filters. Choose another metric or GPU, or select All results.
Selected results as a table
| Model and GPU | Workload | Load | Throughput | First token | Per token | Latency stat |
|---|---|---|---|---|---|---|
| GLM-5.3-Flash, 8x AMD MI350X | 1,024 / 128 tokens | 8 requests | 0.91x | 0.36x | 0.82x | p99 |
| GLM-5.3-Flash, 8x AMD MI350X | 4,096 / 128 tokens | 1 request | 0.83x | 0.28x | 1.26x | p99 |
| GLM-5.3-Flash, 8x AMD MI350X | 4,096 / 128 tokens | 8 requests | 0.96x | 0.48x | 0.71x | p99 |
| GLM-5.3-Flash, 8x AMD MI350X | 16,384 / 128 tokens | 1 request | 0.82x | 0.62x | 1.26x | p99 |
| GLM-5.3-Flash, 8x AMD MI350X | 16,384 / 128 tokens | 128 requests | 0.65x | 1.53x | 0.80x | p99 |
Ratios are plow divided by vLLM, as published. For throughput higher is better; for the two latency columns lower is better.
- Gemma-4 31B, long-context decode, 8x AMD MI350X 1.40x to 1.52x
How much plow’s time per token grows from 1k to 128k context, against 1.9x to 2.9x for vLLM. plow is faster past about 42k tokens at TP4 and 81k at TP8.
, source
How it compares
| GPU | Memory | Bandwidth | BF16 | FP8 | Power |
|---|---|---|---|---|---|
| H100 | 80 GB | 3.35 TB/s | 1,979 TFLOPS with sparsity | 3,958 TFLOPS with sparsity | Up to 700 W |
| MI300X | 192 GB | 5.3 TB/s | 1.3 PFLOPS (2.61 with sparsity) | 2.61 PFLOPS (5.22 with sparsity) | 750 W |
| MI325X | 256 GB | 6 TB/s | 1.3 PFLOPS (2.61 with sparsity) | 2.61 PFLOPS (5.22 with sparsity) | 1,000 W |
| MI350X | 288 GB | 8 TB/s | 2.3 PFLOPS (4.6 with sparsity) | 4.6 PFLOPS (9.2 with sparsity) | 1,000 W, passive cooling |
| MI355X | 288 GB | 8 TB/s | 2.5 PFLOPS (5 with sparsity) | 5 PFLOPS (10.1 with sparsity) | 1,400 W, passive or active cooling |
Vendors quote some peaks only with structured sparsity, marked where they do. Compare measured results, not peaks: see all benchmarks.
Questions
- Is the MI350X good for LLM inference?
- CDNA 4 adds FP4 and FP6 and raises bandwidth to 8 TB/s. On eight MI350X, plow’s time per token grows 1.40 to 1.52 times from 1k to 128k context, against 1.9 to 2.9 times for vLLM. On GLM-5.3-Flash, plow’s p99 time to first token is 0.28 to 0.62 times vLLM’s in four of five cells, while vLLM leads on throughput.
- How much memory does the MI350X have?
- 288 GB of HBM3E at 8 TB/s. That holds the weights of a model up to about 144B parameters in BF16, or 288B in FP8, before the KV cache.
- Which inference engines run on the MI350X?
- vLLM, SGLang and plow, through ROCm.
- Does plow have a tuned build for the MI350X?
- No tuned build is currently listed in the public registry.