為不同客戶運行 10 個以上微調模型：運營指南

在三個客戶時，你可以把一切都記在腦子裡。在五個客戶時，試算表就足夠了。在十個客戶時，某些事情就會出問題——模型被部署到錯誤的客戶，更新覆蓋了生產適配器，或者你意識到你完全不知道哪個 GPU 在運行什麼。

這是 AI 機構的多模型現實。讓你走到這一步的工作——客製化微調、親身部署、個人關注——除非你在其周圍建立系統，否則無法擴展。本指南是在多個客戶之間運行 10 個以上微調模型而不失去理智或利潤率的運營手冊。

多模型現實

大多數機構在 5 到 10 個活躍客戶模型之間的某個地方碰壁。症狀是可預測的：

你記不清哪個版本的哪個適配器部署在哪裡
兩個團隊成員在同一天用不同資料重新訓練同一個模型
客戶報告效能下降，你花 2 小時弄清楚發生了什麼變化
你的 GPU 費用比收入增長得更快，因為沒有什麼被有效地共享

根本原因始終是相同的：在小規模時有效的臨時管理，在接觸到真實容量時就難以為繼。你需要系統。

模型組織系統

基礎是一個命名慣例，它一眼就能編碼你需要知道的一切。我們推薦這種格式：

{client}-{task}-{base}-v{major}.{minor}.{patch}

例如：

acme-support-llama3-v2.1.0 — Acme Corp 的支援票模型，基於 Llama 3，第二個主要版本
baker-legal-mistral-v1.3.2 — Baker Law 的法律審查模型，基於 Mistral，應用了三個修補程式

這個命名慣例貫穿所有地方：你的檔案系統、你的部署配置、你的監控儀表板和你的客戶溝通。

LoRA 適配器庫

如果你每個客戶都在運行一個完整的基礎模型，你做錯了。LoRA 適配器是多客戶 AI 機構可行的全部原因。

按如下方式組織你的適配器庫：

models/
├── base/
│   ├── llama3-8b/
│   └── mistral-7b/
├── adapters/
│   ├── acme/
│   │   ├── support-v2.1.0/
│   │   └── support-v2.0.0/  （先前版本，保留用於回滾）
│   ├── baker/
│   │   ├── legal-v1.3.2/
│   │   └── legal-v1.3.1/
│   └── ...
└── configs/
    ├── acme-support.yaml
    └── baker-legal.yaml

每個適配器目錄包含 LoRA 權重、產生它們的訓練配置、訓練資料的雜湊值和評估結果。重現或回滾所需的一切。

基礎模型共享

這是運營效率所在。載入到 VRAM 中的單個 Llama 3 8B 基礎模型可以同時服務多個 LoRA 適配器。關鍵洞察：你不需要為不同的客戶提供單獨的模型實例。你需要在共享基礎設施上提供單獨的適配器。

實際上，這意味著按基礎模型對客戶進行分組。如果你的 12 個客戶中有 7 個使用 Llama 3 8B 變體，這 7 個適配器可以在記憶體中共享一個基礎模型。

資源規劃

多模型服務的硬體規劃需要具體數字，而非直覺。以下是我們看到有效的情況：

單張 RTX 4090（24 GB VRAM）：

1 個基礎模型（7-8B 參數）+ 同時 3-5 個 LoRA 適配器
在所有適配器上處理約 50-80 個並發請求
適合：在同一基礎模型上最多有 5 個客戶的機構

雙 RTX 4090 設置：

2 個基礎模型 + 總共 6-10 個適配器
處理 100-160 個並發請求
適合：在 2 個基礎模型系列上有 8-12 個客戶的機構

A100 80 GB：

1 個大型基礎模型（70B）或 2-3 個較小的基礎模型 + 10-15 個適配器
處理 200 個以上並發請求
適合：需要更大模型的 12-20 個客戶的機構

計算很重要。如果你每小時為 A100 支付 $2，並以每月 $3K 的費用服務 15 個客戶，你的計算費用約為每月 $1,440，而收入為 $45,000。這僅在基礎設施上就有 96.8% 的毛利率。

每個適配器的記憶體預算

7B 模型的 LoRA 適配器通常根據秩向 VRAM 增加 10-50 MB。在秩 16（涵蓋大多數用例）時，你看到的是每個適配器約 20 MB。這意味著 VRAM 不是你的瓶頸——吞吐量和延遲才是。

規劃每個客戶的峰值並發使用情況。如果客戶 A 在工作時間每分鐘發送 5 個請求，客戶 B 每分鐘發送 20 個，你的服務基礎設施需要在重疊時間內在該基礎模型上處理每分鐘 25 個請求。

監控必要項目

你無法管理你無法測量的事物。對於多客戶運營，你需要四類監控：

1. 每個模型的延遲

分別追蹤每個客戶模型的 P50、P95 和 P99 延遲。一個適配器上的延遲峰值會影響共享該基礎模型的所有適配器。在 P95 基準值 2 倍時設置警報。

