--- layout: post.njk source: https://blog.qiaomu.ai/mint-lora-adapter-llm-infrastructure speaker: 向阳乔木 title: MinT：当一个基座模型需要服务百万个"性格" · 乔木博客 date: '2026-05-15' summary: MinT 是一种 LLM 基础设施方案，通过基座模型驻留与 LoRA 适配器动态切换的分离架构，解决了在同一基座上高效训练、管理和部署百万级不同行为 LLM 的难题，显著提升了后训练和推理的效率。 area: tech-engineering category: ai-application tags: - llm-infrastructure - lora - post-training - model-serving - adapter-management people: - Andrew Chen - Cleon Cheng - Steven Chiang - Nolan Ho - Andrew Lei companies_orgs: - MindLab Research products_models: - MinT - Qwen3 - Kimi K2 media_books: [] draft: true status: evergreen --- 乔木博客 全部 AI工具 AI教程 AI生成 AI资讯 健脑房 播客解读 论文学习 # MinT：当一个基座模型需要服务百万个"性格" 论文学习 · 2026年5月15日 · 36 次阅读 · 约 22 分钟 > 论文原文：MinT: Managed Infrastructure for Training and Serving Millions of LLMsarXiv：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 把冷加载作为一个"服务任务"来管理：去重（多个请求同一个适配器只加载一次）、排队、背压控制，防止大量冷加载请求同时涌入把系统打满。 三层缓存的规模数字： 层级 规模 生命周期 实测 可寻址目录 10³ - 10⁶ 持久（控制面） 实测单引擎扫描 100k 条目，fleet 模型外推到 10⁶ CPU 适配器缓存 几百个 单 actor 运行期 实测单引擎 369/550 个缓存 GPU 批次 64 单解码步 实测 64 个不同适配器并行 对于 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 核心证据）： 模型 路径 检查点大小 物化时间 冷首次样本延迟 Qwen3-4B 适配器路径 252 MiB 0.036 秒 4.1 秒 Qwen3-4B 合并路径 8.06 GB 71.8 秒 55.7 秒 Qwen3-30B 适配器路径 1.69 GB 46.5 秒 117 秒 Qwen3-30B 合并路径 61.1 GB 402 秒 156 秒 4B 模型上，物化时间 0.036 秒 vs 71.8 秒，差了近 2000 倍。 30B 上，402 秒 vs 46 秒，差了近 9 倍。 这个差距会随着模型变大而收窄（因为即使是 LoRA，30B 的也有 1.7GB），但方向是一致的：传输适配器永远比传输整个模型快。 并发训练实验（Schedule 利用率证据）： 模型 策略数 顺序用时 并发用时 加速 峰值显存 Qwen3-4B 3 3081 秒 1736 秒 1.77 倍 65.6 GiB（相同） Qwen3-30B 3 10130 秒 7009 秒 1.45 倍 68.0 GiB（相同） 并发的加速来自"填补空洞"，不需要买更多 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 时代的价值只会越来越大。 © 2026 · 向阳乔木