开源权重 LLM 缓存：为何你的缓存是供应商轮盘赌

对于闭源模型，提示缓存是一份有据可查的契约。Claude 有 cache_control 断点；OpenAI 和 Gemini 在超过 token 下限后自动缓存；折扣公开且稳定。读一页文档就够了。

开源权重打破了这一假设。同一个 Qwen 或 Llama 检查点由十几家服务商提供，而缓存不是模型的属性——它是模型运行位置的属性。 为了说明这一点有多深远，这里有一个实测请求——通过一个多供应商路由器将完全相同的约 4.7K token 提示发送到同一个 Qwen 模型六次，未固定上游：

相同模型、相同路由器、相同提示：账单从 $0.0141 到 $0.000286——相差 49 倍——纯粹取决于路由器选择了哪个上游，以及该上游是否已预热前缀。

摘要

• 开源权重模型的提示缓存是路由结果，而非模型特性。 它在推理引擎中实现——免费且自动——然后被其上的每一层保留或破坏。
• 五层架构：一层提供缓存，三层可以破坏它。 模型（决定可缓存性，本身不提供缓存）→ 推理引擎（缓存，免费）→ 计算服务商（将其产品化，参差不齐）→ 网关（多集群路由）→ 路由器（将请求分散到缓存互不相通的各供应商）。
• 实测数据。 同一请求被路由器分散后，某次选择的费用比另一次高出 49 倍；对于同一模型，某服务商提供了 59.6% 的折扣，另一家则为 0%；各模型公布的缓存折扣范围从 0% 到约 98%。
• 应对措施。 固定路由，使重复前缀命中同一个已预热的缓存；通过费用差异而非 cached_tokens 字段来审计（该字段在真实命中时往往显示为 0）；将延迟单独考量——已预热的预填充速度快 2–10 倍，即便费用折扣接近 0%。

实时数据于 2026-06-14 在一个多供应商路由器和我们自己的网关上测量，使用固定的约 4.7K token 英文提示、较小的 max_tokens，顺序运行。文档化定价于同日对照各供应商主要文档核查，并经过对抗性交叉验证。比率（折扣百分比、延迟变化）是可移植的部分；绝对金额取决于服务商、你的提示和负载情况。引用前请自行复现。

你实际会遇到的缓存类型

在介绍技术栈之前，先统一术语。在开放权重托管服务中，存在四种截然不同的缓存形态，计费方式各有不同。

1. 自动前缀缓存（无需标记）。 最主流的模式。服务器对你的提示词前缀进行哈希，若与之前的请求匹配则复用 KV 状态，并自动应用折扣——无需 cache_control，无需修改代码，通常也无法禁用。DeepSeek、智谱 GLM 以及大多数开放权重托管服务均采用此方式。写入免费；缓存的生命周期从 VRAM（数分钟）到磁盘不等（DeepSeek 会将前缀保留”数小时至数天”）。

2. 显式断点缓存（cache_control）。 Anthropic 的方案，少数开放权重托管服务也提供此功能。阿里巴巴的模型服务灵积（Model Studio）支持在 Qwen 消息块上使用 "cache_control": {"type": "ephemeral"}；部分推理平台也提供等效的标记。你标记边界，支付写入附加费，换取更深的读取折扣。

3. 租用缓存对象（含存储费）。 值得重点关注。Moonshot 的旧版 moonshot-v1 系列要求你通过 POST /v1/caching 创建缓存，然后按写入费、每 token 每分钟的存储费以及每次命中费计费。Google 的 Gemini 显式缓存也是同样的思路——输入成本加上存储费，大约为每百万 token 每小时 $1.00–$4.50。缓存是一种你需要租用并主动进行垃圾回收的资源。

4. 自托管 KV 复用（免费）。 自行运行模型权重，推理引擎会自动免费进行缓存。无写入费、无读取费率、无存储租金——命中时直接跳过预填充（prefill）阶段。

Model Studio 上的 Qwen 同时提供自动和显式两种模式，二者存在真实的权衡：隐式模式命中时按输入的 20% 计费，写入免费；显式模式命中时按输入的 10% 计费，但写入时收取 125% 的费用，且缓存条目的有效期上限为 5 分钟的 TTL。折扣更深，但你需要为填充缓存付费，每次过期后还要再次付费。

缓存在技术栈中的位置

