长上下文 on KnightLi的博客

MiniMax M3 发布：代码 Agent、1M 上下文和原生多模态

Mon, 01 Jun 2026 09:00:00 +0800

MiniMax 在 2026 年 6 月 1 日发布了 MiniMax M3。从官方介绍看，M3 的定位很清楚：面向代码、Agent 和长上下文任务，同时加入原生多模态能力。

这次发布最值得关注的不是单个跑分，而是 MiniMax 把三类能力放到同一个模型里：

代码与 Agent 任务能力；
最高 1M tokens 上下文窗口；
原生多模态，支持图像和视频输入；
计划开放权重，支持后续私有化部署和微调。

如果你正在关注国产模型在编程助手、自动化工作流、长文档处理和多模态理解上的进展，M3 值得单独看一下。

M3 的核心定位

MiniMax 对 M3 的表述是：代码与 Agent 前沿模型，1M 上下文，原生多模态。

这几个关键词对应的是实际使用里的几个痛点：

代码任务不只是补全函数，还需要读项目、改文件、运行工具、修复报错；
Agent 任务会产生大量工具调用记录、日志和中间结果；
长文档、长视频、完整代码库都需要更大的上下文窗口；
图表、截图、公式、视频帧等内容，不能只靠纯文本理解。

因此 M3 更像是给“长链路任务”准备的模型，而不是只面向普通聊天或短文本生成。

1M 上下文来自 MSA 架构

M3 使用 MiniMax 自研的 MSA，也就是 MiniMax Sparse Attention。官方解释里，MSA 的目标是解决传统全注意力在长上下文下计算复杂度快速膨胀的问题。

简单说，全注意力在上下文变长时成本上升很快。MSA 通过稀疏注意力和更适合硬件执行的 KV block 访问方式，让模型在长上下文场景下更容易扩展。

官方称，M3 API 支持最高 1M tokens 上下文，并保证最低 512K tokens。这对几类任务很有意义：

读取完整项目或大型模块；
处理长研究报告、合同、日志和知识库材料；
保留多轮 Agent 执行过程中的工具调用记录；
分析长视频或多模态材料。

不过要注意，长上下文并不等于所有任务都应该塞满上下文。实际使用时，检索、分块、缓存和任务拆分仍然重要。1M 上下文更像是给复杂任务提供上限，而不是替代工程设计。

代码和 Agent 是重点

官方报告里，M3 在多个代码与 Agent benchmark 上给出了成绩，包括：

Benchmark	官方公布成绩
SWE-Bench Pro	`59.0%`
Terminal-Bench 2.1	`66.0%`
SWE-fficiency	`34.8%`
KernelBench Hard	`28.8%`
MCP Atlas	`74.2%`

这些数字可以作为参考，但不建议只看榜单下结论。更值得注意的是 MiniMax 把 M3 的训练和评估重点放在更接近真实协作的 Agent 场景上。

真实的代码工作并不是“一句话生成一个函数”。它通常包括：

反复澄清需求；
阅读已有代码；
制定修改计划；
运行命令和测试；
根据报错继续修；
在多轮上下文里保留决策依据。

这也是 M3 和 MiniMax Code 绑定发布的原因。模型能力只是底层，真正能不能完成工程任务，还要看外层 Agent harness、工具调用、上下文管理和验证流程。

官方展示的几个长链路任务

MiniMax 在报告里列了几个更接近真实工作的案例。

第一个是论文复现。官方让 M3 独立复现一篇 ICLR 2025 Outstanding Paper。M3 连续运行接近 12 小时，产生 18 次 commit 和 23 张实验图，完成了核心实验复现。

这个案例的重点不是“会写论文摘要”，而是它同时用到了：

多模态能力，理解论文里的曲线、公式和图表；
长上下文，把论文、代码和实验日志放进同一任务链路；
代码与 Agent 能力，持续运行、实验、验证和修正。

