企业采购大模型 API,上线前要验证哪 8 项能力避免隐性成本

限流分 RPM、TPM 和并发三种口径。429 要先区分是速率超限还是额度耗尽。 成功率按完整响应计算。HTTP 200 后流式输出中途断开的请求,计为失败。 平均延迟会掩盖慢请求,要同时看 P95、P99 和首 token 时间。 重试可能重复计费。非幂等的 POST 请求不应由客户端自动重试。 99.5% 是服务目标,按 30 天计算约允许 216 分钟不可用,是否赔付取决于合同。 灵眸AI 的公开文档写明请求内容不持久化,调用元数据保留 90 天;多上游切换为毫秒到秒级,不做无限重试。这些是平台自述,尚未实测。

企业采购大模型 API,上线前要验证哪 8 项能力避免隐性成本

作者:灵眸AI 内容团队 · 2026-11-05

企业采购大模型 API 时,单价只决定账单的一部分。上线前应按 8 项指标逐项测试,并向服务商索取书面证据。 限流、高峰期超时、上游故障和失败重试产生的额外调用,都不在单价表上,却会在正式流量下变成真实成本。

重点摘要

  • 429 要先分原因。 速率或并发超限可以退避重试;额度耗尽时重试无效。[1]
  • HTTP 200 不等于完整响应。 成功率应按完整获得预期输出的请求计算。示例中两种口径相差 3 个百分点。
  • 平均延迟会掩盖慢请求。 应同时看 P95、P99 和首 token 时间。[3]
  • 99.5% 是服务目标,不是赔付承诺。 按 30 天计算,允许约 216 分钟不可用。
  • 重试可能重复计费。 RFC 9110 规定,客户端不应自动重试非幂等的 POST 请求,除非能确认请求可以安全重放。[2]

为什么只看单价不够

测试通过不代表能承受正式流量。 测试阶段调用量小,价格和输出质量通常都正常,问题多在高峰期暴露。

假设一家软件公司把大模型接入 SaaS 产品。测试时一切正常,上线后高峰期频繁返回 429,部分请求超时,上游故障时没有备用通道,合同里也找不到可用性承诺。这是假设场景,不是真实客户案例。

这类问题的代价主要出现在以下几处:

  • 失败请求的重试产生额外 token 费用
  • 研发人员投入排障,挤占功能开发时间
  • 业务中断直接影响收入和客户续约
  • 用户流失难以量化,但会持续发生

模型与接口:先确认能接入、能核验

模型名称一致,不能证明后端就是该版本。 采购时应要求服务商说明上游提供商和模型版本,并用同一组请求核对 usage 字段、停止原因、结构化输出和工具调用格式。只凭一次回答的文风判断模型身份,结论不可靠。

指标一:模型版本与变更规则

  • 上游提供商与模型版本,要求书面确认
  • 模型升级和下线的提前通知时间
  • 下线后是否自动切换到其他模型。自动切换会改变输出风格和能力,应事先征得同意

指标二:协议兼容

端点能通,不代表功能一致。 OpenAI、Anthropic、Gemini 三类协议的请求路径、鉴权头、流式事件和错误结构各不相同,网关在中间转换时最容易出现差异。Base URL 配置错误会直接返回 401 或 404。

验收时用实际 SDK 验证:

  • 流式输出
  • Tool Calling 与结构化输出
  • 多模态输入
  • usage 字段,并记录与官方接口的差异

稳定性:决定能不能进入生产

429 不等于限流,需要先分清原因。 RFC 6585 将 429 定义为用户在一段时间内发送了过多请求,响应可附带 Retry-After 头提示等待时间。[1] 实践中常见两类成因:速率或并发超限,应指数退避并降低并发;额度耗尽,重试无效,需要调整额度。

指标三:并发与速率限制

RPM(每分钟请求数)、TPM(每分钟 token 数)和并发(同一时刻在途请求数)限制的是不同瓶颈,不能互相替代。把某个模型的 RPM 当作整个平台的并发能力,是常见误判。

测试方法是阶梯并发:从低并发开始,每一级保持相同时长,逐级升高,记录每级的 429 比例、Retry-After 和 P95 延迟。持续出现 429 的前一级,可近似视为该 Key 在该模型上的并发边界。

指标四:高峰期成功率

成功率应按完整响应计算,而不是只看 HTTP 状态码。

成功率 = 完整获得预期响应的请求数 ÷ 有效请求总数

示例数据:1000 次请求中,950 次返回 HTTP 200,其中 30 次在流式输出中途断开。按 HTTP 层计算为 95.0%,按完整响应计算为 92.0%。以上是示例数据,不是实测结果。

测试应覆盖低并发、正常负载、高并发和突发流量四类场景,分别统计 429、500、502、503、504。RFC 9110 中,503 表示服务暂时过载或维护,504 表示网关未在时限内收到上游响应。两者处理方式不同,不能合并为“5xx”。[2]

指标五:P95 延迟与首 token 时间

平均延迟会掩盖慢请求,验收要看尾部分位数。 Google《Site Reliability Engineering》举例说,平均延迟 100 毫秒、每秒 1000 个请求的服务,仍可能有 1% 的请求耗时 5 秒。[3]

流式请求应分开统计两个指标:首 token 时间(TTFT)和完整耗时。同一手册建议用一分钟窗口观察 P99,它常是系统接近饱和的早期信号。[3]

示例数据:某次 1000 次流式调用的结果为 P50 1.8 秒、P95 6.2 秒、P99 12.5 秒。P50 只有 1.8 秒,但约每 20 个请求中仍有 1 个超过 6.2 秒。

指标六:故障切换与重试

