多租户微调：为你的 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-200 毫秒）。

适用场景： 这是大多数 SaaS 产品的正确答案。这是我们为 90% 的多租户 AI 用例推荐的架构。

模式 3：每租户完整微调

你为每个租户微调一个完整模型。每个租户获得自己完全独立的模型。

工作原理：

• 为每个租户微调单独的模型
• 独立部署和服务每个模型
• 模型层租户之间没有共享基础设施

优势： 最大隔离。最大定制。每个模型可以是不同大小、不同基础、不同量化。你可以给企业租户 A 一个 70B 模型，给初创租户 B 一个 7B 模型。

劣势： 存储和计算成本随租户数量线性增长。管理 100 个独立模型部署是运维噩梦。每租户微调成本高 10-50 倍。

适用场景： 拥有大量数据集（100K+ 示例）、严格数据隔离要求和匹配预算的企业客户。想想银行、国防承包商、大型医院网络。

存储计算

这是决策通常不言自明的地方。以下是不同租户数量下每种模式的原始存储成本：

计算方式：秩 64 目标注意力层的 LoRA 适配器为 50-200MB。Q4 量化的完整 7B 模型约 4-5GB。100 个租户时，每租户 LoRA 总共花费 5-20GB（一个基础模型加 100 个适配器）。每租户完整微调至少花费 400-500GB。

仅存储就有 20-50 倍的差异。而存储还是便宜的部分。

服务架构：适配器热切换如何工作

每租户 LoRA 模式只有在你能快速切换适配器时才有效。以下是架构。

请求流程

传入请求
  → 从认证令牌/请求头提取 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-500 毫秒——该租户的后续请求命中缓存。

扩展策略

• 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 上，LoRA 微调 7B 模型的 1,000 个示例需要 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 或等效的微调基础设施
• 构建租户数据导出（从数据库按租户提取训练示例）
• 创建训练数据格式转换器（你的 schema 到指令/响应对）
• 用一个租户端到端测试微调流水线

第 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 功能的更广泛策略