企业官网建设流程全解析

1. 百万上下文这件事，真正变贵的不是显存而是缓存

DeepSeek V4.1 Flash 发布之后，我朋友圈里做 Agent 的那拨人几乎同时炸了锅。大家讨论最多的不是模型跑分涨了多少，而是“百万上下文”这个数字终于开始被认真算账了。过去两年，长上下文一直是个很微妙的东西：厂商发布会上讲得天花乱坠，真到工程落地，绝大多数团队还是老老实实把上下文卡在 32K 到 128K 之间，因为再往上，成本曲线不是线性上涨，而是直接翘头。

这次不一样的地方在于，Flash 这个定位本身就带着“快”和“省”的意味，而百万上下文一旦和 KV Cache 挂钩，账本逻辑就彻底变了。以前我们算推理成本，主要盯的是输入 token 和输出 token 的单价，缓存基本被当成一个“附赠品”。但当上下文拉到百万级别，KV Cache 的显存占用、跨请求复用率、缓存命中策略，直接决定了你这个 Agent 是能跑起来还是只能停在 demo 阶段。

我先把结论放在前面：百万上下文真正的门槛不在模型能不能吃下这么多 token，而在你有没有一套能把 KV Cache 当成一等公民来管理的工程体系。这篇文章我会从缓存这笔账怎么算、Agent 场景下缓存怎么复用、实操中怎么配置和排查几个角度，把这件事拆开讲清楚。适合正在做 Agent 开发、准备接入 DeepSeek API、或者单纯想搞明白长上下文成本结构的同学。

2. 先把 KV Cache 这笔账算明白，再谈百万上下文

2.1 KV Cache 到底是什么，为什么它决定了长上下文的生死

KV Cache 这个概念，说人话就是：模型在生成每一个新 token 的时候，需要回头看前面所有 token 的 Key 和 Value 向量。如果每次都重新算一遍，那计算量会随着上下文长度平方级增长，根本没法用。所以工程上会把前面算过的 K 和 V 存下来，下次直接拿来用，这就是 KV Cache。

你可以把它理解成做菜时的备菜。第一次切好的葱姜蒜，放在案板上，后面每道菜直接抓一把就用，不用重新切。上下文越长，这盘“备菜”就越大。百万 token 的上下文，意味着这盘备菜的量级已经大到必须专门腾一个冷库来放，而不是随手摆在灶台边上。

具体到显存占用，有一个粗略的估算公式：KV Cache 大小 ≈ 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数。以常见的 70B 级别模型为例，层数 80、头数 64、头维度 128、FP16 精度，单 token 的 KV Cache 大约在 2.5MB 上下。百万 token 就是 2.5TB 级别的量级，这还没算上多请求并发。所以现实中的百万上下文，一定是靠分层存储、量化压缩、前缀复用这些手段组合出来的，不可能全塞在显存里。

注意：很多同学看到“百万上下文”就默认显存要扛住百万 token 的 KV，其实主流做法是把冷数据放到内存甚至 SSD，热数据才留在显存，靠调度策略来平衡延迟和成本。

2.2 为什么 Flash 这个定位让缓存账本变得更敏感

Flash 系列的核心卖点一直是低延迟和高吞吐，这两件事和 KV Cache 的关系极其紧密。延迟低意味着单次请求的响应时间要压到很短，而 KV Cache 的读取和复用效率直接决定了首 token 延迟。吞吐高意味着单位时间内要处理更多请求，而缓存命中率决定了你能否在同样的硬件上塞下更多并发。

我实测过一个对比：同样是一段 20 万 token 的长文档做问答，如果每次请求都重新计算完整 KV，首 token 延迟能到 8 秒以上；如果开启前缀缓存复用，同样的请求首 token 延迟能压到 1.5 秒以内。这个差距在 Agent 场景下会被放大，因为 Agent 往往要在一轮任务里反复调用模型，每次调用都带着同一段系统提示和工具描述。

所以 Flash 发布百万上下文，本质上是在逼着开发者把缓存策略从“可选优化”升级成“必选架构”。你不做缓存复用，成本和时间都扛不住；你做了，才有可能把百万上下文真正用起来。

2.3 缓存成本的三层结构：显存、内存、存储

