MI300X Transformer Sizing Rules

• The paper presents a systematic methodology that derives transformer and MoE sizing rules from microbenchmark results, kernel roofline analyses, and hardware constraints.
• Using concrete metrics like head dimension multiples of 64 and FLOP-size thresholds, the guidelines ensure that each GEMM and attention operation achieves optimal performance.
• These rules integrate strategies in batch–sequence tiling, MLP/MoE expansion, and interconnect configuration to avoid underutilization bottlenecks and maximize throughput.

MI300X-aware transformer sizing rules are systematic guidelines for parameterizing transformer and mixture-of-experts (MoE) models to maximize throughput and efficiency on AMD Instinct MI300X GPUs. These rules are directly motivated by microbenchmark results, kernel roofline analyses, and hardware characteristics (GEMM throughput, HBM bandwidth, interconnect topology) observed in large-scale pretraining deployments on pure AMD clusters. MI300X-aware sizing covers every dimension of transformer and MoE layer parameterization—including head count, hidden width, MLP expansion, expert counts, and batch/sequence tile sizes—to exploit MI300X’s full-stack hardware and networking features and systematically avoid underutilization bottlenecks (Anthony et al., 21 Nov 2025, Ambati et al., 31 Oct 2025).

1. Attention Block Sizing Principles

Transformer attention on MI300X is governed by three primary constraints: head dimension alignment, GEMM size, and batch–sequence tiling. These constraints ensure high kernel utilization for both GEMM-based attention and projection operations.

• Head dimension divisibility: For transformer hidden size $H$, number of attention heads $a$, and per-head dim $d_h = H/a$, the constraint:

$$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$

Ensures the $QK^T$ and output projection GEMMs hit MI300X’s high performance regime (outer dim $\ge 512$, inner dim $\ge 1024$). Too small $d_h$ results in severely reduced matrix multiply efficiency (utilization $U=0.15$ for $d_h=64$, $a$0 for $a$1) (Ambati et al., 31 Oct 2025).

• GEMM FLOP-size constraint: For a single GPU, maximum throughput is achieved when

$a$2

(with $a$3 micro-batch size, $a$4 sequence per GPU, $a$5 heads, $a$6 per-head dim), ensuring that the QK$a$7 and $a$8 projection reaches MI300X’s $a$9200 TFLOP/s peak. Example: $d_h = H/a$0 FLOPs.

• Batch–sequence tiling: The grouped dimension $d_h = H/a$1 must be divisible by $d_h = H/a$2 (ideally $d_h = H/a$3), aligning matrix shapes to rocBLAS/hipBLASLt’s preferred tiles and preventing inefficient memory access patterns (Anthony et al., 21 Nov 2025).

2. MLP and MoE Block Sizing

Fully Connected (MLP) and MoE layers follow a set of expansion, tiling, and FLOP-scale rules directly informed by MI300X microbenchmarks.

• Feedforward expansion: Use a $d_h = H/a$4 expansion for the pre-activation width (not traditional $d_h = H/a$5), i.e.,

$d_h = H/a$6

for SwiGLU activation. This maintains model quality while keeping GEMM sizes above the $d_h = H/a$7 GFLOP threshold on MI300X, optimizing throughput (Anthony et al., 21 Nov 2025).

• Expert MLP tiling: For $d_h = H/a$8 experts per layer and local tokens per expert $d_h = H/a$9,

$$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$0

Ensures $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$1 and $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$2 shapes meet or exceed $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$3 FLOPs, maintaining kernel efficiency. For example, $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$4, $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$5 yields $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$6.

• MoE expert count and widths: Empirically,

$$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$7

(where $$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$8 is top-$$d_h \;\text{must be a multiple of 64, typically}\; d_h \ge 128$$9 routing) provides maximal kernel occupancy and minimizes all-to-all shuffle volume. Each expert’s pre-activation and post-activation widths mirror the MLP rule to retain architectural and FLOP parity with dense blocks.

3. Hardware-Driven Constraints and Interconnect Sizing

Sizing rules are deeply influenced by MI300X’s hardware features—HBM bandwidth, capacity, and interconnects.

