微调模型上线时，LoRA 适配器应动态加载还是合并权重？

面试时怎么答

Adapter 上线先按数量和切换频率判断：少量稳定版本可合并权重，多租户大量版本更适合动态加载。解释合并后为何没有运行时分支，以及动态模式为何会产生加载、缓存和异构 Batch 问题；无论哪种方式，租户与 Adapter 版本都必须强校验。

可以这样答：

如果 Adapter 数量少、版本稳定，我会合并权重换最简单的推理路径；如果是多租户、数百个 Adapter，就动态加载并做热度管理。合并把低秩增量写回基座，运行时没有额外分支；动态模式则要管理 Adapter 权重、请求分组和缓存。要注意，合并会产生大量模型副本，动态加载会造成冷启动和连续批处理碎片。服务侧按热度预热，强校验租户与版本，监控加载 P95、缓存命中、Batch 利用率、吞吐和串用事件。

核心回答

如果只有一个稳定任务、追求最简单且可预测的推理链路，可以把兼容的 LoRA 增量合并进基础权重，生成独立、不可变的服务制品；这样不需要每次额外选择适配器，但每个任务都保存完整权重，发布和回滚成本更高。若一个基础模型服务很多租户或领域，动态加载适配器能共享基座，只保存较小的 LoRA 权重；代价是需要适配器缓存、请求路由、批处理隔离和冷加载治理。

最终选择要由租户数量、热点分布、内存、延迟 SLO、推理引擎支持和发布频率决定。无论哪条路径，都要把基础模型、适配器、tokenizer、Prompt 和生成参数绑定成一个经过评测的发布版本。

展开说明

两种部署方式的主要取舍是：

合并权重：运行时路径简单，适合固定专用模型；但制品体积和副本数随任务增加，量化基座上的合并还要确认框架支持与数值行为。
动态适配器：共享基础权重，适合长尾多租户；但不同适配器的请求可能让 Batch 碎片化，未命中缓存时还会增加首请求延迟。
版本一致性：适配器通常只与特定基座和目标模块兼容，不能只凭文件能加载就认为语义正确。
回滚边界：合并制品回滚整个模型；动态方式可以回滚适配器映射，但必须确保正在处理的会话不会中途换版本。

多适配器系统还需要防止租户 A 的请求引用租户 B 的 adapter ID，适配器选择必须由服务端鉴权后的映射决定。

工程实践

建立不可变清单：base_model_digest + adapter_digest + tokenizer + prompt_version + engine_config。对热点适配器预热并设置缓存上限，对冷门适配器采用有界加载队列；记录每个 adapter 的命中率、加载耗时、并发、质量和成本。合并前后用同一套样本做数值与任务回归，在目标量化和推理后端上再次压测，不假设离线合并成功就等于线上等价。

常见追问

动态 LoRA 为什么可能破坏连续批处理效率？ 同一批请求若使用不同 Adapter，会增加权重读取和分组 Kernel，降低批内复用；频繁换入还会引起等待。
合并 LoRA 后是否一定没有任何质量变化？ 数学上同精度加法应等价，但量化顺序、舍入、合并精度和推理后端可能带来差异，仍需回归验证。
多租户适配器服务如何防止串用和冷启动抖动？ 缓存键绑定租户、基座和 Adapter 不可变版本，调度前鉴权；热点预热、有限并发加载并设置安全回退。

一句话复习

单一稳定任务偏向合并，多租户长尾偏向动态适配器，但两者都必须版本绑定、回归验证并可回滚。

参考资料

面试题来源：AI Engineering Interview Questions 的微调与多模型部署题
技术依据：PEFT 模型合并文档、S-LoRA 论文