多租戶微調：SaaS 中的每個客戶 AI 模型

你的 SaaS 客戶想要了解他們的資料的 AI。不是你的訓練資料。不是你所有租戶的混合平均。他們的術語、他們的工作流程、他們的邊緣案例。

服務 80 家律師事務所的法律科技平台有 80 種不同的詞彙表。服務 50 個電子商務品牌的支援平台有 50 個不同的產品目錄、語調指南和升級政策。服務 30 個診所的醫療保健 SaaS 有 30 種不同的文件風格和專科特定縮寫。

通用 AI 給出通用答案。而通用答案是你的客戶在每次反饋調查中不斷要求「更好的 AI」的原因。

解決方法不是更好的提示。而是每個租戶的模型——這比你想象的更實際。

三種架構模式

為 SaaS 產品添加租戶感知微調恰好有三種方法。每種在費用、隔離和品質上做出不同的權衡。

模式 1：共享微調

你將所有租戶的訓練資料合並到一個資料集中，並微調一個單一模型。每個租戶都訪問同一個模型。

工作原理：

• 從所有租戶聚合訓練範例
• 在組合資料集上微調一個模型
• 所有 API 請求路由到同一個模型端點

優點： 簡單。一個模型需要管理，一個部署需要監控，一個微調需要執行。存儲費用最低——你只運行一個模型。

缺點： 模型學習的是所有租戶的平均值。如果租戶 A 使用「客戶」而租戶 B 使用「用戶」表示同一件事，模型學習的是模糊的中間值。更糟糕的是，租戶 A 的資料影響租戶 B 的回應。對於受監管的行業，這是一個合規問題。

何時有效： 當你的租戶是同質的時——相同的行業、相似的資料、相似的詞彙。如果你正在為牙科診所構建 SaaS，而它們都以類似的方式記錄程序，共享微調可能就足夠了。

模式 2：共享基礎上的每個租戶 LoRA 適配器

你一次微調一個基礎模型（或直接使用），然後為每個租戶創建一個小型 LoRA 適配器。在推理時，你加載基礎模型加上租戶的適配器。

工作原理：

• 部署一個基礎模型（例如 Llama 3.1 8B 或 Qwen 2.5 7B）
• 只使用那個租戶的資料為每個租戶微調 LoRA 適配器
• 在請求時，根據租戶 ID 加載基礎模型 + 正確的適配器

優點： 每個租戶都獲得真正理解其資料的模型。存儲很小——LoRA 適配器根據秩和目標模塊為 50-200MB，相比之下完整模型為 4-14GB。訓練快速且便宜。資料隔離是絕對的：租戶 A 的資料永遠不會接觸租戶 B 的適配器。

缺點： 你需要適配器熱交換基礎設施。在適配器之間切換時有一個小的延遲費用（冷交換通常為 50-200ms）。

何時有效： 這是大多數 SaaS 產品的正確答案。我們為 90% 的多租戶 AI 用例推薦這種架構。

模式 3：每個租戶的完整微調

你為每個租戶微調一個完整的模型。每個租戶獲得自己完全獨立的模型。

工作原理：

• 為每個租戶微調一個單獨的模型
• 獨立部署和服務每個模型
• 在模型層，租戶之間沒有共享基礎設施

優點： 最大隔離。最大定制化。每個模型可以是不同的大小、不同的基礎、不同的量化。你可以給企業租戶 A 一個 70B 模型，給初創租戶 B 一個 7B 模型。

缺點： 存儲和計算費用隨租戶數量線性擴展。管理 100 個獨立的模型部署是一個運營噩夢。每個租戶的微調費用高 10-50 倍。

何時有效： 擁有大量資料集（10 萬以上範例）、嚴格資料隔離要求和相匹配預算的企業客戶。想想銀行、國防承包商、大型醫院網絡。

存儲計算

這是決定通常自我做出的地方。以下是每種模式在不同租戶數量下的原始存儲費用：

計算：秩 64 針對注意力層的 LoRA 適配器運行 50-200MB。Q4 量化的完整 7B 模型約為 4-5GB。在 100 個租戶時，每個租戶 LoRA 花費你 5-20GB 總計（一個基礎模型加上 100 個適配器）。每個租戶的完整微調至少花費 400-500GB。

這僅在存儲上就有 20-50 倍的差異。而存儲是便宜的部分。

服務架構：適配器熱交換如何工作

只有在可以快速交換適配器時，每個租戶的 LoRA 模式才有效。以下是架構。

請求流程