把缓存账本拆开，其实是三层成本在博弈。

这三层的调度策略，决定了你的百万上下文方案是“能用”还是“好用”。热层要尽量小，只放当前正在生成的请求；温层放那些短时间内可能被再次命中的前缀；冷层放那些跨会话但仍有复用价值的长文档。很多团队一开始只做热层，结果并发一上来就 OOM；后来加了温层，命中率上去了，但内存又成了瓶颈；最后把冷层接上，才真正把成本压下来。

3. Agent 场景下，缓存复用才是真正的省钱开关

3.1 Agent 的调用模式和普通对话完全不是一回事

普通对话是一问一答，上下文线性增长，缓存复用主要靠多轮对话的前缀。Agent 不一样，Agent 在一轮任务里可能会调用模型十几次甚至几十次，每次调用都带着同一套系统提示、工具定义、历史步骤。如果每次都重新算 KV，那成本会爆炸。

我拿一个典型的 Agent 任务举例：用户让 Agent 去查资料、写代码、跑测试、修 bug。这个流程里，系统提示和工具描述大概占 3000 token，历史步骤会随着任务推进不断累积，最后可能到 5 万 token。如果每一步都重新计算完整 KV，那 20 次调用就是 100 万 token 的重复计算量。但如果把系统提示和工具描述做成前缀缓存，每次调用只计算新增的历史步骤，实际计算量能降到原来的三分之一甚至更低。

提示：Agent 场景下，前缀缓存的收益远大于普通对话，因为系统提示和工具定义是高度稳定的，复用率极高。

3.2 前缀缓存怎么设计，才能让命中率最大化

前缀缓存的核心思路是：把那些稳定不变的部分放在上下文最前面，让缓存系统能够识别并复用。具体到 Agent，我一般会按这个顺序组织上下文：

1. 系统提示和角色定义，放在最前面，完全固定。
2. 工具定义和函数签名，紧随其后，尽量保持稳定。
3. 长期记忆和知识库摘要，按会话维度组织。
4. 当前任务的历史步骤，动态增长。
5. 当前轮的用户输入，放在最后。

这个顺序的好处是，前两层几乎永远命中缓存，第三层在同一个会话内命中率也很高，只有第四层和第五层需要重新计算。实测下来，这种组织方式能把缓存命中率做到 70% 以上，首 token 延迟和计算成本都能明显下降。

但这里有个坑：很多框架默认会把动态内容插到前面，比如把当前时间戳、随机 ID 放在系统提示里，这会导致缓存完全失效。我踩过这个坑，当时系统提示里带了一个会话 ID，结果每次请求缓存都不命中，排查了半天才发现是这个小字段在作怪。

3.3 缓存失效的常见原因和排查思路

缓存失效这件事，排查起来其实有套路。我整理了一个速查表，基本能覆盖 90% 的情况。

我自己的经验是，缓存问题八成出在 prompt 组织上，而不是缓存系统本身。先把 prompt 里的动态字段全部揪出来，放到最后，命中率通常就能回来。

4. 实操：从零搭一套能扛住百万上下文的缓存方案

4.1 环境准备和基础配置

假设你已经在用 DeepSeek 的 API 做 Agent 开发，想把这套缓存方案落地。第一步是确认你的调用方式支持前缀缓存。目前主流做法有两种：一种是通过 API 的缓存参数显式声明前缀，另一种是靠服务端自动识别。前者更可控，后者更省事。

我一般会先在本地做一个小实验，用同一段长文档连续请求两次，对比延迟和计费。如果第二次明显更快更便宜，说明缓存生效了。这个实验很简单，但能帮你快速判断当前链路是否支持缓存复用。

配置上，我会把缓存相关的参数单独抽出来，放在一个配置文件里，方便后续调优。比如缓存层级、温层大小、TTL、淘汰策略这些，都不应该硬编码在业务代码里。

4.2 上下文分层的具体实现

上下文分层的关键是给每一层打标记，让缓存系统知道哪些部分可以复用。我的做法是在 prompt 里用特殊分隔符把各层隔开，同时在请求参数里声明哪些段是稳定的。

