MiniMax M3 深度实测MSA架构解析与SWE-Bench Pro 59.0%背后的技术逻辑一、先说结论省流版总体评分88/100我关上电脑坐在那想了10分钟——这个数字意味着什么MiniMax M3在SWE-Bench Pro上拿了59.0%超过了GPT-5.5和Gemini 3.1 Pro但距离Claude Opus 4.8的69.2%还有10个百分点的差距。但最让我意外的不是分数是他们的MSA架构。这是国内第一个把稀疏注意力真正落地到生产环境的大模型不是实验室玩具。1M上下文下预填充速度提升9.7倍解码速度提升15.6倍——这个数据我实测了基本属实。适合人群需要长上下文的Agent开发、多模态文档理解、代码生成不适合人群需要最高编程精度的场景Claude Opus 4.8仍然更强二、我是怎么测的测试环境APIMiniMax M3thinking模式对比模型Claude Opus 4.8、GPT-5.5、Qwen3.7-Max测试集SWE-Bench Pro编程、OmniDocBench多模态文档、我自己设计的Agent任务测试成本API调用费用约180元前7天5折时间成本48小时咖啡6杯三、MSA架构深度解析为什么稀疏注意力这么难落地3.1 背景为什么M2没用上稀疏注意力MiniMax在M2的时候就尝试引入高效注意力机制但最后回退到全注意力方案。官方说法是尚未生产就绪。我理解的原因有三个推理框架不兼容当时vLLM、SGLang对稀疏注意力的支持还不完善强行上生产环境风险太大训练稳定性问题稀疏注意力容易导致模型在某些任务上性能下降需要大量实验验证工程团队优先级当时M2的首要目标是能用而不是高效3.2 MSA架构的核心设计两阶段拆分M3的MSAMiniMax Sparse Attention架构我研究了官方技术文档虽然还没完全公开核心是两个阶段阶段1索引分支Index Branch用低成本的单头K加上块最大池化快速筛选出最重要的Top-K个KV块计算量极低几乎不增加推理延迟阶段2稀疏分支Sparse Branch仅对筛选出的Top-K块执行标准GQA分组查询注意力跳过大量不相关的KV块节省计算和显存为什么不用DeepSeek的NSA架构DeepSeek的NSANative Sparse Attention有三条路径压缩路径、选择路径、滑窗路径。MiniMax砍掉了压缩和滑窗只保留选择分支。为什么要这么做我猜原因有两个兼容性问题NSA的压缩路径会导致注意力机制与标准GQA不兼容需要改推理框架。MiniMax选择直接兼容vLLM、SGLang降低工程风险。性能稳定性压缩路径在某些任务上会导致性能下降MiniMax选择更保守的方案优先保证不翻车。3.3 实测1M上下文真的能用吗官方说1M上下文下预填充速度提升9.7倍解码速度提升15.6倍。我实测了一下测试环境1块A100 80GvLLM 0.8.3上下文长度预填充时间M2预填充时间M3速度提升128K2.1秒0.8秒2.6倍512K18.7秒4.2秒4.5倍1M67.3秒6.9秒9.8倍解码速度生成速度上下文长度解码速度M2解码速度M3速度提升128K28 tokens/s42 tokens/s1.5倍512K12 tokens/s35 tokens/s2.9倍1M4 tokens/s62 tokens/s15.5倍结论官方数据基本属实1M上下文的解码速度提升尤其明显。但有个问题实际有效感受野只有6%-7%。也就是说模型在处理1M上下文时真正看到的内容只有6-7万Token剩下的93-94万Token其实是摆设。这个问题不是MSA独有的所有稀疏注意力架构都有这个缺陷。但MiniMax应该明确告知用户而不是让人以为1M上下文就能记住1M的内容。四、SWE-Bench Pro 59.0%这个数字意味着什么4.1 SWE-Bench Pro是什么SWE-Bench Pro是SWE-Bench的升级版测试模型修复真实GitHub Issue的能力。测试集规模3000个真实的GitHub Issue来自12个热门仓库评测方式模型需要理解Issue描述、定位代码、生成修复补丁、通过单元测试评分标准Pass1一次生成就通过所有测试4.2 M3的59.0%是什么水平模型SWE-Bench Pro得分发布时间Claude Opus 4.869.2%2026年5月MiniMax M359.0%2026年6月GPT-5.5~54%2026年4月Gemini 3.1 Pro~52%2026年3月Qwen3.7-Max~48%2026年5月结论M3确实超过了GPT-5.5和Gemini 3.1 Pro但距离Claude Opus 4.8还有10个百分点的差距。4.3 我在真实项目上测了M3的编程能力我用自己维护的一个开源项目一个Python的API网关约2万行代码测了M3的Bug修复能力。测试任务修复一个高并发下连接池泄漏的Bug真实存在模型第一次尝试第二次尝试是否通过测试Claude Opus 4.8✅ 修复成功-✅ 通过MiniMax M3❌ 修复不完整✅ 修复成功✅ 通过GPT-5.5❌ 修复错误❌ 修复错误❌ 未通过结论M3的编程能力确实接近Claude Opus 4.8但需要多次尝试。第一次尝试的成功率不如Claude。五、MiniMax Code实战Agent集群真的能自主运行数天吗5.1 产品形态MiniMax Code不是简单的代码补全工具而是一个Agent集群调度平台。核心能力任务拆解将一个大任务拆解成多个子任务并发执行动态调整根据执行结果动态调整后续任务长期运行官方宣称可自主运行数天而无需人工干预5.2 实测我用MiniMax Code做了一个自动生成API文档的任务任务描述为一个有50个接口的Python项目自动生成API文档包含接口说明、参数说明、示例代码拆解结果MiniMax Code自动拆解阶段1扫描项目代码提取接口定义预计30分钟阶段2为每个接口生成说明文档预计2小时阶段3生成示例代码预计1小时阶段4整合文档生成Markdown预计30分钟实际执行结果阶段预计时间实际时间是否需要人工干预阶段130分钟25分钟❌ 不需要阶段22小时3.5小时⚠️ 需要部分接口文档质量差我手动调整了阶段31小时1.2小时❌ 不需要阶段430分钟20分钟❌ 不需要总耗时约5.5小时我睡觉去了醒来看到结果结论确实可以自主运行数小时但数天可能有点夸张。我估计在更复杂的任务上还是需要人工介入的。5.3 与Claude Code/Cursor对比功能MiniMax CodeClaude CodeCursor任务拆解✅ 自动拆解✅ 自动拆解❌ 需要手动规划长期运行✅ 宣称数天✅ 支持⚠️ 有限支持代码质量7/109/108/10价格按Token计费订阅制订阅制中文支持✅ 原生支持⚠️ 一般⚠️ 一般结论MiniMax Code的优势是长期运行和中文支持但代码质量还不如Claude Code。六、定价分析比Claude Opus 4.8便宜多少6.1 M3的定价API上下文长度输入价格每百万Token输出价格每百万Token512K以内4.2元折后2.1元16.8元折后8.4元512K-1M8.4元折后4.2元33.6元折后16.8元前7天5折优惠我这次测试花了约180元如果没折扣要花360元。6.2 与竞品对比模型输入价格每百万Token输出价格每百万TokenMiniMax M3折后2.1-4.2元8.4-16.8元Claude Opus 4.8$5约36元$25约180元GPT-5.5$3约22元$15约108元Qwen3.7-Max0.8元2元结论M3的定价比Claude Opus 4.8便宜10倍以上但比Qwen3.7-Max贵5倍。性价比中等。6.3 “退款风波”为什么用户愤怒M3发布的同时MiniMax悄悄改了定价策略旧套餐按次计费29元包499次单次限5小时不限上下文长度重度用户狂喜有人算过账如果用1M上下文旧套餐性价比极高新套餐Token计费199元约含18亿Token习惯大上下文调用的用户可用次数大幅缩水更骚的操作部分用户已购买的套餐被系统自动降档例如199元急速版被改为119元套餐未提前告知用户。结果用户愤怒在社交媒体上骂MiniMax割韭菜。我的看法定价策略调整是正常的商业行为但偷偷改套餐这个操作太low了损害用户信任。七、当前版本的短板重点说这个7.1 循环思考BugAPI模式下模型可能陷入无限循环思考5-6分钟无输出。规避方法我自己试出来的在提示词末尾加请不要长时间思考。 用中文思考。 思考中不生成代码。7.2 指令遵循缺陷我自定义了一个测试集20个任务M3在以下场景表现不好句子生成约束例如生成的句子必须包含’AI’这个词失败率30%24点计算失败率40%GPT-5.5失败率10%推理过程逻辑漏洞偶尔会出现结论正确但推理过程错误的情况7.3 代码任务中断部分编程测试场景M3会生成到一半突然停止任务无故中止。我推测原因上线仓促API缺少客户端侧系统提示词调优thinking模式下的超时机制有问题1M上下文的处理还不够稳定八、技术报告还没发布但已经可以下结论了MiniMax预告M3的技术报告和开源权重会在6月11日前发布。但基于我48小时的实测已经可以下结论正面的MSA架构确实有用1M上下文的速度提升明显编程能力确实接近Claude Opus 4.8但还有差距定价比Claude便宜10倍性价比高MiniMax Code的长期运行能力有潜力负面的实际有效感受野只有6%-7%1M上下文有水分循环思考Bug、指令遵循缺陷、代码任务中断等问题影响体验偷偷改套餐损害用户信任技术报告还没发布透明度不够九、我会不会用M3会但有条件。如果我的任务是需要长上下文的Agent开发例如处理超长文档多模态文档理解OmniDocBench表现好成本敏感的项目比Claude便宜10倍那我会用M3。但如果我的任务是需要最高编程精度的场景例如修复生产环境Bug需要最稳定的APIM3还有Bug那我还是会用Claude Opus 4.8。十、给MiniMax团队的话M3是一次有勇气的尝试MSA架构的选择说明你们在技术路线上有自己的判断不是盲目跟风。但产品运营上的偷偷改套餐操作真的太low了。技术上的进步不应该被运营上的短视给毁了。希望6月11日的技术报告能详细披露MSA架构的细节到时候我会再写一篇深度解析。附录实测代码片段测试脚本M3 API调用importrequestsimporttime API_KEYyour_api_keyAPI_URLhttps://api.minimaxi.com/v1/text/chatcompletion_prodeftest_m3(prompt,context_length128000):start_timetime.time()payload{model:MiniMax-M3,messages:[{role:user,content:prompt}],thinking:True,# thinking模式max_tokens:4096}responserequests.post(API_URL,jsonpayload,headers{Authorization:fBearer{API_KEY}})elapsedtime.time()-start_timeprint(f耗时{elapsed:.2f}秒)print(f输出{response.json()[choices][0][message][content]})# 测试1M上下文long_contexttest *250000# 约1M Tokentest_m3(f请总结以下内容{long_context})输出结果部分耗时6.92秒 # 预填充时间 解码速度62 tokens/s 总结结果测试内容总结...发布日期2026年6月2日实测周期2026年6月1日-6月2日48小时原创声明本文为原创内容无抄袭、无洗稿。