MiniMax M3 指南：用于长周期 AI Agent 的稀疏注意力机制

GLM 5.2 最近占据了 AI 领域的大部分讨论，焦点主要集中在其与 Opus 的对比上。这是头条新闻。但实际工作负载却讲述了一个更安静的故事：与我合作的开发者们一直在大规模使用 MiniMax M3，因为它能以极低的成本提供相当的长时程能力。事实上，在 Open Router 上，MiniMax M3 的 Token 使用量仍然比 GLM 5.2 高出 50% 以上。

来源：Open Router 排行榜

长时程 Agent 的主要限制并非智能，而是随着上下文增长而产生的注意力成本。 @MiniMax_AI M3 的设计就是为了消除这一限制。其 50 万 Token 的上下文窗口是开源模型中可用的最长窗口之一，但真正重要的能力是，在上下文不断增长的情况下，能够连续数小时专注于单一任务。M3 是多模态的，具备原生图像和视频理解能力，因此同一个 Agent 可以在一次运行中处理文本、代码和视觉输入。

Fireworks 的发布文章从基础设施角度阐述了同样的观点。它将 M3 描述为 Fireworks 上首个将前沿编程、原生图像和视频理解以及 50 万 Token 上下文窗口整合在一个系统中的开源模型。对于本文而言，Fireworks 在该发布文章中报告的实际声明才是关键。M3 的长上下文解码速度比 M2.7 快 15 倍，长上下文下每个 Token 的计算量降至 1/20，并且 Fireworks 引用了其在论文复现和 CUDA 内核优化任务上 12 到 24 小时的自主运行能力。

长时程任务要求很高，因为上下文会不断增长。一个持续数小时的 Agent 运行会积累代码、日志、工具输出和中间推理结果，而使用标准的密集注意力机制，每个新 Token 实际上都会重新读取所有这些内容。成本随长度的平方增长，因此 Agent 运行时间越长，每一步的成本就越高。这就是大多数长时间运行的 Agent 被过早终止的实际原因。

改变这一状况的机制是 MiniMax 稀疏注意力（MSA），在 MiniMax 最近的报告 MiniMax Sparse Attention 中有详细说明。MSA 改变了模型每一步读取的内容。在注意力计算之前，它会执行一个轻量级的预过滤步骤：一个索引分支对上下文进行分块评分，选择与当前 Token 最相关的块，然后模型只关注这些块。它读取的是索引而非整个库，这使得即使上下文增长到数十万个 Token，每一步的成本也大致保持平稳。

MiniMax 稀疏注意力：一个轻量级的索引分支对键值块进行评分，并为每个查询组选择 top-k 块，主分支仅关注这些块。来源： MiniMax Sparse Attention 论文。

如果你正在使用 M3 进行开发，这意味着：

任意长度下成本可预测。 论文设定 Bk = 128 且 k = 16，因此每个查询和 GQA 组选择 16 个块，即 2,048 个键值 Token。长时间运行仍会产生索引开销，但主要的注意力预算保持固定。
廉价的长上下文。 在论文的模型配置中，他们报告在极端序列长度下，与相同头设置下的密集 GQA 相比，每个 Token 的注意力 FLOPs 减少了 28.4 倍。
生产环境中速度快。 在 H800 上处理长序列时，他们报告预填充速度提升了 14.2 倍，解码速度提升了 7.6 倍。单独的 top-k 基准测试表明，在所有测试设置中，MiniMax 的专用内核比 torch.topk 和 TileLang 更快。
质量损失极小。 在 109B MoE 实验中，论文报告每个 Token 有 6B 活跃参数，并指出 MSA-CPT 在长上下文扩展后仍接近全注意力基线。它在 MMLU、GSM8K、HumanEval、RULER、HELMET 等多个基准测试上进行了评估，同时每个查询仅关注 2,048 个 Token。

随着序列长度增长，MSA 的每个 Token 注意力 FLOPs 和延迟几乎保持平稳，而密集 GQA（分组查询注意力）则急剧攀升：在极端序列长度下，计算量减少 28.4 倍，预填充速度提升 14.2 倍，解码速度提升 7.6 倍。来源： MiniMax Sparse Attention 论文。

这解锁了什么

有趣的部分不仅仅在于 M3 能容纳更多 Token。而在于长上下文变得足够廉价和快速，可以嵌入到需要随时间保持状态的迭代系统中。