第二个是 CUDA kernel 优化。官方让 M3 从一个不能直接运行的 Triton 骨架开始，优化 NVIDIA Hopper GPU 上的 FP8 GEMM kernel。M3 在约 24 小时里完成 147 次 benchmark submission 和 1,959 次工具调用，把硬件峰值利用率从 7.6% 提升到 71.3%，相当于 9.4x 加速。

这个案例说明 M3 更强调长时间自主迭代。普通代码生成模型往往在前几轮失败后就停住，而 Agent 型模型需要能持续根据反馈调整方向。

第三个是让 M3 自主训练模型。官方在 PostTrainBench 中给 M3 四个只完成预训练的 base model，让它在 12 小时内完成数据合成、训练、评估和迭代。最终 M3 得分 0.37，低于 Opus 4.7 和 GPT-5.5，但明显领先其他模型。

这些案例都来自 MiniMax 官方测试，不能直接等同于第三方独立评测结果。但它们能说明 M3 的产品方向：把模型放进长周期、可验证、有反馈的任务循环里。

原生多模态的意义

M3 不是在文本模型后面简单外挂视觉能力。官方称它从训练早期就进行混合模态训练，并重建了数据管线，把训练数据扩展到 100T+ 级别。

对开发者来说，多模态的价值主要在这些场景：

读取截图、图表、公式和设计稿；
分析 PDF、论文、报告和实验图；
理解长视频中的画面变化；
在桌面自动化任务中识别界面元素。

MiniMax Code 也围绕这一点做了产品化。官方提到，MiniMax Code 可以结合 M3 的多模态能力做 computer use，例如根据表格内容跨应用批量录入信息。

MiniMax Code 与 Agent Team

随着 M3 发布，MiniMax Code 也同步更新。官方把 MiniMax Code 定位为更适合 M3 的 Agent 产品，用来释放 M3 的长上下文、代码、Agent 和多模态能力。

MiniMax Code 的 Agent Team 可以把大任务拆成多阶段、并发、可动态调整的流程，并通过类似 Producer + Verifier 的对抗式循环持续产出、反思和修正。

这个方向和 Claude Code、Codex CLI、opencode 等工具处在同一大类：不是只让模型回答问题，而是让模型进入本地或云端开发环境，读文件、改文件、运行命令，再根据结果继续推进。

区别在于，MiniMax 更强调：

M3 的 1M 长上下文；
多模态和 computer use；
Agent Team 的长时间自主执行；
Token Plan 下的大额度使用。

Token Plan 和 API

MiniMax 这次也更新了 Token Plan。官方公布的三档额度是：

套餐	月费	M3 月额度
Plus	`$20/month`	约 `1.7B tokens`
Max	`$50/month`	约 `5.1B tokens`
Ultra	`$120/month`	约 `9.8B tokens`

这些额度看起来非常激进，适合高频代码助手、批处理、长文档处理和多模态任务。但实际是否划算，还要看可用地区、并发限制、速度、稳定性、上下文计费和任务成功率。

API 方面，M3 已经可用。官方说明里有几个点值得注意：

输入长度 <=512K tokens 按标准价格计费；
超过 512K tokens 会进入更高的长上下文价格；
支持开启或关闭 thinking；
thinking 开启时更适合复杂推理、Agent 和长周期协作；
thinking 关闭时响应更快，适合对话和代码补全；
支持 standard 和 priority 服务等级，priority 面向更高并发和更稳定延迟。

官方示例里的模型名是：

`1`	`"model": "MiniMax-M3"`

接口示例使用：

`1`	`https://api.minimax.io/v1/text/chatcompletion_v2`

如果你要把 M3 接入现有代码工具，重点要先确认三件事：OpenAI-compatible 兼容程度、流式输出支持、工具调用格式。

开放权重值得关注，但要等落地

MiniMax 称 M3 将在 Hugging Face 和 GitHub 上开源权重，支持私有集群部署和微调。这个点很重要。

如果权重真正开放，并且推理框架适配顺利，M3 可能会进入几类企业场景：

私有代码库助手；
内部知识库和文档分析；
高敏感数据场景；
政企和本地化部署；
低成本批量 Agent 工作流。

但这里还需要等具体信息落地，包括：

