AI SaaS 背后的隐藏架构
构建 AI SaaS 平台教会了我一件事。
难点不在于调用 LLM，而在于让 AI 在真实的业务场景中落地。
起初，一切看起来都很简单。你会认为：
- API 密钥只是简单的密钥。
- SSO 只是一个连接。
- 计费只是接入 Stripe。
- 部署只是使用 Docker。
- AI 只是调用一下 OpenAI。
但随着平台进入实战阶段，每个简单的课题都会演变成一个复杂的系统。
API Keys
API 密钥不仅仅是一个字符串。在企业级 SaaS 中，密钥必须处理：
- 权限范围 (Scopes) 与过期时间。
- 吊销机制与审计日志。
- 租户边界与速率限制 (Rate limits)。
- 基于套餐的访问权限。
一个密钥必须能够回答：谁拥有它、它属于哪个租户，以及它可以访问哪些资源。
SSO 与身份认证
连接一个身份提供商很容易，难点在于决定信任什么。
- 你是信任邮箱域名还是信任用户组？
- 租户管理员能否创建平台管理员？
- 如果一个用户属于多个租户，该怎么办？
真正的 SSO 需要包含签发者验证 (Issuer validation)、角色映射 (Role mapping) 和会话隔离 (Session isolation)。
AI 运营
调用模型很容易，但运营 AI 很难。你需要追踪：
- Token 消耗与成本。
- 服务商的使用情况与延迟。
- 重试、超时与降级方案 (Fallbacks)。
- Prompt 管理与数据边界。
Demo 只需要一个响应，但商业平台需要知道哪个租户使用了哪个模型，以及确切的成本是多少。
计费与治理
Stripe 处理支付，但它并不定义你的产品。严肃的 SaaS 会将计费与以下内容挂钩：
- 配额 (Quotas) 与功能开关 (Feature gates)。
- 租户限制与订阅状态。
- 部署模式，例如本地部署 (On-prem) 或客户云。
计费演变成了商业治理。它控制着客户被允许使用的功能范围。
执行与扩展
Kubernetes 并不能直接让你实现可扩展性。你必须通过分离以下内容来管理工作负载：
- 队列 (Queues) 与工作进程 (Workers)。
- 资源限制与自动扩缩容 (Autoscaling)。
- 网络策略与可观测性 (Observability)。
你需要知道哪个工作进程正在失败，以及哪个租户产生了最大的负载。
可观测性
监控不是锦上添花，而是产品的一部分。
- 工程师需要知道哪里出了问题。
- 管理层需要知道价值在哪里创造，成本在哪里上升。
最重要的教训是：这些系统是环环相扣的。 如果 AI 缺乏计量，它就会变得昂贵；如果 SSO 缺乏隔离，它就会变得危险；如果计费缺乏强制执行，它就会变成摆设。
构建 AI SaaS 最难的部分不是 Prompt，而是让身份、数据、成本和基础设施协同运作。
Optional learning community: https://t.me/GyaanSetuAi