Deploy MiniMax M3 on GPU Cloud: Self-Host the First Open-Weight Frontier Model with MSA, 1M Context, and Native Multimodality (2026 Guide)

MiniMax M3 launched June 1, 2026 as the first open-weight model to simultaneously hit a 59.0% SWE-Bench Pro score, support a 1M-token context window, and ship native image and video understanding in a single checkpoint. For teams comparing the upgrade from the previous generation, MiniMax M2.7's deployment guide covers the 229B MoE baseline, but M3's MSA architecture and 1M context capability are a different class of deployment challenge. This guide covers the hardware requirements, vLLM and SGLang setup, multimodal serving, agentic coding workloads, and the cost math for self-hosted M3 versus the hosted API options.

TL;DR: Deploy MiniMax M3 on GPU Cloud

MiniMax M3 (428B total, ~23B active, 1M-token context) self-hosts at FP8 on 4x H200 SXM5, or on 8x H100/H200 for full 1M context, which adds ~120 GB of KV cache.

Compare live GPU rates.

What Is MiniMax M3

MiniMax M3 is the company's open-weight frontier model released June 1, 2026. It uses a Mixture-of-Experts (MoE) architecture with 428B total parameters and roughly 23B active per token: each token is routed to 4 of 128 experts, plus 1 shared expert that every token passes through. The small active parameter count per forward pass keeps per-token compute comparable to a mid-sized dense model while the full 428B parameter set resides in VRAM.

Three capabilities define M3's position relative to earlier models:

SWE-Bench Pro at 59.0%. MiniMax published this as M3's official benchmark, and it exceeds both GPT-5.5 and Gemini 3.1 Pro on the same evaluation. SWE-Bench Pro measures multi-step software engineering task completion, which is harder to game than single-pass generation benchmarks. The 59.0% figure reflects the model's ability to understand a codebase, isolate a bug, generate a patch, and verify it passes tests across multiple turns.

Comparison scores for GPT-5.5 and Gemini 3.1 Pro are from MiniMax's official release announcement. M3 leads the open-weight field and outperforms several closed models, but some closed models including Claude Opus 4.8 (~69.2%) score higher on this benchmark. Verify all figures against each provider's current published numbers before using for procurement decisions.

1M token context window. The context length is 1,048,576 tokens. This is not a soft cap with degraded quality at the edges. M3's MSA architecture is specifically designed to maintain coherent retrieval and generation across the full context length at practical inference costs.

Native multimodality. Image and video understanding are built into the base checkpoint, not a separate model or vision adapter. A single endpoint handles text, image, and video inputs interchangeably.

MSA Architecture: How MiniMax M3 Handles 1M Context

Standard full attention scales quadratically: doubling context length quadruples the compute cost. At 1M tokens, full attention becomes impractical on any current GPU configuration. Most long-context models work around this with sliding window attention, retrieval-augmented approaches, or hard limits at 128K or 200K.

M3's MSA (MiniMax Sparse Attention) takes a different approach. By restricting each token's attention to a structured sparse subset of other tokens, MSA delivers more than 9x prefill speedup and more than 15x decode speedup at 1M context versus MiniMax's previous-generation M2 model. Per-token compute at 1M tokens drops to 1/20th of M2's baseline at equivalent context length.

The practical consequence: 1M context inference on M3 costs roughly what 50K context inference costs on a comparable dense model. A 4x H200 config that handles M3 at 32K context handles the same model at 1M context at an affordable operational cost, not at a hardware-multiplying cost.

This matters for real workloads. Full codebase context, entire legal documents, long conversation histories, multi-document research tasks - these now fit in a single request on mid-tier multi-GPU hardware rather than requiring either a smaller context window or a compute cluster that prices out most teams.

For a deeper look at how sparse attention mechanisms change the memory math at extreme context lengths, the DeepSeek sparse attention and long context LLM guide covers the architectural tradeoffs in detail.

GPU Memory Requirements

MiniMax M3 is a MoE model: the full parameter set must reside in VRAM even though only a fraction activates per forward pass. You cannot page unselected experts from CPU without introducing latency that breaks interactive inference.

VRAM requirements by precision for 428B total parameters (weights only; INT4 uses ~0.6 bytes per parameter because real quantized files keep scales, embeddings and some layers at higher precision):

