开放权重 LLM 的提示词缓存：为什么效果全看服务商

使用闭源模型时，提示词缓存只有一套明确的约定。Claude 通过 cache_control 设置断点；OpenAI 和 Gemini 会在 token 数达到门槛后自动缓存；折扣也会公开，且相对稳定。看一页文档就够了。

开放权重模型不一样。同一个 Qwen 或 Llama checkpoint 可能由十几家服务商提供，缓存不是模型自身的属性，而是模型运行环境的属性。 为了说明差异有多大，我们实测了同一请求：通过一个多服务商 router，向同一个 Qwen 模型连续发送六次完全相同、约 4.7K token 的提示词，并且不固定上游。

模型、router、提示词都相同，账单却从 $0.0141 到 $0.000286，相差 49×。唯一的变量是 router 选了哪个上游，以及该上游是否已经缓存了这个前缀。

摘要

• 开放权重模型的提示词缓存取决于路由结果，而不是模型功能。 缓存由推理引擎免费、自动实现；上面的每一层既可能保留它，也可能让它失效。
• 五层架构中，一层提供缓存，三层可能破坏缓存。 模型（决定可缓存性，但不提供缓存）→ 推理引擎（免费提供缓存）→ 算力服务商（将其包装成产品，效果不一）→ gateway（跨集群路由）→ router（把请求分散到缓存互不相通的不同服务商）。
• 实测结果。 同一个请求被 router 分散后，某次调用的成本是另一次的 49×；同一个模型在一家服务商上获得了 59.6% 折扣，换一家则是 0%；各模型公开的缓存折扣从 0% 到约 98% 不等。
• 应对方法。 固定路由，让重复前缀命中同一个热缓存；通过成本差异审计缓存，不要只看 cached_tokens 字段，因为实际命中时它也经常是 0；延迟要单独评估，即使成本折扣约为 0%，热缓存 prefill 仍可快 2–10×。

实时数据于 2026-06-14 测得。测试对象包括一个多服务商 router 和我们自己的 gateway，使用固定的约 4.7K token 英文提示词、较小的 max_tokens，并按顺序执行。公开价格在同一天对照服务商一手文档核验，并进行了交叉验证。真正具有可比性的是比率，例如折扣比例和延迟变化；绝对金额会受渠道、提示词和负载影响。引用前请自行复现。

实际会遇到的缓存类型

先统一术语，再讨论整个技术栈。开放权重模型的托管服务主要有四种缓存形态，计费方式各不相同。

1. 自动前缀缓存（无需标记）。 这是最常见的模式。服务器对提示词前缀计算 hash；如果和之前的请求匹配，就复用 KV 状态并自动应用折扣。无需 cache_control，无需修改代码，而且通常无法关闭。DeepSeek、Zhipu GLM 和大多数开放权重模型服务商都采用这种方式。写入免费；缓存可能只在 VRAM 中保留几分钟，也可能保存到磁盘。DeepSeek 的前缀缓存会保留“数小时到数天”。

2. 显式断点缓存（cache_control）。 这是 Anthropic 采用的模式，少数开放权重模型服务商也支持。Alibaba Model Studio 允许在 Qwen 消息块中设置 "cache_control": {"type": "ephemeral"}；部分推理平台也提供了同类标记。你需要明确标出边界，支付额外的写入费用，换取更高的读取折扣。

3. 租用缓存对象（收取存储费）。 这类缓存需要格外留意。Moonshot 旧版 moonshot-v1 系列要求通过 POST /v1/caching 创建缓存，然后分别收取写入费、按 token 和分钟计算的存储费，以及每次命中的费用。Google 的显式 Gemini 缓存也是同一种模式：除输入费用外，还要支付存储费，约为每 1M token 每小时 $1.00–$4.50。缓存是需要租用并自行回收的资源。

4. 自托管 KV 复用（免费）。 自行运行模型权重时，推理引擎会自动、免费缓存。没有写入费、读取费和存储租金；命中后只是跳过 prefill。

Qwen 在 Model Studio 上同时提供自动和显式两种模式，两者需要明确取舍：隐式模式的命中费用为输入费用的 20%，写入免费；显式模式的命中费用为输入费用的 10%，但写入按 125% 收费，而且缓存条目的 TTL 只有 5 分钟。折扣更高，但首次填充需要付费，每次过期后重新填充还要再付一次。

