多租戶 AI 部署：一個基礎模型，數十個客戶端適配器

如果你運營 AI 機構，你已經知道這種緊張關係：每個客戶都想要一個感覺是為其領域、語調和邊緣案例專門訓練的模型。但為每個客戶啟動一個專用模型實例，是通往 GPU 破產的快速途徑。這個數學在規模上根本行不通。

好消息是你不必在個性化和盈利能力之間做出選擇。帶有 LoRA 適配器熱交換的多租戶 AI 部署讓你可以從單一基礎模型服務數十個客戶——每個都獲得真正定制的行為，而不需要單獨基礎設施的費用。

多租戶挑戰

機構通常從所有客戶共享的單一微調模型開始。這很有效，直到客戶 A 需要正式的醫學語言，客戶 B 需要隨意的電子商務文案，客戶 C 需要結構化的法律摘要。突然間你的一刀切模型讓所有人都不滿意。

幼稚的解決方案是每個客戶一個模型。為每個客戶加載一個 7B 參數模型，你需要每個實例大約 14GB 的 VRAM。二十個客戶意味著 280GB 的 GPU 記憶體——僅為了保持正常運行就需要多個 A100。託管費用膨脹，你的利潤蒸發。

你需要的是一種以共享基礎設施費用提供每個客戶定制化的架構。

架構：基礎模型 + 每個客戶的適配器

解決方案在概念上很簡單：在 GPU 記憶體中保留一份基礎模型的副本，並按請求交換輕量級 LoRA 適配器。

LoRA 適配器通過將小型可訓練權重矩陣注入特定層來修改模型的行為。關鍵洞察是這些適配器很小——對於 7B 模型通常為 50-150MB，相比之下基礎模型為 14GB。基礎模型處理通用語言理解的繁重工作。適配器將輸出引導向特定客戶的風格、領域和要求。

在實踐中，你的推理服務器始終在 GPU 記憶體中保持基礎模型。當帶有客戶 ID 標記的請求到達時，服務器加載相應的適配器，運行推理，並返回結果。基礎權重從不移動。

適配器熱交換如何工作

適配器交換的機制出乎意料地高效。LoRA 適配器只修改模型權重矩陣的一個小子集——通常是注意力層。加載適配器意味著在基礎權重之上添加這些小增量矩陣。卸載意味著移除它們。

在現代硬體上，這個交換需要個位數毫秒。基礎模型在整個過程中保持在 VRAM 中。沒有模型加載，沒有檢查點反序列化，沒有預熱期。適配器只是插入和取出。

這與加載完整模型根本不同，後者根據大小和存儲速度可能需要 30-60 秒。

存儲計算

這是多租戶部署在試算表層面變得引人注目的地方：

傳統方法（每個客戶一個模型）： 20 個客戶 x 每個模型 14GB = 需要 280GB 總 VRAM

適配器方法： 1 x 14GB 基礎模型 + 20 x 100MB 適配器 = 16GB 總 VRAM（適配器按需加載）

這是記憶體需求的 17 倍減少。你可以從傳統方法需要多節點集群的單個 GPU 服務 20 個客戶。在 50 個客戶時，節省更為顯著。

磁碟上的適配器存儲同樣適中。每個 100MB 的一百個適配器是 10GB 的 SSD 空間——按任何標準都微不足道。

請求路由和推理流程

多租戶推理的請求流程如下：

1. 客戶請求到達，帶有 API 金鑰或客戶識別符
2. 路由器解析客戶 ID到相應的適配器文件
3. 適配器緩存檢查——如果適配器已加載，跳到第 5 步
4. 加載適配器到 GPU 記憶體，與基礎模型並排
5. 使用組合的基礎 + 適配器權重運行推理
6. 向客戶返回回應

對於擁有可管理數量活躍客戶（比如，少於 20 個並發）的機構，你可以同時保持所有適配器加載。7B 基礎模型加上 20 個適配器舒適地適合 24GB VRAM——一個消費級 GPU。

對於更大的客戶名冊，LRU（最近最少使用）緩存策略很有效。保持最活躍的客戶的適配器加載，並按需交換不太活躍的適配器。毫秒級的交換時間意味著即使是緩存未命中對最終用戶也是不可見的。

效能考慮因素

雖然架構很優雅，但有一些值得規劃的實際細節：

適配器加載延遲。 從 SSD 冷加載適配器需要 10-50ms。從 NVMe，速度更快。對於對延遲敏感的應用程式，為具有可預測使用模式的客戶預熱適配器。

批次推理。 如果同一客戶的多個請求同時到達，批次處理它們。如果不同客戶的請求到達，你有兩個選擇：按順序處理（在請求之間交換適配器）或維護多個適配器插槽並行處理。正確的選擇取決於你的吞吐量需求。

適配器版本控制。 客戶在迭代。他們三個月前的適配器可能已經過時。你需要一個用於對適配器進行版本控制、回滾和針對生產流量 A/B 測試新版本的系統。

基礎設施大小

基礎設施規劃的粗略指南：

• 1-20 個並發客戶： 單個 GPU 服務器（24-48GB VRAM）。所有適配器保持加載。簡單且具成本效益。
• 20-100 個並發客戶： 單個高端 GPU（80GB VRAM）或一對 48GB GPU。LRU 適配器緩存處理輪換。
• 超過 100 個並發客戶： 帶負載均衡的 GPU 集群。跨節點分片客戶，每個運行相同的基礎模型和適配器子集。

大多數機構完全在第一層。帶有 RTX 4090 或 A6000 的單個服務器可以舒適地處理 20 個以上的客戶。

Ertas 如何適應這個架構

Ertas 旨在使多租戶 AI 部署對沒有專門 ML 運維團隊的機構來說是可行的。

每個客戶的適配器管理。 通過統一介面為每個客戶訓練、版本控制和部署 LoRA 適配器。每個客戶的訓練資料和適配器歷史是隔離且可稽核的。

資料隔離的 Vault。 客戶資料永遠不會混合。Ertas Vault 在資料層強制執行嚴格的租戶隔離——對於在各行業處理敏感客戶信息的機構至關重要。

GGUF 匯出。 當客戶需要他們的模型在本地端或邊緣設備上運行時，將其適配器與基礎模型合並匯出為單個 GGUF 文件。一鍵操作，他們就有了準備好用於 Ollama 或 llama.cpp 的獨立模型。

結果是一個可以入職新客戶、微調其適配器，並將其部署到多租戶堆棧的機構——所有這些都不需要接觸基礎設施程式碼。

開始構建你的多租戶堆棧

多租戶 AI 部署不是未來的架構模式。它是今天最高效的 AI 機構的運作方式。共享基礎模型和每個客戶 LoRA 適配器的組合，以一小部分費用提供真正的定制化。

如果你準備好超越每個客戶一個模型，並構建一個可擴展的 AI 機構，Ertas 提供訓練、部署和資料管理基礎設施來實現這一目標。

延伸閱讀

• 機構如何通過微調削減 90% AI 成本
• 機構的白標 AI 平台
• 本地運行 AI 模型：完整指南