1)关键术语
Vendor:实际执行模型推理的原始提供商。 Authorized Vendors:我们已接入、审核并允许参与路由的提供商。 Model:一个可被实际调用的具体模型实例。 Request:一次单独的推理或 API 调用。 Vendor Status:某个上游提供商的运行状态,例如健康、降级或不可用。2)路由模式与可用性边界
固定 Vendor 模式(你显式设置 vendor)
如果你指定的上游提供商处于不可用状态,我们不对该请求的不可用或失败负责。
自动模式(vendor=auto,在 Authorized Vendors 间路由)
如果该模型对应的所有 Authorized Vendors 都处于不可用状态,我们不对由此导致的不可用或失败负责。
状态判定:综合上游状态页、官方公告,以及我们的监控指标(例如错误率、超时率)进行判断;必要时也可能结合双方日志交叉验证。
3)响应头校验(仅适用于 stream:false)
当请求使用非流式响应(stream:false)时,我们会附加校验响应头,帮助确认此次请求实际使用了哪个上游和对应账号:
X-Vendor-Messages-Id:不做脱敏,与上游的messages_id一致,用于精确对账和追踪。它不是凭证,不能用于认证或再次发起调用。X-Vendor-Api-Key:对实际使用的上游api_key做脱敏或单向处理后的结果,仅用于校验或审计,不能用于调用。
stream:true 的流式请求,这些响应头可能不会返回,或者为空。这本身并不代表违规或模型不一致。如果你需要核验流式请求,请提供请求 ID,我们会结合服务端路由日志和上游凭证进行审计。
安全与保留策略
我们只保留 3 天的以下数据:- 我们内部的请求 ID
- 上述校验响应头
api_key,日志里只会出现脱敏或单向处理后的形式。
X-Vendor-Messages-Id 不是敏感信息,也不能用于认证或二次调用。
如果你在调用链中使用了代理或 CDN,请确保 X-Vendor-* 响应头不会被移除或改写。
非流式响应示例
4)模型一致性与不一致处理
一致性要求:响应中的vendor 字段,或等效元数据,必须与实际执行请求的上游一致。
视为不一致的情形
满足以下任一条件时,可认定存在模型或上游不一致问题:- 响应中的
vendor值与实际执行请求的上游不一致。 - 对于
stream:false请求,校验响应头、我们的路由日志以及上游凭证无法对应,且没有事先书面批准的例外情况。
处理与补偿
一旦确认存在模型不一致问题,我们将按该请求费用的 2 倍 进行补偿。默认通过积分返还或账单抵扣完成;若合同或书面协议另有要求,也可按约定方式处理。 证据与处理流程:请提供请求 ID、时间戳以及原始响应内容;如果能提供响应头会更好。我们会结合校验响应头、服务端路由日志和上游凭证或账单进行核验。 非流式场景下响应头缺失或异常:如果由于上游限制、维护或临时故障导致响应头缺失,我们会提供等效证据,例如上游回执 ID、账单记录、签名证明或服务端日志。如果在合理时间内无法提供等效证据,且你提供的材料完整,该案例可能被视为不一致,并适用 2 倍补偿。5)典型调用
固定 Vendor
自动路由
6)常见问题
问:如何核验流式响应? 答:stream:true 不包含校验响应头。请携带请求 ID 联系支持,我们会基于路由日志和上游凭证进行审计。
问:只要上游挂了,你们就一律不负责吗?
答:不是。固定 Vendor 模式下,如果你指定的上游本身不可用,我们不对该请求的不可用负责。自动模式下,只有在该模型对应的所有 Authorized Vendors 都不可用时,我们才不对该不可用负责。
问:暴露 X-Vendor-Messages-Id 会泄露敏感信息吗?
答:不会。它只是用于追踪和对账的标识,不是凭证。X-Vendor-Api-Key 也已经做了不可逆脱敏处理。