MinT：当一个基座模型需要服务百万个"性格"

论文原文：MinT: Managed Infrastructure for Training and Serving Millions of LLMs

arXiv：https://arxiv.org/abs/2605.13779

发布日期：2026-05-13

作者：Andrew Chen, Cleon Cheng, Steven Chiang, Nolan Ho, Andrew Lei et al.（MindLab Research）

想象你是一家大型 AI 公司的基础设施工程师。

公司跑着一个 235B 参数的大模型，某天产品团队找你说：我们现在有法律助手、财务助手、代码助手，还有几百个企业客户各自定制的版本，明天还会有更多。

能不能让每个版本都独立跑起来？

如果你的第一反应是"复制一份模型、起一个独立服务"，那你遇到的问题就和 MinT 这篇论文要解决的问题一模一样。

235B 参数的模型，一份就要占好几百 GB 的 GPU 显存。

复制一百份？那是公司年度 GPU 预算。

复制一千份？就算是顶级 AI 公司也会破产。

现有基础设施的问题不是技术不成熟，而是它的底层抽象错了。

问题的本质：行为不同，但大脑相同

在深入 MinT 的设计之前，先想清楚一件事：为什么"法律助手"和"财务助手"会有不同的行为？

答案是后训练（post-training）。

两个模型的基础知识相同，区别只在于训练时看过的数据和奖励信号。

从参数的角度看，两者的差异可能只有几百 MB，而共同的部分高达几百 GB。

LoRA（Low-Rank Adaptation）：一种参数高效微调技术，不修改原始模型的巨大权重矩阵，而是在旁边附加两个小得多的矩阵，训练这两个小矩阵来捕捉任务差异。最终微调只需要更新这两个低秩矩阵，参数量可以减少到原始模型的不到 1%。

后训练（Post-training）：预训练之后、部署之前的优化阶段，包括监督微调（SFT）、偏好优化（DPO）和强化学习（GRPO/PPO）等技术，让模型从"能生成文字"变成"能有用地生成文字"。

现有的基础设施在逻辑上把"行为不同"等价于"是不同的模型"，每训练出一个新行为，就要物化一个完整的新检查点，然后加载一个独立服务。

这个等价关系，在策略数量少的时候没问题。但当策略数量达到百、千、万甚至百万时，就会让整个系统崩溃。

MinT 的核心洞察是：这个等价关系是错的。

行为不同，不代表整个模型不同。

大多数情况下，变化的只是一个很小的 LoRA 适配器。

核心设计：让基座永远"住"在那里

MinT 的核心思想可以用一句话概括：基座模型永远驻留，只移动轻量适配器。

基座模型（Base Model）：通用能力的载体，包含预训练阶段学到的全部知识。通常是几十 GB 到几百 GB 的权重矩阵，装满了语言规律、世界知识和推理能力。

适配器（Adapter）：附加在基座模型上的轻量组件。在 MinT 的体系里，这指的是 LoRA 参数，代表一个特定的"行为"或"策略"。

这就像一家大型图书馆：图书馆的建筑、书架、索引系统（基座模型）永远在那里，不会因为某个读者要借一本特定的书而重新盖一栋楼。

读者想要什么，图书管理员（MinT）去把那本书（LoRA 适配器）取来就行。

传统方法是：每个读者都要有专属的图书馆，想要一本书，就把整个图书馆的藏书复制一份过去，连同那本书一起。

传统做法的荒谬之处在于：99% 的内容是一样的，但还是要复制 100%。

MinT 绕开这个问题的方式，是重新定义训练和推理之间传递的"货物"。

原来传的是整个模型（火车厢加上所有货物一起搬），MinT 改成只传行为差异（只换货物，火车厢留在那里）。

上图展示的是 MinT 的适配器切换路径和传统全量检查点路径的时间对比。

Qwen3-4B 模型上，全量合并路径需要 71.8 秒来物化检查点，再花时间加载，合计冷启动延迟超过 55 秒。

而 MinT 的适配器路径，物化时间只有 0.036 秒，整个切换快了 18.3 倍。

把这个数字翻译成具体场景：如果每 30 分钟训练出一个新策略版本，全量路径要花 72 秒传输，适配器路径只需要不到 1 秒。

一年下来节省的等待时间，对工程师来说是真实的生产力差距。

适配器修订版本：行为的最小可管理单元

MinT 引入了一个核心抽象：适配器修订版本（Adapter Revision）。

适配器修订版本（Adapter Revision）：MinT 把每次训练完成后导出的 LoRA 参数快照称为"适配器修订版本"，是一个固定的、版本化的行为载体，可以被回滚、被比较、被独立评估，也是从训练侧传递到推理侧的唯一"货物"。

