The Hardware Behind M3

MiniMax M3 is a 428-billion-parameter open-weights vision-and-language model from the Shanghai lab Moonshot AI. Roughly 23 billion parameters are active per token, drawn from 128 routed experts plus a shared expert in each of 57 MoE layers. M3 handles text, image and video natively and runs in a one-million-token context window. The hardware under that capability has three chapters: the NVIDIA Hopper H100, on which it was trained; the Hopper and Blackwell generations (H100, H200, B200, B100, GB200) on which it now serves; and the AMD Instinct MI355X, an alternative serving path brought up on ROCm since M3’s launch. This post walks through all three, separating what NVIDIA, AMD and Moonshot have published in primary sources from what is company-reported or extrapolated.

Why M3’s hardware matters

A modern frontier model is not “the same algorithm on a faster computer.” Once the parameter count rises past the few-hundred-billion mark, the dominant constraint stops being raw compute and becomes three things at once: memory capacity per accelerator, interconnect bandwidth between accelerators, and how cleanly a mixture-of-experts (MoE) routing pattern can be mapped onto a cluster. M3 sits in the regime where all three matter.

The model is technically a sparse MoE transformer with sixty decoder layers — the first three dense, the remaining fifty-seven MoE — and a 512k-token training context that runs out to a one-million-token serving window. Each MoE layer carries a routing gate and 128 expert feed-forward blocks, of which the gate selects the four most relevant for the current token, plus one always-on shared expert. That is the famous “23 billion active out of 428 billion total” figure: 23 billion is the parameter count fired on a single token, but the 428 billion is the capacity the cluster has to keep live so that any of the 128×57 expert slots could be the next one called.

The practical consequences are simple to state and expensive to live with. First, 428 billion parameters at BF16 take roughly 850 GB just for the weights; in FP8 they take roughly half that. The model does not fit on a single 80 GB H100 HBM3 in either precision, and only barely fits on a single 141 GB H200. Second, the per-token MoE gather step has to land on whichever GPU holds the chosen four experts, and the gradients have to land back where the optimiser states live. Expert Parallelism (EP) — distributing the expert roster so that each GPU owns a slice and tokens are dispatched via all-to-all collectives — is the technique that makes that budget tractable. Third, the long context multiplies the per-step memory pressure: M3 uses MiniMax Sparse Attention (MSA), a learned indexer that prunes the attention matrix down to a small fraction of the full window, which keeps decode memory within reach but not within easy reach.

So the question “what GPU does M3 use” decomposes into three more useful ones: what does it train on, what does it serve on, and which of those is well-documented versus company-marketing. The honest answer is that training is fixed at one generation, serving spans three, and the public evidence is heavier on the serving side than on the exact internal cluster.

The training target: NVIDIA Hopper H100

The chip on which Moonshot AI trained M3 is the NVIDIA H100 SXM — the HGX-board variant, not the PCIe card, not the NVL. NVIDIA’s H100 datasheet describes an 80-billion-transistor part on TSMC’s customised 4N process, with 80 GB of HBM3 memory, a 3.35 TB/s memory bandwidth, eighteen fourth-generation NVLink links carrying 900 GB/s of bidirectional GPU-to-GPU bandwidth, and a configurable TDP that can run up to 700 W.^{[13, 14]}

What mattered most for an MoE workload in 2024 and 2025 was the new fourth-generation Tensor Core: it added two FP8 formats to the Hopper instruction set, E4M3 (four exponent, three mantissa bits) and E5M2 (five exponent, two mantissa bits), and doubled matrix-multiply throughput against the prior A100 generation. The Hopper whitepaper gives the peak rate as 1,979 TFLOPS at BF16 / FP16 Tensor Cores and 3,958 TFLOPS at FP8 Tensor Core (sparsity off).^{[15, 16]}