权重大小和许可证；
量化方案；
vLLM、SGLang、llama.cpp 等框架支持；
显存需求；
多模态和长上下文在本地部署时的实际成本；
是否开放完整训练或微调工具链。

所以现在可以关注，但不宜过早把“开源权重”当成已经可生产部署的事实。

适合谁先试

M3 更适合下面几类用户先试：

经常使用 AI coding agent 的开发者；
想用国产模型替代部分 Claude、GPT 或 Gemini 代码任务的团队；
有长文档、长代码库、长日志分析需求的人；
做自动化工作流、MCP、agent harness 的开发者；
需要大量 token 额度做批处理的人；
对本地化部署和开放权重有长期需求的团队。

如果只是普通聊天、短文本改写、简单问答，M3 未必是最需要优先尝试的模型。它的重点明显放在更重的 Agent 和工程任务上。

我的看法

MiniMax M3 这次发布，最有意思的是路线选择：不只和通用聊天模型比，而是直接把代码、Agent、长上下文和多模态打包成一个面向工程工作流的模型。

这条路线是对的。未来 AI 编程工具的竞争，不会只看模型能不能写一段代码，而会看它能不能在长时间任务里持续规划、执行、验证、纠错，并且把上下文成本控制住。

不过，真正决定 M3 能不能进入主力工作流的，还是几个更朴素的问题：

API 是否稳定；
长上下文价格是否可控；
MiniMax Code 的工具链是否成熟；
OpenAI-compatible 和主流 agent 工具适配是否顺畅；
开放权重能否及时落地；
第三方评测和真实项目体验是否能支撑官方说法。

如果这些问题后续表现不错，M3 会成为国产代码 Agent 模型里很值得关注的一支。

参考

DeepSeek-V4 KV Cache 机制解析：为什么 1M 上下文更省显存

Mon, 18 May 2026 18:38:26 +0800

长上下文模型真正贵的地方，往往不是“能不能塞进 100 万 Token”，而是推理时 KV Cache 要占多少显存。

在 Transformer 解码过程中，每生成一个新 Token，模型都要保留历史 Token 对应的 Key 和 Value。上下文越长，KV Cache 越大；KV Cache 越大，显存、内存带宽、首字延迟和吞吐都会被拖慢。

DeepSeek-V4 的特别之处，是它没有只在注意力头数量上省缓存，而是把压缩进一步推进到序列长度维度。按照 Hugging Face 对 DeepSeek-V4 技术报告的解读，在 1M Token 场景下，DeepSeek-V4-Pro 的 KV Cache 约为 DeepSeek-V3.2 的 10%；如果和常见的 bf16 GQA 架构相比，约为其 2% 左右。

这就是 DeepSeek-V4 缓存机制最值得看的地方：它不是简单把 KV 存得更小，而是减少需要长期保存和检索的 KV 条目数量。

先看几代 KV Cache 优化路线

KV Cache 优化大致可以分成几条路线。

第一类是传统 MHA，也就是 Multi-Head Attention。每个 Query 头通常都有对应的 Key/Value 头。它结构直接，但长上下文下缓存随序列长度线性增长，显存压力最大。

第二类是 GQA，也就是 Grouped Query Attention。多个 Query 头共享较少的 Key/Value 头。LLaMA、Mistral、Qwen 等很多现代模型都采用类似思路。它能显著减少 KV 头数量，是当前主流长上下文模型的常见节省手段。

第三类是 MLA，也就是 Multi-head Latent Attention。DeepSeek-V2、DeepSeek-V3 使用这一路线，把 Key/Value 压缩成低秩潜在表示，从注意力头维度进一步降低缓存占用。

第四类就是 DeepSeek-V4 引入的混合压缩注意力。它把重点放到序列长度维度：不是只减少每个 Token 要存多少 KV，而是把多个历史 Token 压缩成更少的 KV 条目，再用稀疏或稠密方式检索。

可以粗略理解为：

MHA：每个头都认真记。
GQA：多个 Query 头共享一部分记忆。
MLA：把每个 Token 的 KV 表示压成潜在向量。
DeepSeek-V4：把很多历史 Token 聚合成更少的压缩记忆块。