• HBM bandwidth: Sustained on-device memory bandwidth is $QK^T$0–$QK^T$1 TB/s (PyTorch memcpy). Fused kernels (Conv1d, RMSNorm, Muon, FlashAttention) must be sized so their per-kernel memory traffic does not exceed $QK^T$2, otherwise HBM-bound slowdowns occur, especially at $QK^T$3 (Anthony et al., 21 Nov 2025).
• InfinityFabric / intra-node collective bandwidth: Per-GPU intra-node (xGMI) bandwidth is $QK^T$4 ($QK^T$5 GPUs/node, $QK^T$6 GB/s links), favoring parallelism sharded only across full nodes to keep all-to-all communication collective (Anthony et al., 21 Nov 2025).
• Pollara Interconnect: Each GPU NIC is $QK^T$7, giving $QK^T$8 per node. AllReduce performance plateaus at collective message sizes $QK^T$9–$\ge 512$0. A gradient fusion buffer $\ge 512$1 saturates the bus-bandwidth curve and balances communication–computation overlap.

4. HBM Capacity, Model Size, and Activation Footprints

Total model and activation footprints are limited by MI300X’s HBM capacity.

• Parameter and activation budgeting: For $\ge 512$2 layers, hidden size $\ge 512$3,

$\ge 512$4

Where $\ge 512$5 is number of model parameters (total), $\ge 512$6 activation footprint, and $\ge 512$7bytes per parameter/activation (FP16/FP32). $\ge 512$8 on MI300X (Ambati et al., 31 Oct 2025).

• Working set for memory bandwidth: Activation working set per layer,

$\ge 512$9

$\ge 1024$0 should reach at least $\ge 1024$1–$\ge 1024$2 to saturate $\ge 1024$3–$\ge 1024$4 measured bandwidth.

5. Practical Sizing Workflow and Algorithmic Summary

A practical MI300X-centric sizing workflow synthesizes the prior constraints into actionable steps:

1. Choose a hidden size $\ge 1024$5 divisible by $\ge 1024$6 (e.g., $\ge 1024$7, $\ge 1024$8, $\ge 1024$9).
2. Set feedforward width $d_h$0, leveraging SwiGLU if possible.
3. Select expert count $d_h$1 so $d_h$2 and enable top-1 routing.
4. Verify each critical GEMM operation ($d_h$3 and $d_h$4) meets the $d_h$5 GFLOP threshold.
5. Align all major dimensions by $d_h$6 (preferably $d_h$7) to ROCm BLAS tile size preferences.
6. Use fused kernels for layer norm and attention to remain compute-bound, avoiding the $d_h$8 TB/s HBM bandwidth limits.
7. Set gradient fusion to $d_h$9 MiB for communication–computation overlap at Pollara’s saturation point.

Collectively, this process ensures that every block and operation remains in the high-efficiency operational regimes pinpointed by empirical MI300X microbenchmarks (Anthony et al., 21 Nov 2025, Ambati et al., 31 Oct 2025).

6. Model Size, Batch, and Sequence Scaling Trade-offs

Scaling rules on MI300X are characterized by quadratic costs in hidden size and thresholds on working-set memory:

• Model size: $U=0.15$0. Doubling hidden size $U=0.15$1 increases memory requirements $U=0.15$2.
• Sequence length:

$U=0.15$3

e.g., $U=0.15$4, $U=0.15$5 gives $U=0.15$6 tokens in FP16.

• Batch size tuning: For full HBM bandwidth, select $U=0.15$7.
• Utilization: Keep each GEMM shape $U=0.15$8 to maintain $U=0.15$9, targeting $d_h=64$0 per the empirical utilization curves.

7. Implications, Limitations, and Ongoing Research

The MI300X-aware sizing rules, as described by leading research groups (Anthony et al., 21 Nov 2025, Ambati et al., 31 Oct 2025), demonstrate that MI300X’s compute and memory systems support transformer and MoE model design choices qualitatively distinct from legacy GPU worlds, notably by incentivizing highly regular, tile-aligned layouts and lower expansion ratios. The rules reflect a paradigm shift towards tightly hardware–software codesigned architectures, offering throughput and latency competitive with state-of-the-art base models (e.g., Qwen3, Gemma3, Llama-3, OLMoE) at comparable or smaller parameter scales. A plausible implication is that future model and compiler designs targeting MI300X are likely to further reduce per-layer irregularities and harness cross-node collectives for scalable pretraining and inference. The current sizing rules are also constrained by specific kernel and interconnect implementations; continued advances in the ROCm software stack and collective communication are likely to evolve the practical optima in the coming generation of AMD server hardware.