Multi-LoRA 在线服务隔离：适配器身份、显存配额与跨租户防串用

Multi-LoRA 让一个基础模型进程按请求选择不同低秩适配器，避免为每个业务复制整套权重。但节省显存不等于天然隔离：客户端伪造 adapter 名称可能读到别人的能力，热加载未审核文件可能执行错误张量，批处理或缓存漏掉版本键又会让 A 租户收到 B 的行为。共享只能发生在明确可共享的基础权重和计算层，身份、状态与结果必须逐请求分离。

适配器先进入可信注册表

生产请求不能携带任意磁盘路径或下载 URL。训练流水线产出后，将 adapter 权重、PEFT 配置、基础模型 digest、目标模块、rank、alpha、tokenizer 依赖、训练数据版本、评估报告和签名写入只读注册表。平台扫描格式与大小，验证张量名称、shape 和目标层均属于声明的基础模型，再分配内部不可变 digest。

adapterId: support-zh
adapterDigest: sha256:aa71...
baseModelDigest: sha256:90e4...
peftType: LORA
rank: 16
targetModules: [q_proj, v_proj]
ownerTenant: t-1042
maxReplicas: 4
state: APPROVED

仅有业务别名不够，support-zh 可以指向新版本，正在运行的请求必须绑定解析当时的 digest。适配器与基础模型不匹配时启动失败，不能尝试“尽量加载”。LoRA/QLoRA 微调 介绍训练原理，在线平台需要在此基础上补齐制品来源、审批和运行边界。AI 供应链安全 中的签名与物料清单同样适用于 adapter。

请求身份决定适配器，而非客户端参数

网关从已验证租户、产品功能和服务端策略解析允许的 adapter，生成签名后的内部路由上下文；worker 不信任公开 header 中的 adapter_id。授权表采用默认拒绝，缺失映射时返回明确错误，不能回退到某个其他租户或“最近使用”的 adapter。管理员调试也使用短期、可审计的模拟授权。

运行时为每个请求记录 tenantId + baseDigest + adapterDigest + tokenizerDigest，并将同一标识传播到排队、批处理、取消和计量。动态批处理可以把不同 adapter 请求送入同一次调度，但索引映射、输出 buffer、错误和取消信号必须保持逐请求对应；运行时不支持可靠混批时，就按 adapter 分组，不能为了吞吐自行实验。

隔离测试要主动发送错误组合：租户 A 猜中 B 的别名、已撤销版本、错误基础模型、并发切换 adapter、一个请求中途取消以及 worker 重启。预期结果不是“多数时候正确”，而是所有越权组合在加载前被拒绝，观测和响应中不泄露其他租户名称或路径。权限传播可复用 MCP 多租户隔离 的可信上下文原则。

显存和缓存都按 digest 记账

对单 adapter 设置权重大小、rank、并发序列、每租户常驻数量和全局已加载数量上限。加载动作走受限队列并预留显存；达到水位后优先淘汰无活跃引用且最久未用的版本，绝不卸载仍被请求持有的权重。热门租户不能通过不断创建新版本挤掉所有其他 adapter，按租户设置常驻份额和加载速率。

基础模型、adapter 权重、运行时工作区与 KV Cache 分开观测。至少报告每个 digest 的加载耗时、加载失败、常驻字节、活跃请求、命中/换入、淘汰原因和每 token 时延，但外部租户只能看到自己的聚合。高基数 digest 不直接进入不受控的全局指标标签，可写入 trace 或受限日志。

KV Cache、prefix cache 和结果缓存键必须包含 adapter digest。LoRA 会改变层输出，即使输入 token 和基础模型相同，也不能复用另一个 adapter 产生的 KV。Tokenizer 或聊天模板若随 adapter 变化，也一并进入键。关于平台级份额与原子扣账，可与 AI 平台租户配额隔离 组合实施。

每个 adapter 单独评估和发布

共享基础模型升级时，对所有获准 adapter 运行兼容矩阵，不能只验证最热门的一个。门禁至少包含各自黄金任务、基础模型无 adapter 的对照、错配拒绝、并发混批、长上下文、冷加载和内存压力。示例阈值可以是：授权错误为零，结构化成功率不低于旧版本，P95 冷加载低于 8 秒，常驻显存误差小于 5%，在 32 个混合并发下响应归属错误为零。

发布时别名从 adapterDigest=A1 灰度到 A2，按稳定会话路由 1%、10%、50%，同时保留 A1 权重和容量。若任务成功率下降超过 1 个百分点、加载失败连续三个窗口超过 0.5%，或出现任何身份错配，停止新流量并把别名解析恢复 A1；已经绑定 A2 的会话按风险排空或从原始消息重放。流量推进方式可沿用 模型服务金丝雀发布，但回滚单位必须是基础模型与 adapter 的已验证组合。

撤销适配器时，先禁止新解析，再等待引用归零、清理相关缓存并从节点卸载；注册表保留审计记录而不再提供下载。训练数据问题或租户终止都应能按 digest 查出受影响请求。Multi-LoRA 的可靠性不是“一个 GPU 挂了多少 adapter”，而是共享基础算力后，每一次选择仍有可信身份、确定制品、独立资源账本和可验证回滚。

延伸阅读

• LoRA/QLoRA 微调
• AI 供应链安全
• MCP 多租户隔离
• AI 平台租户配额隔离
• 模型服务金丝雀发布