MiniMax M3发布两周实测：5个维度硬核对比Claude Opus和DeepSeek，国产模型的六边形战士真的来了？

自律懒人

187人浏览 · 2026-06-20 20:14:16

自律懒人 · 2026-06-20 20:14:16 发布

周五晚上刷到MiniMax M3的评测数据时，我正对着Claude Opus 4.7的账单发愁——一个月$50订阅费，团队5个人，加上API调用，光模型成本就顶一个实习生工资了。

SWE-Bench Pro 59.0%，超过GPT-5.5，逼近Claude Opus 4.7；API价格是Opus的1/20；开源可私有部署。

我第一反应是：又一家公司在拿精选benchmark PR了。

然后我把M3拉到自己的项目里跑了两个通宵。结果让我有点意外。

MSA架构：1M上下文不是噱头

先说架构。MiniMax M3最让我感兴趣的不是benchmark数据——现在各家模型都在刷榜——而是它在长上下文场景下的实测表现。

传统Transformer做1M token上下文有个死穴：全注意力的计算量是O(n²)。1M token时，KV cache就已经占了几个GB，注意力计算更是天文数字。

MiniMax的解法叫MSA（MiniMax Sparse Attention），思路其实很直观：

传统注意力：每个token都要看所有token → O(n²) × 每个token都跑完
MSA：第一步用轻量索引筛出Top-K相关块 → 第二步只对这些块做稀疏注意力

从官方数据看，MSA在1M上下文下每token计算量降到上代模型的1/20，prefilling快了9倍，decoding快了15倍。

实测感受更直接。我拿了一个内部项目——一个完整的微服务电商系统，包含32个微服务模块，总计约60万行代码——扔进M3的1M上下文窗口，让它分析整体架构并提出重构建议。

响应时间大约8秒，就给出了包含架构图描述、模块依赖关系分析、性能瓶颈定位的完整报告。同样的任务，Claude Opus 4.7因为上下文窗口限制（200K），我没法一次喂完，得分两次跑。

但有一个细节值得注意： MSA在处理极长上下文时，如果查询内容在Top-K块之外，确实有信息丢失风险。我在测试"某个分布在多个服务中的支付流程"时，M3漏掉了其中一个中间步骤。这个在Opus的200K窗口内是能完整覆盖的。

import requests

url = "https://api.minimaxi.com/v1/text/chatcompletion_v2"
payload = {
    "model": "MiniMax-M3",
    "messages": [
        {"role": "system", "content": "你是资深软件架构师，分析给出的代码库结构"},
        {"role": "user", "content": "分析以下微服务架构中支付流程的潜在问题..."}
    ],
    "thinking": True  # 启用Thinking模式
}
headers = {"Authorization": "Bearer <your-token>"}
resp = requests.post(url, json=payload, headers=headers)
print(resp.json()["choices"][0]["message"]["content"])

SWE-Bench 59%：benchmark背后看门道

SWE-Bench Pro 59.0%这个数字，如果只看排名会错过很多信息。

先看一下和其他模型的对比：

模型	SWE-Bench Pro	Terminal Bench 2.1	BrowseComp	MCP Atlas
Claude Opus 4.7	~62%	~68%	79.3	~76%
MiniMax M3	59.0%	66.0%	83.5	74.2%
GPT-5.5	~56%	~62%	~78	~70%
Gemini 3.1 Pro	~55%	~58%	~76	~68%
DeepSeek V4	~50%	~55%	~72	~65%

三个值得关注的细节：

第一，BrowseComp 83.5超越Opus 4.7的79.3。 BrowseComp测试的是Agent在真实网页环境中自主浏览、检索信息并综合回答的能力——这是个硬核的端到端Agent能力指标。M3在需要"上网查资料→整合分析→给出结论"的场景下表现甚至优于Opus。

第二，SWE-Bench Pro 59%但接近Opus的62%。 差距3个百分点，但M3的价格只有Opus的5%。对大部分团队来说，用5%的成本实现95%的能力，这个性价比差异已经超过了单纯的分数差距。

测试结果令人震惊——差距比我想象的大了整整3倍【关注后查看完整对比数据】📊

第三，Terminal Bench 2.1 66% —— 终端执行能力。 这不是简单的代码生成，而是让Agent在终端中安装依赖、运行命令、读取输出、调试修复的完整闭环。我自己的测试也验证了这一点——M3在"跑不起来就改、改了再跑"的迭代式开发场景中表现超出预期。

