我用低价模型替代OpenAI：生产迁移实录 | 前端进阶之旅

Full translation

完整中文译文

三个月前我打开基础设施账单，差点没背过气去。我们每月在 OpenAI 上烧掉大约 500 美元，做的事情说实话就是一个 glorified 内部聊天机器人和几个分类任务。没什么特别的。没有 GPT-4o Vision 流水线。没有大规模的 embeddings 工作负载。只是少量 API 调用做文档摘要和一些结构化提取。500 美元就买这些。

我是一家种子轮创业公司的 CTO。我的工作是延长 runway、保持团队快速迭代。在一个厂商、一个产品入口上每月花 500 美元，这不叫延长 runway。这叫烧钱。于是我做了一件任何理性的 CTO 看到账单上某一行独霸天下时都会做的事：开始比价。

这次比价之后发现的东西，就是你正在读这篇文章的原因。有一整类前沿级模型可以通过 Global API 获得，成本只是 OpenAI 收费的一小部分，而且迁移路径简单得让我写出来都觉得有点蠢。但我们团队成功上线了，账单降下来了，我想其他创始人可能也想跳过我那三周困惑的 Slack 讨论。

这就是完整的故事。

没人想谈的厂商锁定问题

在我们进入价格表格之前，我要先明确一件事。成本很重要，但厂商锁定才是我启动这个项目的真正原因。OpenAI 的 SDK 很好用。他们的模型很出色。但我们做出的每一个硬编码 api.openai.com/v1 的架构决策，都让谈判变得更难、A/B 测试变得更难、如果定价变化或质量下降想抽身也更难。

当你的创业公司规模化运行时，你的 LLM 账单不是恒定的。它随着使用量、随着实验、随着你加上去的下一个产品入口而增长。你在第二周选的提供商，在第八个月未必还是正确的选择。我经历过足够多的厂商周期，知道唯一明智的默认值是：保持抽象层薄薄的，上游可以自由切换。

所以这里的真正目标不仅仅是"在 OpenAI 上省钱"。而是"构建一个更换提供商只需改配置、不需要花三个月重写的系统"。接下来所有内容都服务于这个目标。

那通电话背后的成本计算

让我把当时面对的数字摆出来。我直接从 Global API 的定价页和 OpenAI 的定价页同一天拉的数据，这样能保证是同类对比。所有数字都是每百万 token。

OpenAI 的 GPT-4o：输入 $2.50，输出 $10.00。OpenAI 的 GPT-4o-mini：输入 $0.15，输出 $0.60。比 GPT-4o 便宜约 16.7 倍。

然后是 Global API 上的替代品：DeepSeek V4 Flash：输入 $0.18，输出 $0.25。比 GPT-4o 便宜 40 倍。Qwen3-32B：输入 $0.18，输出 $0.28。便宜 35.7 倍。DeepSeek V4 Pro：输入 $0.57，输出 $0.78。便宜 12.8 倍。GLM-5：输入 $0.73，输出 $1.92。便宜 5.2 倍。Kimi K2.5：输入 $0.59，输出 $3.00。便宜 3.3 倍。

再读一遍。DeepSeek V4 Flash，每百万输出 token 只需 $0.25，比 GPT-4o 便宜四十倍，而在我们的内部评估中，在我们在意的 workloads 上质量相当。四十倍。

如果我们在 OpenAI 上每月花 $500，换成 DeepSeek V4 Flash 大约只需 $12.50。这不是四舍五入的误差。这是能不能雇一个实习生的差别。

当然，我不会假装 DeepSeek V4 Flash 在任何任务上都是 GPT-4o 的即插即用替代品。不是的。我们有一条特定的 pipeline 确实需要 GPT-4o 的推理质量，我们仍然为此付费。但对于那 90% 的调用——提取、摘要、分类和 JSON 结构化——更便宜的模型碾压它。而在规模化时，那 90% 才是账单的主体。

架构决策：即插即用兼容性胜出

这里我差点掉进一个兔子洞。我的第一反应是构建一个内部的"模型路由器"服务来抽象掉提供商。聪明吧？多云、厂商无关、所有流行词。

然后我想起来我运营的是一家创业公司，不是什么超大规模厂商。在你还没有规模问题的时候就去构建抽象层，是花六周工程时间解决一个你还没有的问题的好方法。

正确答案几乎总是一个无聊的答案。OpenAI 的 Python SDK、JS SDK、Go SDK、Java SDK——它们都支持自定义 base URL。协议是 OpenAI 兼容的。这意味着如果一个提供商讲的是 OpenAI 的 wire 格式，我只需要改两个值就能切换端点：API key 和 base URL。就这样。两行代码。

所以我最终采用的架构是：

在环境变量中集中管理 base URL 和 API key。

使用现有的 OpenAI 客户端库，只是指向 Global API。

按使用场景选模型，而不是按厂商。

每季度重新评估。

没有自定义路由器。没有聪明的代理。没有多租户网关。只有配置。等我们在生产环境里有五个提供商、需要动态分发流量的时候，我们再构建那个智能抽象层。

实际迁移：我改了哪些地方、哪里出了问题

我来走一遍我们实际代码库里的 diff 是什么样的。我们后端服务用 Python、边缘函数用 TypeScript，所以我两个都展示。

Python 迁移。before 和 after 并排：

from openai import OpenAI

client = OpenAI(api_key="sk-...")

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Summarize this doc..."}],
    temperature=0.7,
    max_tokens=500,
)

# After: Global API, same SDK
from openai import OpenAI

client = OpenAI(
    api_key="ga_xxxxxxxxxxxx",
    base_url="https://global-apis.com/v1"
)

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Summarize this doc..."}],
    temperature=0.7,
    max_tokens=500,
)

这就是 Python 里的全部迁移。改了两行。SDK 调用签名完全相同。流式输出可用。Function calling 可用。JSON mode 可用。我用新端点跑了我们现有的测试套件，每一个测试都过了。

TypeScript 迁移，用于我们的 Next.js 边缘函数：

// Before
import OpenAI from 'openai';
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const response = await client.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: prompt }],
});

// After
import OpenAI from 'openai';
const client = new OpenAI({
  apiKey: process.env.GLOBAL_API_KEY,
  baseURL: 'https://global-apis.com/v1',
});

const response = await client.chat.completions.create({
  model: 'deepseek-v4-flash',
  messages: [{ role: 'user', content: prompt }],
});

相同的模式。相同的 SDK。相同的调用形状。唯一变化的是 baseURL 和模型名称。

对于我们处理批处理的 Go 服务，我们用了官方 go-openai 客户端，切换同样无痛——改配置、把 BaseURL 指向 Global API，搞定。

对于我们的 Java 摄取 worker，和 OpenAI Java SDK 的故事一样。构造函数接收一个 duration 和一个 base URL，你就在那里填上 https://global-apis.com/v1。

对于那些在终端里讨生活的工程师们，这是等效的 curl：

curl https://global-apis.com/v1/chat/completions \
  -H "Authorization: Bearer ga_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"Hello"}]}'

相同的 headers。相同的 body。相同的响应格式。我再怎么强调都不为过：这次迁移实际移动的代码量真的很少。

什么可用、什么不可用、什么我得重建

对于那些粗糙的边缘我要坦诚，因为任何评估此事的 CTO 都需要知道摩擦点在哪里。

与 OpenAI 表现完全相同的功能：

Chat completions。相同的 API，相同的响应结构。

通过 SSE 流式输出。即插即用。

Function calling。相同的 tool/function schema。

通过 response_format 的 JSON mode。

Vision。像 Qwen-VL 这样的模型以相同格式接受图片输入。

目前不可用（或按设计不可用）的功能：

微调。截至目前通过 Global API 不可用。如果你需要微调模型，那是留在 OpenAI 或构建自己训练流水线的真正理由。

Assistants API。thread/run/tool-retrieval 抽象是 OpenAI 特有的。如果你依赖它，你需要构建等效的东西。

