台风天午休时间从 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 流量打过去。
