如何用证据型评分卡评估 AI Gateway
最可靠的 Gateway 评估是可复现测试工具，而不是供应商功能数量。应评分系统真实需要的协议、模型、失败、证据、数据控制与运维职责。
发布 2026-08-15 · 更新 2026-08-15 · KeepRouter Editorial · 10 分钟阅读
先给结论：评估 AI Gateway 时，应让一套固定、接近生产形态的真实请求样本通过候选平台，并为协议一致性、模型资格、可靠性、可观测性、成本归因、数据控制与运维责任留下通过/失败证据。公开功能表适合初筛，但不是验收证据。
先选择一个有边界的工作流，例如带流式与一个幂等工具的服务端文本端点。对捕获请求脱敏，定义结构与质量断言，并保留旧路由。只有这一小片通过后才扩大范围。
证据型评分卡
| 维度 | 必需证据 | 典型失败条件 |
|---|---|---|
| 协议 | 覆盖每个消费字段的请求/响应 Fixture | 字段被丢弃、改名或静默转换 |
| 模型资格 | 当前目录或 API 结果，加有范围的冒烟证据 | 路由存在，但所选模型拒绝该端点 |
| 流式 | 包含取消与中途失败的有序事件日志 | UI 卡住，或把错误当作成功结束 |
| 工具 | 完整工具调用与工具结果记录 | 参数形态变化或副作用重复执行 |
| 可靠性 | 重试/回退策略与注入失败结果 | 不可重试错误被重复，或回退越过未批准模型 |
| 可观测性 | 可关联的应用、Gateway 与账单记录 | 请求无法追溯到负责人、模型、结果与用量 |
| 成本控制 | Key 范围、输出上限、尝试上限与告警测试 | 单个任务能产生无边界尝试或输出 |
| 数据控制 | 日志、保留、区域与脱敏配置 | 敏感内容违反策略进入日志 |
| 运维 | 部署、升级、事故与回滚手册 | 只有一个人知道怎样恢复服务 |
比较运行模式，而不只比较 API
托管 Gateway、BYOK 控制面和自托管代理可能暴露相似请求形态，但责任分配完全不同。Cloudflare 记录了带分析与流量控制的 Gateway 层；Portkey 记录 Gateway 配置与治理能力；LiteLLM 记录需要团队自行部署运维的代理服务；OpenRouter 记录托管统一 API 与供应商路由控制。KeepRouter 的公开路由以 OpenAPI为准，当前模型资格以模型目录为准。
逐项询问谁负责供应商账户、凭证、账单核对、Gateway 可用性、升级、安全补丁、数据保留、模型上架和事故响应。费率表上看似便宜的部署可能运维成本很高；托管服务可减少运维，却需要不同的信任与数据审查。把这些写成职责，不要写成营销形容词。
分四阶段运行测试工具
- 静态检查。 阅读 OpenAPI、模型详情、状态、安全、限制与错误文档；未知项就明确记录为未知。
- 本地契约测试。 用脱敏 Fixture 将测试客户端指向每个候选，断言字段、事件、工具、usage 与错误类别。
- 注入失败测试。 覆盖错误凭证、不支持字段、限流、超时、取消、重试耗尽与合格回退，绝不触发破坏性工具。
- 有限生产灰度。 路由一个小而可逆的切片，设置明确质量、延迟、错误与成本门槛，并与同一基线工作负载比较。
先用 AI Gateway 基础指南定义范围，再用路由与负载均衡审查策略，用 OpenAI 兼容迁移清单测试客户端行为。KeepRouter 的功能页、状态页与安全页分别证明不同层面，任何一个都不能替代生成链路结果。
边界：验证与路由、模型、账户和时间相关
通过一次 GET、健康页或 OpenAPI 路径，只能证明当时的结构或可达性；不能证明你的 Key 能调用指定模型，也不能证明工具往返正确或回退保持质量。反过来，一次失败也可能来自账户范围或载荷错误，而不是全局故障。每份证据都应标注时间、路由、模型、Key 范围、可用时的构建版本和测试用例，让评审者清楚它究竟证明了什么。
常见问题
功能对比表可以直接选出 AI Gateway 吗？
它可以用于初筛。最终验收应来自对具体契约、工作负载、数据策略和运维责任的可复现测试。
健康检查能证明生成路由正常吗？
不能。它只证明当时的健康检查界面；模型资格、认证、协议与用量证据仍需有范围的生成测试。
参考的一手资料
本文最近复核 2026-08-15
- [1] Cloudflare AI Gateway documentation
- [2] Portkey AI Gateway documentation
- [3] LiteLLM documentation
- [4] OpenRouter quickstart
- [5] KeepRouter OpenAPI