傳入請求
  → 從身份驗證 token / 標頭提取 tenant_id
  → 檢查適配器緩存（內存中的 LRU）
  → 如果已緩存：路由到基礎模型 + 緩存適配器
  → 如果未緩存：從磁碟/S3 加載適配器（50-200ms）
  → 運行推理
  → 返回回應

使用 Ollama 運行

Ollama 支援在基礎模型上加載 LoRA 適配器。設置：

1. 一個基礎模型在內存中。 一次加載你的基礎模型（例如 llama3.1:8b-q5_K_M）。它保持常駐。這花費約 6GB 的 VRAM。

2. 磁碟上的適配器文件。 在目錄結構中存儲每個租戶的 .gguf 適配器文件：/models/adapters/{tenant_id}/adapter.gguf

3. 請求路由。 你的 API 網關提取 tenant_id，選擇正確的適配器路徑，並創建引用基礎模型加上適配器的 Modelfile。

4. 適配器緩存。 在 LRU 緩存中保持最近使用的適配器。對於大多數 SaaS 產品，80% 的流量來自 20% 的租戶。持有 10-20 個適配器的緩存以零交換延遲處理大多數請求。

延遲預算

對於緩存的適配器，每個租戶的開銷可以忽略不計。對於冷交換，你一次添加 50-500ms——那個租戶的後續請求命中緩存。

擴展策略

• 少於 50 個租戶： 單個 GPU 服務器。所有適配器適合內存或緩存，交換速度快。
• 50-200 個租戶： 兩個 GPU 服務器，按 tenant_id 進行一致性哈希。每個服務器處理租戶的子集，改善緩存命中率。
• 200 個以上租戶： 帶 GPU 節點的 Kubernetes 集群。根據租戶活動模式預熱適配器。大多數 SaaS 產品永遠不會達到這一層。

資料隔離和合規

這是每個租戶 LoRA 適配器對共享微調的決定性勝利。

訓練資料分離

使用每個租戶的適配器，資料隔離是結構性的，而不是基於政策的：

• 租戶 A 的訓練資料專門用於創建租戶 A 的適配器
• 租戶 B 的訓練資料從不進入同一訓練運行
• 刪除租戶意味著刪除一個適配器文件——不需要重新訓練共享模型
• 稽核很簡單：每個適配器有清晰的來源追蹤

使用共享微調，你無法在不重新訓練整個模型的情況下取消學習一個租戶的資料。這是 GDPR 第 17 條問題——刪除權意味著你需要能夠消除租戶對模型的影響。

GDPR 和 SOC 2 影響

對於向企業、醫療保健、法律或金融服務銷售的任何 SaaS，僅合規故事就可以證明每個租戶的適配器是合理的。當潛在客戶的安全團隊問「你的資料是否用於訓練服務其他客戶的模型？」——答案需要是否。

租戶資料生命週期

每個租戶微調的清晰資料生命週期：

1. 攝取： 租戶通過你的 UI 或 API 上傳訓練資料
2. 驗證： 自動品質檢查（格式、完整性、去重複）
3. 存儲： 在租戶隔離的存儲中的訓練資料（單獨的 S3 前綴或存儲桶）
4. 訓練： 只使用這個租戶的資料微調適配器
5. 部署： 在租戶特定路徑中存儲適配器
6. 服務： 按請求按需加載適配器
7. 刪除： 當租戶流失或請求刪除時刪除訓練資料 + 適配器

沒有任何步驟接觸另一個租戶的資料。在模型層，租戶之間沒有共享狀態。

費用模型：實際費用是多少

每個租戶的微調費用

在適度的硬體上使用 Ertas 等平台（單個消費級 GPU 或 M 系列 Mac）：

在 RTX 4090 或 M3 Max 上，在 1,000 個範例上 LoRA 微調 7B 模型需要 15-45 分鐘。每個租戶的計算費用為 $2-5。即使在 100 個租戶時，你的總微調費用也是 $200-500——一次性費用，你可以作為入職費傳遞或吸收到你的訂閱定價中。

相比之下，每個完整微調費用 $30-80：100 個租戶為 $3,000-8,000。而且你會定期重複這些，因為租戶積累了更多資料。

服務費用

這是每個租戶 LoRA 最突出的地方：

• VRAM 中的一個基礎模型： 7B Q5 模型約 6GB
• 適配器開銷： 每個加載的適配器約 50-200MB，但你只加載活躍的
• 100 個租戶帶 10 個緩存適配器的總 VRAM： 約 8GB

