How DeepSeek API Context Caching Cuts Input Costs by ~98% on V4

如果你每小时运行一个包含20,000个token的系统提示的代理，并调用它一千次，大多数前沿API的费用将是残酷的。DeepSeek API上下文缓存是那个默默解决这个问题的功能——重复的提示前缀在服务器上被检测到，从硬盘缓存中提供服务，并且费用大约是正常V4-Flash输入速率的五分之一（缓存命中$0.0028，未命中$0.14，自2026-04-26以来降低了98%）。无需配置。没有`缓存控制`断点，没有TTL旋钮，没有额外的SDK调用。

本指南将详细介绍DeepSeek V4-Flash和V4-Pro上的缓存工作方式，`usage`字段告诉你的内容，两个实际成本示例，以及将你的命中率从偶然提高到故意的提示结构习惯。

DeepSeek API上下文缓存实际做什么

DeepSeek的API提供了一种服务器端磁盘缓存，它可以检测同一账户请求中的重复提示前缀，并以折扣率提供服务。该技术默认对所有用户启用，使他们无需修改代码即可受益。每个用户请求都会触发硬盘缓存的构建，如果后续请求与前一个请求有重叠的前缀，重叠部分将只从缓存中获取，这算作缓存命中。

模型仍然从头开始生成响应——缓存仅是对输入端的计费和延迟优化。硬盘缓存仅匹配用户输入的前缀部分；输出仍然通过计算和推理生成，并受温度等参数的影响，引入随机性。

一些容易让人忽视的操作细节：

• 缓存系统使用64个token作为存储单元；少于64个token的内容将不会被缓存。一些第三方指南报告，对于V4的可靠命中，实际的最小值更接近1,024个token——前缀必须至少有1,024个token长，并且必须完全匹配。
• 缓存系统基于“尽力而为”的原则，不保证100%的缓存命中率。缓存构建只需几秒钟。
• 只有具有相同前缀（从第0个标记开始）的请求将被视为重复。输入中间的局部匹配不会触发缓存命中。
• 每个用户的缓存都是隔离的，对他人逻辑上不可见，确保数据隐私和安全。未使用的缓存条目将在一段时间后自动清除。

如果您想验证缓存是否真的在您的账户中工作，我们的 DeepSeek API tester 可以发起两个具有相同前缀的请求，并在响应中显示使用对象。

价格 — V4-Flash和V4-Pro并列

DeepSeek V4于2026年4月24日发布，作为两个开放重量的MoE层级—— deepseek-v4-pro (1.6T total / 49B active) and deepseek-v4-flash (284B / 13B活跃)。两者共享缓存。缓存命中的价格是主要的节省；缓存未命中的比率是你为每个请求的变量尾部所支付的费用。

截至2026年4月的数据，来源于DeepSeek在V4预览版发布时的定价页面——在确定预算前请在实时页面上进行验证。请注意，较旧的deepseek-chat和deepseek-reasoner ID现在作为V4-Flash别名收费；ID弃用截止日期是2026年7月24日（UTC时间15:59，根据DeepSeek的迁移通知）。V3下存在的夜间非高峰折扣已取消——DeepSeek于2025年9月5日停止了该折扣，并在V4中没有重新引入。有关各层级的完整分解，请参阅 DeepSeek API pricing reference.

快速入门：第二次调用时将触发的请求

该API与OpenAI兼容且无状态——这意味着您的客户端必须在每次调用时重新发送对话历史；DeepSeek不会在服务器端存储回合。聊天请求命中 POST /chat/completions, the OpenAI-compatible endpoint at https://api.deepseek.com. 这里是一个使用 OpenAI SDK 的最小 Python 示例：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.deepseek.com",
    api_key="YOUR_DEEPSEEK_KEY",
)

SYSTEM = "You are a senior financial analyst. " * 200  # ~2,000 tokens, stable

def ask(question: str):
    resp = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": question},
        ],
        temperature=1.0,
        max_tokens=1024,
    )
    print(resp.usage)
    return resp.choices[0].message.content

ask("Summarise the Q1 report.")
ask("Now analyse profitability.")  # second call → cache hit on the system prefix

