一个 API 网关把同一份请求卖两遍：Mistral 曝出的「复用推理」为什么值得整个行业紧张
本周流传的一份披露提到，Mistral 的某个 API 网关存在缓存失效（cache miss）漏洞：同一个请求被重复计费、重复推理，同一份计算被卖了两次。目前公开信息有限，细节仍在核实，但这条消息的价值不在具体数字，而在于它暴露了一类正在被忽视的失效模式。
这不是「算错了钱」，是「算错了架构」
独立的缓存失效漏洞（例如 CDN 命中率下降）只会影响成本。但发生在模型 API 网关上的缓存失效，性质完全不同：
- 网关是请求的第一个入口，它决定「这次请求要不要真的花算力」。
- 一旦命中判定失效，压力会直接传导到 GPU 集群，而不是落在边缘节点。
- 重复推理意味着同一批输入被多次送入模型，token 账单与显存占用同时翻倍。
换句话说，网关层的一个判定错误，会在整个推理栈的最贵环节放大。
三个容易被低估的连带影响
第一，计费可信度。 按 token 计费的商业模式建立在「网关计数准确」的前提上。如果网关本身可能重复计数，客户拿到的账单就失去了可验证性。对企业客户而言，这比多收几块钱严重得多——它意味着无法做成本归因。
第二，容量规划失真。 用量监控通常直接采信网关的请求计数。重复计数会让团队误判真实负载趋势，进而在扩容决策上出现偏差。当基础设施投资以十亿美元计时，这种失真代价很高。
第三，SLA 与「幽灵流量」。 重复推理会挤占本应留给其他租户的算力，表现为难以解释的延迟抖动。这类问题的排查成本极高，因为监控面板上看到的是「正常但是变多了」。
为什么这类问题现在更容易出现
推理网关这两年承担了越来越多职责：鉴权、限流、路由、缓存、提示词模板、结构化输出校验、多供应商回退。功能越堆越多，缓存键的设计越来越难做对——要不要把 temperature、seed、系统提示词版本、工具定义都算进 key？少算一项就会错误命中，多算一项就会命中率归零。而在多供应商回退的场景里，「同一语义请求走不同后端」还会让缓存完全无法共享。
对读者的实际影响与建议
如果你在用量较大的模型 API：
- 做一次对账。 抽一批固定输入的请求，用手工计数与账单对照，看是否存在系统性偏差。这是最直接、成本最低的验证手段。
- 自建轻量缓存。 对确定性任务（分类、抽取、固定模板摘要），在客户端或业务层做一层缓存，不要完全依赖供应商网关的命中判定。
- 把「重复请求率」加进监控。 这个指标平时没人看，但它是缓存失效最早的可观测信号。
- 优先选择能用请求 ID 追溯的供应商。 出了问题，能不能按请求维度复现与对账，决定了损失范围。
参考来源
延伸阅读：苹果 M6 把异构核心塞进同一个 L2：芯片竞争的重心正从「核多」转向「搬数据」 · 找一个「长得像 Claude 的问题」：物理学者用 AI 做跨学科计算的方法值得抄