KV cache memory adds on top of model weights and scales with context length. MSA reduces attention compute cost but does not eliminate KV cache memory growth entirely: the KV states for attended positions still need to be stored. At 32K context in FP16, expect roughly 6-8 GB of KV cache overhead. At 128K context, that grows to 20-30 GB. For 1M context inference, FP8 KV cache via --kv-cache-dtype fp8_e5m2 is effectively required to stay within VRAM limits.

At 1M context, the FP8 KV cache alone consumes roughly 120 GB. On a 4x H200 FP8 config with 564 GB total and ~428 GB of model weights, that leaves roughly 136 GB of raw headroom, enough for one full 1M-context request but little else once activations and CUDA graphs take their share. 8x H100 SXM5 (640 GB, ~212 GB headroom) or 8x H200 SXM5 (1,128 GB, ~700 GB headroom) is the practical floor for 1M context with concurrent requests, as reflected in the context budget table later in this post. INT4 on 2x H200 (282 GB) leaves only ~25 GB after weights, so keep --max-model-len at 32K-64K there; 4x H100 INT4 (~63 GB headroom) handles up to roughly 256K with FP8 KV cache.

For the underlying math on parameter counts and bytes per precision format, see the LLM GPU memory requirements explainer.

Spheron GPU Configurations and Pricing

Live Spheron rates for the configurations that fit M3:

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 26 Oct 2026; other providers reflect their most recent published rates and may have changed. Check current GPU pricing → for live rates.

Use spot for batch or bursty workloads (spot capacity can be reclaimed without notice) and on-demand for 24/7 SLA serving.

For FP8 M3 inference, H200 GPU pricing on Spheron is the right starting point. Four H200s split the ~428 GB of FP8 weights into ~107 GB per card, leaving ~34 GB per card (~136 GB total) of the 141 GB HBM3e for KV cache. That handles context lengths up to 512K comfortably (the ~60 GB FP8 KV cache at 512K fits with room for a few concurrent requests) and a single 1M-context request with little to spare. For 1M context with concurrency, move to 8x H100 or 8x H200.

Teams working with INT4 and moderate context lengths will find on-demand H100 cloud pricing useful: four H100 SXM5 cards (320 GB) hold the ~257 GB INT4 footprint with ~63 GB left for KV cache, which suits batch or experimental workloads. Two H200s also fit INT4 on paper, but the ~25 GB left after weights limits you to short contexts and low concurrency.

Step-by-Step Deployment with vLLM

vLLM provides the OpenAI-compatible server, tensor and expert parallelism, and the FP8 KV cache support that M3's 1M context workloads require.

Step 1: Provision the GPU Node on Spheron

Select your instance in app.spheron.ai: 4x H200 SXM5 for FP8, 8x H100 SXM5 or 8x H200 SXM5 if you need the extra VRAM buffer for long context, or 4x H100 SXM5 for INT4. SSH in using the SSH connection guide.

Step 2: Install Dependencies

# CUDA 12.4+ required
pip install vllm huggingface_hub
export HF_TOKEN=<your_token>

Check your CUDA version with nvidia-smi before installing. CUDA 12.4 is recommended for full H200 FP8 throughput. Before installing, check the vLLM release notes to confirm which version added MSA backend support for MiniMax M3, then pin that version or later (e.g. pip install "vllm>=<confirmed-version>"). The MSA attention mechanism requires explicit framework support that may have shipped in a point release after the initial launch.

Step 3: Download Model Weights

Before running this command, verify that MiniMaxAI/MiniMax-M3 is live and publicly accessible on HuggingFace. MiniMax indicated weights would be published within roughly 10 days of the June 1 launch. If the repository is not yet visible, check the MiniMaxAI HuggingFace organization page for the current status and the exact repository name before proceeding.

# Download M3 base weights (confirm the repo exists before running)
huggingface-cli download MiniMaxAI/MiniMax-M3 \
  --local-dir ./minimax-m3 \
  --repo-type model

Also check whether a pre-quantized FP8 or AWQ INT4 variant is available in the MiniMaxAI org. The repository may be gated and require accepting MiniMax's license terms before downloading. You need approximately 430 GB of NVMe storage for the FP8 checkpoint (if available) or approximately 860 GB for BF16 weights. If you download BF16 and quantize on load, budget for the full 860 GB.

If a pre-quantized FP8 checkpoint is not yet published, vLLM's on-the-fly quantization via --quantization fp8 handles the conversion from BF16 weights at load time. This adds a few minutes to startup but does not require a separate FP8 checkpoint file.

Step 4: Launch the vLLM Server

