Inference Academy 基准测试：DeepSeek V4 Flash 冷请求成本高出 14.9 倍

这项测量与回答质量无关。Inference.academy 用一套受控设置测试了 1000、10000 和 100000 输入 token 三档目标，每档搭配 100 或 1000 输出 token 预算。温度设为 0，推理功能关闭。冷请求使用唯一前缀，热请求重复同一个提示词。该网站称这些结果是服务测量值，不是任务质量评分。

成本的定义是请求总费用除以输入 token 数，再乘以 1M，其中包含输出费用。服务商页面上标注的输入价格并不是基准测试所比较的对象。研究报告给出了 10000 输入、100 输出 token、冷缓存条件下 13 条路由的成本数据点。

14.9 倍是基准测试点出的最大差距。在 DeepSeek 的 100000 输入、100 输出预算请求中，本次样本里热调用的成本比冷调用低 14.9 倍。热调用指重复同一个提示词。实测的缓存占比决定了有多少输入工作真正按未缓存价格计费。

速度是另一条轴

在全部 12 种测试条件下，Telnyx 的中位生成速度都排第一。首 token 延迟并没有呈现同样的规律。基准测试称，最快的首 token 取决于请求形态。1000 提示词上首 token 时间最快的服务商，在 100000 时不一定还是最快。

"把提示词发到哪里，决定了你付多少钱、等多久，以及这次调用能不能成功。"

这句话是 inference.academy 对这一测试的概括。时间面板使用 100 token 输出预算的冷请求，并采用统一坐标轴刻度。TTFT 从请求开始计到客户端收到第一个内容或推理增量为止，包含网络和排队时间。P90 在有序观测值之间做线性插值。解码速度在流式输出开始后测量，计算方式是用完成 token 数除以从第一个到最后一个输出增量的耗时。非流式响应完全不测解码速度。

路由是另一个变量。基准测试记录了 OpenRouter 针对每种请求形态和缓存条件返回的上游名称，并指出同一个重复提示词可能到达不同的上游，从而改变其缓存行为。

在 10000 到 100 的热条件下，Together 占 29 次调用，Novita 占 20 次，CoreWeave 占 17 次。在 10000 到 100 的冷条件下，Baidu 出现 15 次，Relace 出现 13 次。该网站明确说明，色块宽度代表调用占比，这些名称是上报的上游，并非经过验证的机器。仅凭这一分布无法确定路由变化的原因。

失败率按输入目标和输出预算分别列出，冷、热条件分开比较。基准测试提醒说，同一个提示词要求更长的回答时，同一条路由的表现可能不同。HTTP 错误、传输错误和响应错误都计为失败，具体次数放在图表下方的表格里。零表示该样本中未观察到失败，并不等于保证不会失败。

对任何要付推理账单的人来说，实际结论比标题要窄。在长输入上，缓存对账单的影响超过一个数量级，而通过路由器拿到的服务商并不固定。基准测试的成本散点图覆盖 14 家服务商和 13 条路由。它自己的说法是最稳妥的总结：这些是服务测量值，描述的是本次样本中发生的情况。