LLM网关选型清单：10分钟评估一个LLM Gateway

跑Claude Code、Codex这类Agent工具时，如果直接调用官方API，账单往往高得离谱。转向第三方LLM网关（LLM Gateway）成了不少开发者的选择，但市面上网关质量参差不齐，怎么快速筛掉不靠谱的？一位开发者在一年内评估了大量网关后，总结出一份10分钟就能跑完的检查清单。

这份清单的核心态度是：默认每个供应商都在夸大宣传，直到数据表证明不是。

协议覆盖：别被"OpenAI兼容"糊弄

"OpenAI兼容"如今只是入场券，说明不了任何问题。真正要查的是：网关是否提供Anthropic原生的 /v1/messages 端点。

原因很直接：

Claude通过OpenAI格式调用会丢失prompt cache和thinking能力
对于每轮都要重读代码仓库的Agent来说，丢掉缓存意味着成本翻倍以上
认证头也不同——Anthropic原生用 x-api-key，OpenAI用 Authorization: Bearer，莫名其妙的401错误通常就是这里出的

另外要确认一点：大多数网关上的Responses API只支持GPT系列，不要假设它能处理Claude。

Prompt cache（提示缓存） 是 Anthropic 为 Claude 提供的服务端缓存机制：当请求前缀（尤其是系统提示、工具定义、长文档）与之前某次请求完全一致时，这部分内容不会重新计算，而是直接命中缓存，按远低于正常输入的单价计费。对 Agent 类应用来说，每一轮对话都会把整个代码仓库或长上下文重新塞进请求，若没有缓存，几乎等于每次都重新付费处理同样的内容，成本会成倍放大。

Thinking（扩展思考） 指 Claude 在给出最终回答前先生成一段内部推理内容，用于复杂规划与多步任务。这部分推理 token 同样会产生费用，并影响输出结构。OpenAI 的 Chat Completions 协议里没有对应的字段和语义，所以经由该格式转发时，thinking 相关的参数和流式事件往往被丢弃或降级处理。选择网关时，确认它是否透传这些 Anthropic 原生能力，比看它是否"兼容 OpenAI"重要得多。

定价表里必须有缓存读取列

如果一张定价表只列了输入和输出两个价格，这本身就是信号。Agent类工作负载绝大部分是缓存输入，一个不在定价表里体现缓存价格的供应商，大概率没有针对缓存做优化。据该开发者的实测经验，缓存读取的价格通常是正常输入价格的零头，忽略这一列会让成本估算严重失真。

缓存读取（cache read）与缓存写入（cache write） 是两类不同的计费项。缓存写入发生在第一次把内容存入缓存时，通常单价略高于普通输入；缓存读取发生在后续命中缓存时，单价通常只有普通输入价格的十分之一左右。因此在任何 Agent 场景的成本模型里，最大的开销往往集中在"缓存读取"这一列，而不是常规输入或输出。

一张只列 input/output 的定价表，会让使用方误以为缓存命中是免费的，或无法判断供应商是否真的实现了缓存。反过来，把 input、output、cache read 三列同时列出，既能核算真实成本，也能侧面验证该网关是否支持缓存透传。缺少缓存列的供应商，通常意味着它把请求原样转发、不做缓存优化，长期使用成本会显著高于标注数字。

折扣是按模型算的，而且随时在变

"最高九折"（或"最高90% off"）作为一个数字毫无意义。真正要看的：

按模型的定价表是实时的，还是一张营销截图？
折扣是按请求发生时那一刻的费率实时计算的，还是噱头？
有没有把上游官方标价和自己的价格并列展示，让你能自行核对？

如果供应商不愿意把上游价格摆在自己价格旁边，这个行为本身就是答案。

积分条款：过期就等于你在给它做无息贷款

积分会过期？ 那你实际上在帮它做资金周转
必须订阅？ 那你被锁定了
按量付费、永不过期、随时充值 —— 这是底线，不是卖点

正常运行时间要分模型看

一个全局的"99.9%"会掩盖你实际在用的那个模型的真实表现。需要的是一个范围，而且要看最差的那个数字，不是最好的。

SLA（Service Level Agreement，服务等级协议） 是对可用性和响应时间的正式承诺，通常包含"月度可用性不低于 X%"这类指标以及相应的补偿条款。一个全局的 99.9% 数字往往是把全部模型、全部区域、全部时段混在一起的加权平均，会掩盖你实际调用的某个模型频繁抖动的事实。

按模型公布 SLA 范围（而非单一全局数字），意味着供应商愿意披露不同上游模型各自的真实表现。评估时应重点看范围中最差的那个数字，因为它对应你最可能遇到的故障场景；同时也要区分"网关自身可用性"和"上游模型可用性"，前者由网关负责，后者网关最多只能做到快速失败或切换。若供应商只给一个漂亮的平均数字而拒绝拆分，通常说明长尾模型的可用性并不好看。

迁移成本

改环境变量没问题。但如果要安装SDK、重写客户端代码、或者强制走注册流程，除非其他方面特别突出，否则直接排到列表末尾。

刻意不放进清单的东西

说个细节（作者原话），他刻意不把宣传中的折扣数字放进清单。"最高90% off"是营销构造——那是最好的一天、最便宜的模型上的最大值。他只看自己实际跑的那两三个模型的定价表，和对应的上游官方价格做对比。

另一个近期才开始关注的问题：上游降级时，正在进行中的请求会怎样？有些网关快速失败，有些静默重试到更高价档位，有些返回一个不是你请求的模型。没有一个网关会主动宣传这一点，只有第一次on-call发现账单不对时才会暴露。

上游降级（upstream degradation） 指网关所依赖的底层模型服务出现限流、超时或部分不可用时，网关必须自行决定如何处理正在进行的请求。常见的三种策略各有代价：

快速失败：立刻返回错误，调用方自己重试，行为透明但会打断 Agent 的连续执行；
静默重试：网关自动重试，可能退回到更贵或更慢的档位，账单因此上涨而调用方毫不知情；
模型替换：返回一个并非你所请求的模型，结果质量变化难以察觉。

这一行为几乎没有网关会主动宣传，只有在第一次对账异常时才会暴露，因此是选型中最难验证、但长期影响最大的盲区。保留一个直连官方 API 的备用密钥，是目前较常见的对冲手段。

作者最终的选择和保留意见

该开发者最终落脚在TeamoRouter，理由是它通过了上述六项检查：支持四种协议格式（Anthropic原生、OpenAI兼容、Responses API、Gemini原生）、有实时按模型定价表含输入/输出/缓存三列、积分永不过期、无需订阅、按模型公布SLA范围而非一个全局数字、配置只需两个环境变量。

他认为最能说明质量的一个信号是：TeamoRouter的官方文档明确建议不要通过OpenAI兼容格式调用Claude，因为成本更高、效果更差。一个平台主动发布把你推离更简单集成路径的警告，比任何折扣宣传都更有说服力。

当然也有保留意见：定价以美元计价，如果以其他货币做预算会承担汇率风险；实体注册信息没有集中展示，企业采购前需要主动询问；另外他没有低成本的方法测试故障转移行为，这也是他仍然保留一个直连API密钥作为备用路径的原因。

故障转移测试：一个待解决的难题

作者抛出了一个具体问题：如何在不花钱搭负载测试环境的前提下，测试上游降级时的故障转移行为？这既是他清单上的第7项，也是目前没有好办法验证的一项。如果你有不同的权重排序方式，或者有他遗漏的评估维度，值得一起讨论。

（原文披露：文章包含推广链接。）