python -m vllm.entrypoints.openai.api_server \
  --model ./minimax-m3 \
  --served-model-name minimax-m3 \
  --tensor-parallel-size 4 \
  --quantization fp8 \
  --enable-expert-parallel \
  --max-model-len 131072 \
  --kv-cache-dtype fp8_e5m2 \
  --gpu-memory-utilization 0.92 \
  --enable-chunked-prefill \
  --max-num-seqs 16 \
  --port 8000

Flag explanations:

For 8x H100 FP8, set --tensor-parallel-size 8. For INT4 configs, drop --quantization fp8 and load a pre-quantized INT4 variant instead, with --tensor-parallel-size 4 on 4x H100 or 2 on 2x H200. In some vLLM releases the expert parallelism flag is --moe-expert-parallel-size instead of --enable-expert-parallel. Check your version's flags with python -m vllm.entrypoints.openai.api_server --help | grep expert.

For 1M context inference, incrementally increase --max-model-len. Start at 131072, verify GPU memory headroom with nvidia-smi, then step up to 262144, 524288, and finally 1048576. Each step doubles the potential KV cache memory requirement.

Step 5: Validate

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "minimax-m3",
    "messages": [
      {"role": "user", "content": "Write a Python function that merges two sorted linked lists, then write a pytest test for it."}
    ],
    "max_tokens": 512
  }'

Confirm http://localhost:8000/health returns 200 and the response includes a valid Python function and test. Monitor GPU memory with nvidia-smi dmon -s m and token throughput at http://localhost:8000/metrics.

Deploy MiniMax M3 with SGLang

SGLang is the better choice for M3's multi-turn agentic and long-document workloads. Its RadixAttention prefix cache reuses KV states for repeated tool schemas, system prompts, and shared conversation history, cutting time-to-first-token on subsequent turns by 30-60% when the shared prefix exceeds 4K tokens.

For SGLang to support M3's MSA attention mechanism, you need a release that explicitly includes M3 support. SGLang 0.5.12 supports M2.7's MoE expert parallelism; for M3's MSA, check the SGLang release notes for the version that added MSA backend support (expected in SGLang 0.6.x or later, released after M3's June 2026 launch):

pip install 'sglang[all]>=0.6.0'

python -m sglang.launch_server \
  --model-path ./minimax-m3 \
  --tp 4 \
  --quantization fp8 \
  --enable-moe-ep \
  --context-length 131072 \
  --port 30000

The --enable-moe-ep flag activates MoE expert parallelism. Without it, SGLang falls back to tensor parallelism, which replicates all expert weights on every GPU and wastes memory on non-active experts.

For M3's agentic workloads where every request carries the same tool definitions and system prompt, SGLang's RadixAttention hits on every turn after the first. A 4K-token shared tool schema across 100 concurrent agent sessions means 100 fewer full prefill passes per session - at M3's throughput rates, that's a meaningful latency improvement. For production SGLang configuration details including monitoring, load balancing, and prefix caching tuning, see the SGLang production deployment guide.

Native Multimodal Serving: Image and Video Understanding

M3's multimodality is not a vision adapter patched onto a text model. The image and video understanding capability lives in the base checkpoint and is accessible through the standard /v1/chat/completions endpoint using the OpenAI vision message format.

Image Input

Pass image data as a content array in the user message. vLLM supports both URL and base64-encoded image inputs:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "minimax-m3",
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "image_url",
            "image_url": {
              "url": "data:image/jpeg;base64,<base64-encoded-image>"
            }
          },
          {
            "type": "text",
            "text": "Describe what you see in this image in detail."
          }
        ]
      }
    ],
    "max_tokens": 512
  }'

For production image workloads, base64 encoding keeps everything in a single request body. For large images, be aware that the image token count contributes to your --max-model-len budget.

Video Input

Video understanding in M3 works by passing video frames as a sequence of image inputs within the same request. Pass frames sampled at your desired temporal resolution (typically 1-2 fps for general understanding, higher for action detection). The model processes the frame sequence as a temporally ordered visual context alongside any text instructions.

Whether M3 supports a dedicated video MIME type or requires frame decomposition depends on the serving framework's implementation. With vLLM, use the multi-image message format and pass frames as an ordered list of image_url items. Verify the supported video input path for your specific vLLM release from the release notes.

M3 understands video; it doesn't generate it. If your pipeline needs to produce video rather than just interpret it, MiniMax's separate release, H3, ships open weights for video generation with native audio, though under a license with its own regional deployment restrictions worth checking first.

Multimodal KV Cache

