S-LoRA 如何用分页 Adapter 内存高效服务数百个 LoRA？

面试时怎么答

S-LoRA 的核心是共享一份基座，把大量 Adapter 当作可分页、可换入的小制品，而不是在 GPU 放数百个完整模型。回答要覆盖主存/GPU 分层缓存、异构 Adapter Batch 与定制 Kernel，再说明冷加载、淘汰抖动、租户公平和串用隔离。

可以这样答：

S-LoRA 的关键不是把几百个完整模型放进 GPU，而是共享一份基座，把 LoRA 参数作为可分页、可换入的小制品管理，并让不同 Adapter 的请求仍能批处理。它需要主存到显存的分层缓存、分页内存和支持异构 Adapter 的 Kernel。不过，容量提高后，冷启动、淘汰抖动和租户公平会变难。服务侧要按热度预取、设租户配额，持续看缓存命中率、加载 P95、Goodput、各租户尾延迟和 Adapter 串用事件。

核心回答

多 LoRA Serving 让所有请求共享一份基础模型权重，只按需加载各自的小型 Adapter。难点不是单个 LoRA 能否动态加载，而是一个 Batch 中请求可能使用不同 Rank、不同目标层和不同 Adapter：系统要把共享的基础 GEMM 与 Adapter 增量计算分开高效执行，并统一管理 GPU/CPU Adapter 内存与 KV Cache。

常见方案是将活跃 Adapter 放入统一内存池，冷 Adapter 留在主存，调度器联合考虑请求、Adapter 热度和 KV 容量；专用 Batched LoRA Kernel 按请求映射执行低秩增量，避免为每个 Adapter 拆成大量小 Kernel。

展开说明

约定列向量 \(x \in \mathbb{R}^{d_{\mathrm{in}}}\)、\(A \in \mathbb{R}^{r \times d_{\mathrm{in}}}\)、\(B \in \mathbb{R}^{d_{\mathrm{out}} \times r}\)，一层的 LoRA 增量为 \(\Delta y = BAx \cdot \frac{\alpha}{r}\)；服务系统常把 Batch 写成行向量矩阵 \(X\)，此时等价形式是 \(\Delta Y = (XA^{\top})B^{\top} \cdot \frac{\alpha}{r}\)。基础项可对整个 Batch 共享计算，而增量项必须按请求选择相应 Adapter。若简单按 Adapter 分批，会损失 Continuous Batching 的自由度；若逐请求启动 Kernel，又会被 Launch 和小矩阵效率限制。

内存层级：GPU 保存热点 Adapter，CPU 保存可快速换入的冷 Adapter，对象存储保存持久版本。
一致性：请求开始后应固定 Adapter 版本；热更新生成新版本，不能原地覆盖正在使用的权重。
隔离：每租户配额、最大 Rank/层数和并发上限防止某个 Adapter 占满池。
调度：同时看 Adapter 命中、请求等待、KV 压力和切换成本，不能只追求同 Adapter 合批。

版本边界：S-LoRA 的统一内存池和 Kernel 是论文系统设计；不同服务框架对支持的 LoRA 层、Rank、量化基础模型和并行模式限制不同，不能假设任意 Adapter 都能热插拔。

工程实践

压测应模拟热点长尾 Adapter 分布，而不是所有请求只用一个 Adapter。记录 Adapter 命中/换入延迟、池占用、Batch 内 Adapter 数、基础与增量 Kernel 耗时、TTFT/TPOT 和逐租户公平性；故障测试覆盖版本撤回、加载损坏、租户删权和正在服务时淘汰。

常见追问

为什么不能把每个 LoRA 都合并成完整模型部署？ 合并后会为每个 Adapter 复制整套基础权重，显存与加载成本随 Adapter 数线性增长，也难以在一个动态 Batch 中共享基础计算。
同一 Batch 中不同 LoRA 如何计算？ 基础模型算子共享执行，LoRA 部分通过请求到 Adapter 的映射，在专用批量 Kernel 中读取各自的 A/B 矩阵并加回输出。
Adapter 热更新如何避免请求前后不一致？ 使用不可变版本 ID 和引用计数；新请求切到新版本，旧请求继续引用旧版本，待引用清零后再回收。

一句话复习

多 LoRA Serving 的核心是共享基础权重，同时把异构 Adapter 的计算、内存池、版本与公平调度统一起来。

参考资料

原始论文：S-LoRA: Serving Thousands of Concurrent LoRA Adapters