长时任务要求很高，因为上下文会不断增长。智能体工作的时间越长，每一步的成本就越高。MiniMax Sparse Attention 改变了模型每一步读取的内容，从而在任何长度下都能实现可预测的成本，并以极小的质量代价获得廉价的长上下文。它使得长上下文变得足够廉价和快速，可以嵌入需要随时间保持状态的迭代系统中。

MiniMax M3：稀疏注意力如何让长时智能体变得实用

最近，GLM 5.2 占据了 AI 时间线的大部分，大多数讨论都集中在它与 Opus 的对比上。这是头条新闻。但实际使用情况更能说明问题：与我合作的开发者们一直在大规模运行 MiniMax M3，因为它以极低的成本提供了相当的长时能力。事实上，MiniMax M3 在 Open Router 上的 Token 使用量仍然领先 GLM 5.2 超过 50%。来源：Open Router Rankings

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

Fireworks 的发布文章从基础设施的角度也指出了这一点。它将 M3 描述为 Fireworks 上第一个将前沿编码、原生图像和视频理解以及 50 万 Token 上下文窗口整合在一个系统中的开源模型。本文关注的实际宣称是 Fireworks 在该发布文章中报告的那些。M3 在长上下文解码上比 M2.7 快 15 倍，长上下文每个 Token 的计算量降至 1/20，Fireworks 还提到在论文复现和 CUDA 内核优化任务上可以进行 12 到 24 小时的自主运行。

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

改变这一问题的机制是 MiniMax Sparse Attention (MSA)，详见 MiniMax 最近的报告《MiniMax Sparse Attention》。MSA 改变了模型每一步读取的内容。在注意力计算之前，它会执行一个轻量级的预过滤步骤：一个索引分支（Index Branch）以块为单位对上下文进行评分，选择与当前 Token 最相关的块，然后模型只关注这些块。它读取的是索引而不是整个库，这使得每一步的成本大致保持平稳，即使上下文增长到数十万个 Token。

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

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

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

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

这带来了什么

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

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

这就是为什么该模型对开发者来说很有吸引力。它将长上下文从一种文档阅读功能转变为智能体需要记忆、迭代和验证的执行基础。

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

这与我长期以来关注的上下文工程工作直接相关。多年来，我鼓励开发者精雕细琢进入上下文窗口的内容。MSA 则是模型学会在窗口内精雕细琢它关注的内容；同样的原则深入到了架构层。对开发者和研究人员来说，这介于一个简短演示和一个可以信赖的工具之间的区别。这意味着一个智能体可以一次读取整个仓库，在单次持续会话中跨整个代码库进行调试，或者持续数小时的实验、日志和修订中完成研究任务，而不会丢失上下文。

在 MiniMax 自己的长时运行中，最强大的结果往往出现在多小时的会话深入之后，远在大多数模型趋于平稳并停止之后。经济实惠的长上下文赋予了智能体这种持久力。

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

如何开始使用 MiniMax M3

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

这个定价很有用，因为它将 M3 重新定位为从 M2.7 升级的路径，而不仅仅是一个新的前沿模型。Fireworks 表示，开源模型的启动定价已降至与 M2.7 标准无服务器使用相同的水平，因此团队无需支付比上一代更高的价格即可获得 M3 的长上下文和原生多模态理解能力。

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

import json
import requests

url = "https://api.fireworks.ai/inference/v1/chat/completions"

payload = {
    "model": "accounts/fireworks/models/minimax-m3",
    "max_tokens": 32768,
    "temperature": 0.6,
    "top_p": 1,
    "top_k": 40,
    "messages": [
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Can you describe this image?"},
                {
                    "type": "image_url",
                    "image_url": {
                        "url": "https://images.unsplash.com/photo-1582538885592-e70a5d7ab3d3?auto=format&fit=crop&w=1770&q=80"
                    },
                },
            ],
        }
    ],
}

headers = {
    "Accept": "application/json",
    "Content-Type": "application/json",
    "Authorization": "Bearer <FIREWORKS_API_KEY>",
}

response = requests.post(url, headers=headers, data=json.dumps(payload), timeout=120)
response.raise_for_status()
print(response.json())

对于更困难的智能体或推理任务，可以在负载中添加 "thinking": {"type": "enabled"}。对于生产工作负载，Fireworks 将无服务器定位为评估的最快路径，将按需部署定位为可预测吞吐量的选项。在此处尝试：Fireworks AI