匿名代号揭面两天后就开源：M3.1 Flash 的发布节奏为什么这么赶

匿名代号揭面两天后就开源：M3.1 Flash 的发布节奏为什么这么赶

【免费下载链接】MiniMax-M3.1-FlashMiniMax-M3.1-Flash 是一款原生多模态混合专家（MoE）模型，面向编程、智能体工作流、计算机使用和网络安全等场景。它支持文本、图像和视频输入，上下文窗口最高可达 100 万 tokens。 在 MiniMax-M3 的基础上，M3.1-Flash 通过全模型稀疏注意力、量化感知训练和 DSpark 投机解码，进一步提升了任务表现与推理效率。项目地址: https://ai.gitcode.com/MiniMax-AI/MiniMax-M3.1-Flash

过去一个月，开发者圈子里流传着一只"神秘的兔子"。9 月下旬，一个叫 Space Bunny 的匿名模型悄悄出现在 OpenCode 的模型列表里，没有厂商署名、没有跑分榜单、甚至没有公开定价。但它硬是靠真实调用量，在 9 月 24 日到 10 月 5 日连续 12 天霸占该平台每日 Token 使用量榜首——9 月 30 日单日处理量冲上 10 万亿 Token，9 月 28 日 OpenCode 官方还在发帖庆祝它"连续 5 天第一、累计 40T Token"。

10 月 19 日，MiniMax 正式认领：Space Bunny 就是 M3.1 Flash 的早期版本，官方确认截至揭面时累计处理量已超过 200 万亿 Token。两天后（10 月 21 日）官方发布帖挂出完整基准表，再两天（10 月 23 日）权重直接开源——也就是你正在看的这个仓库。从"官方发布"到"权重落地"只隔 48 小时，从 API 上线到开源全程 4 天。

这个节奏在大模型行业里相当罕见。本文基于仓库源码、官方配置与社区可查证的时间线，回答三个问题：这条时间线到底怎么拼出来的；"先跑调用量、再放权重"的顺序背后是什么工程取舍；以及今天（权重刚放出来的 10 月 23 日），普通开发者还剩多少信息差可以捡。

一、时间线还原：从 Space Bunny 到开源的三幕

把散落在社区报道、平台数据和仓库本身里的线索拼起来，完整时间线如下：

时间	事件	关键数据
9 月下旬	Space Bunny 匿名接入 OpenCode，无厂商署名、无跑分、无定价	9/24 单日 6.8T → 9/30 单日 10T Token
9/24–10/5	连续 12 天霸榜 OpenCode 每日 Token 用量	9/28 官方帖：连续 5 天第一、累计 40T
9/30 前后	M3.1-Flash-Preview 已在 API 侧可调用，社区出现实测文	1M 上下文、五档推理强度
10/17	对手窗口：DeepSeek V4.1 Flash-1017 发布	与 M3.1 Flash 发布相隔 48 小时
10/19	MiniMax 认领 Space Bunny，M3.1 Flash 上线 API	累计 200T+ Token；输入 1 元 / 输出 4 元 / 缓存 0.1 元（每百万 Token）
10/21	官方发布帖挂出完整基准表，预告"权重 10 月 23 日放出"	DeepSWE v1.1 73.7、OSWorld V2 61.7、CyberGym 82.2
10/23	权重开源（本仓库），芯片生态 Day-0 同步落地	API 上线 3 天内处理超 100T Token；FlagOS 提供 9 家芯片厂商 W8A8 版本

有三个细节值得展开。

第一幕：匿名期的"跑分"是流量，不是分数。在 MiniMax 认领之前，这只兔子没有任何官方基准，社区靠两条独立证据给它定位：一是 OpenCode 的公开日用量表（12 天榜首），二是第三方 AI Coding 榜单上"Space Bunny Max 档 + OpenCode"组合约 57/80 的成绩——与同期的 Gemini 4 Argon High、Kimi K3 High 处在相邻区间。也就是说，在官方贴出任何分数之前，开发者已经用真金白银的调用量和第三方评测把它排进了第一梯队。

