5 月 14 日，HuggingFace Daily Papers 顶流位置出现一份 27 页技术报告：MindLab 团队的 MinT。它不是一个新模型，而是一套基础设施，目标只有一个——让一个百万级 LoRA 适配器目录在生产环境能跑得起来、调得过来、改得动。本文按论文原文的三段 scaling 把核心做法过一遍，并给出对国内自建 LLM 团队的实操启示。
TL;DR
MinT 用「LoRA 是 first-class artifact」这一个简单设计理念，重构了 RLHF 训练 + 推理 + 调度的整条链路。Scale Up 把 LoRA RL 跑到了 1T 参数；Scale Down 让 step time 在 4B 上加速 18.3 倍、30B MoE 上 2.85 倍；Scale Out 用单引擎 sweep 100K addressable adapters 与千级并发演示了真正的「million-scale catalog」。其底层秘诀是：base model 常驻 + adapter-only handoff + cold loading 服务化。本文把每段 scaling 拆给你看，并给出可在自家集群快速复刻的三个工程要点。
一、问题陈述：为什么需要「million-scale」？
MinT 的开篇直接抛出业界正在掉进的一个坑：
「The unit of inference is no longer a model; it’s a policy.」
这句话翻译成工程语言就是：
- 一次 RL 训练 run 会生成数百到数千个 policy revision，每个 revision 想被独立追溯、回滚、评估。
- 一个 SaaS 平台为每个客户 fine-tune 一个 adapter，10 万客户即 10 万 adapter。
- 一个研究团队跑 ablation，每个 hyperparameter 组合各产出一个 adapter，搜索空间动辄百万。
而传统的「merge LoRA → 导出完整 checkpoint → 上 vLLM」流程在这个量级会被三件事压垮：
- 存储：每个 7B merged checkpoint 14GB，10 万就是 1.4PB。
- 加载延迟：从对象存储拉一个 14GB 模型到 GPU，热启动也要 30 秒以上。
- 调度耦合：训练侧和推理侧用的是两个独立 base model 实例，浪费了一半显存。
MinT 的做法是把这三件事一起重写。
二、Scale Up：跑到 1T 参数与现代 attention
Scale Up 维度解决的是 base model 端的问题。MindLab 在论文里给了三组实测：
| 模型规模 | 架构 | LoRA RL 状态 | 备注 |
|---|---|---|---|
| 235B-A22B | MoE + MLA | ✓ 完整 RL run | Tinker cookbook 复刻 |
| 30B | dense + MLA | ✓ 完整 RL run | base benchmark |
| 1T-class | MoE + DSA | ✓ countdown task | 单任务 demo |
值得注意的是 MinT 同时支持 MLA（Multi-head Latent Attention，DeepSeek 路线）与 DSA（Diff-Sparse Attention，新近 paper），表明它的 LoRA 注入并不假设固定的 attention 实现。论文 §3.2 描述了一个 trick：将 LoRA 矩阵动态嵌入到 attention 的 q/k/v 投影后，再交给底层 attention kernel；不论 kernel 是 FlashAttention 2、MLA、DSA 都可以复用。
这个抽象的工程价值在于：你今天用 vLLM + LoRA wrapper 时，每换一种 attention 实现都要写一份适配。MinT 的做法把 LoRA 与 attention 解耦，对自家研究型团队来说是直接可借鉴的。
三、Scale Down：18.3 倍 step 加速从哪里来
Scale Down 才是论文里数据最炸的一段。先看几个核心数字：
| 维度 | 4B dense | 30B MoE | 含义 |
|---|---|---|---|
| Step time（含 handoff） | -18.3x | -2.85x | adapter-only handoff |
| Wall-time（concurrent multi-policy GRPO） | -1.77x | -1.45x | 多 policy 并行 |
| Peak memory | 持平 | 持平 | 没有以内存换速度 |
| Adapter size vs base | <1% | <1% | rank-1 设置 |
加速的来源被论文拆成了三件事：
3.1 adapter-only handoff
传统 pipeline 在每个 RL step 完成后做这样的事：训练侧把更新过的 base model 全量 export → 推理侧重新加载完整 checkpoint → 跑 rollout。
MinT 把这一步改成：
- base model 在训练侧与推理侧始终常驻，永不被替换。
- 每步 RL 只把更新过的 adapter（<1% base size，几 MB 到几十 MB）通过对象存储 push 到推理侧。
- 推理侧拿到 adapter id 后直接 hot-swap，不重启 engine。
这一步把 step time 中「export + reload」从分钟级压到秒级。4B 上加速 18.3 倍，对应的绝对值是从约 90 秒降到 5 秒；30B MoE 上加速 2.85 倍，因为 MoE 的 expert 路由本身就贵，handoff 占比相对小。
3.2 concurrent multi-policy GRPO
第二个 trick 是同一个 base model 上同时跑多个 policy 的 GRPO 训练。论文 §4.4 给出的实现：
[训练 worker 池]
├─ base_model (resident, shared)
├─ policy A: LoRA_a + replay_buffer_a
├─ policy B: LoRA_b + replay_buffer_b
└─ policy C: LoRA_c + replay_buffer_c
每个 micro-batch:
1. 用 base + LoRA_x 跑 forward (x 轮换)
2. 反向传播只更新 LoRA_x
3. 进 advantage estimation 与 KL 约束由于 base 是共享的，多 policy 训练几乎不增加显存峰值，但能把 GPU 利用率从 40-50% 推到 80%+。论文报告 4B 上 wall-time 缩短 1.77 倍。
3.3 Tinker 兼容的 service-oriented 接口
MinT 暴露的训练 API 与 OpenAI 的 Tinker 项目一致，关键两个动词：
sample_rollout(policy_id, prompts) → trajectoriesapply_optimizer_step(policy_id, gradients) → new_revision_id
这一层抽象让上层代码完全不感知底层是 single-GPU PEFT 还是 Megatron-style 分布式训练，迁移成本接近零。
四、Scale Out：单引擎 sweep 100K，千级并发
第三段 scaling 解决推理侧的「million-scale catalog」问题。这里有几个反直觉的设计：
- policy addressability ≠ working set。论文区分了两个概念：可寻址（durable policy id 在 catalog 里登记）与活跃（adapter 当前在 GPU/CPU 内存）。catalog 可以是百万级，working set 维持在千级即可。
- cold loading is scheduled service work。当请求命中一个不活跃 adapter 时，MinT 把加载请求当成普通调度任务，可以排队、合并、按优先级处理，而不是同步阻塞当前请求。
- packed MoE LoRA tensors。这是论文里我最喜欢的工程细节。传统 MoE LoRA 给每个 expert 单独存一个小张量，加载时小对象太多导致 IO 风暴。MinT 把同一 layer 的所有 expert LoRA 打包成一个 contiguous tensor，加载时单次 read 即可，实测加速 8.5-8.7 倍。
落地的数据：
- 单引擎 sweep 通过 100K addressable adapters 不丢请求
- 千级 active adapters 在 cluster 规模下并发
- packed MoE LoRA 把 live engine loading 从约 350ms 压到 40-45ms
五、对国内团队的三条直接启示
读完 MinT 的论文，我抽出对国内自建 LLM 团队最值得复刻的三件事：
- base model 常驻是高 ROI 改造。不论你用 vLLM、LMDeploy 还是 SGLang，先做到训练-推理共享 base model，立刻省一半显存。
- packed MoE LoRA 张量布局适合 Qwen3 MoE / DeepSeek-V3 这类国内主流 MoE 架构，自家 RLHF 团队可以在 PEFT 上 fork 一份实现，验证 8.5 倍能否复现。
- policy id 与 working set 解耦是多租户 SaaS 的必备结构。如果你的产品要给客户 fine-tune adapter，这个解耦决定了你能否扛住「百客户百模型」的扩张。
六、局限与悬而未决的问题
论文也坦白了几个不解决的方向：
- 跨 base 迁移：如果 base model 升级（比如 Qwen3.6 → 3.7），原 adapter 不能直接复用，需要全量再训。
- rank > 8 时收益递减：scale down 的 18.3 倍数字是在 rank-1 设置下测得，rank-8/16 时加速降到 6-8 倍。
- 多模态适配未验证：论文只覆盖了 text-only LoRA，VLM/Audio LM 的 packed tensor 布局可能不同。
- Tinker 兼容意味着 vendor lock-in 风险：API 形态目前只有 OpenAI 在主推，其它框架未必跟进。
七、写在最后
MinT 的真正贡献，不是某个新算子或新 attention 实现，而是它说服业界：在 RLHF 与 multi-tenant LLM 的世界里，「模型」已经不再是一个 17GB 的 .safetensors，而是一个 12KB 的 LoRA adapter 加上它在 catalog 里的 durable id。
把 LoRA 视为 first-class，是 2026 年所有 LLM 平台都该做的一次重构。MinT 给出了一份 27 页的可执行 spec，剩下的就看谁先把开源版本写出来。
💡 论文链接：arXiv:2605.13779 「MinT: Managed Infrastructure for Training and Serving Millions of LLMs」MindLab 团队，27 页技术报告。HuggingFace Daily Papers 5/14 trending。