DeepSeek-V4 的关键变化：从头维度压缩到序列维度压缩

GQA 和 MLA 主要是在“每个 Token 存多少 KV”上做优化。这个方向很有效，但当上下文长度来到 1M Token 时，问题会变得更极端：即使每个 Token 的缓存已经很小，Token 数量本身仍然太多。

DeepSeek-V4 选择把旧上下文压缩成块。也就是说，模型不一定要为每个很久以前的 Token 都保留完整 KV，而是让多个 Token 形成压缩条目。

这有点像读一本很长的书：刚读过的几页你会记得细节，前面几章则更多以摘要、主题和关键线索的形式保存。DeepSeek-V4 的注意力机制也有类似分工：近处保留细节，远处用压缩表示。

CSA：4 倍压缩加稀疏检索

CSA 全称是 Compressed Sparse Attention，可以理解为较细粒度的长程压缩机制。

在 CSA 中，模型会把序列中的若干相邻 Token 压缩成更少的 KV 条目。Hugging Face Transformers 文档里给出的默认压缩率是 m=4，也就是大致每 4 个 Token 形成一个压缩条目。

但它不是简单平均。CSA 使用带学习能力的压缩池，并结合重叠窗口，让模型在压缩时保留更有用的信息。压缩之后，查询并不会对所有历史压缩块都做完整注意力，而是先通过 Lightning Indexer 打分，挑出最相关的 top-k 压缩块，再进入核心注意力计算。

这个结构有两层收益：

历史 KV 条目数量先变少。
每次查询只看最相关的一部分压缩块。

所以 CSA 适合处理远距离但仍需要细节检索的上下文，比如代码库、长文档、工具调用历史里的关键信息。

HCA：128 倍压缩加稠密注意力

HCA 全称是 Heavily Compressed Attention，压缩更激进。

Transformers 文档里给出的默认压缩率是 m'=128。也就是说，HCA 会把更长的一段上下文压成一个压缩条目。压缩后的序列已经很短，因此它不需要像 CSA 那样再做稀疏 top-k 检索，而是让 Query 对所有压缩条目做稠密注意力。

HCA 的作用更像全局摘要。它不追求保留每个细节，而是用极低成本覆盖很长的历史范围，让模型对全局背景、长程主题和远处信息保持感知。

如果把 CSA 比作“可检索的压缩笔记”，HCA 更像“全局目录和摘要”。

滑动窗口：最近上下文仍保留细节

DeepSeek-V4 并不是把所有上下文都压缩掉。

在 CSA 和 HCA 之外，它还保留了滑动窗口分支，用来处理最近的一段未压缩上下文。Transformers 文档里提到，DeepSeek-V4 的 attention block 会把长程压缩分支与滑动窗口 K/V 拼接在一起。

这个设计很重要。生成下一个 Token 时，最近几十到几百个 Token 往往最关键：变量名、函数签名、正在写的句子、刚返回的工具结果、最近用户要求。它们如果被过度压缩，输出质量会明显下降。

所以 DeepSeek-V4 的思路不是“全部压缩”，而是：

近处：保留未压缩细节。
中远处：用 CSA 做可检索压缩。
更远处：用 HCA 做重度全局压缩。

混合层栈：不同层做不同注意力

DeepSeek-V4 不是在所有层里使用同一种注意力。

Hugging Face 的 DeepSeek-V4 文章提到，V4-Pro 的 61 层结构中，前两层使用 HCA，之后的层在 CSA 和 HCA 之间交替，末尾的 MTP block 使用滑动窗口。Transformers 文档也说明，V4-Pro 默认是 2 层 HCA bootstrap 加交替 CSA/HCA。

这说明 DeepSeek-V4 把注意力机制当成分层系统来设计。不同层承担不同信息流角色：有的层更偏全局压缩，有的层更偏稀疏检索，有的部分保留局部窗口。

相比所有层统一使用一种注意力，这种混合结构更复杂，但也更适合 1M Token 这种极长上下文。

FP8 和 FP4 进一步降低缓存成本

