Fine-Tune MiniMax M2.5 with Ertas

    MiniMax 旗舰编码模型——目前在开放权重模型中以 80.2% 的成绩领跑 SWE-Bench Verified 榜单,专为智能体编码工作负载设计。后续的 M2.7 版本继续延展该产品线。

    456B-A45BMiniMax

    Overview

    MiniMax M2.5 目前是开放权重模型中 SWE-Bench Verified 的领跑者,得分高达 80.2%——这是开放权重模型能够在真实软件工程任务上匹配甚至超越专有替代方案的最有力信号之一。该模型采用大型专家混合架构,活跃参数约为 45B,在保持与其总参数量相称的强劲推理经济性的同时,展现出可与前沿专有模型抗衡的编码能力。

    MiniMax 在发布该模型时着重强调了智能体编码工作负载——例如端到端功能实现、多文件重构和代码库导航等任务模式。其训练流程注重可验证代码执行奖励,与 Qwen3-Coder 和 MiMo V2.5 Pro 在后训练方法学上的特色相似。最终成果是一个在处理真实软件工程任务时显著优于同等规模通用模型的模型。

    M2.5 发布之后紧接着推出了 M2.7,继续巩固其在 SWE-Bench 上的领先地位。对于自托管智能体编码代理的团队而言,MiniMax M2.5(或其继任者 M2.7)是当前最具吸引力的开放权重选项之一——它将前沿基准性能、商用宽松许可和优良的推理经济性结合于一身。

    权重已在 Hugging Face 的 MiniMax 组织下公开。许可证为商用宽松型,条款类似于其他中国实验室开放权重发布所采用的 Apache 2.0 / MIT 风格许可。

    Key Features

    SWE-Bench Verified 80.2% 的领先成绩是 M2.5 最具代表性的基准结果。SWE-Bench Verified 评估模型在源自开源仓库的真实软件工程任务上的表现——例如关闭需要多文件改动、测试驱动迭代和跨现有代码库代码理解的 GitHub issue。M2.5 在这一特定基准上的得分超过了包括 MiMo V2.5 Pro 在内的其他开放权重模型。

    智能体编码训练的侧重点带来了仅靠合成基准无法体现的真实可靠性。M2.5 在处理多步编码任务时具有出色的工具使用保真度、结构化输出遵循度和操作可预测性——非常适合在 LangGraph、CrewAI 等智能体框架或专用编码 CLI 中进行生产环境部署。

    45B 活跃参数的 MoE 架构使 M2.5 具备良好的推理经济性。在标准框架上的 token 生成吞吐量约为 45B 级速度,完全在中端服务器硬件的运行范围内。对于 API 成本过高的高吞吐量智能体编码部署,M2.5 的自托管经济性在大多数生产场景下都具有竞争力。

    M2.5 是活跃发布节奏的一部分——M2.7 是其紧邻的继任者,基准成绩进一步提升。对于选择 MiniMax 进行生产部署的团队来说,这种活跃的开发轨迹增强了对未来持续能力提升的信心。

    Fine-Tuning with Ertas

    在 Ertas Studio 中对 MiniMax M2.5 进行完整规模的 QLoRA 微调需要多 GPU 服务器配置。在典型序列长度下,大约需要 280-340GB 的总 VRAM,可在 8x A100 80GB 或同等服务器上运行。

    对于大多数缺少此类基础设施的团队,推荐采用师生蒸馏模式:将 M2.5 用作教师生成合成的智能体编码训练数据,再在该数据上微调更小的基础模型(Qwen 32B、Qwen3-Coder-30B-A3B 或 Llama 70B)。这样可以在继承 M2.5 编码模式的同时,以单 GPU 部署成本得到一个领域专精的编码模型。

    在微调数据集方面,M2.5 从包含完整智能体编码轨迹(任务描述、规划、代码编辑、测试输出和迭代)的训练数据中获益颇多。Ertas Studio 原生支持这些多步格式,包括来自 CLI 智能体运行的工具使用轨迹。

    训练完成后,Ertas Studio 可导出为 GGUF(或 vLLM 原生格式以获得更高吞吐量)。完整 M2.5 模型的 Q4_K_M 量化体积庞大——属于多 GPU 服务器部署级别——但蒸馏到更小基础模型上的微调结果可按 7B-70B 标准尺寸导出,适用于常规单 GPU 部署。

    Use Cases

    智能体编码是 M2.5 的核心目标场景。生产部署模式包括自主 PR 生成、大规模重构辅助、面向企业代码库的 AI 结对编程,以及 CI 集成的代码审查代理。SWE-Bench Verified 的领先地位与强劲的推理经济性相结合,使 M2.5 对于希望自托管编码代理以避免高吞吐量下 API 成本的团队尤为吸引人。

    对于考虑替代 Claude Code、Cursor 后端模型或 GitHub Copilot 的自托管方案的团队而言,MiniMax M2.5 是最强选择之一。前沿基准性能、商用宽松许可和活跃的发布节奏相结合,使其成为可信赖的长期选择,而非临时方案。

    多步工程工作流——代码库迁移、依赖升级、安全审计修复——可显著受益于 M2.5 强大的编码能力与可靠的智能体执行能力的结合。该模型在可验证代码执行奖励上的训练,使其在这些任务类型上比通用模型具有更好的真实可靠性。

    Hardware Requirements

    MiniMax M2.5 在 Q4_K_M 量化下大约需要 250GB 内存,可在 4x A100 80GB 或 4x H100 80GB 服务器上运行,或在拥有 384GB+ 内存的 CPU 推理主机上运行。模型加载完成后,45B 的活跃参数量决定了 token 生成吞吐量。

    对于较小规模部署,Q3_K_M 量化(约 190GB)以略微下降的质量换取更小的内存占用,可在 2x H100 80GB 或 3x A100 80GB 配置上运行。不建议在生产编码代理中使用低于 Q3 的量化——多步推理上的质量退化会变得明显。

    关于在 Ertas Studio 中微调:M2.5 QLoRA 大约需要 280-340GB 的总 VRAM(多 GPU 服务器)。对于没有此规模条件的团队,可使用 M2.5 作为教师,蒸馏到 Qwen3-Coder-30B-A3B(24GB GPU)、Qwen 32B(40GB GPU)或 Llama 70B(48GB GPU)上,从而以显著更低的微调成本获得领域专精的编码代理。

    Supported Quantizations

    Q3_K_MQ4_0Q4_K_MQ5_K_MQ6_KQ8_0

    Related Resources

    Ship AI that runs on your users' devices.

    Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.