MiniMax M3.1 Flash is live on Parasail as of launch day, October 19, and we're one of MiniMax's day-0 launch partners. MiniMax reports 73.7% on DeepSWE and 72.5% on AutomationBench-AA, the top AutomationBench score among open models. Getting a new model running on launch day is the easy part. Getting it to behave correctly under real agentic traffic, with long contexts, many concurrent sessions, tool calls and streaming, is where most of our launch work went.
TL;DR
- M3.1 Flash is available on Parasail at $0.15 per million input tokens and $0.60 per million output tokens. Try it at https://www.parasail.io/models/minimax-m31-flash.
- In an apples-to-apples AgentX comparison on NVIDIA B300, we serve up to +13.4% more total tokens per GPU than SemiAnalysis's state-of-the-art M3.1 Flash recipe at the same per-user speed (393 coding-agent traces; Parasail total throughput projected from measured output throughput).
- We rank #1 on OpenRouter for M3.1 Flash by P50 throughput, as of October 26th.
What's new in M3.1 Flash
M3.1 Flash keeps M3's backbone, including the 128-expert MoE and 1M-token context, and makes three changes that matter for serving:
- Sparse attention in every layer. M3 used dense attention in its first three layers. M3.1 Flash uses MiniMax Sparse Attention throughout, which lowers the cost of long contexts.
- 4-bit routed experts. The routed experts are NVFP4, trained with quantization in the loop rather than quantized afterward. The rest of the model keeps its previous precision.
- Its own speculative decoder. The checkpoint ships a multi-token DSpark drafter. M3 relied on third-party drafters.
We also serve M3.1 Flash with a 4-bit KV cache. Together with all-sparse attention, that brings KV memory per token to half, so long agent sessions stay resident on the GPU.
What we optimized for long agent sessions
Agent prompts grow every turn, and M3.1's 4-bit KV cache and sparse attention needed serving work that off-the-shelf engines didn't have. Three changes mattered most.
Tokenizing only the new part of the prompt. We cache the token IDs of segments we have already seen and tokenize only the new one. The IDs match a plain tokenizer exactly. Median time to first token on AgentX at 16 sessions fell from 388 ms to 158 ms.
KV cache offloading to host memory. Each cached page of M3.1 has five parts: 4-bit K and V, their scales, and the sparse-attention index keys. We move all five to host memory together and restore them byte for byte, compile the transfer kernels at startup, and copy a prefix to host memory only once it is reused. In a restore check, 64 of 64 tokens were identical after a host reload at 32K, 64K and 128K context. Compiling the transfer kernels at startup cut the worst first-eviction time to first token from 13.65 s to 0.89 s. On agent traffic, the server-side cache hit rate was 0.94 to 0.97.
Fused kernels for the sparse-attention layer. For short extends over a long context, sparse-attention prefill was waiting on the CPU. Our driver builds the attention plan once per forward pass instead of once per layer and fuses the index gather and dequantize into one launch. The kernels and output bits are unchanged. When an agent turn appends about 1K tokens to a 64K context, host time per layer fell from 306 µs to 139 µs.
Correctness. We run a tool-call correctness benchmark on every serving build before it ships, and we constrain every tool call to its schema while decoding. On the benchmark, schema mismatches (tool calls whose arguments fail the tool's schema) fell from 0.93% to 0.13%.
On OpenRouter's public tool-call error rate for M3.1 Flash, our rate is about 27% lower than MiniMax's own endpoint (2.03% against 2.78%).
A few bugs we found
The bugs that matter in agentic serving don't show up one request at a time. Two examples:
A race that only appeared at batch 8. With eight or more concurrent requests, speculative acceptance dropped and the output started repeating words. The cause was a timing race: a library kernel read its input before our own kernel had finished writing it, which single-request tests never catch. Fixing it restored speculative acceptance and stopped the repetition.
A rare freeze. Under load with 16 users, the server occasionally stopped responding. Each of the 4 GPUs made its own sampling decision, and once in a while they disagreed by one token: one GPU thought the answer was done, the other didn't, and they waited on each other forever. Now one GPU makes the decision and sends it to the others. Since the fix, the freeze has not come back in our soak tests.
What we chose not to fix. We fix anything that changes outputs, crashes or hangs. We leave alone differences between two equally valid computations, and we keep features off if they're correct but don't make anything faster.
Results
On one 4×B300 node with SemiAnalysis's InferenceX agentic replay (393 real coding-agent traces, around 100K input tokens per turn):
- 16 sessions: about 420 tokens/s per user, 0.09 s median time to first token
- 32 sessions: about 275 tokens/s per user, 0.11 s median time to first token
Measured on the released weights with our production build as of October 25.
In a 12-hour test on live traffic, every production request was served by vLLM, configured following SemiAnalysis InferenceX's recipe, and mirrored to our stack on the same B300 GPUs.
Across 18,252 paired requests our stack decoded 1.16× as fast per request (1.11× to 1.21× depending on concurrency) and reached the first token in 0.51 s against 0.70 s, both medians.
On the same InferenceX agentic replay, compared with vLLM's published results with both sides at the same speculative acceptance length, we were faster per user at every session count, by 0.9% to 8.3%. We produced up to 13.4% more output tokens per GPU (at 32 sessions; 1.3% fewer at 16) and had a 5.1× to 8.9× lower median time to first token. SemiAnalysis runs each point twice as long as ours and on a newer harness, and each point is a single run on both sides. Part of the time-to-first-token gap comes from the two runs sampling different session lengths, so treat that multiple as an upper bound.
We've run this process on every launch since Kimi and each launch adds new cases to the suite.
Run M3.1 Flash on Parasail
For developers
M3.1 Flash runs on our serverless endpoint at $0.15 per million input tokens and $0.60 per million output tokens, with cached input reads at $0.015. There are no minimums. The endpoint is OpenAI-compatible: point your existing client at https://api.parasail.io/v1 and set the model to parasail-minimax-m31-flash . Test it with the tool definitions, structured output and reasoning settings your application actually uses. Try it out on serverless.
For production teams
Dedicated capacity is available when you need guaranteed throughput, and Parasail has completed a SOC 2 Type II examination; the report is available under NDA through our sales team. Parasail does not retain your prompts or outputs. Talk to an engineer today.