The Transformer Engine is the part that actually uses those FP8 instructions: a hardware-and-software block that observes the per-tensor dynamic range as the model trains, picks E4M3 or E5M2, and rescales the matrices into the chosen format on the fly. For most transformer training it lands the bulk of the linear algebra on FP8 while keeping master weights and optimiser states in BF16 or FP32. NVIDIA also added second-generation Multi-Instance GPU (MIG), confidential computing at the silicon level, and a 900 GB/s NVLink that scales — through external NVLink Switches — to a 256-GPU NVLink domain, served by an HGX board that hosts eight H100s and four third-generation NVSwitches.^{[14, 17]}

For M3, the important consequences are density and bandwidth. Each H100 can hold 80 GB of BF16 weights or roughly 160 GB of FP8/INT8, and moves 3.35 TB/s to and from that memory. The NVLink fabric means an expert all-to-all across the cluster lands in microseconds, and SHARP in-network compute acceleration on the third-generation NVSwitch runs reductions on the switch silicon itself. The NVIDIA HGX H100 announcement reports a 256-GPU Hopper pod reaching 1,024 PFLOPS of FP8 compute, 512 PFLOPS of FP16, and 70 TB/s of bisection bandwidth — about an eleven-fold improvement on the comparable A100 pod, for the same number of GPUs.^[17]

What the H100 does not provide is anything close to a four-bit path: there is no native FP4 instruction on Hopper. FP8 was the precision ceiling on this chip. That becomes important in the serving section, because the Blackwell generation that succeeded the H100 explicitly added FP4 to its instruction set.

The reference training recipe: 256 H100s, in five dimensions

The most useful public evidence about how M3 is trained is NVIDIA’s. The Megatron Bridge docs on docs.nvidia.com describe the model precisely as a natively multimodal sparse MoE: 60 layers (3 dense, then 57 MoE), 128 routed experts with top-4 routing, one shared expert, four KV heads, and a vLLM-compatible export at BF16. The same page publishes the reference training recipes with all the knobs filled in, and the second-generation NeMo-RL guide describes a GRPO reinforcement-learning recipe validated on the same layout.^{[5, 6, 7]}

The headline numbers are these: the pretrain reference is `minimax_m3_pretrain_256gpu_h100_bf16_config`, the SFT reference is `minimax_m3_sft_128gpu_h100_bf16_config`, and the baseline tensor / pipeline / expert parallel layout is TP=2 / PP=4 / EP=32, giving a minimum of 128 GPUs and a balanced 256-GPU configuration at DP=2.^{[5, 6]} Each GPU therefore owns four of the 128 experts — a clean partition — and each pipeline stage carries fifteen transformer layers (4 stages × 15 layers = 60, matching the architecture). Nemo-RL’s GRPO layout, also on H100s, runs at CP=8 × EP=128 across thirty-two nodes of eight GPUs, with vLLM generation at TP=16 × EP=16.^{[7, 18]}

The order in which these five parallelism dimensions — tensor parallelism, pipeline parallelism, expert parallelism, context parallelism, data parallelism — are combined is the art. NVIDIA’s Megatron-Bridge parallelism guide keeps them layered rather than nested: TP and EP apply to the operations within a layer, PP and DP apply across the layers and the data, and CP splits the attention window along the sequence axis.^[19] The 2025 follow-up paper “MoE Parallel Folding” on arXiv systematises this as five-dimensional hybrid parallelism and reports up to 49 % Model FLOPs Utilisation on Mixtral-8×22B and 39 % MFU on Qwen2-57B-A14B, both on H100s, scaling to 1,024 GPUs and 128K-token sequences.^[20]

The expert-routing dispatcher is what actually keeps an MoE on the GPU. Standard collectives send all routed tokens in a single all-to-all step, which forces the top-k-expanded token buffer to fit entirely in device memory. NVIDIA replaced that flow with two custom dispatchers: DeepEP, optimised for Ampere, Hopper, B200 and B300 GPUs, and HybridEP, extended to GB200 and GB300 with NVL72 fabrics. The NeMo-RL recipe on M3 calls `attn: sdpa, linear: te, dispatcher: hybridep` and a Transformer Engine `FusedAdam` optimiser with master weights and FP32 second moments.^{[5, 19]}