大多數機構用例的目標延遲：

簡單分類/擷取：P95 低於 500ms
短產生（1-2 段）：P95 低於 2 秒
長產生（完整文件）：P95 低於 10 秒

2. 準確率漂移

隨著世界變化和客戶需求演進，模型會隨時間退化。設置自動評估執行——至少每週一次——針對每個客戶的黃金測試集。追蹤準確率、幻覺率和格式合規性。

當準確率從訓練後基準下降超過 3 個百分點時，是時候重新訓練了。不要等客戶注意到。

3. 使用情況追蹤

記錄每個推理請求：時間戳記、客戶 ID、模型版本、輸入 token 數量、輸出 token 數量、延遲。這些資料有三個用途：

容量規劃（何時添加硬體）
客戶計費（基於使用量或超額費用）
訓練資料收集（生產輸入是你的下一個訓練集）

4. 每個客戶的費用分配

確切知道每個客戶的費用。公式：

客戶費用 = （GPU 小時 × 計算份額）+ （適配器 + 資料的儲存）+ （維護的員工小時）

如果客戶的費用超過其每月費用的 40%，某些事情需要改變——要麼是你的定價，要麼是你的效率。

更新工作流程

重新訓練是大多數機構製造混亂的地方。以下是防止混亂的工作流程：

重新訓練計劃

按客戶層級設置節奏：

標準客戶：每季度重新訓練
高級客戶：每月重新訓練
企業客戶：持續改進，每月部署

永遠不要臨時重新訓練。計劃它、安排資源，並溝通。

更新的 A/B 部署

永遠不要就地替換生產模型。而是：

在當前版本旁邊部署新的適配器版本
將 10% 的流量路由到新版本（金絲雀）
監控 24-48 小時
如果指標保持或改善，提升到 50%，然後 100%
在切換後 7 天內保持舊版本可用

這需要紀律，但它能防止凌晨 3 點的「模型壞了」電話。

回滾程序

回滾應該少於 60 秒。由於你是在切換 LoRA 適配器而不是完整模型，這是可以實現的：

將適配器引用指回先前版本
基礎模型保持載入——不需要重啟
用 5-10 個已知輸入進行快速冒煙測試確認
通知客戶你已回滾並正在調查

如果回滾時間超過 5 分鐘，你的部署系統需要改進。

常見的擴展錯誤

我們看到機構反覆犯這些錯誤。讓自己免受痛苦：

每個客戶一個基礎模型。 為每個客戶載入同一個 7B 模型的單獨實例，浪費了 90% 以上的 VRAM。使用帶有每個客戶 LoRA 適配器的共享基礎模型。

沒有版本控制。 「我就直接覆蓋適配器檔案」是一句在災難發生之前說的話。對一切進行版本控制。每個客戶保留至少 3 個先前版本。

手動部署。 如果部署模型更新需要 SSH 到伺服器並手動執行命令，你在壓力下會犯錯。自動化你的部署管道——即使是簡單的腳本也比手動步驟好。

忽視資源爭用。 當客戶 A 的批次任務在下午 2 點執行，客戶 B 的實時 API 流量同時達到峰值，兩者都變得緩慢。了解你的流量模式並規劃重疊情況。

沒有費用追蹤。 不追蹤每個客戶費用的機構，不可避免地有客戶的服務費用超過他們的付費。這會在你沒有意識到的情況下侵蝕你的業務。

Ertas Studio 的多模型儀表板

Ertas Studio 專門為多客戶機構工作流程而構建。儀表板讓你一眼看到所有客戶的所有已部署模型：

模型登錄，包含完整的版本歷史、訓練譜系和評估分數
資源監視器，顯示每個適配器的計算使用量和費用分配
自動化評估管道，按計劃執行你的測試套件並在漂移時發出警報
一鍵部署，帶有金絲雀路由和即時回滾
客戶範圍的視圖，讓你可以與客戶共享監控資料，而不暴露其他租戶

目標是讓管理 20 個模型感覺像管理 2 個。系統處理協調；你處理客戶關係和模型品質。

實際情況

在 Ertas 上運行 12 個客戶的機構通常以以下方式運作：

2-3 個基礎模型透過 LoRA 適配器為所有 12 個客戶提供服務
自動化每週評估在客戶注意到之前捕捉漂移
高級客戶的每月重新訓練週期，標準客戶的每季度週期
一個部署管道，在不到一小時內將重新訓練的適配器從評估帶到生產
每個客戶的費用追蹤顯示 70-85% 的毛利率

這就是混亂的機構和能夠擴展的機構之間的區別。模型是產品，但運營是業務。

構建多客戶 AI 業務？閱讀更多關於多租戶部署架構、機構如何為律師事務所使用每個客戶的 LoRA 適配器，以及隨著規模擴展降低費用的策略。