相同的调用适用于 deepseek-v4-pro 无其他更改。要启用任一层的思考模式，请添加 reasoning_effort="high" with extra_body={"thinking": {"type": "enabled"}}; 模型随后返回 reasoning_content alongside the final contentDeepSeek还提供了一个与Anthropic（公司名）兼容的界面，针对相同的基URL，如果你的堆栈已经使用了Anthropic（公司名） SDK。完整的设置指南： DeepSeek API getting started.

读取使用对象

每个响应都包含一个 usage 包含两个字段的对象，您应该在每次调用时记录这两个字段：

• prompt_cache_hit_tokens — 来自缓存的输入令牌，按命中率计费。
• prompt_cache_miss_tokens — 未缓存的输入令牌，按未命中率计费。

prompt_cache_hit_tokens是这次请求输入中导致缓存命中的token数量；prompt_cache_miss_tokens是没有命中的token数量。如果你使用LiteLLM作为路由器，它会将其标准化为OpenAI风格的形状：一个包含cached_tokens（该调用中缓存命中的token）的prompt_tokens_details对象。对一个全新的前缀的第一个调用将报告零命中token——这是预期的。缓存构建在后台进行，第二个相同前缀的调用应该报告大部分前缀为命中。

工作成本示例A — V4-Flash代理

一百万次调用，每次调用都有一个2,000个token的系统提示词保持不变，一个200个token的用户消息每次都变化，以及一个300个token的回复。等级： deepseek-v4-flash.

• 缓存输入：2,000 × 1,000,000 = 2,000,000,000 令牌 × $0.0028 / M = $5.60
• 未缓存输入：200 × 1,000,000 = 200,000,000 令牌 × $0.14 / M = $28.00
• 输出：300 × 1,000,000 = 300,000,000 令牌 × $0.28 / M = $84.00
• Total: $117.60

没有缓存——即如果每个输入token都按未命中率计费——仅输入部分就会是2,200,000,000 × $0.14 / M = $308.00，总计$392.00。缓存在整个运行过程中节省了$274.40，大约是工作负载的70%（仅缓存命中行现在比未命中便宜98%，因为2026-04-26的费率下降）。

工作成本示例B — V4-Pro代理

相同的工作负载，前沿等级。等级： deepseek-v4-pro.

• 缓存输入：2,000,000,000 × $0.003625 / M（促销）= $7.25
• 未缓存输入：200,000,000 × $0.435 / M（促销）= $87.00
• 输出：300,000,000 × $0.87 / M（促销）= $261.00
• Total: $355.25 (V4-Pro 75% promo through 2026-05-31; list-price total is $1,421.00)

Pro示例展示了两个问题。首先，在Pro等级上，缓存在绝对美元价值上更有价值——在促销价格下，命中和未命中之间每百万token的差距在Pro上是约$0.43，而在Flash上是$0.137（Pro列表上的$1.74）。其次，输出主导了前沿等级的支出。如果你的工作负载实际上不需要V4-Pro推理，V4-Flash在规模上大约便宜10倍。为了快速检查你自己的数字，请参考 DeepSeek pricing calculator 允许您插入您的命中率和消息配置文件。

五种最大化缓存命中的提示模式

缓存只匹配从token 0开始的相同前缀。这条规则驱动了以下所有的优化。

1. 首先放置稳定的内容。 系统提示 → 工具模式 → 获取的文档 → 最后用户的提问。每次调用中需要变化的任何内容都必须放在最后。
2. 系统提示字节对字节固定。 即使将“你是一个有用的助手。”改为“你是一个有用的AI助手。”也会使每次下游调用中的前缀无效。对系统提示进行哈希处理，并在其发生变化时发出警报。
3. 冻结少样本示例顺序。 在每次调用之间重新排列示例是导致命中率崩溃的最常见原因之一。保持相同的示例顺序不变；只有后续的用户任务会变化。
4. 将易变元数据移至末尾。 时间戳、请求ID、用户ID、A/B标志——这些都不属于缓存前缀之前的内容。将它们附加到最终用户消息的末尾。
5. 预分块长文档。 如果你每次调用都交换一个500K令牌的文档，该文档就不是可缓存的。决定一组规范块，通过ID引用它们，并保持请求间的顺序稳定。