策略记录（Policy Record）：MinT 维护的每个策略的元数据，记录了基座模型版本、LoRA rank 和目标模块、最新训练检查点位置、已导出的适配器修订版本列表。是策略的"档案"，而不是策略本身。

这两个概念的区分值得仔细想一想。

训练完成之后，trainer 手里有很多东西：LoRA 张量、优化器动量、调度器状态、梯度累积、rollout 记录。这些东西推理引擎不需要，也用不了。

推理引擎只需要一个"固定的 PEFT 适配器文件，格式符合 vLLM 的要求"。

MinT 的 export 步骤做的事情，就是把训练侧的一堆状态，精简成推理侧需要的最小文件，然后打上版本号，存进共享存储。

好处是：rollout（采样）可以继续，评估可以进行，在线服务可以响应，都用同一个固定版本。而 trainer 可以继续下一轮更新，两边互不干扰。

这个分离还有一个实用价值：回滚变得简单。

如果某个新版本在评估中表现变差，直接把服务切回上一个适配器修订版本，不需要重新训练，不需要重建服务，秒级完成。

三个扩展维度

MinT 把自己的能力划分为三个方向，每个方向解决一类不同的规模问题。

Scale Down：让切换快到可以忽略

Qwen3-4B 模型的一个 rank-32 的 LoRA 适配器，文件大小是 252 MB。

而同样的模型，全量 bf16 权重需要 8.06 GB。适配器只占基座的 3.3%。

如果用 rank-1 的更精简配置，适配器文件可以压到 7.9 MB，占基座的 0.1%。这才是论文摘要里"小于基座 1%"这个数字的来源。

MinT 还做了另一件事：并发多策略训练。一台机器上的基座模型可以"轮流"被多个策略使用，当策略 A 在等待 rollout 数据时，策略 B 来用同一个训练器做梯度更新。

GRPO（Group Relative Policy Optimization）：一种适合 LLM 后训练的强化学习算法，不需要独立的价值模型，通过对一组输出进行相对比较来估计优势，更节省显存，是 MinT 默认支持的 RL 算法之一。

在 Qwen3-4B 上，顺序训练 3 个策略需要 3081 秒，并发训练压缩到 1736 秒，速度提升 1.77 倍，而峰值显存完全不变。

原因很直觉：之前那些被浪费的"空档期"（策略 A 在等数据的那几分钟），现在被策略 B 充分利用了。

这就像一个厨房里只有一个炉子。

传统做法是把菜一个一个炒完。MinT 的做法是：洗菜、切菜、炒菜流水线并行，这个菜等火候的时候，那个菜已经在炒了。炉子（基座）没变，产出（策略数量）多了。

时间片轮换策略切换的成本也被仔细测量过：切换时，LoRA 张量、优化器动量、调度器位置、梯度累积和 rollout 记录都要写出并读入。

基座权重始终留在 GPU 显存里，不动。

切换的代价和 LoRA 大小成正比，而不是和基座大小成正比。这个设计选择让时间片调度在实际中可行。

Scale Up：万亿参数也能用同一套

规模扩展方向解决的是另一个问题：当基座模型大到一台机器装不下时，MinT 仍然能用同一套流程工作。

张量并行（Tensor Parallelism）：把单个矩阵切成多块，分别放到不同的 GPU 上计算，最后汇总结果，适用于模型太大无法放进单个 GPU 的情况。

专家并行（Expert Parallelism）：MoE 模型的特有并行方式，把不同的"专家子模块"分散到不同的 GPU 上，每个 token 只激活其中一部分。

MoE（Mixture of Experts）：一种模型架构，有很多个专家子模块（每个像一个小模型），每次推理时路由器决定哪些专家来处理当前 token。总参数量大，但激活参数量小，计算效率更高。

对于 Qwen3-235B-A22B（2350 亿总参数，激活 220 亿）和 Kimi K2（1.04 万亿参数）这样的模型，MinT 采用 Megatron 分布式训练框架来管理张量并行和专家并行的分片。

这里有一个细节值得关注：MoE 的强化学习训练比 Dense 模型更难。

原因是路由器不稳定性，同一个 token 在 rollout（采样数据）时走了专家 A，但在训练时重新计算概率，路由器可能选了专家 B。

这样的路径不一致会让策略梯度的估计严重出错。

MinT 的解决方案是记录每个 token 的专家路径，训练时重放这个路径。

如果路径无法重建，就把那个 token 的梯度贡献清零，宁可少用数据也不要用错误的数据。