多上游能降低单一通道故障的影响,但不能消除模型本身的故障,也不能保证流式输出中断后无感恢复。 任何网关都要用同样的测试验证这一点。

假设每次尝试的失败率为 5% 且各次相互独立,三次全部失败的概率约为 0.0125%。这是示例计算。真实故障常同时影响所有重试,独立假设会高估效果。

“客户端不应自动重试非幂等方法的请求,除非能确认请求语义本身是幂等的,或能确认原请求未被执行。”

— Roy T. Fielding、Mark Nottingham、Julian Reschke,RFC 9110 编者(译文)

重试还可能重复计费。采购时应要求服务商书面说明:

  • 健康探测间隔与切换判定条件
  • 切换耗时与重试上限
  • 退避规则
  • POST 类请求重试是否会重复生成、重复计费

数据隐私、SLA 与合同

99.5% 是服务目标,不是赔付承诺。 按 30 天计算,99.5% 允许约 216 分钟(3.6 小时)不可用,99.9% 允许约 43.2 分钟。

指标七:数据留存与跨境

API 调用不等于数据绝对安全。采购时要确认请求内容是否落盘、日志留存多久、是否用于训练、删除机制和跨境路径。《生成式人工智能服务管理暂行办法》第十一条规定,服务提供者不得非法留存能够识别使用者身份的输入信息和使用记录,该办法自 2023 年 8 月 15 日起施行。[4]

不同行业的敏感数据不同:

  • 软件企业关心源代码和密钥
  • 生物医药企业关心未公开的实验数据
  • 高校实验室关心科研数据与受试者信息

应按数据类别分别规定允许发送的范围,并通过数据处理协议(DPA)约定保留期限、转包的上游厂商和删除时限。

指标八:SLA 口径、售后与发票

核对 SLA 时要确认三件事:哪些原因不计入(通常包括用户网络、参数错误和上游的内容拒绝),单次故障多长才计入,月报按模型还是按整体统计。售后条款同样重要,包括故障响应时限、状态页与事件记录、事后报告时限和补偿方式。财务对账需要发票抬头、税号和分项用量明细。

八项验收清单

上线前逐项验收,每项对应一次测试或一份书面证据。

检查项目最低验证动作应索取的证据
模型真实性同一组请求对比,核对 usage 与工具调用结构上游提供商、模型版本、下线公告规则
协议兼容SDK 跑通流式、工具调用、结构化输出各协议端点说明与错误码表
并发与限流阶梯并发,记录 429 出现点与 Retry-After限流对象及两类 429 成因说明
高峰成功率四类负载测试,按完整响应计算分模型、分时段成功率报告
P95 延迟统计 TTFT、完整耗时、P50、P95、P99统计口径、样本量与时间范围
故障切换与重试记录 5xx 与超时的切换过程和重试次数切换规则、重试上限、退避规则、非幂等请求说明
数据隐私核对日志留存、训练用途与跨境路径隐私政策、DPA、留存期限、删除流程
SLA 与合同按公式核算允许的不可用时长SLA 条款、发票类型、故障响应时限、事后报告

怎样用这套标准核对一家服务商

公开文档是核对起点,但每个数字都要用自己的负载重测。 灵眸AI 的公开文档(2026-11-05 核验)对其中几项有具体说明。以下均为服务商自述,本文没有独立测试:

  • ✓ 已写明:多上游池、健康探测和自动故障转移,切换耗时为毫秒到秒级;请求体与响应体不持久化,调用元数据保留 90 天,账户数据存于中国境内;企业档可用性目标 99.5%,单次故障少于 60 秒不计入,提供分模型、分时段的月度报告;支持采购合同与增值税发票。
  • ✗ 文档列明的限制:切换不会完全无感;不做无限重试;流式中断仅对支持的协议尝试续传;请求需经海外通道转发,文档建议不要通过 API 发送国家秘密、商业秘密和身份证号等高敏感数据;更高的 SLA 与赔付条款需与商务约定,以合同为准。

先按上面的八项清单做小额测试,再决定是否扩大投入。

常见问题

大模型 API 出现 429 应该怎么处理?

先看响应中的 Retry-After 和错误原因。速率或并发超限时,用指数退避并降低并发;额度耗尽时重试无效,需要调整额度。

成功率应该怎么计算?

完整获得预期响应的请求数,除以有效请求总数。HTTP 200 但流式中途断开的请求不计为成功。示例中 1000 次请求里有 30 次中途断开,完整成功率为 92.0%。

为什么要看 P95 而不是平均延迟?

平均值会掩盖慢请求。Google SRE 手册举例,平均延迟 100 毫秒的服务仍可能让 1% 的请求耗时 5 秒。验收时应同时记录首 token 时间、P50、P95 和 P99。

重试会导致重复计费吗?

可能。RFC 9110 规定,客户端不应自动重试非幂等的 POST 请求,除非能确认请求可安全重放,或能确认原请求未被执行。采购时要问清服务商的重试规则和计费口径。

99.5% 的 SLA 意味着什么?

按 30 天计算,允许约 216 分钟的不可用时间。它是服务目标,是否有赔付取决于合同。采购时要核对不计入的原因和统计口径。

参考资料

[1] RFC 6585,Additional HTTP Status Codes,IETF,2012 年 4 月,https://www.rfc-editor.org/rfc/rfc6585

[2] RFC 9110,HTTP Semantics,IETF,2022 年 6 月,https://www.rfc-editor.org/rfc/rfc9110

[3] Site Reliability Engineering,第 6 章 Monitoring Distributed Systems,Google,2016 年,https://sre.google/sre-book/monitoring-distributed-systems/

[4] 生成式人工智能服务管理暂行办法,国家互联网信息办公室等部门,2023 年 7 月发布,2023 年 8 月 15 日起施行,https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm