AI API 怎么选

先定义任务，再选模型

最常见的错误是先挑一家模型供应商，再想办法把产品套上去。更稳的顺序是反过来：先把你真正要让模型做的事写成一句话，再看哪些服务商能稳定完成它。

同一个产品里往往有不止一种任务——摘要、分类、结构化抽取、长文生成——它们的成本与失败代价并不一样。把它们拆开，你才可能做出合理的成本结构。

• 任务的输出能不能被规则校验？能校验的可以用更便宜的方案，不能校验的才需要更强的模型。
• 单次调用大概涉及多少内容量？
• 失败一次对用户意味着什么——重试一次就好，还是这一单直接废掉？

如果你的产品只有一个任务，而且输出无法校验，那你在定价时就必须按最坏情况做假设。

按量计费，意味着你的成本会随用户增长

主流模型 API 的计费方式是按用量计费（多数按 token 计，输入与输出分开计价，部分服务商对不同服务等级给出不同倍率）。我们核实到的两家服务商在官方定价页上都采用这一结构。

这带来一个结构性后果：你的收入通常是固定月费，而成本是一条随用量上升的曲线。定价必须在「最坏用量」假设下仍然成立，而不是按平均用量估算。

• 记录每一次调用的用量，而不是只记录调用次数。
• 给自己设一个额度上限，避免单个用户把整月成本吃掉。
• 把批处理这类更便宜、但允许延迟的处理方式，用在不需要即时返回的场景。

本文不给出任何具体单价。价格与模型版本变化频繁，购买前请以服务商官方定价页为准。

一个经常被忽略的前置条件：官方支持地区

在评估模型能力之前，先确认一件事：这家服务商的官方条款是否允许你所在的地区使用它。这不是技术问题，也不是网络问题，靠技术手段绕不过去。

截至 2026-10-01，我们核实到：OpenAI 官方公布的「支持的国家和地区」清单中没有中国大陆、香港与澳门；Anthropic 官方公布的支持地区清单（175 个国家与地区）同样未包含中国大陆、香港与澳门。OpenAI 的错误码文档还记录了「Country, region, or territory not supported」这一情形。

我们只陈述官方页面写了什么。官方页面没有解释原因，我们也不替你推断原因。

请务必自己打开官方页面确认最新清单。这份清单会变化，而且它是决定你能否合规使用的前提。

数据存放在哪里

模型 API 会把你的请求内容发送到服务商的服务器。部分服务商提供数据驻留选项（例如允许把推理固定在某个地理区域），部分会把账号数据默认存放在某一个国家。

如果你的客户是欧洲企业，或者你在隐私政策里写了数据存放在某个地区，这一层必须在选定服务商之前确认清楚，而不是上线之后补。

• 官方是否提供数据驻留区域选项？是全局默认，还是可以按请求指定？
• 是否提供零数据保留之类的选项？需要额外申请吗？
• 账号数据的存储位置，与推理请求的处理位置，是不是同一个地方？

多供应商预案：在架构上留退路

把某一家供应商的 SDK 直接写进业务逻辑，是最容易后悔的决定。模型能力、价格与可用地区都会变化，而你无法预测变化的方向。

更稳的做法是在代码里留一层薄薄的抽象：业务逻辑只依赖你自己的调用接口，供应商之间的差异被收敛在这一个地方。

• 定义自己的请求／响应结构，不要让上游的对象结构渗透到业务层。
• 把模型名、区域、超时与重试策略做成配置，而不是硬编码。
• 至少验证过第二家供应商能跑通同一条链路——哪怕只是偶尔跑一次。

自托管模型什么时候才划算

自托管意味着你要自己负责容量规划、排队、故障恢复与硬件成本。在评估「自托管更便宜」之前，先把工程人力算进去。

• 只有当你有明确的成本、延迟、数据或定制需求，且 API 方案确实无法满足时才考虑。
• 多数 AI 产品在早期并不需要这一层。
• 如果决定自托管，先在 GPU 云上按需跑通，再考虑长期合约。

下一步

这一层是 AI SaaS 十二层里的第 05 层。把它放回整条链路里看，你会更容易判断现在该投多少精力。

• 回到 AI SaaS 技术栈，看第 05 层在整条链路中的位置，以及它与数据层、收款层的关系。
• 在工具库里查看已核实的 AI 服务记录——每条都标注了官方来源与核实日期，你可以逐项自己复核。
• 如果产品要面向海外收费，接着读全球收款那一页，理解自建支付账号与 Merchant of Record 的区别。