14家供应商基准测试：DeepSeek V4 Flash 热缓存下成本降至十四点九分之一

测试只跑一种受控设置：输入 token 目标为 1000、1万和10万，每种搭配 100 或 1000 的输出 token 预算，temperature 为 0，推理关闭。冷请求带唯一前缀，热请求重复同一段提示词。网站写明，这些是服务层面的测量，不是任务质量评分。

研究里的成本不是标价上的输入 token 价格。它等于请求总费用除以输入 token 数，再乘以一百万，输出费用已经折算进去。在整个样本中，DeepSeek V4 Flash 在10万输入、100 输出预算的请求上，热请求比冷请求便宜 14.9 倍。

两次调用之间的路由并不稳定

测试还记录了 OpenRouter 对每种请求形态返回的上游名称。这些名称随缓存状态变化。1000 输入、100 输出的冷调用里，Baidu 最多，18 次，Relace 14 次，AkashML 13 次。同样形态的热调用里，Relace 最多，24 次，CoreWeave 16 次，DeepSeek 11 次。

10万输入、100 token 输出预算下，冷请求大多流向 Baidu（7）、DigitalOcean（3）、Relace（3）和 Wafer（3）。同样形态的热请求流向 Relace（14）、Together（6）和 CoreWeave（5）。作者提醒，分段宽度只是调用占比，这些名称是上报的上游，不是核实过的机器，仅凭这一分布无法确定路由为什么变化。

速度方面，Telnyx 在全部 12 种条件下都拿下中位生成速度第一。首 token 延迟取决于请求形态，没有单一赢家。网站把首 token 时间定义为从请求开始到客户端收到第一个内容或推理增量，包含网络和排队时间；解码速度是上报的完成 token 数除以第一个到最后一个输出增量的耗时。非流式响应不产生解码速度测量。

计时只包含成功的调用。

缓存占比与失败率

研究报告的缓存占比，是缓存输入 token 之和除以同时上报两者的成功请求的输入 token 之和，测量对象是重复的1万提示词，输出预算 100 token。这是 token 占比，不是命中缓存的请求百分比，热序列里也包含它的首次请求。

失败率按输入目标、输出预算和缓存状态分别列出。作者指出，同一段提示词要求更长的回答时，某条路由的表现可能不同。失败率是该条件下失败调用数除以已测量调用数，计入 HTTP、传输和响应错误。确切计数和描述性区间放在图表下方的表格里，原始记录可下载。标注为零表示样本中没观察到失败，未测量的字段标为未上报，而不是零。

对采购方来说，实际解读很有限。冷热之间的差距足够大，重复性工作负载的账单可能主要由提示词复用决定，而不是单看选哪家供应商。但同样的数字也显示，重复的提示词可能落到不同的上游，缓存折扣是否适用就变了。