台风天午休时间，从 octafuse-gateway 上拉了一批真实请求统计，做了一次国内模型供应商的缓存与可用性观察，在这里分享给大家。
这次重点不是单纯比较模型能力，而是看一个更影响 Agent 真实使用体验的问题：谁的缓存更稳，谁更适合长上下文、高频调用、容易反复请求的 Agent 场景。
为什么缓存很重要？
做 Agent 的人应该都遇到过一个问题：模型调用不是一次性的聊天，而是一连串任务链。
比如：
系统提示词很长
工具定义很多
上下文经常重复
多轮推理会不断带上历史信息
Coding Agent 还会反复读取相似文件、相似代码片段
这时候，缓存命中率就非常关键。
缓存命中率高，意味着大量重复输入 token 可以按更低成本处理，首 token 延迟和整体响应体感也会更稳定。反过来，如果缓存突然不命中，用户体感会很明显：同样的任务突然变慢、突然变贵，甚至出现价格背刺。
尤其是 Agent 场景，输入 token 往往远大于输出 token。看起来只是一次请求，实际上前面塞了大量 system prompt、工具 schema、历史上下文和文件内容。
如果缓存不稳定，成本会被迅速放大，用户体验也会大打折扣！
测试数据与结果分析
先说明一下，这次统计省去了很多聚合商数据。原因也很简单：不少聚合商本质上还是转发到模型官网或其他大供应商。对于评估底层缓存与可用性来说，聚合商链路会混入太多变量，不适合作为核心结论。
下面是这批真实请求里，几个主要供应商的统计结果：
从这批数据看，结果比较清楚：模型官方厂商整体表现最好。
比如 DeepSeek 官方、小米 MiMo、智谱这类，缓存命中率可以做到 90% 以上，甚至接近 97%。这对 Agent 来说非常重要，因为它直接决定了长上下文复用时的成本和稳定性。实际体验上，缓存命中率高不仅省钱，也会让响应更稳定。用户不会频繁遇到“同样任务今天突然贵很多”的情况。而其他大云服务商的反而会差一些，所以如果对于缓存比较敏感的场景，模型官方厂是最优选择。
云厂商的MaaS选择
先解释下，为什么这里把阿里云百炼和火山方舟拉进来，但是其他聚合平台没拉进来，主要是因为其他聚合平台没有自己的模型也自己不部署模型，仅靠转发的话，直接以官方的数据为准即可。阿里云百炼和火山方舟不仅有自己的模型，另外还有自部署的开源模型，所以也值得一起评估。
这里从数据上来看，百炼的缓存命中率相比官方模型厂商确实差一些，但相比火山方舟来说，还是高了不少，实测下来可用性也更为靠谱。
慎选避坑：火山方舟
最后，值得一提的是，建议避坑火山方舟。
无论是普通 API 直连，还是 Plan 类产品，火山方舟的缓存表现都比较弱，几组数据大致在 65% 到 73% 之间。这也是为什么网上很多用户说他们家的 Plan 消耗特别快的重要原因之一。
更麻烦的是可用性。实际使用中，火山系更容易遇到 429 类错误或者并发资源不足的问题。由于是连续 Chat 类场景，对于一些上下上文的场景，火山方舟的 API 有时候连单用户的支持都达不到，就会出现 429 错误。
我的体感是：如果要接入火山，最好在客户端做好排队、重试、限流和降级，否则 Agent 一旦进入高频工具调用或并发任务，很容易被打断。
这可能和资源池、调度策略或产品形态有关。无论原因是什么，对使用者来说结果是一样的：缓存不够稳，可用性也不够稳。
所以，除非你对火山的某个独家模型有强需求，否则在 Agent 场景里建议慎选。
真要用，也建议至少做好几件事：
客户端侧排队，避免瞬时并发直接打满
对 429、5xx 做重试和退避
关键任务配置 fallback 供应商
对长任务拆分步骤，减少一次失败导致整条 Agent 链路中断
单独记录缓存命中率、首 token 延迟、错误率和重试次数
结论：谁更适合 Agent？
如果你的目标是跑 Agent，我的建议是：
第一梯队优先选模型官方厂商，比如 DeepSeek 官方、小米 MiMo、智谱这类。缓存命中率高，成本可控，用户体感更稳定。
如果你需要平台型能力，比如多模型统一接入、企业管理、账单和服务治理，可以优先考虑阿里云百炼。它的缓存不如官方厂商漂亮，但整体可用性是靠谱的。
火山方舟系则建议谨慎接入。真要用，最好在客户端做排队、限流、重试和 fallback，不要直接把高并发 Agent 流量打过去。