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 的設計正是為了消除這個限制。其 500K Token 的上下文視窗是開放權重模型中最大的之一，但真正重要的能力是，在上下文持續增長的情況下，能持續專注於單一任務數小時。M3 是多模態的，具備原生的圖像和影片理解能力，因此同一個 Agent 可以在一次運行中同時處理文字、程式碼和視覺輸入。

Fireworks 的發布文章從基礎設施的角度也提出了同樣的觀點。它將 M3 描述為 Fireworks 上首個將前沿程式碼能力、原生圖像和影片理解，以及 500K Token 上下文視窗整合於一體的開放權重模型。對於本文而言，Fireworks 在那篇發布文章中報告的實際聲明才是關鍵。M3 在長上下文解碼方面比 M2.7 快達 15 倍，在長上下文情況下，每個 Token 的計算量降至 1/20，並且 Fireworks 引用了在論文復現和 CUDA 核心優化任務上長達 12 到 24 小時的自動運行案例。

長程任務之所以要求高，是因為上下文從未停止增長。一個持續數小時的 Agent 運行會累積程式碼、日誌、工具輸出和中間推理結果，而使用標準的密集注意力機制，每個新 Token 實際上都需要重新讀取所有這些內容。成本隨長度呈平方增長，因此 Agent 工作得越久，每一步的成本就越高。這就是大多數長時間運行的 Agent 最終被中斷的實際原因。

改變這種機制的關鍵是 MiniMax 稀疏注意力（MSA），該技術在 MiniMax 最近的報告 MiniMax 稀疏注意力中有詳細說明。MSA 改變了模型在每一步讀取的內容。在進行注意力計算之前，它會執行一個輕量級的預過濾步驟：一個索引分支（Index Branch）對上下文進行區塊評分，選擇與當前 Token 最相關的區塊，然後模型僅對這些區塊進行注意力計算。它讀取的是索引而非整個資料庫，這使得即使上下文增長到數十萬 Token，每一步的成本也大致保持平穩。

MiniMax 稀疏注意力：一個輕量級的索引分支對鍵值區塊進行評分，並為每個查詢組選擇前 k 個區塊，主分支僅對這些區塊進行注意力計算。來源：MiniMax 稀疏注意力論文。

如果你正在使用 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 稀疏注意力論文。

這解鎖了什麼

有趣的不僅僅是 M3 可以容納更多 Token。而是長上下文變得足夠便宜和快速，可以嵌入到需要隨時間推移保持狀態的迭代系統中。

自我改進的 Agent。 這是我會關注的第一個應用。一個自我改進的 Agent 需要在提出下一個更改時，同時掌握當前的程式碼、先前的失敗編輯、評估日誌、基準測試結果以及它自己的假設。稀疏注意力並不能解決評估問題，但它使得長時間運行的「提出、驗證、修改」循環不太可能因上下文成本而崩潰。
倉儲級別的工程。 Fireworks 強調了全倉儲程式碼理解和強大的自主程式碼能力。這很重要，因為真正的工程工作很少能塞進一個簡潔的提示詞中。跨程式碼庫進行除錯、追蹤回歸問題以及進行多檔案修改，都受益於一個能在單一會話中保持倉儲、測試輸出和編輯歷史記錄的 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 的定價設為每 1M 輸入 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())