路由器重放（MoE Router Replay）：训练时把 rollout 中每个 token 的专家路由决策记录下来，在策略梯度计算时重放这个路径，保证 rollout 和训练使用完全一致的专家子模块。这是 MinT 保证 MoE RL 训练稳定性的关键机制。

IcePop 修正（IcePop-style rollout correction）：一种安全机制。当训练和 rollout 的 token 概率比值超出设定阈值时，把该 token 的重要性权重置零，防止错误的训练信号污染梯度。

上图展示了 MinT 在 Qwen3 系列 Dense 模型上的训练曲线，覆盖了 SFT（监督微调）、DPO（偏好优化）、GRPO（强化学习）三种后训练范式。

不同任务的指标各异，但曲线都在收敛，说明同一套基础设施适配了不同的训练类型。

MoE 模型的曲线更有挑战性。

Qwen3-30B/235B 两个规模的 GRPO 曲线都在上升，但波动更大，体现了 MoE RL 训练的固有难度。

MinT 的路由记录和 IcePop 修正是让这些曲线收敛而不是发散的关键。

分布式导出（Distributed Export）是这一方向里最复杂的工程细节。

训练时，LoRA 张量被切分到多个 GPU 上，每个 GPU 只持有一部分。推理引擎（vLLM）需要完整的 PEFT 适配器文件。

MinT 在 export 时负责：把张量并行的切片拼合起来，去重共享专家的 LoRA，把专家并行各节点的数据收集到一起，最终写出一个 vLLM 可以直接加载的适配器文件。

这个步骤把分布式训练和推理解耦了：训练端可以用任意并行配置，推理端看到的是一个整洁的 PEFT 文件，两边互不感知对方的内部状态。

Scale Out：百万策略目录的管理

"服务百万个 LLM"这个目标听起来很夸张，但 MinT 对它有严格的定义边界：百万指的是可寻址的策略目录大小，不是同时在 GPU 里跑的数量。

策略目录（Policy Catalog）：MinT 维护的所有已训练适配器的目录，每个条目代表一个可以被名字检索和激活的模型行为版本。就像一个图书馆目录，知道每本书在哪里，但不等于每本书都在你手边。

MinT 把适配器的存在分为三层：

第一层：可寻址目录（冷存储）。所有曾经导出的适配器文件，存在共享存储里，可以按名字找到，但未必在内存里。上限可达百万级别。

第二层：CPU 缓存（暖层）。最近被访问过的适配器，加载到 CPU 内存里等待。单个推理引擎可以维护几百个。

第三层：GPU 批次（热层）。当前正在推理的适配器，在 GPU 的 LoRA 插槽里。同一批次最多 64 个不同的适配器并存。

这个设计类比浏览器的缓存机制：所有网页（百万策略）都"可以访问"，常用的留在内存（CPU 缓存），当前显示的在屏幕上（GPU 批次）。

你不会因为互联网上有千亿个网页就要一次把它们全装进 RAM。

冷加载是 MinT 特别处理的一个问题。当一个新策略被请求但不在 CPU 缓存里，需要从存储加载，这个延迟不可忽视。

MinT 把冷加载作为一个"服务任务"来管理：去重（多个请求同一个适配器只加载一次）、排队、背压控制，防止大量冷加载请求同时涌入把系统打满。

三层缓存的规模数字：

对于 MoE 模型，MinT 还做了"打包 MoE LoRA 张量"的优化：把分散的小文件合并成更大的连续块，减少存储系统的小对象 IO 开销，让冷加载速度提升 8.5 - 8.7 倍。

AutoResearch：从框架到实际 agent 任务

理论说得再好，最终要能用到真实的 agent 任务上才算数。

MinT 提供了一套叫 mint-cookbook 的配方层，把常见的 post-training 任务打包成可复现的流程。

mint-cookbook：MinT 的 recipe（配方）层，包含了 SFT、DPO、rollout-based RL、AutoResearch 等常见后训练场景的配置和代码，用户可以直接用这些配方复现实验或者在上面改造。

AutoResearch 是其中一个值得单独拿出来看的例子。

它的目标是让模型自动完成研究性任务：先用代理指标（proxy metrics）快速筛选候选方案，再用完整评估确认。

图中展示了 LawBench 法律推理任务上的 AutoResearch 轨迹。

灰色点是代理评估筛出来的候选，蓝色点是通过完整评估的策略版本。

可以看到，early stopping 机制在代理分数达到阈值后自动停止，避免了不必要的计算。

整个过程在 MinT 的框架里是全自动的：训练、评估、筛选、再训练，形成一个闭环。

