14家供应商基准测试：DeepSeek V4 Flash 热缓存下成本降低14.9倍

测试采用单一受控设置：输入 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、传输和响应错误。确切计数和描述性区间位于图表下方的表格中，原始记录可下载。标注为零表示样本中未观察到失败，未测量的字段标为“未上报”而非零。

对采购方而言，实际解读较为有限。冷热之间的差距足够大，重复性工作负载的账单可能主要由提示词复用决定，而非单纯取决于供应商选择。但同样的数字也显示，重复的提示词可能落到不同的上游，这改变了缓存折扣是否适用的情况。