MiniMax dots3开源解析：MoE架构、512K上下文与多模态Agent实践

1. 背景：为什么 dots3 值得关注

最近开源大模型圈子里，MiniMax 放出了一个重量级模型，名字叫 dots3。很多读者看到“280B 参数、仅激活 16B、512K 超长上下文”这几个数字，第一反应是“又一个大模型开源了”，但实际去了解之后会发现，它并不是简单的“又一款开源模型”，而是在训练方法、MoE 架构细节、长文本能力和多模态 Agent 支持上都做了不少取舍。

过去一年多，开源模型的竞争基本围绕两条线展开：一是用更小的激活参数做出更聪明的模型，二是把上下文窗口做长，让模型能够处理更复杂的业务场景。dots3 正好把两条线叠在了一起——总参数量 280B，但推理时只激活 16B 参数。这意味着它在保持“大模型容量”的同时，实际计算开销控制在了一个相对可接受的范围内。再搭配 512K 超长上下文，能够一次性塞入大量文本、多轮对话记录甚至整本技术文档。

另一个让人关注的点是它的多模态支持和 Agent 能力。现在很多团队做 Agent 应用时，最大的瓶颈之一就是模型的上下文窗口不够大、工具调用不够稳定、对图片表格等非纯文本输入的处理能力弱。dots3 的设计明显是往“Agent 友好型模型”方向靠拢的。

本文会从技术原理、开源内容、环境准备、本地推理、API 调用、多模态实测、Agent 实战和 FAQ 这几个维度，完整拆解 dots3 到底能做什么、怎么用、有哪些坑。适合对开源大模型感兴趣的算法工程师、后端开发者，以及正在做 Agent 应用落地的技术团队。

需要提前说明的是：大模型相关的版本信息、依赖库和硬件要求更新非常快，本文的示例环境以目前公开资料和实际测试为准。你拿到模型后，建议先确认官方仓库的最新文档，再结合自己的硬件做适配。

2. dots3 核心技术点拆解

2.1 MoE 架构：280B 总参数与 16B 激活参数

很多读者可能对“280B 总参数、16B 激活”这个描述比较陌生。这里先用通俗的方式解释一下。

传统稠密模型（Dense Model）每处理一个 Token，都要把整个模型的参数都加载并参与计算。而 MoE（Mixture of Experts，混合专家）模型把网络拆成多个“专家子网络”，每个 Token 只会路由到其中一部分专家上。所以 MoE 模型的总参数量非常大，但单次推理只激活一部分参数。

dots3 采用的正是 MoE 架构：

总参数量：280B 激活参数量：16B 每个 Token 激活的专家数量：48 个

这里的“激活参数 16B”可以理解成：模型虽然“记住”了大量知识，但处理每个 Token 时只动用 16B 参数的计算量。这带来的直接好处是，推理成本远低于同等总参数量的稠密模型。

但 MoE 架构也有一个经典问题：专家路由不稳定、训练难度高。如果每个专家的能力分化不明显，或者路由策略学得不好，模型效果反而不如稠密模型。

MiniMax 在 dots3 上做了一个非常关键的设计决策——没有沿用传统 MoE 的训练方式，而是采用了 DeepSeek 开源的 Dense-Layer-Sparse-Learning 训练方法。简单说，这种训练策略会先让某些层以稠密形式学习，再逐步引入稀疏路由，让模型在早期训练阶段更容易收敛，后期再通过稀疏化降低推理成本。

2.2 Dense-Layer-Sparse-Learning 是什么

Dense-Layer-Sparse-Learning 是 DeepSeek 在 DeepSeek-V3 技术报告中公开的训练方法，核心思想是让模型在训练初期先用稠密计算学到更稳定的表征，再逐步稀疏化。

dots3 是第一个在公开技术方案中明确表示采用这一训练方法的第三方大模型。对于研究者和开发者来说，这其实比“模型效果有多好”更有参考价值，因为它验证了一条可复现的 MoE 训练路径：

这种方式的优点是：既保留了稠密模型在训练初期的稳定性和知识吸收能力，又能在后期获得 MoE 架构的推理效率。

2.3 512K 超长上下文：实际意义有多大

dots3 支持 512K Token 的上下文长度。很多读者可能对 512K 没有概念，这里给一个直观换算：

• 512K Token 约等于 40 万汉字左右。
• 如果按每页 800 字计算，大约相当于 500 页纯文本文档。
• 如果按代码行数算，可以一次性塞入数万行项目代码。

