On the day MiniMax M3 was open-sourced, Moore Threads S5000 completed Day-0 adaptation.

Domestic GPUs Didn’t Fall Behind This Time

On June 12, MiniMax released its next-generation native multimodal flagship model M3 to the open-source community. On the very same day, Moore Threads announced that its flagship all-in-one AI training/inference smart compute card MTT S5000 had completed Day-0 adaptation — developers could pull the M3 weights and run them directly on domestic cards.

This isn’t Moore Threads’ first Day-0 effort. Earlier this year, from DeepSeek-V4 and MiniMax M2.5/M2.7 to GLM-5.1, nearly every top domestic open-source model release saw Moore Threads complete adaptation and publish a technical blog the same day or next. A year ago, domestic GPUs were still chasing models, blaming hardware compatibility first when problems arose. Now they can run inference on release day and deliver performance-optimized versions within weeks. This shift in pace says more than TFLOPS numbers alone.

First, About MiniMax M3 Itself

To understand why adapting M3 is harder than its predecessor, we need to examine several key changes.

M3 is MiniMax’s first flagship model trained with multimodal integration from Step 0 — not the stitched-together approach of training text first and then adding a vision encoder, but feeding images, videos, and text together in a single token stream from the very first pretraining step. This means that during inference, operator workload distribution differs completely from pure-text models: visual tokens occupy a high proportion, sequence length is longer, and KV Cache access patterns are more fragmented.

Architecturally, M3 continues MiniMax’s own MSA (Mixed Sparse Attention) approach, mixing global attention and local sparse windows to scale context windows to the million-token level without exploding memory. The trade-off of MSA is that its operator structure differs from standard Transformers — mainstream inference frameworks have no ready-made fused kernels, so everyone must rewrite them.

This is why “Day-0 adaptation” still carries weight. The more the architecture diverges from standards, the more valuable it is to be the first to get the operators working and capture the initial wave of try-outs.

What MTT S5000 Did

Moore Threads matched M3’s pain points one-by-one in its hardware specs and optimization path:

• Compute power: MTT S5000 delivers 1000 TFLOPS dense FP8 performance per card, with hardware-level native FP8 acceleration. Since M3 uses FP8 extensively for inference, this fits perfectly.
• Memory and bandwidth: 80GB HBM and 1.6TB/s bandwidth. In million-token context scenarios, KV Cache easily takes up tens of GB, and fully loaded bandwidth is the norm — this setup is clearly designed for “long context on a single card.”
• Operator migration: MUSA C++ and Triton-MUSA abstraction layer. Triton-MUSA is critical, enabling developers to write Triton kernels once and run them directly on MUSA without rewriting CUDA for every card. M3’s new MSA operators could run on Day-0 thanks to this abstraction.

At the framework level, Moore Threads simultaneously brought up both vLLM and SGLang — a deliberate choice. vLLM is the de facto standard in industry deployment for batch serving and PagedAttention; SGLang is more aggressive in structured output, agentic workflows, and RadixAttention cache reuse. Since M3 is geared toward programming and agent scenarios, SGLang support is almost a must-have.

Coding and Agents — Battlegrounds for Both M3 and S5000

MiniMax’s M3 generation focuses on two areas: code generation and agent invocation. These scenarios have counterintuitive requirements for inference infrastructure —

They may seem to have smaller token outputs, but prefill stages have extremely long contexts (stuffing in the entire codebase or toolchain documentation), and multi-turn interactions lead to extremely high KV Cache reuse. In an agent task, the context stays nearly the same in the first few turns, and recalculating prefill each time wastes huge resources.

In its adaptation blog, Moore Threads mentioned custom native operators for M3, improving throughput and reducing latency without loss of precision. Combining previous experience adapting DeepSeek-V4 and GLM-5.1, they’ve formed a methodology for optimizing “long prefill + short decode + high cache reuse” scenarios. This direction is correct — stacking compute to boost MMLU scores is pointless, real agent workloads are a different game.

Full Precision Coverage — From R&D to Deployment

Worth highlighting is MTT S5000’s precision matrix — FP8 to FP64 coverage.

This isn’t common in AI inference cards. Most inference cards slash FP32/FP64 performance for efficiency and focus on FP16/INT8. But MTT S5000 retains FP64 for scientific computing and HPC scenarios; FP32 for fine-tune training; FP16/BF16 for standard inference; FP8 for cutting-edge flagship inference workloads.

Behind this is a practical choice for domestic cards: users want one card usable from model R&D to commercial deployment, without buying different hardware for different precisions. S5000’s configuration is a real “training + inference integration,” not just a slide-deck concept.

Deployment Experience — MUSA + vLLM/SGLang

For developers, the key question is “Can I use it right now?” The answer: Yes.

Using the MUSA software stack with vLLM or SGLang, the deployment path is already clear. Points to note:

• MUSA SDK version: Upgrade to the latest stable version — M3’s operator optimizations ship with the SDK, older versions can run but show a clear performance gap.
• Framework choice: For pure chat/completion, vLLM is easier; for agents, function calling, and structured output, SGLang’s RadixAttention saves much redundant prefill work.
• Long context tuning: In million-token scenarios, KV Cache quantization, PagedAttention block size, and prefix caching switches should be tuned to workload — defaults aren’t optimal.

Moore Threads says it will continue releasing operator-level performance optimization patches — this is important in the domestic GPU space, because Day-0 readiness is only the starting point; iteration speed in the following weeks determines whether it truly enters production.

A Bigger Trend

From an industry perspective, the first half of 2026 has been noteworthy: domestic open-source large models are releasing faster, with DeepSeek, MiniMax, Zhipu, and Step all delivering major versions almost quarterly; domestic GPU Day-0 adaptation has become standard practice — if you can’t run the model on release day, you’ve failed.

This closed loop signals the end of the era when “domestic models can only run on H100.” Not that performance is fully equal, but the three thresholds — “usable, easy to use, production-ready” — have been crossed. For developers, more options mean more bargaining power.

Incidentally, OpenAI Hub now supports invoking MiniMax M3 via a unified key, compatible with the OpenAI format, and directly accessible domestically. If you just want to test M3 before deciding on self-hosting inference, you can use the API; for large-scale deployment, consider Moore Threads’ domestic solution. The two paths aren’t mutually exclusive.

Final Note

MTT S5000 + M3 might look like an ordinary adaptation announcement, but over the past 12 months, domestic AI compute stacks have rapidly approached mainstream levels in adaptation speed, framework ecosystem integration, and precision coverage.

The remaining question is performance — for equal batch size and context length, how does S5000’s throughput and latency on M3 compare to H100/H200? Moore Threads hasn’t disclosed this yet, but will likely post benchmarks in future blogs. Once we see them, we can judge the true strength of this Day-0 effort.

References

• ITHome: Day-0 support — Moore Threads completes adaptation of MiniMax M3 large model — full disclosure of MTT S5000 hardware specs and adaptation technical details