你從一個原本只服務一個的 GPU 服務 100 個租戶。每個租戶的服務費用實際上是專用模型部署的 1/100。

每月服務費用比較（100 個租戶）：

以每月 $150-300 服務 100 個租戶的個性化模型，每個租戶的費用為 $1.50-3.00/月。這在你的 SaaS 定價中是可以四捨五入的。

將其納入你的 SaaS 定價

三種有效的模式：

1. 包含在企業層。 微調 AI 是你 $500+/月計劃的功能。每個租戶設置費用 $2-5，每月服務費用 $1.50-3.00。利潤率極高。

2. 附加功能。 每月 $50-100 的「AI 定制」附加功能。客戶自助服務培訓資料上傳，你自動化微調管道。

3. 入職費 + 包含。 $500 一次性設置費涵蓋微調費用和資料準備。持續服務包含在訂閱中。

這些任何一種都在 AI 功能本身上產生 90% 以上的利潤率。

實施時間表

為現有 SaaS 產品添加每個租戶微調，對後端工程師來說是一個 2-4 週的專案。以下是分解。

第 1 週：訓練管道

• 設置 Ertas 或等效的微調基礎設施
• 構建租戶資料匯出（從你的資料庫按租戶提取訓練範例）
• 創建訓練資料格式轉換器（你的架構到指令/回應對）
• 端對端測試一個租戶的微調管道

第 2 週：服務基礎設施

• 使用 Ollama 或 vLLM 部署基礎模型
• 構建適配器加載和緩存層
• 實施租戶感知的請求路由
• 添加帶 LRU 緩存的適配器熱交換邏輯

第 3 週：產品整合

• 構建面向租戶的資料上傳或訓練觸發 UI
• 添加微調任務狀態追蹤
• 將租戶特定的模型整合到你現有的 AI 功能中
• 在適配器尚未就緒時實施回退到基礎模型

第 4 週：運營和完善

• 添加監控：每個租戶的延遲、緩存命中率、適配器加載時間
• 構建自動重新訓練觸發器（新資料閾值、計劃的）
• 設置適配器版本控制和回滾
• 使用模擬多租戶流量進行負載測試

你不需要 ML 團隊。你需要一個能夠遵循文件並整合 API 的後端工程師。微調複雜性由平台處理。你的工作是管道工程：獲取資料、路由請求、管理適配器。

常見錯誤

過度設計第一個版本。 從 5 個租戶開始。驗證每個租戶的模型可測量地改善你的產品指標。然後擴展基礎設施。

忽略資料品質。 在 200 個高品質範例上訓練的 LoRA 適配器優於在 2,000 個嘈雜範例上訓練的適配器。在構建訓練管道之前構建資料驗證。

跳過回退。 當新租戶簽約時，他們還沒有微調的適配器。你的系統需要優雅地回退到基礎模型（或共享微調），直到其適配器準備好。

不測量差異。 進行 A/B 測試：基礎模型 vs 租戶特定適配器。如果適配器對給定租戶的準確率、相關性或用戶滿意度沒有可測量的改善，不要發布它。一些租戶可能沒有足夠的獨特資料來受益。

訓練過於頻繁。 大多數租戶不需要每天重新訓練。由資料閾值觸發的每週或每月重新訓練（例如，自上次訓練以來 100 個新範例）就足夠了，並使計算費用可預測。

前景

未來三年獲勝的 SaaS 產品將像今天對待資料存儲一樣對待 AI 個性化——作為每個租戶自動配置並隨使用量擴展的資源。

現在，每個租戶的微調感覺像是競爭優勢。到 2028 年，這將是基本要求。你的客戶將期望你的 AI 理解他們的術語、他們的工作流程、他們的邊緣案例——因為你競爭對手的 AI 會。

好消息：基礎設施現在就準備好了。LoRA 適配器使每個租戶的微調在經濟上可行。適配器熱交換使其在運營上可行。像 Ertas 這樣的平台使其對沒有 ML 專業知識的團隊也可以使用。

問題不是是否構建每個租戶的 AI。而是你在競爭對手之前還是之後構建它。

延伸閱讀

• 機構的多租戶 AI 部署 — 機構如何大規模管理每個客戶的模型部署
• 機構業主的 LoRA 適配器指南 — 深入了解 LoRA 適配器的工作原理以及為什麼它們是正確的定制化單元
• 無需 ML 團隊為你的 SaaS 添加 AI 功能 — 使用現有工程團隊交付 AI 功能的更廣泛手冊