超长上下文的核心价值，不只是“能读更多字”，而是让 Agent 类应用有了新的设计空间。以前做 Agent 时，为了控制 Prompt 长度，经常要把资料做检索再拼接，上下文窗口有限时，关键历史信息可能被截断。有了 512K 窗口，在许多场景下可以直接把完整资料库、完整会话历史、整份代码仓库的关键文件喂给模型。

不过需要强调的是，“支持 512K”不代表“所有场景都必须用满 512K”。实际工程里，超长上下文的推理延迟会明显升高，显存占用也会增大，所以建议按需使用，不要盲目追求最大长度。

2.4 多模态输入与深度思考能力

dots3 并不仅仅是纯文本模型，它还支持多模态输入。根据公开资料，用户可以直接上传图片，让模型读取图片中的文字、图表信息和代码截图等内容。

多模态输入对日常开发的价值非常直接：

• 前端页面出了 bug，直接截图发给模型，让它定位问题。
• 论文里的表格或公式，截图后让模型提取并解释。
• PPT 或流程图转换成图片后，让模型理解整体结构。

除了多模态输入，dots3 加入了类似“深度思考”的能力。模型可以输出两种状态：一种是普通直接回答，另一种是先展开完整思考链路再给结论。在 Agent 场景中，这种能力非常关键。复杂任务往往需要模型先拆解子目标、判断先调用哪个工具、再决定如何整合结果，而不是“问一句答一句”。

需要说明的是，dots3 的“深度思考”和 OpenAI o1 系列的做法并不完全相同，目前更多体现在 Agent 工具调用和复杂推理场景中。建议以实际体验为准。

3. 开源内容与模型权重说明

3.1 开源协议

dots3 采用 Apache 2.0 协议开源文本权重，这意味着你可以自由使用、修改、商用，只需保留版权声明。相比一些“开源但只能研究”的模型，Apache 2.0 对商业团队友好很多。

不过有一个细节需要留意：dots3 的模型结构本身是基于 DeepSeek-V3 的架构来的，而 DeepSeek-V3 的开源协议是 MIT License，这是“更宽松”的协议。因为官方叠加 Apache 2.0，社区里也有人讨论是否存在授权叠加问题，目前官方定位为“基于 MIT license 的 DeepSeek-V3 架构做二次开发，模型权重采用 Apache 2.0”，具体商用合规建议让公司法务确认。

3.2 开源内容清单

MiniMax 这次开源的内容大致包括：

当前很多第三方生态工具（如 vLLM、SGLang 等）也在陆续适配 dots3，建议部署前先确认你要用的推理框架是否已经支持该模型结构。

3.3 多模态能力的授权说明

这里要特别注意：dots3 的多模态能力目前并非“完全开放权重”状态。

根据目前公开信息，dots3 多模态相关的权重需要单独申请商用授权，如果你只是个人学习或研究，可以直接用 API 体验多模态效果；如果要在商业产品中集成多模态能力，需要走官方商务渠道。

如果你的使用场景只涉及文本，那就没有这个限制。文本权重可以直接下载，也可以商用。

4. 环境准备与依赖说明

这一部分我们重点说明如何把 dots3 跑起来。先看环境需求，再给出可落地的操作步骤。

4.1 硬件要求

dots3 总参数 280B，即使采用 MoE 架构，想把整模型权重加载到单张显卡也不现实。本地部署前需要先明确一个概念：MoE 模型理论上是“只激活部分专家”，但实际推理框架在加载阶段，仍然需要把全部专家权重读入显存或内存中。你不可能只加载 16B 参数就跑起来，因为不同 Token 会路由到不同专家，所有专家参数在计算时都可能会被访问。

因此硬件规划建议如下：

需要强调：MoE 的硬件要求和一个 16B dense 模型完全不同。很多新手看到“激活 16B”，以为单卡 24G 或 48G 就能跑，这个理解是不对的。在没有量化且没有 expert-parallel 优化的前提下，280B 权重需要非常可观的存储。

4.2 环境与依赖

如果你希望本地分布式推理，目前 MiniMax 提供了 MiniMax-Inference 仓库，里面包含推理说明。由于模型本身基于 DeepSeek-V3 架构，社区常见的适配方式包括：

• 基于 transformers 加载 safetensors 权重并做模型并行（需要自行处理并行切分）。
• 等待 vLLM / SGLang 官方支持后，使用更高效的推理引擎。
• 使用 llama.cpp 之类的社区方案尝试量化版部署。

下面给出两种最直接的上手途径。

5. 上手方式一：通过 API 快速体验

对于大多数开发者来说，最快验证一个模型能力上限的方法，是先调用 API。MiniMax 官方为 dots3 开放了 API 渠道，并且平台上有“思考模式”选项，可以打开深度思考能力。

