單GPU運行N個專家模型：Multi-LoRA的低成本實戰——從法律專家到代碼專家詳情 - AI AiFly 博客

對於個人或小公司有部署使用本地大模型的需求，但由於業務需求直接部署一個開源的通用大模型又不滿足需求。這時常見的解決方案是使用RAG方案或微調模型方案。微調是使用領域知識訓練模型，使模型其具備相應的領域知識能力。微調後模型可獨立生成相應的領域知識，無需再通過RAG方案問答時通過上下文提供對應的領域知識。

模型私有化部署對顯卡資源的消耗比較高，對於一個4B模型BF16部署的資源已經達到9GB(4B×2×10⁹ ×1.2≈9 GB)，對於14B模型最少需要32GB顯存需求。就算是部署低精度或量化版模型一個基本可用的14B模型也最少需要16GB左右顯存。

對於這種規模的顯存需求對於個人或小公司來説同時部署N個全量微調的專家模型似乎有點難。如果部署10個微調的領域專家模型需要的資源是N倍的顯存資源(10 * 9GB =90GB)，這已經是超過一張A100的顯存資源也超過3張4049(24GB)卡的資源。

微調

微調除了全參數微調還有參數高效微調（PEFT），通過高效微調LoRA後根據微調的參數規模適配器的大小隻有幾十MB到幾百MB不等。前面文章我們也介紹過LoRA，這邊再簡單介紹下LoRA的基本原理。
LoRA (Low-Rank Adaptation) 是目前最主流的大模型高效微調（PEFT, Parameter-Efficient Fine-Tuning）技術。它的核心思想是：凍結預訓練模型的權重，僅在各層中注入可訓練的低秩矩陣（Low-Rank Matrices）。
W = W₀ + ΔW = W₀ + BA
其中：
W₀ 是凍結的預訓練權重（維度 d x d）。
B 是 d x r 的矩陣（初始化為 0）。
A 是 r x d 的矩陣（高斯初始化）。
r 是秩（Rank），通常遠小於 d（通常取8~128）。
優勢：
顯存極低：僅需訓練不到 1% 的參數。
不破壞原模型：原模型權重不變，LoRA 只是作為一個“外掛”插件。
便於切換：同一個基座模型可以加載不同的 LoRA 權重來適應不同任務（如一個負責寫代碼，一個負責寫小説，一個負責法律知識），無需重新加載大模型。
成本低：不僅可以在訓練時顯著降低顯存佔用和訓練時間，還保持與全量微調相當的效果。

多微調模型使用對比

專家模型

上面介紹了PEFT微調的一種技術LoRA微調原理，本節主要介紹LoRA技術實際應用。通過LoRA微調後會生成LoRA適配器此適配器的大小與微調時訓練的參數規模相關通常幾十MB到幾百MB不等，LoRA適配器不嚴謹的可稱為專家模型。
LoRA適配器通常有兩種使用方式：

靜態合併：LoRA適配器合併到基座模型，基座模型參數改變，不可再分離。
動態加載：LoRA適配器單獨存儲，基座模型參數不變，使用時加載。

LoRA 動態加載不只是技術選擇，還是應對模型快速迭代的最佳經濟策略。
LoRA可解決領域細分的顆粒度問題。不單是不同領域行業知識需要分開微調，單一行業(如法律)內部也存在民事、刑事、合同法、涉外法等等差異巨大的子領域，直接哪這些行業知識去微調去全參數微調一個模型或許也能微調好，但工程難度不小，消耗的資源也不少。

打破“基座更新即重練”的成本詛咒，按目前行業的發展每半年一代新模型發佈速度，每當基座模型(Base Model)更新又要投入大量的資源去全參數微調更新專家模型，如果使用的是LoRA專家模型，只需基於新基座快速遷移與微調輕量級的適配器（Adapter）。LoRA 將模型的維護升級成本從“指數級”降低到了“線性級”。

工程實踐

多LoRA架構的核心在於基座共享，插件熱拔插。在顯存中，我們只保留一份巨大的基座模型權重，而針對不同領域的 LoRA 模塊（僅佔極小顯存）則根據用户請求實時加載或切換。還可以使用基座模型提供通用的知識服務。

多LoRA適配器架構

整個多LoRA架構系統像一個現代化的綜合醫院：

應用層（掛號處）：接收病人（請求）。
路由層（分診台）：決定病人去哪個科室（選擇哪個 LoRA），或者只是去藥房買點感冒藥（基座直通）。
顯存管理（調度中心）：確保醫生（LoRA 參數）已經就位。
推理引擎（診療室）：醫生（LoRA）配合基礎醫療設施（基座模型）進行診斷。

注意上圖中LoRA適配器是旁路（Sidecar）權重，它是掛在基座模型上的，數據流直接進入“基座+LoRA”的組合體。LoRA 和基座是並聯計算（或者説數學上的權重相加），而不是串聯處理。

查看當前大模型推理服務存在多少模型，下面可以看到存在一個基座模型Qwen3，三個LoRA專家模型。

 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}
    ]
}

在使用時只需要選擇某個LoRA模型或不指定LoRA專家模型，直接使用基座模型；

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",  
    }
)

現在業內多LoRA部署有多種成熟的方案，多LoRA專家模型部署推理主流方案如下：

vLLM: 目前最流行的推理框架之一，原生支持 Multi-LoRA serving。它可以在處理請求時動態地為不同請求應用不同的 LoRA 適配器，而無需重新加載基座模型。
Hugging Face TGI (Text Generation Inference): 提供了對多個 LoRA 適配器的支持。
LoRAX (LoRA Exchange): 專門為服務數千個 LoRA 模型而設計的推理服務器，優化了 LoRA 的換入換出機制。
SGLang：原生支持Multi-LoRA serving，請求時動態的為不同應用路由到不同的LoRA適配器。
LoRAX：號稱一個GPU上能部署上百LoRA適配器模型。

未來

未來也未必是未來。
目前除了已經成熟的基於LoRA外掛適配器權重的多專家模型方案外，還有一中學術界還在探索中沒那麼成熟的MoE-LoRA方案，混合專家融合的LoRA方案。
LoRA微調可以理解為訓練了N個獨立的LoRA(針對不同數據集)，創造了N個專家。

LoRA A：只用代碼數據訓練（Code Expert）。
LoRA B：只用數學數據訓練（Math Expert）。
LoRA C：只用小説數據訓練 (Creative Writing Expert)。

MoE-LoRA可以理解為把這 N 個 LoRA 塞進一個模型裏並使用門控控制。
目前獨立LoRA存在一個問題就是需要提前知道任務級或會話級類型。一旦你選定了 LoRA（代碼專家），在接下來的生成中，它就無法處理其他領域的知識，不適合複合型任務。

而MoE-LoRA則不存在上面問題，模型內部有一個門控(Gating)，針對每一個 Token（詞元）進行決策，可以瞬間切換LoRA專家，一會使用代碼專家 LoRA一會使用文學專家LoRA。模型是一個既懂着又懂那的縫合怪天才。一個句子的生成過程中動態調用不同的能力，這是獨立 LoRA 絕對做不到的。有一種專家間的軟協同能力。

文章首發地址：https://mp.weixin.qq.com/s/WFGDI_cAGca6v3ZDapEidw

AiFly 博客

AiFly 博客

博客 / 詳情