如何看待 Minimax 新的 M3 多模态模型以及更新的 Token Plan?
最近发布的大模型数量还挺多的，比如刚刚发布的MiniMax M3，还有前段时间的DeepSeek V4，Claude Opus 4.8，Gemini 3.5 Flash，Qwen 3.7 Max，基本上每个模型都强调了自己的 Agentic Coding 能力。那其实如果仔细看的话，大家有一个共同点，那就是他们都把 Context 上下文长度的 baseline 干到1M。
特别是回想过去的这几年，特别是从 2023 年起，GPT-3.5 那个阶段的上下文也就 4K，也就是几千的中文，短短的两年多就到了 200K。
然后在 2024 年开始出现了一个 million，但是那个时候的一个 million 其实是非常昂贵的。那时候依旧采用很多还是采用 Full Attention。到现在 2026 年，才把一个 million 的上下文长度做成了标配，其实这里面最重要的就是稀疏注意力的架构创新。
MiniMax M3 的这个模型，实现了三点：Agentic Coding、100 万上下文、原生多模态，每个都延续了M2.7的优异性能，在现在强调生产力的场景下表现都很能打。
其实仔细想想，这里面最重要的基石就是 MSA（MiniMax Sparse Attention）。这个技术是整个模型最基础的核心，因为只有上下文长度上去了，才能够直接去处理复杂任务以及多模态内容（毕竟多模态内容的 Token 占比往往会比较多）。
对于稀疏注意力来讲，其实同行的策略也有很多，不过MSA的设计思路更加化繁为简，对于硬件非常友好。当然了，在开源模型里面:
DeepSeek 有自己的 DSA
Kimi 有自己的 MoBA
它们的出发点其实是一致的:Full Attention的 在成本太高，所以都得尽量让每个 query 去注意真正相关的那一小部分KV,把复杂度压到 。
技术路线的区别在于"以多大的颗粒度来挑"。
这里有两派:MoBA、MSA 把 KV 切成块、以"整块"为最小选择单位；而 DeepSeek 的 DSA 用一个轻量 indexer给每个 token 打分、直接挑 top-k 个 token(细到单个 token)。粗有粗的硬件友好,细有细的选得准——这本身就是一组耐人寻味的权衡。
而在 block 这条路上,MoBA、MSA 两个真正的分水岭也不在"选块",而在"怎么给一个块打分"：MoBA 取块内均值(mean-pool)，而 MSA 的答案是—块内取最高分(max-pool)。
我们先来看一下 MSA 的架构，整体上是GQA-based Attention Block，主要有两步—Step 1 Index Branch 做block粒度的粗筛，Step 2 Sparse Branch 在选中块上做full注意力。
在钻进公式之前,先说我对这套结构的整体理解:它本质是"先派一个侦察兵粗看一遍、圈出重点区域,大部队再只往重点区域投入兵力"。
侦察兵要快、可以糙(低维粗筛),大部队要准、不能省(全精度注意力)——把"决定看哪里"和"真正去看"拆成两件事、用两种成本去做,这就是 MSA的总思路。
第一步就是Index Attention，这一步就是我理解的"侦察兵"。它的任务不是算注意力,而是用最低的成本,给每个 KV 块打个分:这块里有没有我要的东西。
具体到技术细节,架构图是这么做的:KV 按固定 block_size 切块,这一支不直接对原始 K 打分,而是先走一次低维 Index Attention——用一组专门的低维
第二维是 1——对应图上标注的 "One index query per GQA group":不是每个 head 各自选块,而是一个 GQA group 共用一条 index query 选块,选块成本因此摊到组粒度而非头粒度。然后先算低维相关度图 ,按块做 max pool 得块得分,再 TopK 选出块索引。
稀疏注意力正是靠增加这个初筛阶段来避免复杂度爆炸。
我觉得这里面还有一个点非常重要，就是 Block Max Pool。为什么要用 Max Pool 而不是用均值池化层呢？我的直觉是：判断一个块值不值得看的标准，应该是这个块里是否有某句话直接命中了我们需要的答案，而不是看这个块平均和我有多相关。
长上下文检索的本质，就是在的一大堆噪声里，可能只有一个地方是有用的。一个块里 99% 甚至更多内容可能都是废话，也许只有几个 token 是答案。如果按平均分来看，这个信息就很容易被一堆废话稀释掉，导致整块都被丢弃。
如果按照最高分（Max Pool）的策略这个块就能保住。我觉得 MSA 选择后者，可能就是它“很难忘掉”的机制根源。
第二步是Sparse Branch，这就是"大部队"。第一步的侦察兵圈好了重点块，大部队不再满世界找，只对那几个被选中的块做Full Attention，其余的块直接当不存在。
省下的算力和访存,全来自"被丢掉的那一大半块根本不进计算"。
第二支用完整查询头 ,配合 Step 1 的索引 ,只在选中块上做 full attention。
之前的 Full Attention 做法其实就是为了防止丢掉信息，因为在很多任务上，丢掉信息的代价可能要比省掉的开销更大。这也是为什么有些模型的 API 会如此之贵，因为它们的所有部分都采用了 Full Attention。
但随着 Context 长度的增加，Full Attention 肯定是不可持续的，因为算法优化往往需要经历从 到 这样的阶段。其实 MSA 最核心的点就在于选出来的块是否足够精准。如果足够精准，那么这套打法就是非常有效的。
为了验证这一点儿，我测试了从 64K 到接近 512K 上下文。测试中选择了“多帧”的“大海捞针”（Needle In A Haystack）测试，进行了深度扫描和跨段聚合查询，并采用了不同深度的测试方法。
我的结果是在所有规模上都成功了，包括比较复杂的“多帧”抑制检索以及跨段聚合查询。在所有规模上都没有翻车。
| 实测 input_token | 延迟 | 多针 verbatim | 跨段聚合（求和 3800） | 深度 0→100% |
|---|---|---|---|---|
| 64,526 | 8.8s | 3/3 | 通过 | 全 Y |
| 128,925 | 13.1s | 3/3 | 通过 | 全 Y |
| 257,726 | 17.8s | 3/3 | 通过 | 全 Y |
| 515,310 | 47.7s | 3/3 召回（逐字 2/3*） | 通过 | 全 Y |
当然也不是完全没有瑕疵，在接近 512K 的测试中：90% 深度的人名 "Dr. Liang Whitmore" 被输出成 "dr. Liang whitmore"，逐字2/3那个地方。
可以说，能记住的上下文，才算真正的上下文。在我测到的范围内,MSA这套"块内取最高分"的逻辑是验证过成立的。考虑到现在能够广泛支持 1 million 上下文的模型还不多，我觉得 MiniMax 把这套方法拿出来，在开源大模型领域逐渐有封闭的趋势下这种依旧在技术领域里面深耕、追求技术深度的打法，是非常值得鼓励的。