第二幕：揭面日的数字密度是刻意的。10 月 19 日认领当天，官方同时给出三组数字：累计 200T+ Token（证明稳定性）、Agent 任务综合成本下降 70%（证明性价比）、200+ TPS 且 P50 稳定在 170+ TPS（证明速度）。注意口径：70% 的降本对应的是 Agent 任务"综合使用成本"，不是每一档单价统一打三折——对照同系列的 M3 标准档，输入和输出单价各降约 52%，缓存读取降约 76%，三者叠加加上推理提速，才合成"70%"。

第三幕：开源不是终点，是第二次造势。10 月 23 日权重放出时，官方口径是"上线三天处理超 100 万亿 Token，今日正式开源"——把吞吐量指标和权重发布捆在一起传播。仓库本身的 git 历史也印证了这种"一次性投放"：整个仓库只有一个初始提交，日期就是 10 月 23 日，没有任何中间版本、没有权重逐步补齐的痕迹。48 个model-*-of-00048.safetensors分片、dspark/目录里的 draft head、以及model.safetensors.index.json索引，在同一天齐活。

二、为什么先跑调用量、再放权重：顺序背后的取舍

把时间线倒过来看，这个顺序几乎是"被工程现实逼出来的"，每一环都有对应理由。

匿名期其实是生产级压测

M3.1 Flash 是 428B 总参数、每 token 激活约 23B 的 MoE，配 100 万 token 上下文（config.json 中max_position_embeddings: 1048576）。这种规格的模型，KV Cache 管理、稀疏注意力的边界行为、长上下文下的吞吐抖动，都不是评测集能暴露的。在 OpenCode 这类真实开发工具里裸跑两个月、累计 200T+ Token，等于让开发者免费帮它完成了 7×24 的压力测试——包括缓存命中率、并发限流、超长输入的稳定性这些只有真实流量才能打出来的问题。揭面时敢直接喊"Agent 任务成本降 70%""200+ TPS"，底气来自这段时间的线上数据，而不是实验室数字。

真实调用量是发布前最硬的"跑分"

社区里有一个现象值得注意：Space Bunny 匿名上线时是"零跑分、零价格"状态，社区因此产生了一大批反向分析文章——从系统提示词注入、角色一致性一直猜到"太空兔"是有意埋的产品彩蛋（甚至出现了完全虚构的"space_rabbit.bin 完整性协议"这类谣言帖）。信息差本身成了流量入口：12 天的调用量霸榜比任何榜单都更能说明"有人在大量用它"，而悬念维持了两周的话题热度。这本质是一次零付费投放的病毒传播，代价是信息噪音——但 MiniMax 显然算过这笔账。

开源是生态锁定，Day-0 就是证据

权重放出只有 4 天窗口，但配套生态一天没缺。这一点在本仓库里有直接证据：

• docs/FlagOS-Multi-Chip-Support-and-Downloads.md 显示，权重开源当天，FlagOS 社区已为平头哥、NVIDIA、沐曦、海光、华为昇腾、摩尔线程、天数智芯、昆仑芯、青稞微共9 家芯片厂商的平台提供了 W8A8 量化部署版本，且明确写了部署流程与tensor_parallel_size等启动参数示例；
• README_zh.md 中 SGLang cookbook 与 vLLM recipe 在开源时点均已存在；
• dspark/目录直接附带了投机解码所需的 draft head 权重（model-dspark-00001.safetensors），而不是"权重先发、推理优化后补"。

换句话说，这次"开源"交付的不是一堆参数文件，而是一套可部署包：QAT 量化好的权重 + draft head + 多芯片适配方案。权重早一周晚一周放，对生态没有本质影响；但 API 先跑量、权重后放出，能同时保住 10 月 19 日到 23 日这几天的 API 独占窗口（期间官方还给了 MiniMax Code 订阅用户限时不限量活动），并把开源本身做成第二个传播节点。