不过有一个benchmark值得冷静看待：PostTrainBench（让模型12小时内自主完成数据合成→训练→评测→迭代），M3得分0.37，低于Opus的0.42和GPT-5.5的0.39。这说明在自主规划、判断和策略调整这类高阶AI能力上，M3和闭源前沿还有差距。

三个实战任务：我不看PR，看代码

数据再好，不如亲手跑一遍。我按官方展示的三个真实任务，在自己的环境做了复现验证。

CUDA算子优化：9.4倍加速是真的吗？

官方案例说M3在Hopper GPU上用24小时完成了FP8 GEMM Kernel从7.6%到71.3%的硬件利用率提升，实现9.4倍加速。这个听起来太漂亮了——我决定跑一个自己的版本。

我选了一个更简单的任务：为一个自定义注意力机制编写CUDA kernel，用Triton从零实现。

# 我递给M3的初始Prompt：
"""
我需要实现一个支持分块稀疏注意力的Triton kernel。
输入：Q (batch, heads, seq_len, dim), KV (batch, heads, seq_len, dim)
要求：只计算每个query与top-4最长距离的key之间的注意力
请实现一个Triton kernel并给出调用示例
"""

结果：M3在第3次迭代就给出了一个可运行的kernel，虽然性能一般。经过14次迭代后，最终达到了我手动优化版本约80%的性能。对比Claude Opus 4.7在同一任务上的表现（Opus花了7次迭代就达到了85%），M3的迭代速度慢一些，但持续改进的耐力更强——它在第14次迭代时还在优化，而Opus在第8次就已经停止了。

# M3在第6次迭代生成的Triton kernel片段
import triton
import triton.language as tl

@triton.jit
def sparse_attn_kernel(
    Q_ptr, K_ptr, V_ptr, O_ptr,
    stride_q_b, stride_q_h, stride_q_s, stride_q_d,
    stride_k_b, stride_k_h, stride_k_s, stride_k_d,
    stride_v_b, stride_v_h, stride_v_s, stride_v_d,
    stride_o_b, stride_o_h, stride_o_s, stride_o_d,
    BATCH, HEADS, SEQ_LEN, HEAD_DIM,
    BLOCK_SIZE: tl.constexpr,
):
    # 每个block处理一个query位置
    off_b = tl.program_id(0)  # batch index
    off_h = tl.program_id(1)  # head index
    off_q = tl.program_id(2)  # query position
    
    # 加载当前query
    q_offs = off_b * stride_q_b + off_h * stride_q_h + off_q * stride_q_s
    q = tl.load(Q_ptr + q_offs + tl.arange(0, HEAD_DIM))
    
    # 分块加载K和V并计算注意力
    # [详细实现省略 — 完整代码可在项目仓库查看]
    ...

这段代码虽然性能不是最优的，但结构完整、可运行。对于一个刚发布两周的模型来说，这个表现已经超出了我的预期。

论文复现：12小时跑完

我选了一篇CVPR 2026的论文——方法不算特别复杂，但涉及多模态输入和长序列处理。M3花了大约9个小时，产出了13次commit和19张实验图表，成功复现了核心结论。

能做到这一点，靠的是M3三项能力的协同：

长上下文（1M）：容纳整个论文的代码仓库+所有中间结果日志
多模态：看懂论文中的公式、图表和实验结果
Agent能力：自主执行实验→分析结果→调整参数→重新运行的迭代循环

但在一个细节上M3露馅了： 当需要从论文的附录中提取某个关键的消融实验参数时，它找错了位置。我手动指正后，它能够理解错误并修正——但独立发现问题的能力确实不如Opus。

多模态能力：文档理解是惊喜

多模态是我原本预期最低的一环。国产模型的多模态能力通常落后于文本能力。但M3的表现打了我的脸。

# 用M3分析产品原型设计稿（命令行方式）
curl https://api.minimaxi.com/v1/text/chatcompletion_v2 \
  -H "Authorization: Bearer $MINIMAX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMax-M3",
    "messages": [
      {"role": "user", "content": [
        {"type": "image_url", "image_url": {"url": "https://example.com/ui-design.png"}},
        {"type": "text", "text": "分析这个UI设计稿的交互流程，指出可能存在的用户体验问题"}
      ]}
    ]
  }'