5.1 获取 API Key

登录 MiniMax 开放平台，创建账号后，在控制台创建一个 API Key。注意保存好这个 Key，不要在公开仓库中提交。

创建完成后，把 API Key 配置到环境变量中：

export MINIMAX_API_KEY="你的key"

5.2 文本生成体验

如果你习惯使用 OpenAI SDK，可以发现 MiniMax 的接口风格与 OpenAI 高度兼容。只需要修改 base_url 和 model 名称，就能直接跑通。

下面给出一个最小可运行的文本生成示例：

from openai import OpenAI client = OpenAI( api_key="你的key", base_url="https://api.minimax.io/v1" ) response = client.chat.completions.create( model="MiniMax-M2", messages=[ {"role": "user", "content": "请用通俗的语言解释什么是 MoE 模型，并给出一个实际应用场景。"} ], ) print(response.choices[0].message.content)

需要提醒的是，不同时间段平台开放的模型名称可能有所调整，建议先查看官方 API 文档确认 model 字段取值，再写进代码。

5.3 开启深度思考模式

调用方式是在 messages 中加入一个 system 配置：

from openai import OpenAI client = OpenAI( api_key="你的key", base_url="https://api.minimax.io/v1" ) response = client.chat.completions.create( model="MiniMax-M2", messages=[ { "role": "system", "content": "请开启深度思考模式，先分析问题，再给出最终回答。" }, { "role": "user", "content": "有三个数，它们的平均数是 15，其中一个数是 12，其余两个数的平均是多少？" } ], ) print(response.choices[0].message.content)

如果模型正确开启了思考模式，你会观察到回答中包含推理过程，或者响应中会多出 reasoning_content 等字段。具体字段名以官方文档为准。

5.4 图片理解与多模态输入

dots3 支持图片上传。API 调用时，可以使用 content 数组，同时传入文本和图片：

