Keln 网关基准实测，缓存命中 93.9%，四家 AI 网关跑 3360 轮

一句话结论，用同一个 DeepSeek V4.1 Flash 跑满 24 小时真实智能体会话，四家 AI 网关的缓存命中率从 62.6% 到 93.9% 相差 31 个百分点，账单从 9.14 美元到 20.20 美元相差一倍多，而其中两家在请求明确要求最高推理强度时悄悄少给了三分之二的思考量，响应却完全正常。

AI 网关这个角色最近两年被推到了链路的关键位置上。开发者不想直接对接多家模型供应商的 API，于是多了一层网关来做统一计费、故障切换、模型路由和缓存复用。多一层就多一层不确定性，网关选得好是成本优化，选不好就是成本黑洞加上偶发的质量问题。10 月 22 日，Keln 团队发布了一份四家网关的对照基准，把这层不确定性第一次用同一套方法摊开测量。

参与对比的是 Keln、OpenRouter、Vercel AI Gateway 和 Ramp Router 四家，全部跑在 DeepSeek V4.1 Flash 上，全部开启零数据保留、最高推理强度与工具调用。需要注意基准由 Keln 自己做，团队来自 NVIDIA 与 Google，Keln 也是其中一家，读者看的时候要把这层立场放在心里。不过这份基准的方法写得相当细，原始账本没有公开但分析脚本放进了仓库，第三方可以自己复算。

基准怎么设计的

整个实验跑了 24.3 小时，从 2026 年 10 月 20 日 00:25 UTC 到 10 月 21 日 00:44 UTC，中间有 64 分钟没有任何网关收到请求，这段时间被从图表的时间轴里剔除了。总计 13440 轮，每家网关 3360 轮，四个网关在同一个时刻收到同一轮请求，互不等待。

会话素材来自 Hugging Face 上公开的 armand0e Claude Code 语料，用原生工具调用回放，每一段录下来的助手回合作为下一次请求发出，录下来的工具结果追加到上下文后面，会话因此像原始用户那样自然增长。8 个会话，每会话 30 轮，每次两个并发，共跑 14 遍，每遍换新的盐值与新的会话 ID。每轮的中位长度是 40700 个 token。5% 的轮次会暂停 1 到 20 分钟，用同一颗种子让四家经历相同的间隔。

参数方面，推理强度按各家 API 各自认的形式设到最大，max_tokens 给到 30000，temperature 为 1，开启流式输出。路由配置也按各家的推荐写，Keln 用它的公开 API 原样，OpenRouter 走 nitro 并要求 provider.zdr 为真，Vercel 在它那份零数据保留供应商列表里按每秒 token 数排序，Ramp 用 Responses 方言。

这组数据里最刺眼的是最右列。Ramp 的缓存命中率只有 62.6%，3360 轮里有 946 轮是完全冷启的，换供应商换到 500 次，未缓存的 prompt token 累积到 4750 万。账单因此冲到 20.20 美元，而它实际只完成了 3263 轮，预付钱包在 23:44 UTC 见底，拒掉了最后 97 轮，这是钱包限额而不是网关故障，它其余的数字都基于跑完的 23 小时。

缓存命中率的差距来自路由策略

缓存这件事本身没有玄学，答案落在四家不同的路由选择上。Keln 会把一段对话留在持有其前缀的供应商上，Vercel 会把对话钉在首个供应商 5 分钟，OpenRouter 和 Ramp 则每次请求都重新选一次。

换供应商意味着冷 prompt，几万个 token 要按未缓存价重新读一遍，首字也要多等几秒。Keln 在 3360 轮里只换了 14 次，OpenRouter 换了 148 次，Vercel 60 次，Ramp 500 次。暂停时长的影响被单独量化了。暂停 10 分钟之后，Keln 还能从缓存里提供 75% 的下一轮 prompt，OpenRouter 是 52%，Vercel 25%，Ramp 23%。暂停不足一分钟的话四家没有差别。