That is the training recipe as published by NVIDIA. It says three important things. First, Moonshot AI’s choice of TP=2 rather than the more common TP=4 or TP=8 makes sense only if the dominant cost of communication is now the EP all-to-all rather than the TP all-reduce — exactly what Hopper’s NVLink-900 bandwidth makes cheap. Second, an EP=32 partition puts roughly four experts per GPU, which matches the routing memory budget comfortably. Third, FP8 training is on the table but the shipped recipe uses BF16; the FP8 path is documented as a separate configuration. Inference supports both BF16 and FP8 cleanly. NVIDIA’s NeMo AutoModel coverage describes M3 as “trained on Hopper GPUs, with BF16 and FP8 support” and lists both BF16 and MXFP8 checkpoints on Hugging Face.^[7]

There is, of course, a wide gap between the recipe NVIDIA publishes and the actual cluster Moonshot AI used. NVIDIA’s recipes are minimum-viable configurations intended to match the model architecture; production training for a 428-billion-parameter MoE will in practice use much larger topologies with sequence parallelism across all of context parallelism, pipeline parallelism and a hand-tuned EP. Nobody outside the lab knows the exact scale. What is known is that Hopper is the family it shipped on.

FP8 and the precision story across the stack

The natural question after “Hopper” is “what precision.” FP8 deserves its own section because it is the move that makes 256-GPU training of an MoE model of this size economic at all, and because the precision story changes again on Blackwell and CDNA 4.

Until the Hopper generation, the de facto training precision for large transformer models was BF16, with FP32 master copies of the weights and optimiser states. That was a clean choice and it cost memory and FLOPs roughly equally: each BF16 weight consumed two bytes, and a transformer weight × activation × gradient all had to flow through the GPU at half-precision speed. By 2023, model size had grown faster than per-GPU memory had, and the limit on the per-GPU throughput of BF16 Tensor Cores was felt in every published training-time curve.

FP8 addresses the limit twice over. Each weight is one byte instead of two, halving memory and doubling throughput. The new formats are narrow by design. E4M3 offers more mantissa, less exponent range — useful for activations and gradients, which usually cluster near zero. E5M2 offers more exponent range, less mantissa — useful for weights, which can have a wider dynamic range. Each is matched by a per-tensor scaling factor, learned or re-derived every training step, that recovers most of the dynamic range lost by going from seven (BF16) to three (E4M3) mantissa bits. The Hopper Transformer Engine works out which format and which scale factor to use per tensor, which is the engineering detail that turns an otherwise fragile precision choice into something usable.^[15]

M3’s actual training precision is one explicit on-the-record statement and several undocumented assumptions. The explicit statement is the two checkpoint variants Moonshot published: `MiniMaxAI/MiniMax-M3` in BF16, and `MiniMaxAI/MiniMax-M3-MXFP8` in MXFP8. MXFP8 is the OCP microscaling flavour of FP8, which carries a per-block scaling factor inside the data type itself rather than as a separate tensor; it is mathematically equivalent to NVIDIA’s E4M3 plus per-block scale at the format level. The NeMo AutoModel page treats both as first-class checkpoints.^[7]

The exact recipe Moonshot trained on — BF16, MXFP8, or native NVIDIA FP8 with the Transformer Engine — is not in the public evidence. NVIDIA’s reference pretrain config is BF16; an FP8 variant is implemented as a config swap in Megatron-Bridge, but the paper-quality reference M3 results come from BF16.^[5] What is clear is that the precision story does not end at FP8. The Blackwell microarchitecture introduced a second-generation Transformer Engine with native FP4 support (E2M1 with per-block microscaling), and AMD’s CDNA 4 (the architecture in the MI355X) introduced MXFP4 and MXFP6 alongside MXFP8. Each moves one rung further down the precision ladder because each new generation has more memory bandwidth than the last, and serving is the regime where memory bandwidth, not raw FLOPS, is the bottleneck.

