多客戶微調：一個基礎模型，每個律師事務所的自訂 LoRA 適配器

如果你需要為每個客戶使用單獨的 GPU，AI 機構的經濟效益就會瓦解。Llama 3.1 8B 模型佔用 16 GB 的 VRAM。五個客戶、五個完整模型、五個 GPU——在你賺到一分錢之前，這就是 $10,000-15,000 的硬體。

LoRA（低秩適應）完全改變了這個等式。一個基礎模型保留在 GPU 記憶體中。每個客戶的適配器——通常各 50-200 MB——在推理時進出切換。一個 GPU 服務所有你的客戶。

本文涵蓋架構、如何訓練客戶特定的適配器、熱切換的工作原理、成本影響，以及律師事務所所需的資料隔離保證。

多客戶服務的 LoRA 架構

LoRA 的運作方式

標準微調修改模型的所有權重——數十億個參數。LoRA 採用不同的方法：它凍結基礎模型，並訓練在特定層修改模型行為的小型「適配器」矩陣。

數學原理：與其更新權重矩陣 W（大小 d × k），LoRA 訓練兩個小矩陣 A（大小 d × r）和 B（大小 r × k），其中 r（「秩」）遠小於 d 或 k。有效權重變為 W + BA。

對於 7B 模型上秩為 16 的 LoRA：

• 基礎模型大小： 約 14 GB（FP16）
• LoRA 適配器大小： 約 50-100 MB
• 組合推理： 與基礎模型相同的速度（適配器矩陣被高效合併或應用）

多客戶架構

GPU 記憶體：
┌────────────────────────────────┐
│   基礎模型（Llama 3.1 8B）     │ ← 載入一次，保留在記憶體中
│          約 14 GB               │
├────────────────────────────────┤
│   活動 LoRA 適配器              │ ← 每次請求切換
│   （客戶特定，約 100 MB）       │
└────────────────────────────────┘

適配器儲存（SSD）：
├── firm-a-contract-review.safetensors    (85 MB)
├── firm-b-due-diligence.safetensors      (92 MB)
├── firm-c-case-summary.safetensors       (78 MB)
├── firm-d-regulatory.safetensors         (110 MB)
└── firm-e-intake-triage.safetensors      (65 MB)

一張 RTX 5090（32 GB VRAM）可以同時保存基礎模型加上幾個適配器，或者在毫秒內從 SSD 切換適配器。

訓練客戶特定的適配器

每個律師事務所客戶都有自己的適配器，在其特定資料上訓練。

每個客戶的資料準備

對於每個事務所，收集：

1. 歷史工作成果： 合約審查、案例摘要、研究備忘錄、客戶通訊
2. 風格指南： 事務所如何格式化交付物、術語偏好、風險評級量表
3. 領域重點： 業務領域專業化（M&A、訴訟、IP、監管）

格式化為指令-回應對：

{"instruction": "審查此併購協議條款的反壟斷風險：[條款文字]", "response": "[事務所 A 的分析風格和風險評估]"}

訓練配置

對於客戶特定的法律適配器：

每個適配器的訓練時間：使用 Ertas Studio 或手動 LoRA 訓練，在單個 GPU 上 30-90 分鐘。

品質驗證

在部署客戶的適配器之前：

1. 留出 10-15% 的訓練資料用於評估
2. 透過基礎模型和微調模型運行評估集
3. 將輸出與原始律師撰寫的回應進行比較
4. 檢查：
   • 風險識別的準確性
   • 風險評級的一致性
   • 遵守事務所特定術語
   • 正確引用條款號和交叉參照

推理時的適配器熱切換

熱切換使多客戶服務在實踐中可行。基礎模型保持載入；只有輕量級適配器在請求之間變化。

使用 Ollama

Ollama 支援多個模型變體。為每個客戶適配器建立一個 Modelfile：