还有一个容易被忽略的角度。同一个供应商放在不同网关后面，缓存表现也不一样。基准里有一家供应商，四条路径的缓存命中率分别是 92.6%、87.5%、84.1% 和 63.0%，走的全是同一个模型和同一个供应商。这说明缓存能不能命中，一半取决于上游供应商的缓存策略，另一半取决于网关会不会把请求甩给别家。

把这条逻辑往前推一步就能理解账单差异。Keln 相比 OpenRouter 少读了 700 万个未缓存 token，相比 Vercel 少 950 万，相比 Ramp 少 3950 万。这就是为什么四家跑完全相同的 3360 轮，总账单的区间是 9.14 美元到 20.20 美元。

最该警惕的是推理量被悄悄截断

这份基准里最值得警惕的发现在推理量上，缓存与账单都摆在明处，推理量藏得更深。四家收到的请求都明确要求最高推理强度，模型也一样是 DeepSeek V4.1 Flash，供应商还有重叠，推理 token 数本该在温度为 1 的噪声范围内对齐。

实际结果是每轮平均推理 token，Keln 856，OpenRouter 1033，Vercel 403，Ramp 420。Vercel 与 Ramp 给出的推理量不到 Keln 的一半，但响应看起来是成功的，没有任何告警或报错。

中位数看更清楚。Keln 40，OpenRouter 42，Vercel 54，Ramp 36，中位数四家基本一致。差距全部来自少数推理上千 token 的轮次。统计推理超过 5000 token 的轮次，Keln 有 152 轮，OpenRouter 212 轮，Vercel 只有 36 轮，Ramp 43 轮。在四家都用到的同一个供应商上，OpenRouter 是每 12 轮出现一次超长推理，Keln 每 15 轮一次，而 Vercel 与 Ramp 要到每 70 轮才一次。

这类问题之所以难发现，是因为它完全藏在成功响应里。你无法知道模型只思考了三分之一的量，响应正常回来，账单还更便宜。错误会在更难的某一轮才暴露，而那一轮的日志显示请求完全正常，网关自然不会被怀疑。

账单数字其实早就提示了这件事，只是容易被读成好消息。Vercel 的账单最低只有 9.14 美元，原因在于它实际跑的推理量更少，单价并没有便宜。把推理量按 Keln 的 856 token 水平重新定价，Vercel 的账单应该是 10.97 美元而不是 9.14 美元，Ramp 应该是 21.89 美元而不是 20.20 美元。差额就是被截断的思考量。

基准方法的边界在哪

要正确使用这份数据，得知道它测的是什么、没测什么。

第一，模型只有 DeepSeek V4.1 Flash 一款。不同供应商的缓存策略差异很大，换模型结论可能不一样。第二，会话是回放而非真人使用，工具调用是录制好的，不包含真实的工具失败重试与用户打断。第三，原始账本与响应体没有公开，只给了分析脚本，这削弱了第三方核验的能力。第四，基准由参测方之一发布，方法细节写得很足，但缺少独立机构的复现。

还有一点是它测量的是长会话场景。中位轮次 40700 个 token，这是编码智能体这类长上下文场景的数字。如果你的应用每轮只有几百 token，缓存命中率与换供应商的权重会完全不同，结论不能直接搬。

话说回来，推理截断这个发现的价值并不依赖基准的绝对准确性。只要能确认有网关在最高推理强度下返回更少的推理量且不作提示，这个现象本身就值得所有依赖推理模型的团队自查一遍。

怎么把这套数据用在自己的系统里

读这份基准最实用的方式，是把它当成一张排查清单，而不是选型结论。

第一件事是查自己的缓存命中率。多数团队从没量过这个数字。口径是缓存命中的 prompt token 占全部 prompt token 的比例，按 usage 里的字段算。如果这个数字低于 80%，第一笔要省的钱就在路由策略上，把会话尽量留在持有其前缀的供应商上，让缓存的生存期覆盖真实的使用间隔。

