单GPU运行N个专家模型：Multi-LoRA的低成本实战——从法律专家到代码专家
<p> 对于个人或小公司有部署使用本地大模型的需求，但由于业务需求直接部署一个开源的通用大模型又不满足需求。这时常见的解决方案是使用RAG方案或微调模型方案。微调是使用领域知识训练模型，使模型其具备相应的领域知识能力。微调后模型可独立生成相应的领域知识，无需再通过RAG方案问答时通过上下文提供对应的领域知识。</p><p> 模型私有化部署对显卡资源的消耗比较高，对于一个4B模型BF16部署的资源已经达到9GB(4B×2×10⁹ ×1.2≈9 GB)，对于14B模型最少需要32GB显存需求。就算是部署低精度或量化版模型一个基本可用的14B模型也最少需要16GB左右显存。</p>
<p> 对于这种规模的显存需求对于个人或小公司来说同时部署N个全量微调的专家模型似乎有点难。如果部署10个微调的领域专家模型需要的资源是N倍的显存资源(10 * 9GB =90GB)， 这已经是超过一张A100的显存资源也超过3张4049(24GB)卡的资源。</p>
<h2 id="微调">微调</h2>
<p> 微调除了全参数微调还有参数高效微调（PEFT），通过高效微调LoRA后根据微调的参数规模适配器的大小只有几十MB到几百MB不等。前面文章我们也介绍过LoRA，这边再简单介绍下LoRA的基本原理。<br>
LoRA (Low-Rank Adaptation) 是目前最主流的大模型高效微调（PEFT, Parameter-Efficient Fine-Tuning）技术。它的核心思想是：冻结预训练模型的权重，仅在各层中注入可训练的低秩矩阵（Low-Rank Matrices）。<br>
<strong>W = W₀ + ΔW = W₀ + BA</strong><br>
<strong>其中：</strong><br>
W₀ 是冻结的预训练权重（维度 d x d）。<br>
B 是 d x r的矩阵（初始化为 0）。<br>
A 是 r x d 的矩阵（高斯初始化）。<br>
r 是秩（Rank），通常远小于 d（通常取8~128）。<br>
<strong>优势：</strong><br>
<strong>显存极低</strong>： 仅需训练不到 1% 的参数。<br>
<strong>不破坏原模型</strong>： 原模型权重不变，LoRA 只是作为一个“外挂”插件。<br>
<strong>便于切换</strong>： 同一个基座模型可以加载不同的 LoRA 权重来适应不同任务（如一个负责写代码，一个负责写小说，一个负责法律知识），无需重新加载大模型。<br>
<strong>成本低</strong>：不仅可以在训练时显著降低显存占用和训练时间，还保持与全量微调相当的效果。<br>
<img src="https://img2024.cnblogs.com/blog/84976/202512/84976-20251207201305513-857028976.png" alt="image" loading="lazy"><br>
<strong>多微调模型使用对比</strong></p>
<h2 id="专家模型">专家模型</h2>
<p> 上面介绍了PEFT微调的一种技术LoRA微调原理，本节主要介绍LoRA技术实际应用。通过LoRA微调后会生成LoRA适配器此适配器的大小与微调时训练的参数规模相关通常几十MB到几百MB不等，LoRA适配器不严谨的可称为专家模型。<br>
LoRA适配器通常有两种使用方式：</p>
<ol>
<li><strong>静态合并</strong>：LoRA适配器合并到基座模型，基座模型参数改变，不可再分离。</li>
<li><strong>动态加载</strong>：LoRA适配器单独存储，基座模型参数不变，使用时加载。</li>
</ol>
<p> LoRA 动态加载不只是技术选择，还是应对模型快速迭代的最佳经济策略。<br>
LoRA可解决领域细分的颗粒度问题。不单是不同领域行业知识需要分开微调，单一行业(如法律)内部也存在民事、刑事、合同法、涉外法等等差异巨大的子领域，直接哪这些行业知识去微调去全参数微调一个模型或许也能微调好，但工程难度不小，消耗的资源也不少。</p>
<p> 打破“基座更新即重练”的成本诅咒，按目前行业的发展每半年一代新模型发布速度，每当基座模型(Base Model)更新又要投入大量的资源去全参数微调更新专家模型，如果使用的是LoRA专家模型，只需基于新基座快速迁移与微调轻量级的适配器（Adapter）。LoRA 将模型的维护升级成本从“指数级”降低到了“线性级”。</p>
<p><img src="https://img2024.cnblogs.com/blog/84976/202512/84976-20251207201519443-1664404808.png" alt="image" loading="lazy"></p>
<h2 id="工程实践">工程实践</h2>
<p> 多LoRA架构的核心在于基座共享，插件热拔插。在显存中，我们只保留一份巨大的基座模型权重，而针对不同领域的 LoRA 模块（仅占极小显存）则根据用户请求实时加载或切换。还可以使用基座模型提供通用的知识服务。<br>
<img src="https://img2024.cnblogs.com/blog/84976/202512/84976-20251207201540396-821492115.png" alt="image" loading="lazy"></p>
<center>多LoRA适配器架构</center>
<p> 整个多LoRA架构系统像一个现代化的综合医院：</p>
<ul>
<li><strong>应用层（挂号处）</strong>： 接收病人（请求）。</li>
<li><strong>路由层（分诊台）</strong>： 决定病人去哪个科室（选择哪个 LoRA），或者只是去药房买点感冒药（基座直通）。</li>
<li><strong>显存管理（调度中心）</strong>： 确保医生（LoRA 参数）已经就位。</li>
<li><strong>推理引擎（诊疗室）</strong>： 医生（LoRA）配合基础医疗设施（基座模型）进行诊断。</li>
</ul>
<p><strong>注意上图</strong>中LoRA适配器是旁路（Sidecar）权重，它是挂在基座模型上的，数据流直接进入“基座+LoRA”的组合体。LoRA 和基座是并联计算（或者说数学上的权重相加），而不是串联处理。</p>
<p> 查看当前大模型推理服务存在多少模型，下面可以看到存在一个基座模型Qwen3，三个LoRA专家模型。</p>
<pre><code> http://192.168.1.1:13000/v1/models
{
"object": "list",
"data": [
{"id": "../../models/Qwen3-4B","object": "model","created": 1765038561,"owned_by": "xxx","root": "../../models/Qwen3-4B","parent": null,"max_model_len": 40960},
{"id": "law_lora","object": "model","created": 1765038561,"owned_by": "xxx","root": "../../lora/LoRA-and-MoE/law/law-lora-model-4B-1206","parent": "../../models/Qwen3-4B","max_model_len": null},
{"id": "starTrek_lora","object": "model","created": 1765038561,"owned_by": "xxx","root": "../../models/Qwen3Guard-StarTrek-Classification-4B","parent": "../../models/Qwen3-4B","max_model_len": null}
{"id": "hn_lora","object": "model","created": 1765038561,"owned_by": "xxx","root": "../../models/hn-lora-Qwen3-4B","parent": "../../models/Qwen3-4B","max_model_len": null}
]
}
</code></pre>
<p>在使用时只需要选择某个LoRA模型或不指定LoRA专家模型，直接使用基座模型；</p>
<pre><code>response = client.chat.completions.create(
model="Qwen3-4B",
messages=[
{"role": "user", "content": inference_prompt},
],
temperature=0,
max_tokens=1024,
#可不使用lora
extra_body={
"lora_path": "law_lora",
}
)
</code></pre>
<p> 现在业内多LoRA部署有多种成熟的方案，多LoRA专家模型部署推理主流方案如下：</p>
<ul>
<li>vLLM: 目前最流行的推理框架之一，原生支持 Multi-LoRA serving。它可以在处理请求时动态地为不同请求应用不同的 LoRA 适配器，而无需重新加载基座模型。</li>
<li>Hugging Face TGI (Text Generation Inference): 提供了对多个 LoRA 适配器的支持。</li>
<li>LoRAX (LoRA Exchange): 专门为服务数千个 LoRA 模型而设计的推理服务器，优化了 LoRA 的换入换出机制。</li>
<li>SGLang：原生支持Multi-LoRA serving，请求时动态的为不同应用路由到不同的LoRA适配器。</li>
<li>LoRAX：号称一个GPU上能部署上百LoRA适配器模型。</li>
</ul>
<h2 id="未来">未来</h2>
<p><strong>未来也未必是未来。</strong><br>
目前除了已经成熟的基于LoRA外挂适配器权重的多专家模型方案外，还有一中学术界还在探索中没那么成熟的MoE-LoRA方案，混合专家融合的LoRA方案。<br>
LoRA微调可以理解为训练了N个独立的LoRA(针对不同数据集)，创造了N个专家。</p>
<ol>
<li>LoRA A：只用代码数据训练（Code Expert）。</li>
<li>LoRA B：只用数学数据训练（Math Expert）。</li>
<li>LoRA C：只用小说数据训练 (Creative Writing Expert)。</li>
</ol>
<p> MoE-LoRA可以理解为把这 N 个 LoRA 塞进一个模型里并使用门控控制。<br>
目前独立LoRA存在一个问题就是需要提前知道任务级或会话级类型。一旦你选定了 LoRA（代码专家），在接下来的生成中，它就无法处理其他领域的知识，不适合复合型任务。</p>
<h2 id="而moe-lora则不存在上面问题模型内部有一个-门控gating针对每一个-token词元-进行决策可以瞬间切换lora专家一会使用代码专家-lora一会使用文学专家lora模型是一个既懂着又懂那的缝合怪天才一个句子的生成过程中动态调用不同的能力这是独立-lora-绝对做不到的有一种专家间的软协同能力"> 而MoE-LoRA则不存在上面问题，模型内部有一个 门控(Gating)，针对每一个 Token（词元） 进行决策，可以瞬间切换LoRA专家，一会使用代码专家 LoRA一会使用文学专家LoRA。模型是一个既懂着又懂那的缝合怪天才。一个句子的生成过程中动态调用不同的能力，这是独立 LoRA 绝对做不到的。有一种专家间的软协同能力。</h2>
<p>文章首发地址：https://mp.weixin.qq.com/s/WFGDI_cAGca6v3ZDapEidw</p><br><br>
来源：https://www.cnblogs.com/softlin/p/19318752
頁:
[1]