FROM llama3.1:8b
ADAPTER /path/to/firm-a-adapter.gguf
SYSTEM "你是[事務所 A]的法律文件分析師..."

將每個註冊為單獨的模型名稱：

ollama create firm-a-contract-review -f Modelfile.firm-a
ollama create firm-b-due-diligence -f Modelfile.firm-b

在推理時，在 API 請求中指定模型名稱。Ollama 透明地處理適配器載入。

使用 vLLM

vLLM 使用 --enable-lora 標誌原生支援 LoRA 適配器服務：

python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B \
  --enable-lora \
  --lora-modules firm-a=/adapters/firm-a firm-b=/adapters/firm-b

透過 API 呼叫中的模型參數請求特定適配器：

{
  "model": "firm-a",
  "messages": [{"role": "user", "content": "審查這個條款..."}]
}

vLLM 的 LoRA 實現特別高效——它可以在 GPU 記憶體中保存多個適配器，並以接近零的延遲在它們之間切換。

切換延遲

對於大多數法律工作流程，即使是冷切換延遲也難以察覺——使用者正在等待需要 5-30 秒的多頁文件分析。

成本效益

隨著你的客戶數量增長，LoRA 方法的成本優勢變得顯著：

每個客戶一個完整模型（簡單方法）

LoRA 適配器方法

單個 GPU 可服務 10 個以上客戶，因為：

• 基礎模型（14 GB）只載入一次
• 每個適配器只增加 50-100 MB 的 VRAM（或從 SSD 切換）
• 法律工作負載是突發性的——並非所有客戶同時產生推理請求

在 10 個客戶時，LoRA 方法便宜 5 倍。在 20 個客戶時，便宜 10 倍。

每個客戶的訓練費用

透過 Ertas Studio 微調每個適配器：

• 訓練計算：極少（在機構 GPU 上 30-90 分鐘）
• 資料準備：2-4 小時的機構時間
• 驗證和部署：1-2 小時

每個新客戶適配器的機構總費用：大約半天的工作。這被計入實施費用——法律 AI 部署通常為 $5,000-15,000。

資料隔離保證

律師事務所需要客戶之間的絕對資料隔離。LoRA 架構在多個層面提供這一保證：

訓練資料隔離

每個客戶的訓練資料僅用於其適配器。在 Ertas Studio 中，每個客戶是具有單獨資料儲存的單獨專案。訓練期間不會發生跨客戶資料混合。

適配器隔離

每個適配器檔案在密碼學上是獨立的——事務所 A 的適配器中的權重不包含事務所 B 的訓練資料的任何資訊。適配器是完全從客戶資料中學習的數學轉換。

推理隔離

在推理時：

• 每個請求指定使用哪個適配器
• 適配器僅為該請求獨立載入
• 請求輸入和輸出按客戶分別記錄
• 客戶請求之間沒有共享狀態

稽核證據

對於合規文件，你可以展示：

1. 訓練資料來源：哪些資料訓練了哪個適配器
2. 適配器譜系：基礎模型版本 + 訓練配置 + 適配器校驗和
3. 推理記錄：哪個適配器服務了哪個請求，附有時間戳記
4. 無交叉污染：適配器權重在數學上是獨立的

這種隔離水平滿足最嚴格的法律合規要求，包括有競爭客戶的事務所的利益衝突隔離牆要求。

開始使用

1. 在 GPU 上設置基礎模型（Ollama 或 vLLM）
2. 為你的第一個客戶準備訓練資料
3. 使用 Ertas Studio 或手動微調訓練 LoRA 適配器
4. 與客戶一起部署和測試
5. 為每個新客戶重複——相同的基礎模型，新的適配器

隨著你標準化資料準備和部署管道，每個客戶的邊際工作量會減少。

---

延伸閱讀

• 機構的多租戶 AI 部署 — 服務多個客戶的更廣泛架構
• 模型蒸餾和 LoRA 指南 — LoRA 訓練和蒸餾的技術深度解析