Where M3 runs for inference: H100, H200, B200, GB200

Training runs once. Serving runs every time someone types a query. That asymmetry is what makes the serving hardware choice the longer-lived, more economically important half of the story.

For NVIDIA, the supported M3 inference hardware is exactly the four GPU generations that fit the precision envelope NVIDIA ships at: H100, H200, B200, B100 and GB200. NVIDIA’s NIM catalogue page lists the family explicitly, and the SGLang MiniMax-M3 cookbook — the reference serving stack NVIDIA, Moonshot and AMD all converge on — exposes configuration generators for the B200, B300, GB-series, H200 and AMD paths under one URL.^{[8, 21]}

H100 is the floor. 80 GB of HBM3 at 3.35 TB/s, FP8 Tensor Cores at 3,958 TFLOPS, four NVLinks per GPU at 900 GB/s aggregate. Running M3 in FP8 with hybrid expert parallelism on eight H100s is feasible but tight: each request holds roughly 100 GB of weights in FP8 plus per-request KV cache, which barely fits. NVIDIA’s NeMo-RL recipe serving path runs vLLM with TP=16 / EP=16 in BF16 across sixteen H100 nodes (so about 128 GPUs total) for the validation runs.^[7]

H200 is a memory refresh on the same Hopper die: 141 GB of HBM3e and 4.8 TB/s of bandwidth, with no FP8 throughput change. For a 428-billion-parameter model, the extra 61 GB of HBM is the difference between “fits at FP8 batch size one with no headroom” and “fits with room for KV cache on long-context requests.” That is why H200 is the right minimum for production serving, even though H100 can do the job for development.^[22]

Blackwell is the generational step. The B200 dies ship in the same physical footprint as HGX Hopper; each carries 192 GB of HBM3e (the H200 and B200 datasheets differ on the precise GB figure because of binning and the dual-die layout, but the working memory at FP4 with KV-cache headroom is similar), eight TB/s of bandwidth, and the second-generation Transformer Engine with native FP4 (E2M1 with microscaling) and FP6. The HGX B200 baseboard carries eight B200s over 1.8 TB/s fifth-generation NVLink per GPU, total 14.4 TB/s of intra-board fabric and 62 TB/s of memory bandwidth across the baseboard. The peak rates per GPU per NVIDIA’s Blackwell B200 datasheet and the Cornell CVW walkthrough are 18 PFLOPS FP4, 9 PFLOPS FP8/FP6, 4.5 PFLOPS FP16/BF16, and 75 TFLOPS FP32 — about double Hopper on FP8 and twenty-fold on FP4.^{[23, 24, 25]}

GB200 ties two B200 dies to one NVIDIA Grace Arm CPU over NVLink-C2C, and the GB200 NVL72 form factor packages 36 Grace CPUs and 72 B200 GPUs into a single liquid-cooled rack, all-addressable over 130 TB/s of NVLink bandwidth. The usable per-rack throughput is 1,440 PFLOPS of FP4 and 720 PFLOPS of FP8/FP6, with 13.4 TB of total HBM3e and 17 TB of CPU-side LPDDR5X. A full rack at the FP4 line can serve an M3-class workload in a single physical unit.^{[26, 27]}

The bigger throughput gain on Blackwell is not the FP8 number — it is the FP4 number. FP4 halves memory use against FP8 and doubles throughput against it, so the same model fits at the same batch size on half the GPUs, and twice the batch size on the same GPUs. For a model whose serving is memory-bandwidth-bound rather than compute-bound, FP4 is what unlocks the economic gain. Hopper does not have it; Blackwell does.