import base64 from openai import OpenAI client = OpenAI( api_key="你的key", base_url="https://api.minimax.io/v1" ) def encode_image(image_path): with open(image_path, "rb") as f: return base64.b64encode(f.read()).decode("utf-8") image_base64 = encode_image("code_screenshot.png") response = client.chat.completions.create( model="MiniMax-M2", messages=[ { "role": "user", "content": [ {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_base64}"}}, {"type": "text", "text": "请识别这张图片中的代码，并指出可能存在的 bug。"} ] } ], ) print(response.choices[0].message.content)

图片识别能力在很多真实业务里非常实用。比如给模型发一张“控制台报错截图”，让它直接定位异常栈，可以明显减少人工复述报错的时间。

6. 上手方式二：本地部署核心流程

如果你对数据隐私有要求，或者想基于开源权重二次微调，就需要把权重下载到本地，并且搭建推理环境。

这里必须提前说明：本地分布式推理 dots3 的门槛较高。下面的示例，目标是让你理解整体流程，而不是用单机单卡直接跑起来。

6.1 下载模型权重

先安装 Hugging Face CLI 工具：

pip install -U huggingface_hub

然后下载模型。假设你的服务器有足够大的磁盘空间（建议预留 700GB 以上），执行：

huggingface-cli download MiniMaxAI/MiniMax-M2 --local-dir ./MiniMax-M2

如果你访问 Hugging Face 的速度较慢，可以使用国内镜像站，比如某些高校或机构提供的 huggingface 镜像。

6.2 使用 MiniMax-Inference 推理仓库

MiniMax 官方提供了一个推理仓库，包含基础版和 Agent 版两套推理代码。基本流程如下：

git clone https://github.com/MiniMax-AI/MiniMax-Inference cd MiniMax-Inference pip install -r requirements.txt

官方对 Agent 版推理代码的描述是“为 Agent 场景做了针对性优化”，如果你后续要构建工具调用型 Agent，建议直接使用 Agent 版推理代码。

6.3 模型并行与张量并行

280B 参数模型在单卡上跑不动，必须做模型并行。常见做法是把不同层或不同专家分布到多张 GPU 上。MiniMax 使用的并行方案内部比较复杂，但对一般开发者来说，最需要知道的是：

• 需要使用至少多张 80G 显存级别 GPU。
• 推理框架必须支持 expert parallelism 和 sequence parallelism。
• 不要轻易尝试普通 transformers 直接加载完整权重。

由于不同硬件环境差异太大，这里不写死启动命令。建议参考官方 MiniMax-Inference 仓库 README 中给出的具体启动方式，按你的 GPU 数量和显存调整 --tensor-parallel-size 参数。

6.4 显存不够时的方案

如果你的设备暂时不具备多卡条件，可以从以下几点入手：

7. 实战：用 dots3 做一个多模态 Agent

这一节我们做一个完整的 Agent 示例。目标：让模型根据用户上传的截图，分析页面问题，并调用一个查询工具获取数据库信息，最后输出完整结论。

这个示例能覆盖三个关键能力：工具调用、多模态理解和长上下文整合。

7.1 技术架构

整体流程如下：

用户截图上传 -> OCR/图像读取 -> 模型分析截图内容 -> Agent 调用查询接口 -> 返回结构化结果 -> 模型整合最终结论

由于 dots3 直接支持图片输入，可以省去单独的 OCR 环节。架构可以简化为：

1. 用户输入一张“系统监控看板”截图。
2. dots3 理解截图中的指标内容。
3. Agent 根据用户指令，调用外部数据查询工具获取实时数据。
4. dots3 结合截图与实时数据，给出结论。

7.2 定义工具调用函数

为了让模型能够调用工具，我们需要在 API 请求中声明 tool。MiniMax API 的 tool calling 格式与 OpenAI 的 function calling 类似。

先定义一个“查询监控数据”的工具函数：

def query_metric(metric_name: str) -> str: mock_data = { "cpu_usage": "45.2%", "memory_usage": "62.8%", "qps": "3250", "error_rate": "0.12%" } return mock_data.get(metric_name, "unknown metric")

实际项目中，这个函数内部会连接数据库、Prometheus 或内部监控系统，这里用 Mock 数据做演示。

7.3 定义请求结构

接下来构建请求。注意把模型的能力和工具声明同时放进请求中：

import base64 from openai import OpenAI client = OpenAI( api_key="你的key", base_url="https://api.minimax.io/v1" ) tools = [ { "type": "function", "function": { "name": "query_metric", "description": "查询系统监控指标", "parameters": { "type": "object", "properties": { "metric_name": { "type": "string", "enum": ["cpu_usage", "memory_usage", "qps", "error_rate"], "description": "指标名称" } }, "required": ["metric_name"] } } } ] def encode_image(image_path): with open(image_path, "rb") as f: return base64.b64encode(f.read()).decode("utf-8")

7.4 发起 Agent 对话

接下来，向模型发送图片和问题：

image_base64 = encode_image("monitor_dashboard.png") response = client.chat.completions.create( model="MiniMax-M2", messages=[ { "role": "user", "content": [ { "type": "image_url", "image_url": { "url": f"data:image/png;base64,{image_base64}" } }, { "type": "text", "text": "这是当前系统监控截图。请识别图中各指标，并查询 error_rate 和 qps 的最新数据，判断系统是否存在风险。" } ] } ], tools=tools, tool_choice="auto", )

模型如果认为需要调用工具获取更多数据，会在返回内容中包含 tool_calls 字段。我们可以检查这个字段，并执行对应的工具函数：

import json message = response.choices[0].message if message.tool_calls: for tool_call in message.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) print(f"调用函数: {fn_name}, 参数: {fn_args}") result = query_metric(fn_args["metric_name"]) print(f"函数返回: {result}")

然后把工具结果回传给模型，让模型给出最终结论。

7.5 完整 Agent 对话循环

为了简单，下面给出一个支持“模型连续调用工具”的最小循环：

messages = [ { "role": "user", "content": [ {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_base64}"}}, {"type": "text", "text": "看图分析系统状态，并查询 error_rate 和 qps 的最新值，最终输出风险判断。"} ] } ] for step in range(3): response = client.chat.completions.create( model="MiniMax-M2", messages=messages, tools=tools, tool_choice="auto", ) msg = response.choices[0].message if not msg.tool_calls: print("最终回答:") print(msg.content) break messages.append(msg) for tool_call in msg.tool_calls: fn_name = tool_call.function.name fn_args = json.loads(tool_call.function.arguments) result = query_metric(fn_args["metric_name"]) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": result, })

这个循环最多执行 3 轮工具调用，如果模型不再发起新调用，就跳出循环，输出最终结果。

7.6 实测效果分析

从实际体验来看，dots3 在这种“图片识别 + 工具调用 + 多轮整合”的场景中，表现确实比较亮眼。主要体现在三点：

• 能较准确地识别监控截图上的关键指标，包括图表上的数字和文字标签。
• 在复杂指令面前会主动判断是否需要调用工具，不会盲目作答。
• 工具调用后的参数生成比较规范，基本能直接 json.loads 解析。

但也要指出局限：如果图片像素过低、图表文字被遮挡，识别效果会明显下降。建议在实际使用中，先对图片做必要的裁剪和放大处理，再传给模型。

8. 长文本场景实测：512K 上下文能做什么

很多读者对 512K 上下文没有概念。我们做一个假设场景：你只需要把一份几十万字的内部技术规范文档作为背景资料直接传给模型，而不是做 RAG 切片检索。

传统方案长这样：

用户问题 -> 文档切片 -> 向量检索 -> 拼接 TopK 片段 -> 模型回答

这种方式的好处是节省 Token，缺点是切片方式会影响检索准确性，模型可能遗漏上下文关联信息。

而 dots3 的超长上下文，允许在部分场景直接采用“全量文档输入”方案：

用户问题 -> 完整输入文档（如果长度在模型可承受范围内） -> 模型回答

这种方式最适合以下场景：

• 法律合同审查，需要对全文条款做交叉比对。
• 大型项目代码审查，README、核心模块、测试代码都能一次性放入。
• 复杂系统运维排查，历史日志、配置文件、错误报告一起丢给模型。

不过需要提醒一下，超长上下文不等于“无限上下文”。在实际调 API 或本地推理时，还要考虑两个成本：

1. Token 费用：长度越大，单次请求费用越高。
2. 推理时间：输入越长，首字返回时间越长。

9. 常见问题与排查思路

9.1 问题表格

9.2 关于“激活 16B”的典型误解

很多新手看到“仅激活 16B”，会误以为可以像跑 7B 或 14B 模型一样在消费级显卡上运行。这是常见的认知误区。

MoE 模型推理时，虽然单 Token 计算量相当于 16B 稠密模型，但加载模型权重时，必须把 280B 参数全部装入显存或内存。即使做量化，280B 权重也需要非常大的存储空间，因此本地部署通常要准备多卡服务器或大内存机器。

9.3 API 返回超长内容如何稳定获取

dots3 支持超长输出，但在实际调用时，如果设置了流式输出，需要处理流式事件的拼接逻辑；如果不是流式输出，建议设置网络超时时间不要小于 3 分钟，避免请求被客户端提前断开。

10. 最佳实践与工程建议

10.1 图片输入要做预处理

dots3 虽然支持多模态，但不是万能的。实际使用中，图片越清晰、关键区域越突出，识别准确率越高。建议在业务中引入图片预处理流程：先对图片做格式归一化，再裁剪无关区域，必要时放大关键区域。

10.2 Agent 场景需要合理的工具设计

工具调用型 Agent 有一个常见问题：模型需要从工具名和参数描述中学会“什么时候该调哪个工具”。因此工具描述要写清楚边界和预期输出，比如 query_metric 函数中要明确说明 metric_name 的可选值，缩小模型乱猜范围。

10.3 控制输入长度，而不是盲目塞满上下文

虽然 dots3 支持 512K 超长上下文，但建议根据实际场景控制输入长度。处理长文档时，设置清晰的指令位置和结构，把问题放在文档之前或之后，让模型更容易定位关键信息。

10.4 权限与合规

如果你要商用 dots3 的多模态能力，务必阅读官方多模态商用授权说明。对于企业内部敏感数据，建议先做脱敏处理再上传到云端 API。

10.5 版本要动态跟踪

大模型的 GitHub 仓库和 API 文档更新频繁。本文的示例代码在写作时能跑通，但不排除未来模型名称、接口字段或工具调用格式会变化。建议定期查看官方仓库的 Release 和 API 更新日志。

11. 总结与后续学习建议

dots3 这次开源，最值得关注的并不是某一个单项数据，而是它把“低成本推理架构、超长上下文、多模态输入和 Agent 友好能力”组合到了一起。这种模型形态，对未来开源大模型的应用方式会有不小影响。

如果你打算深入学习，建议按下面的路径走：

• 先通过 API 体验文本生成、深度思考、图片理解、工具调用四个基础能力。
• 再阅读 MiniMax 的技术报告，重点理解 Dense-Layer-Sparse-Learning 和 MoE 路由策略。
• 然后用 Python 写一个简单 Agent 原型，把工具调用跑通。
• 等推理框架适配成熟后，再尝试本地多卡部署。

如果遇到具体报错，建议到官方 GitHub Issues 中检索，也可以把你的 model 参数配置、显存信息和完整报错日志贴到评论区一起讨论。

技术发展总是很快，但“理解模型架构、掌握调用方式、学会在业务中验证能力”这条路不会过时。希望这篇文章能帮你快速上手 dots3，少踩一些部署和调用的坑。