不只比价格:AI内容平台在评测页里不会告诉你的三件事

选模型API的时候,绝大多数对比表长这样:价格、上下文长度、跑分、是否支持函数调用。

这些指标当然重要,但它们是宣传页上的指标。真正会让你半夜被叫醒的,是三件对比表里找不到的事。

一、限流不是一个数字,是一套算法

所有平台都会告诉你RPM和TPM,但你不知道的是:

• 限流是按账号还是按API key算? 在多环境部署时(测试/预发/生产),按key算意味着你要申请三个配额。
• 是滑动窗口还是固定窗口? 固定窗口在每分钟边界会出现双倍突发,你的峰值请求可能被拒。
• 排队还是立刻拒绝? 有的平台超过限流直接返回429,有的是排队等(延迟从1s涨到30s,但不报错)。后者更危险,因为它悄悄消耗你的超时预算。
• 上下文长度是否计入TPM? 一个128k上下文的请求在TPM口径里可能是30万token。

我们的做法是:上线前用固定QPS压测10分钟,记录每个请求的响应时间分布,而不是平均值。如果p99出现台阶状跳变,说明有排队机制,你的超时设置必须按最坏情况留余量。

二、失败时的行为差异,远大于成功时的能力差异

成功路径上,主流平台的表现大同小异。区别全在异常路径:

场景	平台A	平台B
超长上下文超限	直接400报错	静默截断中间部分
内容被安全策略拦截	返回空字符串,finish_reason=content_filter	返回替代回复
结构化输出不合schema	报错重试	返回近似结构
服务过载	429	200 + 降级小模型结果

静默降级是最可怕的。你不报错,你拿到一个看起来正常的回答,但它是旧模型给的。这在客服、财务、医疗场景里是事故源头。

检查方法:固定要求某个只在旗舰模型上才有的能力,然后大量并发打,看在过载时的输出特征是否变化。或者直接查返回体里的 model 字段。

三、数据留存条款里的三个常被忽略的条款

企业客户经常只看“是否用于训练”。但真正麻烦的是:

1. 保留时长:多数平台默认保留30天(用于滥用监控)。对处理个人身份信息的场景,这需要签单独协议。
2. 子处理方名单:你的数据可能被转给第三方做内容审核。名单会变,但没人会主动通知你。
3. 日志与调用记录的可见性:谁能看到你的prompt?运维?支持团队?客户要求审计时你能提供什么?

实务建议:把“数据保留时长”“子处理方变更通知”“审计日志导出”写成一张自查表,作为采购前的硬门槛。三项中任一项无法书面确认,就不要放进生产环境处理敏感数据。

四、那价格呢?

价格当然要算,但要用正确的算法:

真实单位成本 = 单价 × (1 + 重试率) × (1 + 降级补偿系数) / 可用率

一个便宜30%但p99不稳定的平台,加上重试与降级补偿后,真实成本常常高于贵的那个。再叠加工程成本——你要为它写更复杂的重试逻辑、降级逻辑、监控逻辑——一次选型的差价很容易被两个月的开发成本吃掉。

结论:对比表应该长什么样

我的建议是,给每个候选平台建一张内部评分卡,至少包含:

• 能力维度:目标场景的实测通过率(不是跑分)
• 稳定性维度:10分钟压测的p99与错误码分布
• 契约维度:数据保留、子处理方、SLA赔付条款
• 工程维度:SDK成熟度、结构化输出可靠性、流式断连恢复

模型能力每季度都在变,但契约和失败行为一旦确定,就是一两年的事。

选型时优先看后者,因为前者你随时可以换,后者换起来要动整个架构。