NVIDIA lists FP8 inference throughput at 9 PFLOPS per B200 GPU (versus 4 PFLOPS per H100 GPU) and FP4 at 18 PFLOPS — but those peaks are dense Tensor Core rates; the realised M3 throughput comes from the NVIDIA NIM benchmarks and the SGLang cookbook.

What unifies Hopper and Blackwell inference on M3 is EAGLE3 speculative decoding. The model generates one token at a time, which is memory-bandwidth-bound: each token requires the full context to be re-read. EAGLE3 adds a small auxiliary “draft” model that proposes a handful of tokens ahead of the main model, and the main model verifies them in a single forward pass. Verified tokens count as accepted; rejected ones are recomputed. The acceptance rate translates roughly one-for-one into a throughput win. On M3, the served draft is `MiniMaxAI/MiniMax-M3-EAGLE3`, and AMD’s ATOM path uses the same draft for ROCm.^{[9, 28]}

AMD’s third path: Instinct MI355X

Until mid-2026 the answer to “what GPU does M3 serve on” was NVIDIA-exclusive. AMD published day-zero support for M3 on its Instinct accelerators, both in vLLM and in SGLang, covering the MI300X and the new MI350 series (MI350X and MI355X), built on AMD’s CDNA 4 architecture.^[10]

The flagship is the MI355X. AMD’s product brief lists 288 GB of HBM3e (twice the H200, 1.6× the B200), 8 TB/s of memory bandwidth (matching B200), 16,384 stream processors across eight Accelerated Compute Dies on a TSMC 3 nm/6 nm multi-chip package, MXFP4 at 10.1 PFLOPS dense, MXFP6/MXFP8 at 5 PFLOPS dense, and 256 MB of last-level cache. The OAM module is rated at 1,400 W TBP. Eight of them on a UBB 2.0 board form a full mesh over fifth-generation Infinity Fabric at 538 GB/s bidirectional per chip, aggregating 2.3 TB of HBM3e per platform.^{[29, 30]}

The reason this matters for M3 is the per-GPU memory: 288 GB is enough to hold the entire 428-billion-parameter model in BF16 across only four MI355X accelerators, with room for the KV cache underneath. NVIDIA needs eight H100s or four B200s to clear the same bar; AMD needs fewer boxes to host the same weights. On the per-rack-throughput axis, the SemiAnalysis InferenceX MI355X entry records 10,066 dense FP4 TFLOPS and 5,033 dense FP8 TFLOPS at the chip level, and the AMD ROCm blog presents single-node ATOM throughput curves on MI355X against NVIDIA B200 (with vLLM) and multi-node ATOMesh numbers against NVIDIA B300 (with Dynamo vLLM).^{[9, 30, 31]}

The serving stack is also AMD’s own: ATOM, a ROCm-native inference engine, and ATOMesh for multi-node disaggregated prefill and decode, with KV-cache transfer over the Mooncake stack. EAGLE3 speculative decoding is supported on ATOM, and the AMD blog traces the path through MXFP4 and MXFP8 from a single-node configuration through the multi-node disaggregated layout.^[9]

What AMD does not have, as of early 2026, is a public training reference for MoE models at M3’s scale on MI355X. The MI355X is built for inference and the lower-precision training of smaller models; pretraining a frontier model still happens on NVIDIA’s reference recipes and verified hardware. AMD’s path for M3 is therefore a serving path, not a training one — and that, as much as anything, is what makes the hardware story behind M3 a question of three chips serving a model trained on a fourth.

What the wider stack tells us

Three things stand out about the 2026 data-centre GPU landscape when read through M3.

Power has become a primary design constraint. The H100 SXM runs up to 700 W. The H200 SXM is the same. The B200 SXM5 envelope is 1,000 W with peak at 1,200 W. The MI355X OAM runs at 1,400 W TBP. A GB200 NVL72 rack draws 132 kW of compute alone; an MI355X eight-way platform draws over 11 kW per chassis. Whatever wins this generation is going to be limited less by transistor count than by the megawatt at the data-centre hookup.^{[26, 29]}