Image tokens occupy KV cache space the same as text tokens, but at a higher per-token density. A single full-resolution image typically maps to 256-1024 visual tokens depending on how M3's vision encoder tiles the input. For long-context requests that combine a large image with a 100K text context, budget accordingly: a 1000-token image in a 100K text context adds 1% to the effective context length but may add significantly more to the KV cache if the attention pattern is different from pure text.

Monitor nvidia-smi dmon -s m when serving mixed text-image workloads. If you see KV cache memory pressure, reduce --max-model-len or lower --max-num-seqs before increasing image resolution.

Agentic Coding Workloads

M3's 59.0% SWE-Bench Pro score is the headline. For context: this benchmark measures multi-step software engineering task completion across real GitHub issues with real test suites. The score exceeds GPT-5.5 and Gemini 3.1 Pro; some other closed models like Claude Opus 4.8 (~69.2%) score higher, but M3 leads the open-weight field by a substantial margin. For the self-hosted use case, this means frontier-class coding capability on hardware you control, at costs that scale with usage rather than per-token charges.

The self-hosted advantage compounds with M3's 1M context window. A 200K-line codebase fits in a single request context, which means the model reads the full project before generating a patch rather than working from retrieval results. For multi-file refactors, interface changes, and bugs with distant root causes, full-context inference produces more accurate patches with fewer iterations than retrieval-augmented approaches.

Tool Definitions

The agentic tool schema is identical to M2.7's pattern:

[
  {
    "type": "function",
    "function": {
      "name": "code_exec",
      "description": "Execute Python code in a sandboxed environment and return stdout, stderr, and exit code.",
      "parameters": {
        "type": "object",
        "properties": {
          "code": { "type": "string", "description": "Python code to execute" },
          "timeout": {
            "type": "integer",
            "description": "Execution timeout in seconds",
            "default": 30
          }
        },
        "required": ["code"]
      }
    }
  },
  {
    "type": "function",
    "function": {
      "name": "file_write",
      "description": "Write content to a file, creating parent directories as needed.",
      "parameters": {
        "type": "object",
        "properties": {
          "path": { "type": "string", "description": "Relative file path" },
          "content": {
            "type": "string",
            "description": "File content to write"
          }
        },
        "required": ["path", "content"]
      }
    }
  },
  {
    "type": "function",
    "function": {
      "name": "test_runner",
      "description": "Run the test suite and return a summary of passes, failures, and error messages.",
      "parameters": {
        "type": "object",
        "properties": {
          "test_file": {
            "type": "string",
            "description": "Path to the test file to run"
          },
          "framework": {
            "type": "string",
            "enum": ["pytest", "unittest"],
            "default": "pytest"
          }
        },
        "required": ["test_file"]
      }
    }
  }
]

Multi-Turn Agent Loop

import json
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused")
MAX_ITERATIONS = 5

def dispatch_tool(name: str, args: dict) -> dict:
    raise NotImplementedError(
        f"dispatch_tool: '{name}' is not implemented. "
        "Wire up code_exec, file_write, and test_runner before running this loop."
    )

def is_stalled(messages: list) -> bool:
    raise NotImplementedError("Implement per /blog/deploy-minimax-m2-7-gpu-cloud/")

def run_agentic_loop(task: str, tools: list) -> str:
    messages = [{"role": "user", "content": task}]

    for iteration in range(MAX_ITERATIONS):
        response = client.chat.completions.create(
            model="minimax-m3",
            messages=messages,
            tools=tools,
            tool_choice="auto",
            max_tokens=4096,
        )

        choice = response.choices[0]
        messages.append(choice.message.model_dump(exclude_none=True))

        if not choice.message.tool_calls:
            return choice.message.content or ''

        if choice.finish_reason == "length":
            return "Error: response truncated before tool arguments were complete."

        for tool_call in choice.message.tool_calls:
            try:
                args = json.loads(tool_call.function.arguments)
            except json.JSONDecodeError:
                return "Error: malformed tool call arguments."
            result = dispatch_tool(tool_call.function.name, args)
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": json.dumps(result),
            })

        if iteration >= 2 and is_stalled(messages):
            return "Agent stalled: same test failures persisting. Review manually."

    response = client.chat.completions.create(
        model="minimax-m3",
        messages=messages,
        tools=tools,
        tool_choice="none",
        max_tokens=4096,
    )
    return response.choices[0].message.content or ''

For the stall detection and sandboxed code execution patterns, the M2.7 deployment guide covers the full implementation including Docker-based isolation and the is_stalled() function.

The 1M Context Advantage