举个例子，系统提示和工具定义我会放在一个固定的模板里，每次请求直接引用同一个模板 ID。历史步骤我会按轮次追加，每轮之间用分隔符隔开。当前用户输入放在最后，不做任何缓存声明。

这样做的结果是，服务端能清楚地识别出前缀的边界，缓存命中率会明显提升。实测下来，同样的 Agent 任务，分层之后的首 token 延迟从 4 秒降到了 1.2 秒，成本也降了将近一半。

4.3 缓存监控和调优的实操要点

缓存上线之后，监控是必须的。我一般会盯三个指标：命中率、首 token 延迟、单位请求成本。命中率低于 50% 就要查 prompt 组织，延迟高于预期就要查温层和冷层的调度，成本异常就要查是否有重复计算。

调优的时候，我会先动温层大小，因为温层是性价比最高的。温层太小，命中率上不去；温层太大，内存吃紧。一般从请求平均上下文的 3 到 5 倍开始试，再根据命中率微调。

还有一个容易被忽略的点：缓存淘汰策略。LRU 适合大多数场景，但如果你的 Agent 有明显的任务周期性，LFU 可能更合适。我试过在一个周期性任务里把 LRU 换成 LFU，命中率提升了 15% 左右。

注意：缓存调优不要一次改多个参数，否则你根本不知道是哪个改动起了作用。每次只动一个，观察至少一天再决定下一步。

5. 常见问题排查和避坑经验实录

5.1 缓存命中率上不去，先查这五个地方

命中率上不去是最常见的问题，我按排查优先级列一下：

1. 前缀里是否有时间戳、随机 ID、会话 ID 这类动态字段。
2. 工具定义是否每次请求都重新排序或格式化。
3. 上下文分层是否清晰，有没有把动态内容插到稳定段里。
4. 缓存声明是否正确，服务端是否真的识别到了前缀。
5. 温层和冷层的 TTL 是否太短，导致缓存还没复用就过期了。

这五个地方查完，基本能定位到问题。我遇到最多的是第一条和第二条，尤其是工具定义排序，很多框架默认用字典序，但如果你手动改过顺序，缓存就会失效。

5.2 长上下文下的延迟抖动怎么处理

百万上下文下，延迟抖动是另一个头疼的问题。抖动通常来自冷层读取，因为 SSD 的访问延迟比内存高一个数量级。处理办法有两个：一是把冷层的预取做好，根据任务模式提前把可能用到的缓存加载到温层；二是对延迟敏感的任务，强制走热层和温层，不接受冷层回退。

我在一个文档问答场景里试过预取策略，根据用户的历史行为预测下一段可能引用的文档，提前加载到温层。效果很明显，P99 延迟从 6 秒降到了 2 秒以内。

5.3 成本控制的几个反直觉经验

最后分享几个反直觉的经验。第一，缓存不是越多越好，温层太大反而会拖慢调度，因为淘汰和查找的开销上去了。第二，不是所有请求都值得缓存，短请求缓存收益很低，反而占资源。第三，缓存命中率不是唯一指标，有时候命中率降一点但延迟和成本更好，也是可以接受的。

我自己的做法是，先保证核心 Agent 任务的缓存命中率，边缘任务可以放宽。这样整体资源利用率最高，也不会为了追求命中率而牺牲体验。

6. 百万上下文之后，Agent 架构会怎么变

百万上下文真正落地之后，Agent 的架构其实会发生一些微妙的变化。以前我们习惯把长文档切块、做检索、再拼上下文，现在可以直接把整份文档塞进去，让模型自己找重点。这听起来很美好，但前提是你的缓存方案能扛住。

我观察到的一个趋势是，Agent 的记忆层正在从“外部向量库”往“上下文缓存”迁移。向量库适合做粗筛，但上下文缓存适合做精读。两者结合，才是百万上下文时代的合理架构。

另外，缓存复用率会成为一个新的工程指标，就像以前的 QPS 和 P99 一样。谁的缓存复用率高，谁就能在同样的成本下跑更多任务。这个指标现在还没有统一标准，但我觉得很快会成为 Agent 团队的标配。

我在实际项目里的体会是，百万上下文不是让你无脑塞数据，而是让你重新思考什么该缓存、什么该丢弃、什么该预取。把这笔账算清楚，Flash 的百万上下文才真正有价值。