在 SaaS 中构建 AI 功能：何时停止调用 OpenAI API

OpenAI API 几乎是每个 SaaS AI 功能的正确起点。它上线快，不需要基础设施，GPT-4o 的质量在原型阶段很难挑剔。

但有一个点——一个你可以计算的特定点——在那里调用 OpenAI API 是错误的架构。这是你需要在那个点到来之前进行的分析。

为什么你从 OpenAI API 开始（而且应该如此）

对于新的 AI 功能，OpenAI API 几乎总是正确的第一步：

• 不需要 ML 专业知识
• 不需要管理基础设施
• 开箱即用质量优秀
• 迭代快速——更改提示，部署，完成

这不是错误。这是正确的工程实践。在投入更复杂的基础设施之前，在 OpenAI API 上构建可以验证该功能是否值得构建。

错误在于当你的使用量增长时，将 OpenAI API 视为永久架构。

经济拐点

OpenAI API 成本随使用量线性扩展。你的基础设施成本（服务器、数据库）通常是次线性扩展的。

计算方法：

对于每个 AI 功能，估算：

• 每次请求的平均 token 数（输入 + 输出）
• 每个活跃用户每月的平均请求数
• 当前 MAU（月活用户）
• 12 个月后预计 MAU

示例：

• AI 邮件草稿功能：每封草稿 800 token
• 用户平均每月生成 15 封草稿
• 今天 1,000 MAU，12 个月后 10,000 MAU

在 1,000 MAU 时，每月成本大约可以接受。在 50,000 MAU 时，单一 API 项的月成本变成了真正的 COGS 问题。

你的交叉点就是你应该开始计划迁移的日期，而不是执行的日期。 迁移需要 4-8 周。在达到交叉点 MAU 的 40% 时就开始计划。

迁移实际涉及什么

从 OpenAI API 迁移到自托管模型并不像听起来那么复杂：

• Ollama 和类似工具暴露 OpenAI 兼容 API
• 你的应用代码只需更改基础 URL 和模型名称
• 不需要应用架构更改

实际需要时间的是：

1. 模型选择和评估 — 选择能很好处理你任务的基础模型
2. 微调 — 在你的特定用例上训练
3. 基础设施搭建 — 部署带适当扩展和监控的推理服务器
4. 质量验证 — 验证本地模型在你的特定任务上匹配 OpenAI 输出质量
5. 渐进上线 — 将小比例流量路由到本地模型后再完全迁移

质量：真正的关注

质量担忧有效的任务：

• 开放式创意生成
• 复杂多步推理任务
• 需要广泛世界知识的任务

微调 7B 模型匹配或超越 GPT-4o 的任务：

• 定义良好的窄领域内的任务
• 重复性格式化和提取任务
• 一致风格/语调的内容生成
• 分类和路由

混合架构

你不必永久选择一个或另一个。实用的混合架构：

• Tier 1 请求（高量，定义明确的任务）：本地微调模型
• Tier 2 请求（低量，复杂或不常见的任务）：GPT-4o API

基于查询复杂度信号实现路由逻辑。简单的高量请求走本地。复杂的边缘情况走 OpenAI。这在保护复杂查询质量的同时捕获了大部分成本节省。

何时不迁移

一些 SaaS AI 功能应该永远留在 OpenAI 上：

• 不到用户基数 1% 使用的功能（不值得迁移努力）
• 任务的复杂性和新颖性确实需要前沿模型能力的功能
• 将在未来 12 个月被替换或停止的功能
• 质量风险超过成本节省的功能（高风险的面向用户的决策）

---

延伸阅读

• The Hidden Cost of Per-Token AI Pricing — API 规模化定价的完整经济学
• Fine-Tune Once, Charge Monthly: The Productized AI Service Model — 将 AI 构建到客户产品中的机构
• Running AI Models Locally — 部署选项和硬件指南