Memory bandwidth is the bottleneck, not raw FLOPs. The H100 has 3.35 TB/s. The B200 has 8 TB/s. The MI355X has 8 TB/s. Each generation multiplies the previous one’s bandwidth faster than it multiplies FP8 throughput, because inference on context-heavy models is dominated by moving weights and KV cache, not by doing arithmetic. That is why FP8 (Hopper), FP4 (Blackwell), and MXFP4 (CDNA 4) all moved in the same direction at the same time: when memory bandwidth is the limit, halving the bytes moves twice as many tokens.

Software and silicon are now co-designed. The Hopper Transformer Engine, Blackwell’s second-generation Transformer Engine, the HybridEP dispatcher, AMD’s AITER-optimised kernels, and the MXFP formats themselves are tightly tied to specific GPUs and software stacks. That raises the cost of moving a model between vendors, but it is also what lets each vendor claim order-of-magnitude wins on inference throughput within their own stack.^{[15, 9]}

Where this leaves M3

M3 is a frontier-class model trained in the back half of the Hopper generation, served into the Blackwell generation, and ported onto the first wave of AMD CDNA 4 hardware. The same weights run on all three without recompilation because Moonshot AI shipped the checkpoints in BF16 and MXFP8, both of which sit cleanly within every precision envelope from H100 upwards and from MI300X upwards. What changes between hardware generations is the precision in which you serve (FP8 on Hopper, FP4 on Blackwell and CDNA 4), the memory in which you cache (80 GB on H100, 141 GB on H200, 192 GB on B200, 288 GB on MI355X), and the interconnect that links the experts all-to-all (NVLink-900, NVLink-1800, Infinity Fabric 538 GB/s).

The dominant economic question about M3 is no longer “does it work on Hopper” — it does, with the NeMo recipes, with Megatron-Bridge, and at FP8 throughput. The interesting questions now sit on the serving side: how a single M3 workload behaves when its precision drops from FP8 to FP4 (nearly twice the throughput per Blackwell or CDNA 4 GPU); how it batches when the KV cache expands from 80 GB to 288 GB of HBM3e; how often the EAGLE3 draft model on the same checkpoint needs to be re-trained; and how the disaggregated prefill/decode layout — prefill on a Blackwell pod, decode on a separate CDNA 4 pod — reshapes throughput. Those are the questions that decide which GPU actually carries an M3 deployment at scale.

The model itself does not change with the silicon. The hardware under it does.

References