For large codebase tasks, pass the full repository as the initial context before the task description. With --max-model-len 1048576, a 200K-token codebase occupies roughly 20% of the available context, leaving 800K tokens for the conversation history, generated patches, and test output across many iterations. This is qualitatively different from M2.7's 200K context or other models with shorter windows: you are not choosing which files to retrieve, you are giving the model everything at once.

Cost: Spheron vs MiniMax API vs OpenRouter

Self-hosting M3 makes economic sense above a throughput threshold. Below that threshold, the hosted API is cheaper because you pay only for tokens used, not for idle GPU time.

Approximate cost per 1M output tokens at typical sustained throughput:

Self-hosted cost per 1M tokens = (price_per_hour / throughput_toks_per_sec / 3600) * 1_000_000. At $7.28/hr with ~800 tok/s, that is $7.28 / (800 x 3600) x 1,000,000 = $2.53/M tokens. The Spheron rows are a worked example with input rates frozen at 12 Jun 2026 spot pricing ($1.82/hr per H200, $1.43/hr per H100); plug in the live rates from the table above to rerun them. On-demand rates change the math, so recompute with the on-demand column if you need SLA-backed capacity.

Throughput estimates above are assumptions, not measurements. M3 activates ~23B parameters per token, so plan on lower per-GPU decode throughput than a ~10B-active MoE on the same hardware, and measure on your specific configuration and workload.

The breakeven picture depends on which API pricing tier you are comparing against. At the launch promo rate (~$1.20/M output tokens), none of the FP8 configs win at these throughput assumptions; 4x H200 FP8 would need roughly 1,690 tokens/second sustained to match it. At standard API rates (~$2.40/M output), the crossover point is roughly 840 tokens/second of sustained throughput on a 4x H200 spot config. INT4 on 2x H200 spot (~$1.69/M) beats the standard rate at ~600 tok/s and reaches the promo rate at roughly 840 tok/s, with quality tradeoffs and very little KV cache room.

For workloads below a few hundred tok/s average throughput, the hosted API is cheaper at any pricing tier. For batch jobs, overnight processing, or shared team deployments with concurrent users, self-hosting wins on cost once average throughput clears the crossover.

If your actual traffic is mostly short instruction-following or vision queries rather than 1M-context agentic coding, a dense single-GPU family is worth checking before committing to a multi-GPU M3 deployment: our Ministral 3 deployment guide covers Mistral's 3B, 8B, and 14B tiers that fit on a single L40S or RTX 4090 with built-in vision support.

Long-Context Tuning and Production Checklist

VRAM vs Context Budget Tradeoff

--max-model-len is the single most important flag for M3. Setting it to the model's theoretical maximum (1,048,576) reserves maximum KV cache allocation, which may leave insufficient VRAM for model weights on tighter configs. Set it to the 90th percentile context length of your actual workload:

A single 1M-context request at FP8 fits on 4x H200 (564 GB total), but only just. For 1M context with concurrent requests, use 8x H100 (640 GB, ~212 GB after weights) or 8x H200 (1,128 GB, ~700 GB after weights).

Throughput and Production Checklist

• FP8 KV cache enabled (--kv-cache-dtype fp8_e5m2)
• --max-model-len set to workload maximum, not theoretical limit
• --enable-chunked-prefill active for mixed-length request queues
• Expert parallelism enabled (--enable-expert-parallel or --moe-expert-parallel-size)
• Prometheus metrics endpoint enabled and scraped (/metrics)
• NVMe storage for weights (~430 GB for FP8 checkpoint, ~860 GB for BF16)
• GPU memory headroom verified with nvidia-smi before serving production traffic
• Spot vs on-demand decision logged: spot for batch, on-demand for SLA workloads

For detailed KV cache tuning strategies including FP8 quantization, --max-num-batched-tokens, and cache eviction policies, see the KV cache optimization guide. Once M3 is one of several models behind your API surface, whether that's routing between the self-hosted deployment and the hosted MiniMax API during a spot preemption or splitting traffic across M3 and other models by task, an AI gateway like LiteLLM, Portkey, or Kong handles that routing logic instead of hand-rolling it into the application layer.

MiniMax M3's MSA cuts 1M-context inference cost to a fraction of what full-attention alternatives require. A single 4x or 8x H200 node on Spheron gives you the VRAM to run all 428B parameters at FP8 without multi-node networking overhead.

H200 GPU pricing on Spheron → | On-demand H100 capacity → | View all GPU pricing →

Deploy M3 on Spheron →