赶节奏的代价：验证窗口被压缩

这个顺序并非没有风险。发布节奏一快，第三方独立验证的窗口就被压缩：10 月 21 日才挂出完整基准表，社区独立实测（比如 10 月 21 日"Claude Code 接 DeepSeek V4.1 与 M3.1 Flash"的对比文）基本与权重开源同步才展开。另外基准表本身也有版本口径问题——README_zh.md 的"评测说明"里逐项标注了不同评测使用的工具版本（BankerToolBench 用 OpenCode 1.17.18、CyberGym 用 Claude Code 2.1.263 1M 上下文等），横向对比时这些脚注比分数本身更该被读。

三、源码级核对：4 天里到底开源了什么

权重文件之外，仓库里的配置文件把"M3.1 相对 M3 改了什么"写得相当清楚。

全模型稀疏注意力真的落到每一层了。config.json 中sparse_attention_config.sparse_attention_freq是一个 60 长度的数组，值全为 1——对应 README 中"前三个全注意力层替换为稀疏注意力"的说法：M3 尚有 3 层保留全注意力，M3.1 Flash 里 60 层全部走 MiniMax Sparse Attention（MSA）。具体参数是sparse_block_size: 128、sparse_topk_blocks: 16、sparse_num_index_heads: 4，即每个 query 只挑选 16 个长度为 128 的 KV 块做注意力。这正是"1M 上下文还能 200+ TPS"的计算基础：长上下文的 prefill 不再是全量二次复杂度。

量化不是后加的，是训练期做的。同一文件的quantization_config显示：主干quant_method: mxfp8（weight_block_size: [1, 32]、动态激活量化），MoE 专家单独走moe_quant_algo: NVFP4（nvfp4-pack-quantized格式），而gate、embed_tokens、lm_head、multi_modal_projector、vision_tower等敏感层被列进ignored_layers保持高精度。QAT（量化感知训练）+ 混合精度策略意味着这套权重就是最终部署形态，不存在"先放 BF16、再补量化"的二次开源。

DSpark 投机解码是这次架构里最值得看的新部件。dspark/config.json 完整描述了 draft 模型：5 层、block_size: 7（一次起草 7 个 token）、markov_rank: 256的马尔可夫头、enable_confidence_head: true（带置信度头决定接受多长的 draft）、上下文取自目标模型的 5 个层（dspark_target_layer_ids: [3, 17, 31, 45, 59]，均匀分布在 60 层里）、滑动窗口 4096。README 明确说 DSpark 取代了 M3 时代的"类 EAGLE MTP 方案"——草稿模型从多头 MTP 换成了带马尔可夫建模 + 置信度头的独立 draft head，且 draft 全程 BF16（dspark_aux_gemm_precision: bf16），因为它的开销要小到可以被目标模型一次前向"摊平"。

推理档位写进了 chat template。chat_template.jinja 第 85–89 行处理reasoning_effort变量，渲染为<effort>{low|medium|high|xhigh|max}</effort>注入 system 段；思考模式默认adaptive（模型自行决定本轮是否思考），思考内容统一包在<mm:think>标签内；工具调用采用 XML 风格的 `

【免费下载链接】MiniMax-M3.1-FlashMiniMax-M3.1-Flash 是一款原生多模态混合专家（MoE）模型，面向编程、智能体工作流、计算机使用和网络安全等场景。它支持文本、图像和视频输入，上下文窗口最高可达 100 万 tokens。 在 MiniMax-M3 的基础上，M3.1-Flash 通过全模型稀疏注意力、量化感知训练和 DSpark 投机解码，进一步提升了任务表现与推理效率。项目地址: https://ai.gitcode.com/MiniMax-AI/MiniMax-M3.1-Flash