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都要把整个模型的参数都加载并参与计算。而 MoEMixture 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 这次开源的内容大致包括文件说明模型权重文本权重完整开放支持 huggingface 下载推理代码MiniMax-Inference 仓库中的推理脚本Agent 推理代码针对 Agent 场景优化的推理代码技术报告说明架构细节与训练方法当前很多第三方生态工具如 vLLM、SGLang 等也在陆续适配 dots3建议部署前先确认你要用的推理框架是否已经支持该模型结构。3.3 多模态能力的授权说明这里要特别注意dots3 的多模态能力目前并非“完全开放权重”状态。根据目前公开信息dots3 多模态相关的权重需要单独申请商用授权如果你只是个人学习或研究可以直接用 API 体验多模态效果如果要在商业产品中集成多模态能力需要走官方商务渠道。如果你的使用场景只涉及文本那就没有这个限制。文本权重可以直接下载也可以商用。4. 环境准备与依赖说明这一部分我们重点说明如何把 dots3 跑起来。先看环境需求再给出可落地的操作步骤。4.1 硬件要求dots3 总参数 280B即使采用 MoE 架构想把整模型权重加载到单张显卡也不现实。本地部署前需要先明确一个概念MoE 模型理论上是“只激活部分专家”但实际推理框架在加载阶段仍然需要把全部专家权重读入显存或内存中。你不可能只加载 16B 参数就跑起来因为不同 Token 会路由到不同专家所有专家参数在计算时都可能会被访问。因此硬件规划建议如下方案配置适用场景纯内存演示512GB 内存CPU 推理体验模型结构不追求速度多卡部署8 张 A100/H100 80G完成基础推理量化部署支持量化框架适配后降低显存占用精度略损API 调用官方或第三方 API最快体验方式需要强调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你的key5.2 文本生成体验如果你习惯使用 OpenAI SDK可以发现 MiniMax 的接口风格与 OpenAI 高度兼容。只需要修改 base_url 和 model 名称就能直接跑通。下面给出一个最小可运行的文本生成示例from openai import OpenAI client OpenAI( api_key你的key, base_urlhttps://api.minimax.io/v1 ) response client.chat.completions.create( modelMiniMax-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_urlhttps://api.minimax.io/v1 ) response client.chat.completions.create( modelMiniMax-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_urlhttps://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( modelMiniMax-M2, messages[ { role: user, content: [ {type: image_url, image_url: {url: fdata: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 显存不够时的方案如果你的设备暂时不具备多卡条件可以从以下几点入手方案说明使用 API成本最低模型能力不损失等待社区量化社区出现 GGUF/AWQ 量化后部署门槛会明显降低使用小尺寸模型如果只是学习和实验先跑通同架构的小模型也是一条路径云 GPU 按需租用按小时租用最稳妥7. 实战用 dots3 做一个多模态 Agent这一节我们做一个完整的 Agent 示例。目标让模型根据用户上传的截图分析页面问题并调用一个查询工具获取数据库信息最后输出完整结论。这个示例能覆盖三个关键能力工具调用、多模态理解和长上下文整合。7.1 技术架构整体流程如下用户截图上传 - OCR/图像读取 - 模型分析截图内容 - Agent 调用查询接口 - 返回结构化结果 - 模型整合最终结论由于 dots3 直接支持图片输入可以省去单独的 OCR 环节。架构可以简化为用户输入一张“系统监控看板”截图。dots3 理解截图中的指标内容。Agent 根据用户指令调用外部数据查询工具获取实时数据。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_urlhttps://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( modelMiniMax-M2, messages[ { role: user, content: [ { type: image_url, image_url: { url: fdata:image/png;base64,{image_base64} } }, { type: text, text: 这是当前系统监控截图。请识别图中各指标并查询 error_rate 和 qps 的最新数据判断系统是否存在风险。 } ] } ], toolstools, tool_choiceauto, )模型如果认为需要调用工具获取更多数据会在返回内容中包含 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: fdata:image/png;base64,{image_base64}}}, {type: text, text: 看图分析系统状态并查询 error_rate 和 qps 的最新值最终输出风险判断。} ] } ] for step in range(3): response client.chat.completions.create( modelMiniMax-M2, messagesmessages, toolstools, tool_choiceauto, ) 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 或本地推理时还要考虑两个成本Token 费用长度越大单次请求费用越高。推理时间输入越长首字返回时间越长。9. 常见问题与排查思路9.1 问题表格问题现象常见原因解决思路模型回答说没有视觉能力未使用支持多模态的模型版本确认 model 名称是否支持多模态或通过 API 调用工具调用不生效tools 参数格式错误对比 OpenAI 工具调用格式检查 function 定义字段图片内容理解不准图片分辨率太低先裁剪、放大关键区域再上传本地部署加载失败显存或内存不足换更大配置使用多卡分布式推理Model 名称 404API 平台模型代号变更查询官方平台最新文档模型输出中断超时时间过短调长 timeout 等待时间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少踩一些部署和调用的坑。
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都要把整个模型的参数都加载并参与计算。而 MoEMixture 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 这次开源的内容大致包括文件说明模型权重文本权重完整开放支持 huggingface 下载推理代码MiniMax-Inference 仓库中的推理脚本Agent 推理代码针对 Agent 场景优化的推理代码技术报告说明架构细节与训练方法当前很多第三方生态工具如 vLLM、SGLang 等也在陆续适配 dots3建议部署前先确认你要用的推理框架是否已经支持该模型结构。3.3 多模态能力的授权说明这里要特别注意dots3 的多模态能力目前并非“完全开放权重”状态。根据目前公开信息dots3 多模态相关的权重需要单独申请商用授权如果你只是个人学习或研究可以直接用 API 体验多模态效果如果要在商业产品中集成多模态能力需要走官方商务渠道。如果你的使用场景只涉及文本那就没有这个限制。文本权重可以直接下载也可以商用。4. 环境准备与依赖说明这一部分我们重点说明如何把 dots3 跑起来。先看环境需求再给出可落地的操作步骤。4.1 硬件要求dots3 总参数 280B即使采用 MoE 架构想把整模型权重加载到单张显卡也不现实。本地部署前需要先明确一个概念MoE 模型理论上是“只激活部分专家”但实际推理框架在加载阶段仍然需要把全部专家权重读入显存或内存中。你不可能只加载 16B 参数就跑起来因为不同 Token 会路由到不同专家所有专家参数在计算时都可能会被访问。因此硬件规划建议如下方案配置适用场景纯内存演示512GB 内存CPU 推理体验模型结构不追求速度多卡部署8 张 A100/H100 80G完成基础推理量化部署支持量化框架适配后降低显存占用精度略损API 调用官方或第三方 API最快体验方式需要强调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你的key5.2 文本生成体验如果你习惯使用 OpenAI SDK可以发现 MiniMax 的接口风格与 OpenAI 高度兼容。只需要修改 base_url 和 model 名称就能直接跑通。下面给出一个最小可运行的文本生成示例from openai import OpenAI client OpenAI( api_key你的key, base_urlhttps://api.minimax.io/v1 ) response client.chat.completions.create( modelMiniMax-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_urlhttps://api.minimax.io/v1 ) response client.chat.completions.create( modelMiniMax-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_urlhttps://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( modelMiniMax-M2, messages[ { role: user, content: [ {type: image_url, image_url: {url: fdata: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 显存不够时的方案如果你的设备暂时不具备多卡条件可以从以下几点入手方案说明使用 API成本最低模型能力不损失等待社区量化社区出现 GGUF/AWQ 量化后部署门槛会明显降低使用小尺寸模型如果只是学习和实验先跑通同架构的小模型也是一条路径云 GPU 按需租用按小时租用最稳妥7. 实战用 dots3 做一个多模态 Agent这一节我们做一个完整的 Agent 示例。目标让模型根据用户上传的截图分析页面问题并调用一个查询工具获取数据库信息最后输出完整结论。这个示例能覆盖三个关键能力工具调用、多模态理解和长上下文整合。7.1 技术架构整体流程如下用户截图上传 - OCR/图像读取 - 模型分析截图内容 - Agent 调用查询接口 - 返回结构化结果 - 模型整合最终结论由于 dots3 直接支持图片输入可以省去单独的 OCR 环节。架构可以简化为用户输入一张“系统监控看板”截图。dots3 理解截图中的指标内容。Agent 根据用户指令调用外部数据查询工具获取实时数据。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_urlhttps://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( modelMiniMax-M2, messages[ { role: user, content: [ { type: image_url, image_url: { url: fdata:image/png;base64,{image_base64} } }, { type: text, text: 这是当前系统监控截图。请识别图中各指标并查询 error_rate 和 qps 的最新数据判断系统是否存在风险。 } ] } ], toolstools, tool_choiceauto, )模型如果认为需要调用工具获取更多数据会在返回内容中包含 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: fdata:image/png;base64,{image_base64}}}, {type: text, text: 看图分析系统状态并查询 error_rate 和 qps 的最新值最终输出风险判断。} ] } ] for step in range(3): response client.chat.completions.create( modelMiniMax-M2, messagesmessages, toolstools, tool_choiceauto, ) 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 或本地推理时还要考虑两个成本Token 费用长度越大单次请求费用越高。推理时间输入越长首字返回时间越长。9. 常见问题与排查思路9.1 问题表格问题现象常见原因解决思路模型回答说没有视觉能力未使用支持多模态的模型版本确认 model 名称是否支持多模态或通过 API 调用工具调用不生效tools 参数格式错误对比 OpenAI 工具调用格式检查 function 定义字段图片内容理解不准图片分辨率太低先裁剪、放大关键区域再上传本地部署加载失败显存或内存不足换更大配置使用多卡分布式推理Model 名称 404API 平台模型代号变更查询官方平台最新文档模型输出中断超时时间过短调长 timeout 等待时间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少踩一些部署和调用的坑。