你拆得挺到位的。98%这个数字确实离谱，我前阵子也在搞类似的推理优化，70%左右就到头了，再往上提每一点都是指数级的难度。你说到Prefix Caching和注意力掩码预计算，我猜他们可能还结合了某种动态的key-value eviction策略，不然维持这么高的命中率，缓存一致性得爆炸。另外，我比较好奇的是他们怎么处理长尾请求的？长序列的缓存占用巨大，如果命中率还能稳住98%，那说明他们的请求聚合算法相当聪明，可能做了某种语义级别的聚类，而不是简单的URL或参数哈希。

你提到从70%到85%降了40%成本，这我完全信。我算过一笔账，如果按DeepSeek现在的调用量，哪怕只降到95%命中率，他们的推理成本也比同行低一个数量级以上。这比堆参数更狠，参数多只是烧钱，效率高却是直接改变商业模型——别人卖推理服务是卖算力，他们卖的是算力的“剩余价值”，利润空间完全不一样。

不过有个点想讨论：这种极致优化会不会带来副作用？比如对动态性强的任务（像实时对话生成）适配性会不会变差？毕竟高缓存依赖的是请求模式的可预测性。如果他们的策略能同时兼顾长尾和突发流量，那这个护城河就真的深了。

85%到98%这个跨度确实夸张。我去年搞过类似优化，70%提到85%已经费了不少劲，主要是动态batch和请求调度上做文章，但再往上走就碰到天花板了——长序列推理场景下，cache miss率跟用户行为分布强相关，不是单纯靠工程能解决的。DeepSeek能做到98%，大概率是在请求聚合层做了很细的pattern识别，甚至可能对高频prompt做了离线预缓存。

有个点我想问，98%这个数字是整体统计还是按token粒度算的？如果是后者，那他们可能把attention计算和cache lookup完全解耦了，类似vLLM那种prefix caching的进阶版，但98%意味着几乎每个请求都能复用前序计算结果，这在多轮对话里尤其难，因为用户输入变长后前缀匹配率会断崖下跌。除非他们做了动态截断或者语义级缓存，不是单纯靠字符串匹配。

另外你提到的“注意力掩码预计算”，我猜他们可能用了某种自适应稀疏注意力，把非必要的历史KV cache直接丢弃，只保留关键前缀。这跟MoE路由结合起来的玩法，感觉比单纯堆参数有技术含量得多。说到底，现在大家算力都差不多，谁能在推理效率上抠出利润，谁就能在价格战里活下来。不过这打法对数据集依赖也很重，要是用户query分布变了，缓存命中率会不会骤降？挺好奇他们有没有做自适应回退策略。