核心思想如下。开放权重模型的提示词缓存恰好在某一层得以实现，却在其上的每一层都面临被破坏的风险。 从权重层向上逐层审视，在每一层都要问：这一层是在提供缓存，还是仅仅在转发请求——以及它是否会破坏下层已经完成的缓存？

  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.

第一层 — 模型：可缓存性，而非缓存

这是大多数人认为缓存所在的层——“DeepSeek 有缓存”——因此也是第一个需要精确界定的层。一个检查点是一组权重；无论 KV 缓存是否存在，它运行的注意力机制都是相同的。它不附带任何缓存、折扣、TTL 或 cache_control 标记——这些都是服务层的特性。严格来说，权重本身不提供任何缓存产品。

但权重并非中立，DeepSeek 正是说明这一点的完美例子。模型的注意力架构决定了 KV 缓存的大小，从而决定了缓存的成本下限：

• DeepSeek 的**多头潜在注意力（MLA）**将 KV 缓存压缩为低秩潜在表示——大约是标准多头缓存的 4–14%。正是这种压缩使得 DeepSeek 的 API 能够将前缀持久化到磁盘，并将缓存读取定价为输入成本的约 2%。架构是使能者；磁盘缓存是构建于其上的产品。
• 分组查询注意力（GQA）——被 Llama、Qwen、Mistral 和 DeepSeek 所采用——通过共享 KV 头来按分组因子缩减缓存（Llama-3 上约为 8 倍）。

因此，第一层的贡献是可缓存性，而非缓存：架构设定了上层所能实现的缓存成本下限，但权重本身从不直接服务缓存的 token。而”DeepSeek 有缓存”这一说法悄然将两个不同的事物混为一谈——权重（本层，提供 MLA）和 DeepSeek 的 API 与服务栈（第 2–3 层，提供磁盘缓存、折扣和用量字段）。下载开放权重自行运行，你保留了 MLA 的小型 KV 缓存，但磁盘缓存产品仍留在 DeepSeek 的服务器上——你继承的是你自己部署的第 2 层。因此，操作层面的结论依然成立：不要问一个模型是否缓存，而要问它在哪里提供服务——只是不要因此误以为架构无关紧要。架构设定了上限；部署路径决定了你实际能得到什么。

第二层 — 推理引擎：缓存的构建之处，且免费

再往上一层，缓存不仅存在——它已被解决，且免费。 现代推理引擎会自动缓存前缀：

• vLLM — 自动前缀缓存：对每个 KV 块进行哈希，复用任何已见过前缀哈希的块，按 LRU 策略淘汰。在 V1 中默认开启。
• SGLang — RadixAttention：将 KV 缓存存储在基数树中，使任何共享前缀都能被复用，并支持缓存感知调度。
• TensorRT-LLM — 块复用（enable_block_reuse，默认开启），可选将 KV 块卸载到主机内存。

LMCache 等项目进一步扩展了这一能力——将 KV 卸载到 CPU/磁盘，并跨实例共享，这正是解决我们即将面临的路由问题的雏形。关键在于：如果你自托管，那就大功告成了。缓存是自动的，除了你已经运行的 GPU 之外不产生任何额外成本，按 LRU 淘汰，且归你所有——命中时直接跳过预填充，降低 TTFT，提升吞吐量。不存在 cached_tokens 计费字段，因为没有任何东西被计费；收益体现在你自己的延迟指标中。对于闭源模型，你租用缓存；对于开源模型，你可以完全拥有它。代价与托管世界恰好相反：缓存是短暂的（VRAM，LRU），因此只有在前缀保持热状态时才能存活——而这正是上层必须维护的东西。

第三层——计算主机：将其产品化，但参差不齐

商业推理主机封装了第二层并运行副本集群。它们继承了免费的自动缓存——问题在于是否实现得好，而答案在两个维度上都喜忧参半。

首先，暴露方式和定价差异悬殊。在主要的开放权重主机中：有的对缓存输入统一打五折，并允许缓存命中的 token 跳过速率限制；有的在无服务器模式下默认打五折；有的按模型对缓存输入单独定价（例如某 Qwen 层级约打两折），并暴露缓存键提示以提升亲和性；还有的在专用端点上始终开启缓存且无法关闭。底层引擎相同，却有四种定价哲学。

其次——这也是缓存失效的第一个场景——多副本问题。你的热前缀存在于处理冷请求的那一个副本的显存中。主机自身的负载均衡器可能将你的下一个请求路由到另一个缓存为冷的副本。我们亲历了这一情况：将同一 Qwen 模型每次固定到单个上游，并执行冷→热测试：