第二件事是查推理量有没有被截断。做法是把自己网关返回的 usage 里的推理 token 数按轮次记录下来，看长尾分布。如果绝大多数轮次在几十 token、偶尔冒出来几千 token 的那种形状被削平了，说明上游做了限制。这跟我们此前拆解 Cohere Rerank 5 宣称节省 35% token 时讨论的情况类似，token 数量本身是个需要盯住的量。

第三件事是查换供应商的频率。一次换供应商就是一次冷 prompt，如果你的账单里有大比例的未缓存 token 而业务上并没有真正做多供应商切换，那通常是路由在无谓地漂移。

多供应商路由的价值在 Exa 3.0 搜索 API 掀起的价格战 里体现得很清楚，它把接口抽象和成本控制推到了台面上。但抽象层越多，可观测性越差，网关这一层尤其如此。

回到首字延迟，四家的 p50 都在 0.42 到 0.45 秒之间，几乎没有差别，Ramp 的 p95 到了 4.48 秒是唯一的异常值。解码速度四家都在 390 到 430 token 每秒的区间。真正的差异全在预填充和缓存这一侧，而这一侧恰好是长会话场景里开销最大的地方。

这类路由与缓存的工程细节，其实与我们之前看的 Vercel 开源 durable-harness 的崩溃续跑机制 属于同一片区域。网关这一层决定的是成本与延迟的起点，而智能体框架决定的是这一层之上能跑多少步，两者叠加起来才是智能体产品的真实账单。这也解释了为什么 DeepSeek V4.1 Flash 把 KV Cache 缩小 437 倍 这类模型侧的工作，与网关侧的路由优化会同时出现在账单改善的清单上。

FAQ

四家网关应该怎么选

如果你的场景是长会话的编码智能体，缓存命中率与换供应商频率这两个指标的权重最高，按这份数据 Keln 表现最好。如果你的场景短轮次为主、看重最低单价，Vercel 的账单确实最低，但要留意它的推理量偏低这件事。有多供应商容灾需求且预算敏感，OpenRouter 的推理量与缓存表现居中，是比较稳的选择。Ramp 在这份测试里各项都落后，除非有其他强约束，否则不建议优先考虑。

推理 token 被截断会怎么表现

最典型的表现是复杂问题上的答案质量下降，但响应本身完全正常，没有报错也没有降级提示，账单甚至更低。隐蔽之处在于日志记录不出来，因为那一轮的 usage 显示请求正常。所以只能靠长期统计推理 token 的分布来发现，把长尾削平了就是被截断了。

这份基准能不能直接照搬到别的模型上

不能直接搬。推理截断这个现象大概率与模型和供应商的实现有关，换模型结论可能不同。缓存命中率和换供应商频率的相对关系也有模型相关性，不同供应商对提示前缀的缓存处理策略差异很大。可以借的是方法，把回放语料、相同轮次、相同并发、统一的暂停种子这套测法搬到自己关心的模型与网关上重新跑一遍。

小结

这份基准把 AI 网关这个环节从感觉贵但说不清贵在哪推进到了可以逐项对照。四个结论各有用处。缓存命中率决定大头的 prompt 成本，换供应商次数决定冷读的规模，首字延迟的差异极小所以不必在这上面较劲，而推理量被截断是最该警惕的那个问题，因为它把成本优化变成了质量退化。

对大多数团队来说，先别急着换网关，先把缓存命中率量出来、把推理 token 的长尾看明白。这两件事做完，再回到这张表上做选择，结论会稳得多。

相关阅读

• DeepSeek V4.1 Flash 深度解读，KV Cache 缩小 437 倍
• Cohere Rerank 5 发布，BRIGHT 82.2 分与 token 节省 35%
• Exa 3.0 搜索 API 上线，AI 搜索赛道进入价格战
• Vercel 开源 durable-harness，5 个编码智能体框架拆解