DeepSeek-V4 的缓存节省不只来自压缩率。

Hugging Face 的文章提到，V4 的大部分 KV 条目使用 FP8 存储，RoPE 相关维度保留 BF16，而 CSA 里的 Lightning Indexer 使用 FP4。压缩比例、低精度存储、稀疏检索叠加在一起，才形成了非常低的 KV Cache 占用。

这也提醒我们：不要只看“上下文长度 1M”这个宣传数字。真正决定可部署性的，是长上下文下的显存占用、带宽压力、推理延迟和工程实现。

和其他模型的差异

与传统 MHA 相比，DeepSeek-V4 不再为长历史里每个 Token 保留完整注意力记忆，缓存压力下降非常明显。

与 GQA 相比，DeepSeek-V4 不只是减少 KV head 数量，还减少长历史的 KV 条目数量。GQA 仍然要随序列长度线性积累缓存，而 V4 会把远处上下文压成块。

与 DeepSeek-V3 的 MLA 相比，V4 的重点从“每个 Token 的表示更紧凑”进一步扩展到“历史 Token 数量也被压缩”。MLA 已经大幅降低单 Token KV 占用，但面对百万级上下文时，序列长度本身仍是压力来源。

与普通稀疏注意力相比，DeepSeek-V4 的 CSA 是先压缩再稀疏检索，索引器面对的是更短的压缩序列；HCA 则通过 128 倍压缩让全量稠密注意力也变得便宜。

对 Agent 和长任务有什么意义

Agent 工作流特别吃长上下文：它会读文件、调用工具、接收工具返回、生成计划、修正计划、继续调用工具。上下文越长，KV Cache 越容易成为瓶颈。

DeepSeek-V4 这种缓存机制的潜在价值在于：

更容易承载长代码库、长文档、多轮工具调用历史。
首字延迟和吞吐更不容易被 KV Cache 拖垮。
同等硬件上可以跑更长上下文或更多并发请求。
对百万 Token 场景，部署成本更接近实际可用，而不是只停留在论文指标。

不过也要注意，压缩注意力不是免费午餐。把历史 Token 压缩成块，必然涉及信息取舍。模型需要在“省显存”和“保留可检索细节”之间做平衡。真正效果还要看任务类型：代码定位、法律文档、长篇问答、Agent 工具链，对细节召回的要求并不一样。

不要把 2% 理解成所有成本都降到 2%

“KV Cache 约为 GQA 的 2%”很容易被误读。

它主要指 KV Cache 显存规模，不等于总推理成本只剩 2%，也不等于所有场景速度都会提升 50 倍。推理还包括模型权重读取、MoE 路由、前馈网络、注意力计算、调度开销、通信开销等。

Hugging Face 的文章里也把两个数字分开讲：在 1M Token 场景，DeepSeek-V4-Pro 相对 DeepSeek-V3.2 的单 Token 推理 FLOPs 是 27%，KV Cache 是 10%。这说明缓存和计算是两个不同维度。

所以更稳妥的说法是：DeepSeek-V4 让超长上下文的 KV Cache 压力显著降低，从而改善百万 Token 场景的部署可行性；但具体吞吐和延迟仍取决于实现、硬件、批处理、量化和推理框架。

小结

DeepSeek-V4 的缓存机制和其他大模型最大的不同，是它把 KV Cache 优化从注意力头维度推进到了序列维度。

GQA 是少存一些 KV 头，MLA 是把每个 Token 的 KV 表示压得更紧，DeepSeek-V4 则进一步把远处 Token 聚合成压缩块，并通过 CSA、HCA、滑动窗口和低精度存储组合起来，让百万 Token 上下文不再被 KV Cache 轻易卡死。

这不是单一技巧，而是一整套长上下文推理架构：近处保细节，远处做压缩，需要细节时稀疏检索，需要全局时重度摘要。

对开发者和 Agent 应用来说，它的意义很直接：长上下文不只是“能输入更多”，还要“跑得起、跑得稳、成本能接受”。DeepSeek-V4 真正改变的，正是这一点。