DeepSeek 今日无缓存？GLM 切换后缓存率骤降

深度解读：DeepSeek今天缓存失效？GLM-5.2与DeepSeek API调用对比分析

本文基于LINUX DO论坛一则AI技能/提示词/工作流分享，结合官方文档与社区实测，系统分析DeepSeek API缓存机制的当前状态、与GLM-5.2的对比，以及实际使用中的成本与性能影响。原文仅分享现象，未涉及技术细节，本解读忠实还原原文要点，并补充必要上下文说明。

背景

DeepSeek（DeepSeek-V系列模型）作为国内领先的AI大模型提供商，其API服务长期以极具竞争力定价闻名，尤其在上下文相关的高频推理场景（如Agent工作流、编程任务、连续对话）下，用户常通过多轮调用同一前缀数据来提升效率。2025年以来，DeepSeek API正式推出上下文硬盘缓存技术，默认对所有用户开启，用户无需额外代码改动即可享受。

GLM-5.2（智谱AI GLM系列最新版本）同样支持大模型API调用，其模型架构与DeepSeek-V3.2高度复用（稀疏注意力、MoE等核心设计），但缓存机制存在显著差异。论坛帖子记录了同一工作流在两个模型上的表现差异：同一提示词（prompt完全一致），GLM-5.2从0点至今数据未命中缓存，而DeepSeek历史数据提示词缓存率达到95%左右。此对比发生在10点后，GLM-5.2可用性降低时自动切换至DeepSeek，引发用户对DeepSeek“今天缓存失效”的疑问。

核心内容

原文核心围绕两个模型同一提示词调用过程的缓存行为差异展开：

• 调用过程完全一致：用户在同一Agent工作流或自动化任务中，向GLM-5.2和DeepSeek发送相同提示词（prompt）。DeepSeek按历史数据提示词缓存率95%左右持续命中。
• 时间切换与可用性影响：10点后，GLM-5.2可用性下降，工作流自动切换到DeepSeek，导致用户观察到“今天DeepSeek缓存没了”的现象。
• 缓存命中率实测：DeepSeek历史数据（包括多个posts）显示95%左右的缓存率，远高于GLM-5.2的当前表现（截至帖文时间，GLM-5.2 0点至今未命中缓存）。
• 缓存工作原理隐含：原文未详述，但与DeepSeek官方机制一致，即缓存基于输入前缀重复度，命中时大幅降低计费（输入缓存部分按极低倍率计费，命中率高则整体成本降至10%以下）。

原文仅记录现象，未分析原因或解决方案，仅作为提示词/工作流分享案例。6 posts - 5 participants的讨论区中，用户主要讨论DeepSeek缓存机制的稳定性、与GLM-5.2的对比，以及在高频调用场景下的实际成本节省。

关键要点

• DeepSeek API内置上下文硬盘缓存，默认开启，命中率可达95%（原文实测数据）；缓存建立耗时秒级，失效后自动清空（一般几小时至几天）。
• GLM-5.2与DeepSeek提示词调用过程完全一致，唯一差异在于缓存可用性：GLM-5.2当前缓存命中率为0（0点至今），DeepSeek保持95%历史水平。
• 切换触发：10点后GLM-5.2可用性降低，自动切入DeepSeek，导致用户感知“缓存失效”。
• 缓存影响核心：命中缓存时输入token成本大幅降低（官方机制下可节省90%以上费用），未命中则按全价计费；输出token无缓存，计费标准不变。
• 原文未提及具体token量、准确切换时间或解决方案，仅作为工作流分享案例，需用户自行验证或优化前缀结构以维持高命中率。

意义与影响

此事件凸显DeepSeek缓存机制在实际自动化工作流中的优势：95%命中率意味着在高频重复提示词场景中，推理成本可降至原先的10%以下，显著降低长期使用成本（尤其Agent循环调用或连续编程任务）。与GLM-5.2的对比则反映缓存机制对整体可用性和费用控制的直接影响——缓存失效时用户被迫切换模型，可能导致临时性能或可用性波动，但DeepSeek的持久缓存特性仍保持整体竞争力。

对于开发者而言，此类案例提醒优化提示词前缀一致性（确保重复度高）以维持缓存命中，同时注意模型切换时的上下文重置风险。DeepSeek缓存“尽力而为”的设计虽非100%保证，但实际使用中已广泛验证其成本优化效果，助力AI应用从实验阶段转向生产级部署。长期看，此机制正推动行业向更低成本、高效推理方向发展，用户可通过监控usage字段中的prompt_cache_hit_tokens等指标，进一步提升工作流效率。