1. Moonshot AI (2026). MiniMax-M3 model card. Hugging Face. https://huggingface.co/MiniMaxAI/MiniMax-M3
2. Runpod (2026). How to run MiniMax M3 on Runpod. https://www.runpod.io/articles/guides/run-minimax-m3-on-runpod
3. NVIDIA Megatron Bridge documentation - MiniMax-M3. https://docs.nvidia.com/nemo/megatron-bridge/0.6.1/models/minimax/minimax-m3.html
4. NVIDIA NeMo-RL - MiniMax-M3. https://docs.nvidia.com/nemo/rl/nightly/guides/models/minimax/minimax-m3.html
5. NVIDIA Megatron Bridge - Parallelisms guide. https://docs.nvidia.com/nemo/megatron-bridge/latest/parallelisms.html
6. NVIDIA Megatron Bridge - recipe API: minimax_m3_pretrain_256gpu_h100_bf16_config. https://docs.nvidia.com/nemo/megatron-bridge/nightly/apidocs/bridge/bridge.recipes.minimax.h100.minimax_m3.html
7. NVIDIA NeMo AutoModel - MiniMax-M3 coverage page. https://docs.nvidia.com/nemo/automodel/model-coverage/vision-language-models/minimax/MiniMax-M3
8. NVIDIA NIM - minimaxai / minimax-m3. https://docs.api.nvidia.com/nim/reference/minimaxai-minimax-m3
9. AMD ROCm blog (2026). Efficient MiniMax-M3 Inference on AMD Instinct GPUs with ATOM and ATOMesh. https://rocm.blogs.amd.com/artificial-intelligence/minmax-m3-atomesh/README.html
10. AMD developer resource (2026). Day 0 support for MiniMax M3 on AMD Instinct GPUs. https://www.amd.com/en/developer/resources/technical-articles/2026/day-0-support-for-minimax-m3-on-amd-instinct-gpus.html
11. Wikipedia - Hopper (microarchitecture). https://en.wikipedia.org/wiki/Hopper_(microarchitecture)
12. Wikipedia - Blackwell (microarchitecture). https://en.wikipedia.org/wiki/Blackwell_(microarchitecture)
13. NVIDIA (2022). NVIDIA H100 Tensor Core GPU Architecture (whitepaper). https://www.ece.lsu.edu/koppel/gp/refs/gtc22-whitepaper-hopper.pdf
14. NVIDIA (2022). H100 Tensor Core GPU datasheet (mirror). https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/nvidia-h100-80-gpu.pdf
15. NVIDIA - Hopper architecture page. https://www.nvidia.com/en-us/data-center/technologies/hopper-architecture.md
16. NVIDIA - H100 product page (specifications). https://www.nvidia.com/en-us/data-center/h100.html
17. NVIDIA Developer Blog (2022). Introducing NVIDIA HGX H100. https://developer.nvidia.com/blog/introducing-nvidia-hgx-h100-an-accelerated-server-platform-for-ai-and-high-performance-computing/
18. NVIDIA Megatron-Core developer guide - Mixture of Experts package. https://docs.nvidia.com/megatron-core/developer-guide/0.15.0/api-guide/moe.html
19. NVIDIA Megatron Bridge - HybridEP / DeepEP dispatcher coverage. https://docs.nvidia.com/nemo/megatron-bridge/latest/parallelisms.html
20. NVIDIA (2025). MoE Parallel Folding: Heterogeneous Parallelism Mappings for Efficient Large-Scale MoE Model Training with Megatron Core. arXiv:2504.14960. https://arxiv.org/abs/2504.14960
21. SGLang - MiniMax-M3 cookbook. https://docs.sglang.io/cookbook/autoregressive/MiniMax/MiniMax-M3
22. NVIDIA H100 NVL product brief (2023). https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/h100/PB-11773-001_v01.pdf
23. NVIDIA - DGX GB200 product page. https://www.nvidia.com/en-us/data-center/dgx-gb200/
24. NVIDIA - GB200 NVL72 product page. https://www.nvidia.com/en-us/data-center/gb200-nvl72/
25. NVIDIA Blackwell B200 datasheet (mirror). https://www.primeline-solutions.com/media/categories/server/nach-gpu/nvidia-hgx-h200/nvidia-blackwell-b200-datasheet.pdf
26. Together AI - NVIDIA HGX B200 cluster pricing & specs. https://www.together.ai/gpu/nvidia-hgx-b200
27. Cornell CVW - Horizon GPUs: Blackwell B200 - Tensor Cores, Fifth Generation. https://cvw.cac.cornell.edu/gpu-architecture/horizon-gpus-blackwell-b200/tensor_cores_fifth_gen
28. AMD Instinct MI355X Platform - product brief. https://www.amd.com/content/dam/amd/en/documents/instinct-tech-docs/product-briefs/amd-instinct-miI355x-platform-brochure.pdf
29. AMD - MI355X GPU product page. https://www.amd.com/en/products/accelerators/instinct/mi350/mi355x.html
30. SemiAnalysis InferenceX - MI355X specs. https://inferencex.semianalysis.com/chips/mi355x
31. Moonshot AI - MiniMax-M3-MXFP8 checkpoint. Hugging Face. https://huggingface.co/MiniMaxAI/MiniMax-M3-MXFP8