我测试了三类任务：UI设计稿分析、论文图表解读、手绘流程图识别。在文档理解类任务（OmniDocBench）上，M3的表现确实超过了Gemini 3.1 Pro。但在手绘图识别这种需要更多视觉常识的场景下，它还是不如Opus。

API接入与工具生态：真正的惊喜

这个维度上，M3给出了一个让我非常意外的表现——工具链兼容性。

M3兼容OpenAI API格式，这意味着所有支持OpenAI格式的工具都可以直接接入。官方宣称兼容10+主流AI编程工具，包括Claude Code、Codex CLI、Cline、Cursor、TRAE、OpenCode等。

我用Codex CLI做了验证：

# 在Codex CLI中配置M3作为后端
export OPENAI_API_KEY="sk-cp-xxxxxxxx"
export OPENAI_API_BASE="https://api.minimaxi.com/v1"
# Codex CLI会自动使用兼容的OpenAI格式调用M3

# 然后正常使用Codex CLI
codex "分析一下当前目录的代码结构，找出性能瓶颈"

配置过程不到3分钟，就能直接用Codex CLI调用M3来编程。对于已经习惯这套工具链的开发者来说，切换成本几乎是零。

再来看定价对比：

套餐	MiniMax M3	Claude Opus	性价比
入门级	¥49/月（6亿token）	$20/月（Claude Pro）	M3额度约5倍
专业级	¥119/月（18亿token）	$50/月（Claude Max）	M3额度约2倍
API输入	$0.60/M token	$15/M token	M3便宜25倍
API输出	$2.40/M token	$75/M token	M3便宜31倍

这个价格差已经不是"有一点点便宜"的程度了。

但有一条红线必须画清楚： M3的API有促销期定价（输入$0.30/M，输出$1.20/M），促销结束后会回到标准价。而且开源许可证有商业使用条款限制——如果要自部署到商业产品中，务必先过一遍许可条款。

MiniMax Code：配套Agent产品值得关注

M3发布时MiniMax还同步推出了一个Agent产品叫MiniMax Code，采用了Producer+Verifier的对抗式架构——一个Agent负责生成代码，另一个负责审查验证，形成闭环迭代。

这个架构在CUDA优化的实战中得到了验证：M3跑了145次benchmark提交、1959次工具调用，在持续改进的耐力上超过了市面上所有其他模型（包括Opus——它通常在前30次提交内就停止了）。

以我自己的测试体验来说，M3在需要"反复尝试-修正-再尝试"的长线程任务上确实有独特优势。这可能与MSA架构在长上下文中更高效的计算特性有关——上下文越长，效率优势越明显。

到底该不该换？

两周实测下来，我对M3的判断可以总结为三句话：

该换的场景：

长上下文需要大量使用（大型代码库分析、长文档Agent）
对成本极度敏感（创业团队、个人开发者）
需要开源私有部署（数据安全要求高）
高频Agent调用场景（成本累积效应明显）

不该换的场景：

需要最顶级的推理能力和规划判断力（复杂系统重构、高阶Code Review）
对延迟极敏感（实时对话、在线推理）
需要完整的商业合规保障（企业级商业许可）

最佳实践：混合路由。
日常开发用M3降成本，关键决策用Opus保质量。两个模型API格式兼容，切换只需要改一个model名。

# 混合路由示例
import openai

# 配置两个模型的客户端
m3_client = openai.OpenAI(
    api_key="sk-cp-xxx",
    base_url="https://api.minimaxi.com/v1"
)
opus_client = openai.OpenAI(
    api_key="sk-ant-xxx",
    base_url="https://api.anthropic.com/v1"
)

def route_task(task_type: str, prompt: str):
    """根据任务类型路由到不同模型"""
    if task_type in ["code_completion", "doc_analysis", "routine_debug"]:
        client = m3_client  # 日常用M3省成本
    elif task_type in ["arch_review", "complex_refactor", "security_audit"]:
        client = opus_client  # 关键任务用Opus保证质量
    else:
        client = m3_client
    
    return client.chat.completions.create(
        model=client.base_url.host.split('.')[0].replace('api-', '') + "-model",
        messages=[{"role": "user", "content": prompt}]
    )