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 缓存成本的三层结构显存、内存、存储把缓存账本拆开其实是三层成本在博弈。层级典型介质访问延迟单位成本适用数据热层显存微秒级极高当前活跃请求的 KV温层主机内存百微秒级中等近期可能复用的前缀 KV冷层本地 SSD毫秒级低历史会话、长文档缓存这三层的调度策略决定了你的百万上下文方案是“能用”还是“好用”。热层要尽量小只放当前正在生成的请求温层放那些短时间内可能被再次命中的前缀冷层放那些跨会话但仍有复用价值的长文档。很多团队一开始只做热层结果并发一上来就 OOM后来加了温层命中率上去了但内存又成了瓶颈最后把冷层接上才真正把成本压下来。3. Agent 场景下缓存复用才是真正的省钱开关3.1 Agent 的调用模式和普通对话完全不是一回事普通对话是一问一答上下文线性增长缓存复用主要靠多轮对话的前缀。Agent 不一样Agent 在一轮任务里可能会调用模型十几次甚至几十次每次调用都带着同一套系统提示、工具定义、历史步骤。如果每次都重新算 KV那成本会爆炸。我拿一个典型的 Agent 任务举例用户让 Agent 去查资料、写代码、跑测试、修 bug。这个流程里系统提示和工具描述大概占 3000 token历史步骤会随着任务推进不断累积最后可能到 5 万 token。如果每一步都重新计算完整 KV那 20 次调用就是 100 万 token 的重复计算量。但如果把系统提示和工具描述做成前缀缓存每次调用只计算新增的历史步骤实际计算量能降到原来的三分之一甚至更低。提示Agent 场景下前缀缓存的收益远大于普通对话因为系统提示和工具定义是高度稳定的复用率极高。3.2 前缀缓存怎么设计才能让命中率最大化前缀缓存的核心思路是把那些稳定不变的部分放在上下文最前面让缓存系统能够识别并复用。具体到 Agent我一般会按这个顺序组织上下文系统提示和角色定义放在最前面完全固定。工具定义和函数签名紧随其后尽量保持稳定。长期记忆和知识库摘要按会话维度组织。当前任务的历史步骤动态增长。当前轮的用户输入放在最后。这个顺序的好处是前两层几乎永远命中缓存第三层在同一个会话内命中率也很高只有第四层和第五层需要重新计算。实测下来这种组织方式能把缓存命中率做到 70% 以上首 token 延迟和计算成本都能明显下降。但这里有个坑很多框架默认会把动态内容插到前面比如把当前时间戳、随机 ID 放在系统提示里这会导致缓存完全失效。我踩过这个坑当时系统提示里带了一个会话 ID结果每次请求缓存都不命中排查了半天才发现是这个小字段在作怪。3.3 缓存失效的常见原因和排查思路缓存失效这件事排查起来其实有套路。我整理了一个速查表基本能覆盖 90% 的情况。现象可能原因排查方法命中率突然掉到 0前缀里有动态字段对比两次请求的完整 prompt命中率波动大上下文顺序不稳定检查工具定义是否每次重新排序首 token 延迟高缓存未生效或温层未命中查看缓存层日志和命中统计显存持续增长热层未及时释放检查请求结束后的缓存回收逻辑内存占用高温层缓存过多调整温层淘汰策略和 TTL我自己的经验是缓存问题八成出在 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 缓存命中率上不去先查这五个地方命中率上不去是最常见的问题我按排查优先级列一下前缀里是否有时间戳、随机 ID、会话 ID 这类动态字段。工具定义是否每次请求都重新排序或格式化。上下文分层是否清晰有没有把动态内容插到稳定段里。缓存声明是否正确服务端是否真的识别到了前缀。温层和冷层的 TTL 是否太短导致缓存还没复用就过期了。这五个地方查完基本能定位到问题。我遇到最多的是第一条和第二条尤其是工具定义排序很多框架默认用字典序但如果你手动改过顺序缓存就会失效。5.2 长上下文下的延迟抖动怎么处理百万上下文下延迟抖动是另一个头疼的问题。抖动通常来自冷层读取因为 SSD 的访问延迟比内存高一个数量级。处理办法有两个一是把冷层的预取做好根据任务模式提前把可能用到的缓存加载到温层二是对延迟敏感的任务强制走热层和温层不接受冷层回退。我在一个文档问答场景里试过预取策略根据用户的历史行为预测下一段可能引用的文档提前加载到温层。效果很明显P99 延迟从 6 秒降到了 2 秒以内。5.3 成本控制的几个反直觉经验最后分享几个反直觉的经验。第一缓存不是越多越好温层太大反而会拖慢调度因为淘汰和查找的开销上去了。第二不是所有请求都值得缓存短请求缓存收益很低反而占资源。第三缓存命中率不是唯一指标有时候命中率降一点但延迟和成本更好也是可以接受的。我自己的做法是先保证核心 Agent 任务的缓存命中率边缘任务可以放宽。这样整体资源利用率最高也不会为了追求命中率而牺牲体验。6. 百万上下文之后Agent 架构会怎么变百万上下文真正落地之后Agent 的架构其实会发生一些微妙的变化。以前我们习惯把长文档切块、做检索、再拼上下文现在可以直接把整份文档塞进去让模型自己找重点。这听起来很美好但前提是你的缓存方案能扛住。我观察到的一个趋势是Agent 的记忆层正在从“外部向量库”往“上下文缓存”迁移。向量库适合做粗筛但上下文缓存适合做精读。两者结合才是百万上下文时代的合理架构。另外缓存复用率会成为一个新的工程指标就像以前的 QPS 和 P99 一样。谁的缓存复用率高谁就能在同样的成本下跑更多任务。这个指标现在还没有统一标准但我觉得很快会成为 Agent 团队的标配。我在实际项目里的体会是百万上下文不是让你无脑塞数据而是让你重新思考什么该缓存、什么该丢弃、什么该预取。把这笔账算清楚Flash 的百万上下文才真正有价值。