这个实验说明的不仅是技术可行性，更是整个设计思路的延伸：当 adapter revision 成为行为的基本单元，"搜索最优策略"这件事就自然变成了在 adapter 空间里做优化搜索，而搜索的每一步都有完整的审计追踪。

实验里最值得看的数字

MinT 用几个实验来验证它的设计。

Handoff 实验（Scale Down 核心证据）：

4B 模型上，物化时间 0.036 秒 vs 71.8 秒，差了近 2000 倍。

30B 上，402 秒 vs 46 秒，差了近 9 倍。

这个差距会随着模型变大而收窄（因为即使是 LoRA，30B 的也有 1.7GB），但方向是一致的：传输适配器永远比传输整个模型快。

并发训练实验（Schedule 利用率证据）：

并发的加速来自"填补空洞"，不需要买更多 GPU，不需要更大的显存，只需要重新安排时间表。

如果用通俗的说法：同样的机器，同样的钱，MinT 让你在相同时间里训练出 1.77 倍多的策略版本。

对于需要持续迭代多个产品线的 AI 公司，这是一个真实的竞争优势。

系统运转的全貌

把三个维度拼在一起，MinT 是这样工作的。

一个训练请求进来，MinT 的服务层验证请求、查找策略记录、找到兼容的 worker，然后把工作排队。

训练完成后，MinT 导出一个适配器修订版本，把分散在多个 GPU 上的 LoRA 张量片段重新拼合成 PEFT 格式，放入共享存储。

推理请求进来时，服务层把用户的策略名字解析为具体的适配器修订版本。

如果 GPU 里已经有了，直接用；如果 CPU 里有，提升到 GPU；如果只在存储里，调度冷加载任务，加载完再推理。

整个流程里，基座模型的权重从来不被复制、不被修改，只有 LoRA 适配器在三层之间移动。

Tinker：MindLab 之前的一个 RL 训练框架，MinT 兼容其 API 设计，意味着已有的 recipe（训练配方）可以无缝迁移到 MinT，降低用户的迁移成本。

一个 Tinker 兼容的 API 让调用者看不到这一切复杂性，只需要告诉 MinT：我要用哪个策略，给我推理结果。底层的驻留管理、时间片调度、导出转换、缓存提升、冷加载排队，全部对调用者不可见。

这是良好基础设施设计的经典标志：把复杂性藏在接口后面，让上层系统保持简单。

另一个细节值得一提：MinT 的 fault tolerance（容错）设计。

操作可见性规则确保，只有当 MinT 把元数据条目写入完成后，该适配器修订版本才对外可见。

如果 worker 在写入 adapter 文件之后、但在记录元数据之前崩溃，后续请求看不到这个不完整的修订版本，调用方可以安全重试。

这个"先有文件、再有元数据记录"的两步提交设计，让系统在故障面前保持了行为的确定性。训练可以重跑，评估可以重跑，在线服务始终只选择完整提交的版本。

操作可见性（Operation Visibility）：MinT 的提交机制，只有当操作的所有文件写入完成并且元数据记录成功落库，这个操作结果才对调用方可见。Worker 中途崩溃不会产生"幽灵版本"，保证了策略目录的一致性。

写在后面

2025 年之前，大多数 LLM 服务系统的隐含假设是：模型的行为版本数量是有限的，一位数或者两位数。

这个假设在那个时代完全合理，因为训练一个版本需要几天甚至几周，哪个公司会同时维护一千个版本？

但强化学习改变了这个节奏。

GRPO 这类算法让"每次 rollout 一个更新"成为常态操作。

一个 agent 在 24 小时里可能产出数十个有意义的策略版本。

再加上多租户，每个企业客户都想要自己的定制版本，策略数量的增长不再是线性的，而是指数的。

MinT 的出现恰好踩在这个需求爆炸的时间点上。

它不是在回答"如何训练更好的模型"，而是在回答"如何在一个大模型上同时运营一百万个小行为"。

这个问题的重要性，在 agentic AI 和个性化 AI 成为主流之后，会比训练算法本身更加基础。

让我觉得有意思的一点是，MinT 的整体架构思路和操作系统的进程管理惊人地相似：基座模型像 CPU，LoRA 适配器像进程上下文，三层缓存像寄存器和 L1/L2 缓存和内存的层次结构，冷加载像缺页异常，策略记录像进程控制块。

AI 基础设施正在重新发明操作系统的那些核心抽象，只是规模大了几个数量级，要解决的约束也不一样。

如果这个方向成立，未来的 AI 基础设施工程师可能更像今天的 OS 工程师：研究调度、缓存、并发，而不是模型本身。那些掌握了"系统层"思维的工程师，在 AI 时代的价值只会越来越大。