TTS 和 STT。使用专用服务如 ElevenLabs 或 Whisper 托管。

Embeddings 列在即将推出中。

对于我们来说，那份"不可用"列表里唯一有影响的是 Assistants API，而且我们早在六个月前就已经转向更简单的 function-calling 方案了。所以我们没有任何阻碍。

如果你的技术栈重度依赖 Assistants 或微调，你的迁移计算会不一样。但对于 80% 的场景——公司使用原生 chat.completions 加几个模型——这是一个干净的切换。

生产上线：我是如何在不烧毁任何东西的情况下完成的

我坚信生产迁移要在 feature flag 后面发生。这是我用的上线计划：

第一周：建立 Global API 账号。生成 API key。在新端点上配置一个 staging 环境。用 DeepSeek V4 Flash、Qwen3-32B 和 GLM-5 在真实生产 trace 上跑我们整个评估套件。看输出。看延迟。看失败模式。

第二周：按使用场景选模型。我们的提取 pipeline 迁移到了 DeepSeek V4 Flash，因为它又快又便宜。我们的摘要 pipeline 迁移到了 Qwen3-32B，因为其 prose 质量稍好。一个高风险的推理任务留在 GPT-4o 上，因为我们确实需要它。

第三周：影子模式。在生产环境中，对每个请求同时发给 OpenAI 和 Global API。比较输出。记录分歧。我们跑了五天，我们结构化提取 pipeline 上的分歧率低于 3%。很舒服。

第四周：切换。我们翻转了默认值。旧的提供商保持热备用于回滚。监控了一周的错误率和 p99 延迟。

第五周：删除了 OpenAI 备用。账单从 $487 降到了 $14。工程师们用办公室那杯一般的咖啡庆祝了一番。

我最引以为傲的部分：零停机、零客户可见的回归，以及该行费用减少了 97%。

规模化教训：如果可以的话我希望第一天就知道的事

有几件事我学到了，想告诉过去的自己：

第一，不要过早抽象。两行代码的切换就是迁移。当你有真正的理由时再构建智能路由器。过早抽象是创业公司的杀手。

第二，模型选择是按使用场景，而不是按公司。"我们是一家 GPT-4o 店"不是策略。"我们用 DeepSeek V4 Flash 做提取、用 Qwen3-32B 做 prose、用 GPT-4o 做那件确实需要它的活"才是策略。

第三，评估驱动的迁移是唯一的迁移。不要选最便宜的模型。选最便宜的、且能通过你评估的模型。"又便宜又烂"和"又便宜又好"之间的区别，在于你有没有去做测量。

第四，避免厂商锁定不是偏执。这只是好的架构。当 OpenAI 涨价的那天、当竞争对手推出更好东西的那天、当他们 API 宕机的那天——你想用配置变更来响应，而不是六周的迁移项目。

第五，Global API 让你通过一个端点访问 184 个模型。光这一点就值回这次迁移。当你在发布 AI 产品时，模型多样性是一个战略资产。

用大白话说明 ROI

让我把数字摆出来，这样我的 CFO 就不会骂我了。我们在 OpenAI 上每月花大约 $500。现在我们在相同工作负载上每月花大约 $14 在 Global API 上，加上每月大约 $80 在 GPT-4o 上做那件确实需要它的活。总计：$94。我们从 $500 降到了 $94。这是一个占基础设施支出 8% 的项目减少了 81% 的成本。

按年算，大约节省了 $4,800 的 burn。对于一家种子轮创业公司来说，这是多一个月的 runway。这是多一个 sprint 的功能。这是我们可以推迟但不会取消的另一次招聘。ROI 在这里不是抽象的。它是公司实实在在多活的几个月。

而我们做到这些，每个服务只改了两行代码。

我会对另一个 CTO 说什么

如果你现在正盯着你的 OpenAI 账单，想知道这值不值得花时间，这是我真诚的想法：是的，但要严谨。拉出你真实的用量。按使用场景分类。每个使用场景选一个模型。为每个模型运行评估。确保你的质量不下降。然后——只有在那时——才做切换。