自我改进的 Agent。 这是我首先会关注的应用。一个自我改进的 Agent 需要在提出下一步修改时，同时关注当前代码、之前的失败编辑、评估日志、基准测试结果以及自身的假设。稀疏注意力并不能解决评估问题，但它使得长时间运行的“提出、验证、修改”循环不太可能因上下文成本而崩溃。
仓库级工程。 Fireworks 强调了全仓库代码理解和强大的 Agent 编程能力。这很重要，因为实际的工程工作很少能塞进一个简洁的提示词中。跨代码库调试、追踪回归以及进行多文件修改，都受益于一个能在单次会话中保持仓库、测试输出和编辑历史活跃的 Agent。
科学和系统研究。 Fireworks 指出了在论文复现和 CUDA 内核优化上的长时间自主运行。这些是很有用的例子，因为工作本身不是一个单一的答案，而是一系列实验、日志、失败、修复和测量，其中连续性本身就是产品特性。
多模态长上下文工作流。 M3 是原生多模态的，而非仅文本加上视觉模块。它结合了长上下文与原生图像和视频理解能力，因此单次运行可以同时推理文本、代码、截图、图表和视频帧。这开启了从模型或截图到代码的视觉转代码、视频分析、多模态文档审查，以及那些在长时间会话中，能同时保持视觉上下文与代码和工具轨迹活跃的 Agent。

这就是为什么这个模型对开发者来说很有趣。它将长上下文从一个文档阅读功能，转变为一个为需要记忆、迭代和验证的 Agent 提供的执行基础。

值得注意的是，为什么现在才出现这个。MiniMax 在 M2 代就引入了稀疏注意力，但因为基础设施尚未成熟而搁置了。对于 M3，重点放在了内核上。MSA 将上下文划分为块，使用连续内存访问一次性读取每个块，并且只关注相关的块，这使得它在保持质量的同时，运行速度比其它开源的稀疏注意力方法快数倍。

这直接联系到我一直在关注的上下文工程工作。多年来，我一直鼓励开发者精心筛选进入上下文窗口的内容。MSA 是模型学会了在窗口内筛选它要关注的内容；同样的原则向下移动了一层，进入了架构层面。

对于开发者和研究人员来说，这就是一个简短演示和一个可靠工具之间的区别。这意味着一个 Agent 可以一次性读取整个仓库，在单次持续会话中跨整个代码库进行调试，或者将一项研究任务贯穿数小时的实验、日志和修订，而不会丢失上下文。在 MiniMax 自己的长时程运行中，最强结果往往出现在多小时的会话深处，远在大多数模型达到平台期并停止之后。可负担的长上下文正是赋予 Agent 这种持久性的关键。

这是我觉得最引人入胜的部分。我构建的 Agent 失败通常不是因为模型能力弱，而是因为它们无法维持一个长任务，而可靠的长上下文正是最终解决这个问题的底层基础设施。

如何开始使用 MiniMax M3

对于技术团队来说，@FireworksAI_HQ 的观点是可操作的。M3 的稀疏注意力设计只有在服务层能够在长上下文中保持延迟、吞吐量和成本稳定时才有用。Fireworks 表示它为 MiniMax 的第一方 API 推理提供支持，提供 MiniMax 模型系列中最快的端点，M3 定价为每 100 万输入 Token 0.60 美元起，并提供无服务器和按需部署选项。按此费率，M3 在类似使用场景下的成本比 GLM 5.2 低约 75%，这使得故事的重点不再是更大的上下文窗口，而是长时程 Agent 能否在经济上可行地投入生产。

这个定价很有用，因为它将 M3 重新定义为从 M2.7 的升级路径，而不仅仅是一个新的前沿模型。Fireworks 表示，开源模型的发布定价已降至与标准无服务器使用场景下的 M2.7 持平，因此团队可以在不支付高于上一代价格的情况下，获得 M3 的长上下文和原生多模态理解能力。

要测试 M3，请使用与其它 Fireworks 模型相同的 Fireworks 聊天补全端点。模型 ID 是 accounts/fireworks/models/minimax-m3，由于该模型是多模态的，单个请求可以在同一条消息中包含文本和图像 URL。

python

1import json
2import requests
3
4url = "https://api.fireworks.ai/inference/v1/chat/completions"
5
6payload = {
7    "model": "accounts/fireworks/models/minimax-m3",
8    "max_tokens": 32768,
9    "temperature": 0.6,
10    "top_p": 1,
11    "top_k": 40,
12    "messages": [
13        {
14            "role": "user",
15            "content": [
16                {"type": "text", "text": "你能描述一下这张图片吗？"},
17                {
18                    "type": "image_url",
19                    "image_url": {
20                        "url": "https://images.unsplash.com/photo-1582538885592-e70a5d7ab3d3?auto=format&fit=crop&w=1770&q=80"
21                    },
22                },
23            ],
24        }
25    ],
26}
27
28headers = {
29    "Accept": "application/json",
30    "Content-Type": "application/json",
31    "Authorization": "Bearer <FIREWORKS_API_KEY>",
32}
33
34response = requests.post(url, headers=headers, data=json.dumps(payload), timeout=120)
35response.raise_for_status()
36print(response.json())