MiniMax M3：稀疏注意力如何让长周期智能体真正实用
近期AI领域的讨论大多围绕GLM 5.2展开，主流话题都是它和Opus的性能对比。那是头条新闻。实际工作负载则讲述了一个更安静的故事：与我合作的开发者一直在大规模使用MiniMax M3，因为它能提供相近的长周期能力，成本却低得多。事实上，MiniMax M3在Open Router平台的令牌使用量仍比GLM 5.2高出50%以上。
来源：Open Router排行榜
限制长周期智能体发展的主要因素从来不是模型智能，而是不断增长的上下文带来的注意力计算成本。MiniMax M3就是为消除这一限制而设计的。它拥有50万令牌的上下文窗口，是目前开放权重模型中最长的窗口之一，但真正重要的能力是：在上下文不断增长的情况下，连续数小时专注于单个任务。M3是原生多模态模型，自带图像和视频理解能力，因此同一个智能体可以在一次运行中同时处理文本、代码和视觉输入。
Fireworks的发布文章也从基础设施角度印证了这一点。它将M3描述为Fireworks平台上第一个将前沿代码能力、原生图像和视频理解以及50万令牌上下文窗口整合在同一个系统中的开放权重模型。对于本文而言，Fireworks在那篇发布文章中报告的实际数据最为关键：M3的长上下文解码速度比M2.7最高快15倍，长上下文场景下单令牌计算量降至M2.7的二十分之一，Fireworks还提到在论文复现和CUDA内核优化任务中实现了12至24小时的自主运行。
长周期任务之所以要求极高，是因为上下文从未停止增长。一次多小时的智能体运行会积累代码、日志、工具输出和中间推理结果，而使用标准密集注意力时，每生成一个新令牌实际上都会重新读取所有已有内容。计算成本随上下文长度的平方增长，因此智能体运行时间越长，每一步的成本就越高。这就是大多数长运行智能体被迫中断的实际原因。
改变这一局面的机制是MiniMax稀疏注意力（MSA），详见MiniMax最近发布的报告《MiniMax Sparse Attention》。MSA改变了模型每一步的读取范围：在注意力计算之前，它会先运行一个轻量预过滤步骤——一个索引分支对上下文进行分块打分，选出与当前令牌最相关的块，模型只对这些块进行注意力计算。它读取的是索引而非整个库，这样即使上下文增长到数十万个令牌，每一步的成本也大致保持稳定。
MiniMax稀疏注意力：一个轻量级索引分支对键值块进行打分，并为每个查询组选出top-k块，主分支仅关注这些块。来源：MiniMax Sparse Attention论文
如果你正在使用M3进行开发，这意味着：
- 任意长度下成本都可预测。论文设置Bk=128，k=16，因此每个查询和GQA组选择16个块，即2,048个键值令牌。延长运行仍会有索引开销，但主要注意力预算保持固定。
- 长上下文成本极低。在论文的模型配置中，与相同头设置下的密集GQA相比，极端序列长度下单令牌注意力FLOPs减少了28.4倍。
- 生产环境中速度快。在H800长序列测试中，预填充速度提升14.2倍，解码时钟速度提升7.6倍。独立的top-k基准测试显示，MiniMax的专用内核在所有测试设置中均快于torch.topk和TileLang。
- 质量损失极小。在109B MoE实验中，每令牌激活60亿参数，论文报告称经过长上下文扩展后，MSA-CPT仍接近全注意力基线。它在MMLU、GSM8K、HumanEval、RULER、HELMET等众多基准上进行了评估，而每个查询只关注2,048个令牌。
随着序列长度增长，MSA的每令牌注意力FLOPs和延迟几乎保持平稳，而密集GQA则急剧攀升：极端序列长度下计算量减少28.4倍，预填充速度提升14.2倍，解码速度提升7.6倍。来源：MiniMax Sparse Attention论文
这解锁了什么
有趣的不只是M3能容纳更多令牌，而是长上下文变得足够便宜、足够快，可以嵌入需要随时间保持状态的迭代系统。
- 自改进智能体。这是我最先关注的第一个应用。自改进智能体需要在提出下一次修改时，始终保留当前代码、之前失败的修改、评估日志、基准测试结果及其自身假设。稀疏注意力不会解决评估问题，但它能让持续的“提出-验证-修改”循环更不容易因上下文成本过高而崩溃。
- 仓库级工程开发。Fireworks强调全仓库代码理解和强大的智能体编码能力。这很重要，因为实际工程工作很少能压缩进规整的提示词中。跨代码库调试、跟踪回归问题、修改多文件，这些都需要智能体在同一会话中保留整个仓库、测试输出和编辑历史。
- 科学与系统研究。Fireworks提到在论文复现和CUDA内核优化任务中的长时间自主运行。这些是很实用的例子，因为此类工作不是给出单个答案，而是一连串的实验、日志、失败、修复和测量——连续性本身就是产物特性。
- 多模态长上下文工作流。M3是原生多模态模型，并非在文本模型后附加视觉模块。它将长上下文与原生图像和视频理解相结合，因此单次运行就能同时推理文本、代码、截图、图表和视频帧。这为从原型或截图生成代码、视频分析、多模态文档审核等场景打开了空间，也让智能体能在长时间会话中，将视觉上下文与代码和工具痕迹一并保持。
这就是为什么这个模型对开发者来说很有吸引力。它将长上下文从一个文档阅读功能，转变为需要记忆、迭代和验证的智能体的执行基底。
值得指出的是，为什么这一技术现在才到来。MiniMax在M2一代就引入了稀疏注意力，但当时基础设施不够成熟，因此搁置了。对于M3，重点放在了内核上。MSA将上下文分块，通过连续内存访问单次读取每个块，只关注相关的块，因此在保持质量的同时，速度比其他开放稀疏注意力方法快数倍。
这直接关联到我多年来一直关注的上下文工程工作。我一直在鼓励开发者精心筛选进入上下文窗口的内容。MSA是模型学会在窗口内自动筛选关注内容——同样的原则只是下沉到了架构层面。
对于开发者和研究者来说，这是短演示和可靠工具之间的区别。这意味着一个智能体可以一次读取整个仓库、在单次持续会话中调试整个代码库、或通过数小时的实验、日志和修订推进研究任务而不丢失上下文。在MiniMax自己的长周期运行中，最强结果往往出现在多小时会话的后期，远在大多数模型早已进入平台期并停止之后。可负担的长上下文正是赋予智能体这种持久性的东西。
这是我觉得最令人信服的一点。我开发的智能体通常失败不是因为模型能力不足，而是因为它们无法支撑长任务。可靠的长上下文正是从根本上解决这个问题的基础设施。
如何开始使用MiniMax M3
对于技术团队来说，Fireworks AI的切入点具有可操作性。M3的稀疏注意力设计只有在服务层能维持长上下文的延迟、吞吐量和成本稳定时才能发挥效用。Fireworks表示，它本身就为MiniMax的第一方API推理提供支持，提供MiniMax模型系列中速度最快的端点，M3定价为每百万输入令牌0.6美元起，支持无服务器和按需部署选项。按照这个费率，M3在同等使用量下比GLM 5.2便宜约75%，这使得这个故事的核心不再是更大的上下文窗口，而是长周期智能体能否在经济上可行地运行于生产环境。
这个定价很有用，因为它将M3重新定位为从M2.7升级的路径，而不仅仅是又一个新的前沿模型。Fireworks表示，开放权重发布定价已降至与标准无服务器使用场景下的M2.7持平，因此团队可以在不支付比上一代更高成本的情况下，获得M3的长上下文和原生多模态理解能力。
要测试M3，使用与Fireworks其他模型相同的聊天补全端点。模型ID是accounts/fireworks/models/minimax-m3。由于模型是多模态的，单个请求可以在同一条消息中同时包含文本和图片URL。
对于更复杂的智能体或推理任务，可以在请求负载中添加"thinking": {"type": "enabled"}。对于生产工作负载，Fireworks将无服务器部署定位为最快的评估路径，按需部署则适合需要稳定吞吐量的场景。
在此处尝试：Fireworks AI