关于提示结构更深入的讨论，请参阅。 DeepSeek prompt engineering。如果您要将此集成到检索管道中，该图显示了为缓存友好性放置检索块的位置。 DeepSeek RAG tutorial 启用方式

DeepSeek缓存与OpenAI和Anthropic（公司名）的比较

所有三个提供商都缓存提示前缀；区别在于你支付的费用、谁管理它以及缓存将接受的最小大小。

“自动+无写入成本”的组合使得DeepSeek缓存管理变得轻松。您无需付费填充缓存，也无需付费保持其活跃状态，且无需管理缓存键。代价是DeepSeek给予您的控制较少：没有OpenAI的路由提示或Anthropic（公司名）的手动断点等效功能。如果命中率看起来很低，唯一的解决方案是重新构建您的提示。对于API接口的更全面对比，请参阅 提示词缓存键 在系统提示中注入的时间戳，重新生成的工具模式JSON（键顺序已更改），在元数据中固定的不同模型版本——这些中的任何一项都会破坏前缀。 DeepSeek vs Claude and the DeepSeek API docs and guides.

您的命中率看起来低于预期的原因

• 前缀已更改。 如果您中途取消并重试，新的请求仍然会按照完整的匹配前缀价格计费——但下游的可观察性工具可能会错误报告。请参阅
• 前缀太短。 低于64个token将完全不缓存；低于约1,024个token，实际中命中不可靠。
• 缓存TTL已过期。 未使用的条目会在数小时到数天内被清除；低流量提示词会变冷。
• 你击中了错误的账户。 缓存按账户隔离。不同组织下的两个API密钥不共享缓存。
• 流式处理中响应失败。 一旦您认识到重复的前缀成本仅为新鲜前缀的五十分之一（在V4-Flash上低于2%的未命中率），一些之前不可行的模式变得可行： DeepSeek API error codes 重试语义的参考。

当缓存改变架构选择时

20K令牌的指令集曾经是浪费的。有了缓存，您只需支付一次，并在数千次调用中分摊成本。适用于合规性要求高的助手、拥有大型工具目录的代理以及特定领域的风格指南。

• 长系统提示。 A 20K-token instruction set used to be wasteful. With caching, you pay it in full once and amortise it across thousands of calls. Useful for compliance-heavy assistants, agents with large tool catalogues, and domain-specific style guides.
• 规模化下的少样本学习。 二十个上下文示例对于大量分类或提取来说在经济上是合理的。
• 仓库范围内的代码审查。 将代码库作为稳定的词首，只更改问题。V4的100万个token上下文窗口和384000个token输出上限，整个提示符都适合，只有尾部的问题在错误率下重新计费。
• 基于稳定语料库的RAG。 如果您检索到的片段来自一个小而缓慢的知识库，确定性排序可以让缓存吸收大部分输入成本。

关于这些模式在特定角色应用中的使用，请参阅。 DeepSeek for developers and the broader DeepSeek for coding 用例。

局限性和诚实警告

在围绕缓存进行架构设计之前需要考虑的三件事：

1. 尽力而为，不保证。 即使是相同的提示符偶尔也可能错过。为最坏的情况（所有内容都按错误计费）做好准备，并将缓存视为正面因素。
2. 不支持跨账户共享。 通过一个DeepSeek账户代理的多租户SaaS从跨租户缓存中受益；每个租户的API密钥则不然。
3. 输出不会被缓存。 相同的提示符，相同的温度≠相同的响应。如果您需要响应级别的缓存，请在自己的应用层中实现。

关于原始发布的额外阅读材料—— DeepSeek于2024年8月的公告 ——以及Simon Willison同时期的 技术撰写。 两者对于架构原理仍然有用，尽管自那时起比率已经改变。

DeepSeek AI Guide is an independent resource and is not affiliated with DeepSeek or its parent company. Model IDs, pricing and API behaviour change; check the official DeepSeek documentation and pricing page before committing to a production decision.