第23章：LoRA 与多租户模型服务

1. 项目背景

某AI平台同时服务三个业务线：客服Bot（需要礼貌、专业的话风）、营销文案助手（需要活泼、有创意的文风）和法务合同审核（需要严谨、精确的表达）。三个业务线都基于同一个Qwen2.5-7B基础模型，但需要不同的"人格"和专业知识。

最初的方案是部署三个独立的模型服务——每个微调一个专用模型。但三份7B FP16模型各占14GB显存，总计需要42GB——单张A100-80GB勉强够用，但剩余显存只够KV Cache用。如果再加一个业务线，就必须再买一张GPU。

团队发现了LoRA（Low-Rank Adaptation）方案：在基础模型之上，加载一个小型的"适配器"（通常只有几十MB到几百MB）来改变模型的行为。一个基础模型 + 3个LoRA适配器 = 仅需14GB + 3 × 50MB ≈ 14.15GB——节省了超过66%的显存。

但实施中遇到了新问题：客服团队的LoRA适配器"感染"了营销话风——部分用户的请求得到了营销风格的回复。排查发现，请求A（营销场景，使用营销LoRA）完成后，后续请求B（客服场景）错误地继承了营销LoRA的参数。

痛点：LoRA是多租户模型服务的利器——一个基础模型支撑多个业务微调版本。但LoRA的加载/卸载、请求级别的适配器切换、租户隔离、与量化和缓存的兼容性——每一个都是踩坑的高发区。vLLM通过--enable-lora和请求参数lora_name提供了原生的LoRA支持，但理解其工作机制是正确使用的前提。

2. 项目设计

（场