AI / 模型 API

这个类别解决什么问题

让你在不训练模型的前提下，把语言模型能力接进自己的产品。

什么时候需要

当产品的核心价值需要模型能力，而你不打算自建推理时。这也是 AI 产品最先要做的技术决策。

选择时看哪些指标

这些是评估这类服务时通用的判断维度，不针对任何具体厂商。

• 单位用量的成本与你的定价是否匹配
• 上下文长度、输出长度与调用频率限制
• 稳定性和超时表现
• 是否支持你的数据结构与工具调用方式
• 是否存在单一供应商依赖风险

中国开发者特别需要考虑什么

网络可达性、调用延迟与账号可用性都需要自行评估。建议在架构上预留多供应商切换能力，而不是把某一家写死在代码里。

这一层的成本结构

模型 API 的账单由三类用量构成：输入、输出，以及被重试和浪费掉的部分。输入和输出通常分别计价，输出往往更贵；长上下文会把每次调用的输入成本整体放大，多轮对话则随轮数累积。这部分是典型的可变成本，随用户数线性上升；固定部分只有你主动买的承诺用量或预留吞吐。真正难估的是失败调用：超时、限流、输出格式不符都会让你为没产生价值的请求付费。所以要跟踪的指标是「一次合格结果花了多少钱」，而不是单个 token 的单价。

常见误区

• 只用单价比较服务商，不看单次任务的实际花费。不同模型需要几次调用、输出多长、重试率多高都不一样。做法是固定二三十条真实样本，在同一任务上跑完，记录每条的总成本与耗时。
• 把模型调用放在请求主链路里同步等待。用户页面跟着超时，一刷新就翻倍消耗。耗时明显的任务应改成入队、后台处理、完成后通知；只有秒级返回的任务才同步，并设好超时和降级返回。
• 没有用量上限和限流。一个用户粘进来一本书，就可能把这个月的预算吃掉。按账号设用量上限，按请求设内容长度上限，对异常增长设告警并自动降级，而不是等账单出来才发现。

从零开始的上手顺序

1. 把任务写成一句话，并准备二十条真实输入和你认可的判定标准。先有评测集再选模型，顺序反了就只能靠感觉调。
2. 用同一批样本在两家以上服务商上跑通，记录通过率、延迟、单次成本。固定参数并保存原始输出，否则结果不可复现，讨论会停在印象上。
3. 在代码里定义自己的请求与响应结构，把模型名、超时、重试策略放进配置，别让某家的对象结构渗透进业务逻辑。
4. 加上用量日志和硬上限：按账号、按接口记录用量，超限直接拒绝，并给用户一句能看懂的话，而不是抛一个上游错误。
5. 上线前写好降级路径：超时返回什么，主供应商不可用时切到哪家，哪些功能可以先关掉，这些要提前测过一次。

在不同业务模式中的作用

常见问题