缓存在技术栈中的位置

核心结论是：开放权重模型的提示词缓存只在一层真正得到解决，上面的每一层都可能让它失效。 从模型权重开始逐层向上看，每一层都要问两个问题：它是实际提供缓存，还是仅仅转发缓存？它会不会破坏下层已经实现的缓存？

  request
     |
     v
  +--------------------------------------------------+
  | L5  router             scatters across vendors   |  can break it
  | L4  gateway            multi-cluster routing     |  can break it
  | L3  compute host       uneven delivery           |  can break it
  |==================================================|
  | L2  inference engine   CACHING LIVES HERE, free  |  <-- the cache is born here
  |==================================================|
  | L1  model              cacheability: MLA / GQA   |  sets the ceiling
  +--------------------------------------------------+

  A cache hit is born at L2 and must survive L3-L5 routing to reach you;
  every layer above L2 is a chance to land where your prefix isn't.

第 1 层：模型决定可缓存性，但不提供缓存

很多人认为缓存来自模型本身，例如“DeepSeek 有缓存”，所以首先要把这个概念说清楚。checkpoint 只是一组权重。无论是否存在 KV cache，它执行的 attention 都一样。权重不附带缓存、折扣、TTL 或 cache_control 标记，这些都属于服务层功能。严格来说，权重本身不提供任何缓存产品。

但权重并非毫无影响，DeepSeek 正好说明了原因。模型的 attention 架构决定 KV cache 有多大，也就决定了缓存成本最低能降到什么程度：

• DeepSeek 的 Multi-head Latent Attention（MLA） 将 KV cache 压缩成低秩 latent，大小约为标准 multi-head cache 的 4–14%。正是这种压缩，让 DeepSeek API 可以把前缀持久化到磁盘，并将缓存读取价格降至输入价格的约 2%。架构提供了实现条件，磁盘缓存则是在此基础上构建的产品。
• Llama、Qwen、Mistral 和 DeepSeek 使用的 Grouped-Query Attention（GQA） 通过共享 KV head，按分组倍数缩小缓存。Llama-3 上约为 8×。

因此，第 1 层提供的是可缓存性，而不是缓存本身。架构决定上层最多能把缓存成本压低到什么程度，但权重自己不会提供任何缓存 token。“DeepSeek 有缓存”实际上把两个不同的东西混在了一起：一个是权重，也就是这一层提供的 MLA；另一个是 DeepSeek 的 API 和服务栈，即第 2–3 层提供的磁盘缓存、折扣和 usage 字段。下载开放权重并自行运行后，你仍然能获得 MLA 带来的小型 KV cache，但磁盘缓存产品仍留在 DeepSeek 的服务器上。你最终获得什么缓存能力，取决于自己部署的第 2 层。因此，运维上仍然不该问某个模型是否缓存，而应该问它在什么地方、以什么方式提供服务。不过，这不代表架构不重要：架构决定上限，请求路径决定实际结果。

第 2 层：推理引擎真正实现缓存，而且免费

再向上一层，缓存不仅已经存在，而且早已解决，并且免费。 现代推理引擎会自动缓存前缀：

• vLLM：Automatic Prefix Caching 会为每个 KV block 计算 hash，复用之前出现过相同前缀 hash 的 block，并通过 LRU 淘汰。V1 默认启用。
• SGLang：RadixAttention 把 KV cache 存储在 radix tree 中，任何共享前缀都能复用，同时支持 cache-aware scheduling。
• TensorRT-LLM：通过 block reuse（enable_block_reuse，默认启用）复用缓存，还可以选择把 KV block offload 到 host memory。

LMCache 等项目在此基础上继续扩展：将 KV offload 到 CPU 或磁盘，并在多个实例之间共享。这正是解决后续路由问题的起点。关键在于，如果采用自托管，缓存问题到这里就结束了。缓存自动工作，除了现有 GPU 成本外无需额外付费，通过 LRU 淘汰，而且归你自己控制。命中只会跳过 prefill，从而降低 TTFT、提高吞吐量。这里没有 cached_tokens 计费字段，因为根本不存在按 token 计费；收益直接体现在自己的延迟指标中。闭源模型的缓存需要租用，开放权重模型的缓存则可以完全掌握在自己手里。代价正好与托管服务相反：缓存是临时的，位于 VRAM 中并由 LRU 管理，所以只有当前缀持续保持热度时才能存活。上面的每一层都必须维持这种热度。