提供商 A 缓存干净，并如实上报。提供商 B——其宣传了该模型的缓存读取价格——在我们的测试中，经历一次冷调用和两次热调用后，始终未获任何折扣。无论原因是资格限制、副本扇出，还是需要超过两次请求才能预热，该路径上的实测结果为零。这一能力在第二层已得到解决；你是否真正受益，则是第三层的执行细节，因主机而异。

第四层 — 网关：多集群问题

网关位于一个或多个上游服务之前，将副本问题放大为集群问题。如果网关在集群或提供商之间轮询请求，而不保持缓存亲和性，那么已预热的缓存在结构上将变得不可达——每个请求都会落到一个没有对应前缀的节点上。具备缓存感知能力的网关必须按前缀哈希进行路由，使相同的前缀始终粘连到同一上游，就像第二层将其粘连到相同 KV 块一样。

我们在一个第三方网关上针对开放权重模型进行了冷→热的全量测试，直接读取每个请求的 cost 字段：

DeepSeek-V4 达到了 97–99% 的折扣（亲和性端到端生效）；qwen3.5-plus 和 qwen3-max 在预热调用中返回约 0% 的折扣，尽管其价目表中列有缓存读取价格。这张表还隐藏着两条网关层面的经验教训：

• usage 字段会说谎，cost 字段不会。 在这里的每一次调用中，cached_tokens 读取值均为 0，即便是那些成本下降 99% 的请求也不例外。许多兼容 OpenAI 的网关不会为自动缓存的上游填充缓存 token 字段。应通过冷热调用之间的 cost 差值来审计，而非依赖 token 字段——这与审计网关缓存声明的经验如出一辙。
• 即使成本没有降低，延迟也会改善。 每次预热调用的速度都提升了 2–10 倍——qwen3.5-flash 从 10.2s 降至 1.0s——包括那些折扣约为 0% 的请求。缓存命中会跳过预填充阶段，无论服务商如何定价，因此即使账单上没有任何体现，缓存在 TTFT 方面仍然能带来收益。

一个不保持亲和性的网关会给你一个无法触达的缓存；一个不透出缓存成本的网关会给你一个无法验证的缓存。

第 5 层 — 路由器：跨提供商的随机分发

在最顶层，一个多提供商路由器将同一个模型 ID 的负载均衡到不同公司的集群上——每个集群拥有独立的缓存。此时即便在单个提供商内部实现了完美的亲和性也无济于事：如果第 1 次调用路由到某个厂商，第 2 次路由到另一个厂商，就不存在可以命中的共享缓存。这正是本文开头所描述的分散问题，它与第 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,
    },
  })

值得肯定的是，该路由器确实上报了 cached_tokens（命中时为 4,224）以及每次请求的 cost，因此两者都可以验证——这比第 4 层那个读数为 0 的网关要好。但路由约束需要你自己来设置。缓存本质上是一个被包装成定价功能的路由问题： 缓存在第 2 层是免费的，而第 3、4、5 层则是三种不断升级的方式，让你把自己路由到缓存之外。

折扣力度有多大？差异悬殊

当路由确实对齐时，能节省多少？对于闭源模型，缓存读取折扣集中在 90% 左右。对于开源权重模型，即便在同一厂商的产品线内，公开的缓存读取价格也从象征性优惠到近乎全免不等。以下是各家官方公布的费率：

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）决定了缓存能有多便宜，但它本身从不提供缓存 token——因此仍需关注请求在哪里被处理，以及该宿主机的技术栈是什么。
• ✅ 自托管？你已经免费拥有它（第 2 层）。确认自动前缀缓存已开启（vLLM/SGLang 默认开启），并监控你的前缀命中率。
• ✅ 在计算宿主机上，验证交付情况，而非价格栏（第 3 层）。缓存读取价格只是一个声明；请实际测量冷启动→热启动的成本差值。在宿主机支持的情况下，使用缓存键亲和性提示。
• ✅ 通过网关时，要求缓存亲和性路由和成本报告（第 4 层）。如果相同的前缀无法固定到同一个上游，或者热调用时 cost 没有下降，则缓存不可达或无法验证。
• ✅ 在路由器上，固定上游（第 5 层）。限制路由策略（例如设置带回退禁用的 provider-order 字段），否则负载均衡会将请求分散到不相交的缓存中，导致命中率归零——还可能触发成本高出 20–50 倍的上游。
• ✅ 将延迟与成本分开衡量。 即使价格折扣接近 0，热预填充的速度也能快 2–10 倍。
• ✅ 留意按存储费计费的缓存类型。 租用型缓存（Moonshot moonshot-v1、Gemini 显式缓存）会按 token 时间对空闲缓存计费；自动前缀缓存则不会。

