MiniMax-H3
serving recipe.

Floors are the minimum the vLLM recipe publishes across the whole replica, from vLLM's own runs. The control plane compares them with its own sizing from the model config.

The recipe does not list parallelism strategies; its flags carry the tested layout.

• B300 · 8 GPUs
• DGX Spark (GB10) · 1 GPU
• GB200 NVL4 · 4 GPUs
• RTX 4090 · 2 GPUs
• RTX 5090 · 2 GPUs
• RTX PRO 5000 Blackwell 4x · 4 GPUs
• RTX Pro 6000 2x · 2 GPUs
• MI300X · 8 GPUs
• MI325X · 8 GPUs
• MI355X · 8 GPUs
• Ascend 950PR · 1 GPU

Wingsmith runs models through NVIDIA Dynamo, so it serves on NVIDIA GPUs. Other vendors are listed as the recipe states them.

vllm serve MiniMaxAI/MiniMax-H3 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 8000 \
  --num-gpus 4 \
  --usp 4 \
  --ring 1 \
  --vae-patch-parallel-size 4 \
  --vae-parallel-mode tile \
  --vae-use-tiling

Dependencies

• Gated checkpoint — request access on the model card, then download it locally. Serve the root directory: both DiTs remain in subdirectories while the modular service shares the encoder and VAEs.
• Ascend pip path: build vLLM v0.26.0 with the NPU target and vLLM Ascend from the matching release branch. This replaces the CUDA wheel shown in the pip tab above.
• pip path only: install current vLLM-Omni main for the modular MiniMax-H3 pipeline.
• Optional pip extra for explicitly comparing FA4 on datacenter Blackwell. The generated B300/GB200 route uses the TRTLLM_ATTN default; RTX PRO 5000 and the two-GPU RTX routes use CUDNN_ATTN. (optional)
• Docker path only: clone current vLLM-Omni main to the path mounted by the generated command so it overrides the older package in the image.
• Ascend Docker path: the generated docker run emits --gpus all, which the NPU runtime ignores. Start the container with the CANN device and driver mounts below, then run the serve command inside it. --shm-size is required — the 64 MB default cannot carry the decoded video back to the API server over shared memory.
• pip path only: ffmpeg and ffprobe must be on PATH for reference-video preparation and MP4 video+audio muxing. The official Docker images already bundle them.

1. Register the weights

   In the console, or through the API. Resolving a slug proposes an artifact and writes nothing.

   curl "http://localhost:8000/v1/artifacts/resolve?source=hf:MiniMaxAI/MiniMax-H3"

2. Read the draft

   The draft carries this recipe as upstream evidence: the tested flags, the precision and memory floor, the parallelism layouts, and the hardware vLLM verified, with links back to the recipe. Nothing from it is applied without you, and the draft warns when the plane's own sizing and the published floor differ by a quarter or more.

3. Create the workload

   Choose the engine, device shape and scale. The plane picks the clusters, and each cluster's operator renders the deployment as a Dynamo graph.

4. Give it an endpoint

   One model name for clients, routed by the gateway to deployments on every cluster serving it.

Run the control plane locally →

• How much GPU memory does MiniMax-H3 need?The vLLM recipe publishes a minimum of 202 GB across the whole replica for its BF16 variant. That is vLLM's own measurement, not a per-GPU figure.
• Which parallelism layouts does the MiniMax-H3 recipe support?The recipe does not list parallelism strategies.
• Can Wingsmith serve MiniMax-H3?Wingsmith serves models through NVIDIA Dynamo on clusters with NVIDIA GPUs. Register MiniMaxAI/MiniMax-H3 and the plane attaches this vLLM recipe to the draft as evidence: its tested flags, precision and memory floor, for you to review rather than applied on your behalf.

From the vLLM recipe for MiniMaxAI/MiniMax-H3 ↗ (snapshot at 4bcc189), Apache 2.0.