大模型 API 怎么选、怎么不被烧死

AI 产品和普通 SaaS 最大的区别，是它的成本结构。

普通 SaaS 的边际成本接近于零——多一个用户多花的服务器钱可以忽略。但 AI 产品不一样：用户每点一次「生成」，你的 API 账单就涨一笔。一个重度用户、一段没优化的 prompt、一个被盗刷的 API Key，都能让你的账单在一天内翻几十倍。

我见过太多 AI 产品死在成本上——不是没人用，是用得越多亏得越多。这篇讲清楚怎么选模型、怎么控成本、怎么防止被烧死。

先认清一件事：模型是有成本梯度的

不同模型的价格能差出一两个数量级。把所有任务都丢给最贵的模型，是新手最常见的烧钱方式。

主流模型的大致价格梯度（截至 2026 年 6 月，按每百万 token 计，具体以官方为准）：

关键认知：输出 token 通常比输入 token 贵 3-5 倍。 所以让模型「少废话、直接给结果」不只是体验问题，也是省钱问题。

按场景配模型，不要一刀切

一个 AI 产品内部往往有多个调用环节，每个环节对模型能力的要求不同。把它们都用旗舰模型是浪费。

举个例子，一个 AI 写作产品的内部流程可能是这样配的：

原则：把钱花在用户能直接感知质量的环节，其余环节用便宜模型或者根本不用模型（能用规则/正则解决的别调 API）。

控成本的几个核心手段

缓存：最立竿见影的省钱方式

很多请求是重复的。同样的 prompt、同样的输入，没必要每次都调一遍 API。

• 精确缓存： 输入完全相同就直接返回缓存结果。适合确定性任务（翻译、固定格式转换）
• 语义缓存： 输入意思相近就复用结果（用 embedding 算相似度）。适合 FAQ、客服类
• Prompt 缓存： OpenAI、Anthropic 都提供了 prompt caching——长的系统提示词部分可以被缓存，重复使用时大幅降价。如果你的 system prompt 很长且固定，一定要开

光是把固定的长 system prompt 做缓存，重度调用场景能省下一大笔。

降级：贵模型扛不住就退一步

设计一个降级链路，而不是死磕一个模型：

• 旗舰模型超时/限流/报错 → 自动切到主力模型
• 用户是免费用户 → 默认用便宜模型，付费用户才上旗舰
• 高峰期成本压力大 → 临时降级保成本

降级不只是省钱，也是保可用性——单一模型供应商挂了你的产品不至于全停。

限流和用量上限：防止单用户拖垮你

这是防止「被烧死」的关键。必须做：

• 单用户速率限制： 每个用户每分钟/每天能调多少次，设上限
• 用量配额： 免费用户每月 N 次，超了要么付费要么等下月
• 异常检测： 某个用户突然调用量暴增，自动熔断 + 告警
• 单次输入长度限制： 防止有人贴一本书进来把你的 token 烧爆

没有限流的 AI 产品，等于把信用卡裸放在公网上。

控制输出长度

• 在 prompt 里明确要求简洁输出
• 设置 max_tokens 上限
• 流式输出（streaming）虽然不省钱，但能让用户提前看到结果、提前停止，间接减少无效生成

API Key 防盗刷:别把密钥暴露在前端

这是血泪教训。绝对不要把 API Key 放在前端代码里。

前端能看到的东西，用户就能扒出来。API Key 一旦泄露，别人可以用你的额度疯狂调用，等你发现时账单已经几千上万美金了。OpenAI、Anthropic 的论坛里这种案例每个月都有。

正确做法：

• API Key 只放在后端。 前端调用你的后端，后端再去调大模型，密钥永远不出服务器
• 设置消费上限。 在 OpenAI/Anthropic 后台设置每月 hard limit，到顶自动停，给账单上个保险
• 用代理层做统一管控。 如果调用多个模型，用一个网关层（如 LiteLLM、自建代理）统一管理 Key、限流、计费、日志
• Key 轮换 + 权限隔离。 不同环境用不同 Key，生产 Key 定期轮换，泄露了能快速作废
• 监控异常调用。 调用量、来源 IP、消费速度异常时立刻告警

如果你做的是给用户填自己 API Key 的产品（BYOK 模式），也要做好用户 Key 的加密存储，不能明文落库。

用量监控:不监控就是闭眼烧钱

你必须随时知道钱花在哪了：

• 按用户/功能/模型维度统计消耗——哪个功能最烧钱，哪类用户成本最高
• 设置消费告警——日消费超过阈值立刻通知你
• 记录每次调用的 token 数和成本——出问题能追溯
• 定期看成本报表——OpenAI/Anthropic 后台有用量面板，至少每周看一次

很多人是收到天价账单才发现出事了。监控和告警让你在烧到失控前就能踩刹车。

给用户计费时,怎么不亏本

如果你的 AI 产品向用户收费，定价必须覆盖 API 成本，还要留出利润。常见的坑是定价时只算了「平均用户」，结果被重度用户吃垮。

几个原则：

• 算清楚单用户成本天花板。 不是平均成本，是最坏情况——一个把额度用满的用户会花你多少钱
• 订阅 + 用量上限组合。 $19/月包含 X 次调用，超出部分按量收费或限速。纯不限量订阅遇到重度用户必亏
• 免费版严格限量。 免费用户是成本中心，用量必须卡死
• 重度用户单独定价。 给真正高频的用户一个更高的档位，而不是让他们在便宜档位里把你薅穿
• 成本随模型降价更新定价。 大模型 API 价格一直在降，定期重算你的成本结构

参考定价模型的详细讨论，见 SaaS 定价踩坑记。

中国开发者的额外注意点

• 网络可用性： OpenAI、Anthropic、Google 的 API 对中国 IP 有限制，后端服务器需要部署在海外，或通过合规的海外节点调用
• 国产模型作为补充： DeepSeek、Qwen 等国产模型价格极低、国内可直接访问，适合做成本敏感的环节或国内市场的产品。能用国产模型满足质量要求的环节，没必要花贵价用海外模型
• 不要用来路不明的「中转 API」做生产环境： 便宜的第三方中转 API 稳定性和数据安全都没保障，关键业务别依赖（相关风险分析见 AI 中转站是门好生意吗）

一个最小可行的成本控制清单

刚开始做 AI 产品，按这个清单先把底线兜住：

1. API Key 只在后端，前端绝不暴露
2. OpenAI/Anthropic 后台设置月度消费 hard limit
3. 给每个用户加速率限制和用量配额
4. 长 system prompt 开启 prompt caching
5. 按场景分配模型，别全用旗舰
6. 设置日消费告警
7. 限制单次输入长度和 max_tokens
8. 定价时按「最坏情况用户」算成本，不是平均用户

把这八条做了，你不会因为成本失控而突然死掉。剩下的优化（语义缓存、降级链路、多模型网关）可以在产品跑起来后逐步加。

相关阅读：Claude Code、Codex、Cursor 横评 · SaaS 定价踩坑记