结论

对于闭源模型，“它会缓存吗？“只有一个答案。对于开放权重模型，这一能力在数年前就已在推理引擎层得到解决——vLLM 和 SGLang 会自动、免费地缓存所有前缀。在此之上的一切都是管道问题，这些管道要么保留了缓存命中，要么将你从中分散开去：计算宿主机的副本均衡器、网关的集群路由、路由器在多个供应商之间的随机分发。模型架构决定了缓存能有多便宜的上限——MLA 和 GQA 是真实的、模型层面的优化——但请求所经过的路径决定了你实际能获得什么。请将缓存行为视为一种路由属性——在你实际运行的路径上以成本维度来衡量它，固定路由以确保你命中的缓存正是你预热过的那个，并记住：如果第二个请求落到了第一个请求从未触及的地方，世界上最深的折扣也毫无价值。

关于 KV 缓存存在的原理以及 TTL 的工作方式，请从 KV 缓存与 TTL 的工作原理 开始阅读；若要审计网关的缓存声明，请参阅 你的 LLM 网关在缓存问题上撒谎了吗？。

常见问题

开放权重模型支持提示词缓存吗？ 权重决定了缓存能有多便宜——MLA 和 GQA 等注意力架构会压缩 KV 缓存——但缓存本身、折扣以及 API 均来自推理服务栈。缓存在推理引擎（vLLM、SGLang、TensorRT-LLM）中实现，由计算主机继承，再由网关和路由器转发（或分散）。将同一个检查点部署到三台主机，你可能获得免费的自动缓存、完全没有缓存，或仅支持显式缓存。

为什么同一个模型在两次调用中的费用相差 49 倍？ 在多提供商路由器上，未固定的请求会被负载均衡到不同供应商的集群，这些集群有不同的基础价格和互不相交的缓存状态。一次调用命中了价格昂贵且缓存为冷的提供商，另一次则命中了价格便宜且缓存为热的提供商。固定上游（限制提供商顺序，关闭回退）可以同时控制这两个因素。

如果我自托管，需要为缓存付费吗？ 不需要。vLLM、SGLang 和 TensorRT-LLM 中的自动前缀缓存默认开启且免费——命中缓存只是跳过预填充阶段。你只需为已有的 GPU 付费，缓存归你所有，在 VRAM 不足时按 LRU 策略驱逐。

API 返回 cached_tokens: 0，但账单下降了——缓存生效了吗？ 很可能是的。许多网关不会为自动缓存的上游填充 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 约 $1–4.50 / 百万 token / 小时）。忘记删除的闲置缓存会持续计费。自动前缀缓存不收取存储费。

验证说明：实时费用/延迟数据于 2026-06-14 针对多提供商路由器及我们自有网关进行测量，使用约 4,700 token 的固定提示词、较小的 max_tokens，按顺序执行冷→热调用；折扣根据每次请求返回的 cost 计算。文档定价及缓存机制已于同日对照各提供商主要文档进行核查，并经过对抗性交叉验证；部分供应商数据（尤其是 Moonshot 的显式缓存费用）变动频繁——引用前请确认当前值。实际数据因提供商、提示词、地区和负载不同而有所差异。

参考资料

• DeepSeek — 定价
• DeepSeek — KV 缓存 / 上下文缓存指南
• DeepSeek-V3 技术报告 — MLA（KV 缓存压缩）
• GQA: Training Generalized Multi-Query Transformer Models（Ainslie 等）
• 阿里云模型服务灵积 — 上下文缓存与定价
• Moonshot AI — 上下文缓存
• Zhipu / Z.AI — 定价与缓存
• vLLM — 自动前缀缓存
• SGLang — RadixAttention / 缓存
• LMCache — KV 缓存卸载与共享
• Google — Gemini 上下文缓存

所有链接均于 2026-06-14 核查。本文不构成财务建议；使用前请自行核实当前定价。

← 返回博客