Model Merging & Distillation: 解释多 LoRA 服务与适配器合并的差异。

Core Concept: 多 LoRA 服务：同一基座 + 动态加载不同适配器（省显存、可热切换）；合并：把适配器烘焙进权重（推理无开销、但不可切换）。

数学机理：<strong>两种使用方式</strong>。<strong>(1) 多 LoRA 服务（multi-LoRA serving）</strong>——(a) <strong>共享一个基座模型</strong>（显存中只存一份权重）；(b) 为每个任务/租户维护一个<strong>小的 LoRA 适配器</strong>（几 MB~几百 MB）；(c) 推理时按请求<strong>动态加载对应的适配器</strong>（<code>W + B_iA_i</code> 的增量在计算时加上，或用专门的 kernel 批量处理多个适配器）。<strong>优点</strong>：(a) <strong>省显存</strong>——N 个任务的显存 ≈ 1 个基座 + N 个小适配器（而非 N 个完整模型）；(b) <strong>可热切换</strong>（不同请求用不同适配器，无需换模型）；(c) <strong>可动态增删</strong>（新任务加适配器即可）。<strong>缺点</strong>：(a) <strong>推理有额外开销</strong>（加载适配器、计算增量）；(b) <strong>批量效率降低</strong>（同一 batch 内不同请求用不同适配器，难以用大矩阵乘——除非用专门的 multi-LoRA kernel）；(c) 实现复杂（需要 serving 框架支持，如 vLLM 的 multi-LoRA、S-LoRA）。<strong>(2) 适配器合并（merge）</strong>——把 LoRA 增量<strong>烘焙进基座权重</strong>：W' = W + (α/r)·BA（或合并多个：W + Σ）；合并后是<strong>一个普通的稠密模型</strong>。<strong>优点</strong>：(a) <strong>无推理开销</strong>（就是普通模型，可用最快的 kernel）；(b) <strong>可进一步量化/优化</strong>（如把合并后的模型量化）；(c) 部署简单。<strong>缺点</strong>：(a) <strong>不可切换</strong>（合并后失去原基座与其他适配器）；(b) 若要多个能力，需<strong>分别合并</strong>成多个模型（显存 ×N）；(c) 合并多个 LoRA 时可能有<strong>干扰</strong>（需 TIES/DARE）。<strong>选择依据</strong>——(a) <strong>多任务/多租户服务</strong> → <strong>多 LoRA 服务</strong>（省显存、可切换）；(b) <strong>单一能力的生产部署</strong> → <strong>合并</strong>（推理最快）；(c) <strong>需要极致性能且只有一个任务</strong> → 合并 + 量化；(d) <strong>需要快速迭代多个任务</strong> → 多 LoRA（避免每次重训/重合并）。<strong>与'模型合并'的关系</strong>——'合并 LoRA'是'模型合并'在 PEFT 上的特例（因为 LoRA 增量本身就是任务向量）；多 LoRA 服务则是'不合并、动态组合'的思路。<strong>注意</strong>——<strong>合并是不可逆的</strong>（除非保存了原基座与适配器）；故生产上应保留原基座 + 适配器（可随时重新合并或切换）。

深度剖析与工程权衡：① <strong>'多 LoRA 服务省显存'的量化</strong>——若 10 个任务各需一个 7B 模型，则完整模型需 10×14GB=140GB；多 LoRA 只需 14GB（基座）+ 10×0.1GB=15GB。这是数量级的节省。② <strong>'批量效率'是多 LoRA 的痛点</strong>——同一 batch 内不同请求用不同适配器时，难以用大矩阵乘（因为每个请求的权重不同）；专门的 multi-LoRA kernel（如 S-LoRA）可缓解，但仍有开销。故<strong>高并发同任务</strong>场景合并更优。③ <strong>'合并的不可逆性'需注意</strong>——合并后原基座与适配器被'覆盖'；故应<strong>保留原件</strong>（可重新合并或切换）。④ <strong>'合并多个 LoRA 的干扰'</strong>——多个适配器相加可能有冲突（同任务向量相加）；故需 TIES/DARE 等处理。⑤ <strong>'量化与合并的顺序'</strong>——通常'先合并再量化'（合并后是普通模型，可整体量化）；若'先量化再合并'则需注意量化误差与 LoRA 精度不匹配。⑥ <strong>面试要点</strong>——被问'多 LoRA 服务 vs 合并怎么选'，应给出'<strong>多 LoRA（共享基座、省显存、可切换、有推理开销、批量效率低）vs 合并（无开销、部署简单、不可切换、需 ×N 显存）</strong>'与'<strong>多任务/多租户用多 LoRA、单一能力生产用合并</strong>'；能指出'合并不可逆需保留原件'是深度理解的标志。