第 3 层：算力服务商将其产品化，但效果参差不齐

商业推理服务商会封装第 2 层，并运行由多个 replica 组成的集群。它们继承了免费、自动的缓存能力，问题在于能否把它稳定地交付给用户。实际差异主要体现在两个方面。

第一，能力暴露方式和价格差异很大。在主要的开放权重模型服务商中，有的对缓存输入统一打 5 折，并允许缓存 token 不计入 rate limit；有的 serverless 默认打 5 折；有的按模型分别为缓存输入定价，例如某个 Qwen 档位约打 2 折，同时提供 cache-key hint 来增强 affinity；还有的在 dedicated endpoint 上强制启用缓存，但不对外披露。底层推理引擎相同，定价策略却有四种。

第二，这也是缓存第一次会真正失效的地方：多 replica 问题。热前缀存在于处理冷请求的那个 replica 的 VRAM 中。服务商自己的 load balancer 可能把下一次请求转发到另一个缓存尚未预热的 replica。我们实际观察到了这种情况：每次固定到一个 Qwen 上游，依次执行冷请求和热请求：

服务商 A 正常命中缓存，并正确上报。服务商 B 虽然公开提供该模型的 cache-read 价格，但在我们的测试中，一次冷请求和两次热请求之间没有任何折扣。原因可能是请求不符合缓存条件、被分发到了不同 replica，或预热所需请求数超过两次。无论原因是什么，这条路径上的实测结果都是零。第 2 层已经具备缓存能力，用户能否真正获得它，则取决于第 3 层的具体实现，而且不同服务商差异明显。

第 4 层：gateway 的多集群问题

gateway 位于一个或多个上游之前，会把 replica 问题进一步放大成集群问题。如果 gateway 在缺少 cache affinity 的情况下，跨集群或服务商 round-robin 分发请求，那么热缓存实际上无法访问：每个请求都会落到没有该前缀的位置。支持缓存感知的 gateway 必须按前缀 hash 路由，让相同前缀持续落到同一个上游，就像第 2 层将其固定到相同 KV block 一样。无论是自行运维 LiteLLM 等软件，还是使用托管服务，这一点都成立；具体运维取舍可参考 LiteLLM 与托管 gateway 的对比。

我们通过第三方 gateway，对多个开放权重模型执行了一组冷请求和热请求测试，并直接读取每次请求返回的 cost：

DeepSeek-V4 的命中折扣达到 97–99%，说明 affinity 从头到尾都正常工作；qwen3.5-plus 和 qwen3-max 虽然在目录中标有 cache-read 价格，热请求的折扣仍约为 0%。这张表还反映了 gateway 层的两个问题：

• usage 字段可能不可靠，成本不会。 这里的所有请求中，cached_tokens 都是 0，包括成本下降 99% 的请求。许多兼容 OpenAI API 的 gateway 不会为自动缓存的上游填充缓存 token 字段。审计时应该比较冷请求和热请求之间的 cost 差异，而不是依赖 token 字段。这与审计 gateway 的缓存声明 是同一个道理。
• 即使成本不变，延迟也会改善。 所有热请求都快了 2–10×，其中 qwen3.5-flash 从 10.2s 降至 1.0s，包括那些折扣约为 0% 的请求。只要缓存命中，就能跳过 prefill，与服务商如何定价无关。因此，即使 gateway 完全不提供账单折扣，缓存仍能改善 TTFT。

不保留 affinity 的 gateway 会提供一个无法命中的缓存；不暴露缓存成本的 gateway 会提供一个无法验证的缓存。

第 5 层：router 在服务商之间随机分发

最上层的多服务商 router 会把同一个模型 ID 分发到不同公司的集群，而这些集群拥有彼此独立的缓存。此时，即使单个服务商内部的 affinity 完美无缺，也无济于事：第一次调用发给一家服务商，第二次发给另一家，就不可能命中共享缓存。本文开头的数据正是这种分散的结果，而且它进一步放大了第 4 层的问题：请求不仅跨多个集群，还跨越缓存状态和价格都互不相通的多个服务商。最贵的一次选择，其基础费率是最便宜上游的 20×。只有当路由碰巧连续落到同一个服务商时，缓存才开始生效。

