# MiniMax M3.1 Flash Open Weights: License and Deployment Requirements

MiniMax's downloadable model is here, but the commercial license and hardware-specific serving recipes matter as much as the benchmark table.

By Paras Madan | 2026-10-23


MiniMax released M3.1 Flash's downloadable weights on October 23, following its earlier API launch. Teams can now evaluate running the multimodal model on their own infrastructure. The practical questions are different from API pricing: which hardware can serve it, which features survive that configuration, and what the license permits.

The [release announcement](https://x.com/MiniMax_AI/status/2113452026902589732) confirms that the weights are available now. This is the promised model release, rather than another announcement of future availability.

## What is available to download

The [official model repository](https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash) describes a mixture-of-experts model with approximately 428 billion total parameters and 23 billion activated per token. It accepts text, images and video, produces text, and supports a context window of up to one million tokens.

The checkpoint includes the DSpark draft head for speculative decoding. MiniMax recommends SGLang, vLLM and TokenSpeed serving routes; its model card lists Transformers, KTransformers, Unsloth and ATOM integrations as still in progress. A repository tag should not be mistaken for a completed integration.

Downloadable weights give a team control over the serving environment. They do not make a model of this size a normal single-GPU application. The active parameter count describes the computation selected for a token, not the complete set of weights that a deployment needs to accommodate.

## The MiniMax community license has commercial conditions

The repository uses the [MiniMax Community License](https://huggingface.co/MiniMaxAI/MiniMax-M3.1-Flash/blob/main/LICENSE), not an Apache or MIT license. Its commercial-use provisions require visible MiniMax attribution and a one-time notice. Products and services generating more than $20 million in yearly revenue require separate prior written authorization instead.

The license also contains prohibited-use conditions. These are material deployment terms, so a team planning commercial use should read the full license and check its own situation before proceeding. Access to the files alone is not a substitute for that review.

**Open weights and unrestricted commercial use are different questions.** For a startup comparing a hosted API with its own deployment, license review belongs alongside the infrastructure estimate, rather than at the end of the engineering work.

## Hardware changes the usable feature set

The [vLLM deployment recipe](https://recipes.vllm.ai/MiniMaxAI/MiniMax-M3.1-Flash) provides separate configurations for Blackwell, AMD MI355X and Hopper hardware. Its Blackwell and MI355X examples use four-way tensor parallelism. The Hopper example uses eight H100 or H200 GPUs.

More importantly, the published Hopper configuration caps context at 262,144 tokens, disables video inputs and does not enable DSpark speculative decoding. Images remain supported. Those are properties of that recipe, not a claim that every possible Hopper deployment has identical limits.

The recipe also distinguishes memory needed to load weights from the larger serving budget required for context and concurrency. A server that starts successfully has passed only the first test. It still needs room for the conversation state of simultaneous requests.

This changes how a comparison should be designed. If a product needs long videos or very large document collections, test those workloads on the exact hardware and serving configuration being considered. A model-level capability list is too broad to answer whether a particular deployment can support the product.

## What to measure before replacing an API

A useful evaluation should begin with complete tasks rather than isolated token-speed measurements. For a coding agent, include tool calls, reasoning output, retries and the final acceptance check. Measure elapsed time and cost per accepted result at realistic concurrency.

Self-hosting also makes utilization part of the economics. A dedicated machine costs money while waiting for work, and an overloaded one can create queues even when individual generations are fast. Compare the service at the traffic pattern you actually expect, including quiet periods and bursts.

There is a second comparison worth making: the same task through the existing API and through the proposed local stack. Differences can come from sampling settings, parsers, context limits or serving optimizations, so a failed task does not immediately isolate the model as the cause.

The release makes that investigation possible. The useful outcome is a reproducible deployment that meets a workload's cost, latency and quality requirements, not merely a downloaded checkpoint with an attractive benchmark score.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI teams explain model releases, deployment choices and technical tradeoffs in content that developers and founders can use and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).