一次 API 请求，账单上怎么会冒出两次调用？
简单说，因为你设了回退。第一个提供方没答上来，网关换一家接着答，两次都算钱。
这期重点就这一条。剩下的是附赠。
五款网关，20 条评论
上个月 dev.to 上有篇 LLM 网关对比，五款工具：LiteLLM、Kong AI Gateway、Portkey、Bifrost、Apache APISIX。
作者按提供方抽象、流量管理、可靠性、可观测性、运维控制五个维度打分，总览表做得很齐。
维度是他挑的，跟你实际会踩的坑，未必是一回事。
这类文章我现在的读法是先翻到底。20 条评论，信息量比正文大。
先说一句你多半不用管的
原文自己写了，只对接一个提供方、流量有限的场景，未必需要网关。
这是全篇对普通人最有用的一句。网关本质上是应用和模型之间加的一层转发，做路由、限流、重试、鉴权、日志、成本统计这些活。它不替代 GPT、Claude、Gemini，只管这些模型周边的杂事。
你写个脚本调一个模型，加这层就是给自己找活干。多一层，就多一个会挂的东西。后面几条讲的都是例外情况。
回退不是免费的
原文提了一句，首个请求失败后由别的提供方接管，会额外带来延迟和模型用量。回退策略要在可用性、成本和响应时间之间权衡。
白话版是，自动重试是一笔交易，你拿钱和时间换稳定。值不值，看那次调用本身值多少。这条没有统一答案。
作者写了这句，没往下推。评论区替他推了。
一次超时，可能变成三次提供方调用
这条是评论区 Hayrullah Kar 提的，本期唯一必须抄走的东西。
按“请求”记账，一次失败后回退会产生两次计费调用。按请求聚合的日志会把它记成一次。结果是“每次成功应答的成本”这个数，你根本算不出来。
Julian Neagu 补了另一刀。一次超时可能很快演变成两到三次提供方调用，只记录最终请求，这类成本几乎无法察觉。
作者在回复里给了方案，按“尝试”记录。尝试序号、提供方、模型、延迟、结果、token，全部挂在同一个父请求 ID 上。
他还说了一句关键的话。超时不代表提供方没在处理请求。所以你有可能先为一次被放弃的尝试付费，再为重试付费。
这个日志格式不玄，直接抄就行。哪怕只加一个尝试序号，也比现在这笔账清楚。
不同提供方的 token，不是同一种东西
还是 Hayrullah Kar。不同提供方对缓存输入、推理 token、图像 token 的计数方式不一样。
把 token 归一化成仪表盘上的一个字段，等于对不同量求平均。
这条我之前没想到过。几个提供方各自定义自己的 token，你硬合成一个数，那个数就不说明任何事。他建议去查这五款工具里哪些会把提供方的原始 usage 对象原样暴露出来。这个查法本身值得学。
网关自己会挂
自托管网关一旦上了，就是所有模型调用前面的单点。它的超时预算必须短于调用方，否则重试会层层叠加。
这条我只理解了一半。大意是别让网关的重试和调用方的重试互相打架。先放在这里，搞明白了我再补一句。
作者后来也承认，整篇文章完全没覆盖网关自身的失败模式。对自托管方案来说，这是真实的生产风险。
流式应用别只看一个延迟数字
评论里有人提到，部分网关会缓冲 SSE 分块。原始吞吐看着正常，首 token 时间已经坏了。
流式的东西要分开测。首 token 时间、持续响应行为、中断、完成时间，压成一个延迟数字，等于什么都没测。
作者回复说这篇没做跨五款的并发基准，给不出上游饱和时的表现，后面另写一篇。他建议先去查 Kong 和 APISIX 这类 NGINX 风格代理的缓冲配置。
回退会悄悄换掉你评测的模型
Kartik 提的。故障转移会让应答的模型不是被评分的那一个，评测结果就不成立了。
他的做法是评测流量固定到单一提供方，只让网关承载生产流量。这个切法很干净，可以直接学。
作者顺着补了几个改进方向。按请求记录实际服务的提供方和模型，把评测期间发生的回退单独标成事件，再用同一份录制流量加同样的故障注入做回放。
作者认了两次错
原文漏了尝试级日志，也完全没写网关自身的失败模式。作者说前一条会列成独立的评估标准，后一条要补进失败场景测试。
一篇对比文被评论区补出两个评估维度，这件事比它的结论有用。
还有一个评论区反复追问的。网关在上游饱和时，是排队、丢请求，还是直接把 429 透传出去？排队的话，队列有没有上限，会不会超时，这些请求能不能在指标里看见？
作者没答，说另写一篇。
我把它列在这儿，是因为它提醒了一件事。所有提供方都健康的时候，网关看起来都很好。差别要出事的时候才露出来。
再补一句我自己的判断。这期我没挑那五款谁强谁弱。按我现在的标准，选哪个的差距，远小于你有没有把日志记对。工具换一次是几天的成本，账单黑箱是几个月都看不见。
网关这个词我之前也收过，那时候讲的是它跟 MCP 的区别。其实没变过。它管的永远是模型周边那些没人愿意自己写的事。包括最不体面的那件，算清你到底花了多少次调用。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。