解决方法是消除随机性。让路由保持确定性，使重复前缀始终落到同一个热缓存：

# Pin the upstream; otherwise load-balancing scatters you across disjoint caches.
# (field names follow a common multi-provider router's API)
import requests

requests.post(f"{ROUTER_BASE}/chat/completions",
  headers={"Authorization": f"Bearer {API_KEY}"},
  json={
    "model": "qwen/qwen3.5-35b-a3b",
    "messages": messages,
    "usage": {"include": True},              # return cost + cached_tokens
    "provider": {                            # the part that makes caching work
        "order": ["<your-chosen-upstream>"],
        "allow_fallbacks": False,
    },
  })

这家 router 确实正确上报了 cached_tokens，命中时为 4,224，同时还返回每次请求的 cost，所以两者都能验证。这比第 4 层中始终返回 0 的 gateway 更好，但路由约束仍然需要用户自行配置。**缓存本质上是一个披着定价功能外衣的路由问题：**第 2 层免费提供缓存，而第 3、4、5 层会以逐步升级的方式，把请求路由到无法命中的位置。

折扣到底有多大？没有统一标准

路由正确命中后，究竟能省多少钱？闭源模型的 cache-read 折扣大多接近 90%。开放权重模型公开的 cache-read 价格则从象征性折扣到接近免费不等，甚至同一家服务商的不同模型也差异很大。以下是一手公开价格：

DeepSeek 的自动磁盘缓存提供了目前最深的折扣。deepseek-v4-flash 的缓存输入读取价格是 $0.0028/M，未命中价格为 $0.14/M，比例为 1:50；我们在第 4 层测试中复现了 97.9% 的折扣。托管相同开放权重模型的第三方服务商会独立设置缓存输入价格：有些统一提供约 50% 折扣，有些按模型提供约 50% 到约 90% 的折扣。因此，最终折扣取决于请求落到哪家服务商，而不只取决于模型。同一个功能名称，折扣相差 48 个百分点。

折扣属于服务渠道属性，因此同一个模型在不同渠道上的缓存经济性也不同。以 deepseek-v4-pro 为例，有四种结果：

“DeepSeek-V4-Pro 支持缓存”虽然没错，但几乎没有实际参考价值。真正需要问的是：在哪里支持、折扣多少、如何上报。

决策清单

• ✅ 模型决定上限，但不提供缓存（第 1 层）。MLA、GQA 等 attention 架构决定缓存成本最低可以多低，但模型本身不会提供缓存 token。因此，仍要确认模型在哪里运行，以及服务商的技术栈如何处理缓存。
• ✅ 如果是自托管，缓存已经免费提供（第 2 层）。确认自动前缀缓存已启用，并监控前缀命中率。vLLM 和 SGLang 默认都会开启。
• ✅ 使用算力服务商时，要验证实际效果，而不是只看价格表（第 3 层）。cache-read 价格只是一项声明；需要实测冷请求和热请求的成本差异。如果服务商提供 cache-key affinity hint，就使用它。
• ✅ 通过 gateway 调用时，必须要求 cache-affinity 路由和成本上报（第 4 层）。如果相同前缀无法固定到同一个上游，或热请求的 cost 没有下降，缓存要么无法访问，要么无法验证。
• ✅ 使用 router 时，固定上游（第 5 层）。约束路由，例如指定服务商顺序并关闭 fallback。否则，load-balancing 会把请求分散到缓存互不相通的不同服务商，既丢失命中，还可能落到贵 20–50× 的上游。
• ✅ 延迟和成本分开评估。 即使金额折扣约为 0%，热缓存 prefill 仍可快 2–10×。
• ✅ 留意收取存储费的缓存类型。 租用型缓存，例如 Moonshot moonshot-v1 和 Gemini 显式缓存，会按 token 和存储时间对闲置缓存收费；自动前缀缓存不会。

结论

对于闭源模型，“是否支持缓存”通常只有一个答案。对于开放权重模型，推理引擎层早在多年前就解决了缓存问题：vLLM 和 SGLang 会自动、免费缓存每个前缀。上面的所有层都只是基础设施管道，可能保留命中，也可能把请求分散到无法命中的位置，包括算力服务商的 replica balancer、gateway 的集群路由，以及 router 在不同服务商之间的随机分发。模型架构决定缓存成本能降到多低，MLA 和 GQA 确实是模型层面的实质优势，但请求路径决定最终获得什么。应把缓存行为视为一种路由属性：在实际生产路径上按成本进行测量，固定路由，让后续请求命中已经预热的缓存。无论折扣多高，如果第二个请求落到第一个请求从未访问过的位置，都没有意义。

要了解 KV cache 为什么存在以及 TTL 如何工作，可先阅读 KV Cache 与 TTL 的工作原理；要审计 gateway 的缓存声明，可参考 你的 LLM Gateway 是否虚报缓存？。

常见问题

开放权重模型支持提示词缓存吗？ 权重决定缓存成本最低能降到什么程度。MLA 和 GQA 等 attention 架构可以缩小 KV cache，但缓存本身、折扣和 API 都来自服务栈。缓存由推理引擎实现，例如 vLLM、SGLang 和 TensorRT-LLM；算力服务商继承这项能力，gateway 和 router 再进行转发或分散。同一个 checkpoint 交给三家服务商，可能分别得到免费的自动缓存、完全没有缓存，或只能使用显式缓存。

为什么同一个模型的一次调用比另一次贵 49×？ 在多服务商 router 上，未固定上游的请求会通过 load-balancing 分发到不同服务商的集群。这些集群的基础价格不同，缓存状态也互不相通。一次调用可能冷启动命中了昂贵的服务商，另一次则热命中了便宜的服务商。固定上游，例如约束服务商顺序并关闭 fallback，才能同时控制这两个变量。

自托管时需要为缓存付费吗？ 不需要。vLLM、SGLang 和 TensorRT-LLM 默认启用自动前缀缓存，而且免费。命中后只会跳过 prefill。你只需支付原本就要承担的 GPU 成本，缓存归自己管理；需要释放 VRAM 时，由 LRU 淘汰。

API 显示 cached_tokens: 0，但账单下降了，缓存是否生效？ 很可能已经生效。许多 gateway 不会为自动缓存的上游填充 cached_tokens。应该以 cost 字段为准：如果冷请求和完全相同的热请求之间出现大幅成本下降，就说明命中了缓存。

哪种开放权重模型的缓存折扣最高？ DeepSeek 的自动磁盘缓存。deepseek-v4-flash 的缓存输入读取价格约为 $0.0028/M，未缓存价格为 $0.14/M，折扣约 98%。我们在 V4 系列的冷请求→热请求测试中复现了 97.9–99.2% 的折扣。许多第三方服务商只提供统一的约 50% 折扣。

收取存储费的缓存有什么风险？ Moonshot moonshot-v1 的显式缓存和 Gemini 显式缓存会按 token 和时间收取缓存保留费用，Gemini 约为每 1M token 每小时 $1–4.50。忘记删除的闲置缓存会持续产生费用。自动前缀缓存没有存储费。

验证说明：实时成本和延迟数据于 2026-06-14 测得。测试对象为一个多服务商 router 和我们自己的 gateway，使用固定的约 4.7K token 提示词、较小的 max_tokens，并按顺序执行冷请求→热请求；折扣根据每次请求返回的 cost 计算。公开价格和缓存机制在同一天对照服务商一手文档核验，并进行了交叉验证；部分服务商数据经常变动，尤其是 Moonshot 的显式缓存费用，引用前请确认最新值。实际结果会随服务商、提示词、地域和负载而变化。

来源

• DeepSeek — 价格
• DeepSeek — KV cache / 上下文缓存指南
• DeepSeek-V3 技术报告 — MLA（KV-cache 压缩）
• GQA：训练广义 Multi-Query Transformer 模型（Ainslie 等）
• Alibaba Cloud Model Studio — 上下文缓存与价格
• Moonshot AI — 上下文缓存
• Zhipu / Z.AI — 价格与缓存
• vLLM — 自动前缀缓存
• SGLang — RadixAttention / 缓存
• LMCache — KV cache offloading 与共享
• Google — Gemini 上下文缓存

全部核验于 2026-06-14。本文不构成财务建议；依赖相关价格前，请先确认当前定价。

← 返回博客