2026 年 9 月 8 日下午，DeepSeek 在官方交流群里放出了一个名为 deepseek-v4.1-flash-expires-on-0910 的临时端点。两天后官方正式上线，一边把 Flash 系列缓存命中的输入价格压低了约六成，一边宣布让 Flash 接管原先发往 V4 Pro 的请求。官方公告里摆出来的词依然是原生多模态、更强、更快、更便宜。粗看一眼，大家很容易以为这又是一场常规降价。

跟更新公告一起放出来的，是一份 51 页的英文技术报告，题目叫 Pushing the Limits of KV Cache Compression。整份报告没花篇幅渲染模型能力有多大跃迁，通篇都在扣着缓存压缩算细账。正文列出的几组对照数据交了底：全局 KV 缓存压缩到了上一代的约四分之一，持久化 KV 缓存缩减到约八分之一；从 4K 上下文一路拉到 100 万 token，跨度拉大到 256 倍，decode 阶段的计算量仅仅上浮了四分之一，整条计算曲线近乎走平。

一个 agent

的真实账单，钱花在哪

跑长时程任务的 agent 每执行一轮工具调用，前面攒下来的所有对话、代码文件和报错，系统就得整个重新读入一遍。模型每轮推理消耗的参数规模始终没变，随身携带的上下文历史却越滚越多。

为了省去每次从头解析长文本的力气，系统会把读过的每一段上下文换算成中间状态存下来，放进高速显存，这就是常驻的 KV 缓存。这份工作记忆省掉了大量重复的前向计算，账单却转嫁给了存储介质。高速显存单价昂贵而且空间有限，一旦存不下，系统就得把数据写进 SSD 或主机内存做落盘。下一轮工具调用返回结果，总线又得把数据重新搬回显存。占显存、落盘存储、总线搬运，这三处开销紧紧咬在了一起。

要是把 agent 放在长上下文环境里，这三重负担还会成倍放大。对话历史与运行日志只增不减，显存往往跑上几轮就会见底，落盘存储也从权宜之计变成了常态。只要会话中断后重开，或是缓存没命中需要重算，系统就得把这批数据重新取回、再算一遍。走到这一步，账单的压力重心悄悄转移到了如何把读过的内容存好、并在下一次调用中完整取回，模型推理计算本身的支出退到了后面。

因果链：agent 每轮工具调用都要重读历史，工作记忆随之变大，占显存、落盘、搬运三段成本叠加，账单重心从计算转向存储与搬运。

为什么算力不再是主战场

上一代 V4 重点对付的，正是长上下文带来的计算瓶颈。随着稀疏注意力机制铺开，模型不用再抓着整段文本逐字逐句计算，只要挑出关联紧密的局部上下文做前向传播，计算这一项的支出就大幅滑落。不过系统的瓶颈并没有凭空消失，只是换了位置。DeepSeek 在报告引言里直接给出了证据：前向算力开销降下来之后，真正把整体延迟与成本推高的，变成了持久化存储占用的容量以及机器总线搬运数据的耗时。

按 Amdahl 定律，只把系统里某一环做快，剩下的部分仍会拖住整体的提速。某一环压得越低，继续打磨它的边际回报就越小，瓶颈自然漂移到下一处。如今 decode 阶段的计算优化已经跨过了收益拐点，顺着老路继续抠算力很难再挤出成本空间。此前未曾深入压缩的高速显存容量、持久化磁盘开销以及节点间的互联带宽，眼下成了左右服务总成本的关键。

推理成本的较量就这样从算力侧滑向内存体系，算力优化退到次要位置。DeepSeek 这份报告里看似零散的工程取舍，无论是做层间共享还是切到低比特存储，全部顺着这条主线落在了显存容量、外存落盘与总线搬运的各个节点上。

对比面板：旧战场是算力，边际收益递减；新战场是内存，竞争落在存储与搬运。

压缩的三个乘数，以及为什么是这三个

缓存占多大地方，是一道很短的乘法题。单个条目占多少字节，整段序列切出多少个条目，还有多少层要各存一份。三个数乘起来，就是这份缓存的总体积。能下手的地方也只有这三处，动其中任何一个，省下的空间都会按比例反映到总量上。

条目这一维过去动得最多。GQA、MLA 这类做法让不同的注意力头共用一部分维度，把单个条目做小。这次的额外一笔落在精度上：主 KV 条目从上一代的 8 位精度换成 4 位，体积接近减半。这一步之所以安全，是因为 4 位格式只用在存储，缓存条目送进注意力计算之前会先还原成高精度浮点数。计算端不做低精度冒险，只在搬运和静置环节收缩体积，底层芯片也就不需要专用的低精度矩阵乘法单元，精度损失可以忽略。

序列这一维同样是旧账。把连续几个 token 合成一个条目，序列就短了，条目数随之下降，缓存方案名字里的压缩二字也由此而来。

真正没怎么动过的，是第三个数：层。以往每一层都各自维护一份全局 KV 缓存，可相邻几层抓取的全局视野高度重叠，里面全是重复。要消掉这些重复，先得判断哪些信息不能共享。报告把上下文拆成两半：精细的语言特征随网络深度层层变化，集中在局部的最近窗口，必须逐层各自保留；全局视野做的是粗粒度的检索定位，相邻层差异很小，允许跨层共用。整套压缩只针对全局分支，局部细节完整保留。

共用不等于白拿。假若每一层都套用同一份全局记忆，还只能盯着同一批位置，网络深度带来的分工就没了。报告用的是分组复用。前两层只做局部注意力；编码器其余 18 层分成三组，每组开头一层从头算出全局记忆，随后五层照用；解码器分成五组，每组开头一层要么从头算、要么重新挑一批注意力位置，随后三层把记忆和位置一并继承。真正从头计算的层很少，大部分层靠复用省下了重复存储。三个乘数一起收紧，才有了全局 KV 降到上一代约四分之一的结果。

另外两块资源：prefill

与持久化

除了显存常驻开销，跑长上下文还有两笔躲不开的硬账：处理海量输入消耗的预填充算力，以及多轮会话存盘所需的持久化存储。技术报告对这两块物理资源各自实施了定向重构。

Agent 的调用特征往往是反复重读长文本，但每次只吐出少量工具调用 token，大量计算资源因此耗在了预填充阶段。DeepSeek 把 40 层的网络平分为前半程的编码器与后半程的解码器。解码器所需的全局 KV 状态，直接由编码器末层的输出映射生成，不再跟随网络逐层反复推演。预填充阶段的计算负荷削减近半，形成了一套非对称参数结构：解析输入阶段每个 token 仅激活 8B 参数，进入逐字生成输出阶段才调用完整的 16B 参数。省下来的算力，恰好对准了 agent 在高频交互中最昂贵的那笔开销。

处理多轮交互的持久化存储，团队用了另一种工程取舍。以前为了在跨轮会话中复用状态，滑动窗口那部分 KV 缓存也得整块写进磁盘，占地方，也占带宽。测试数据显示，滑动窗口实际发挥检索效能的范围比理论设定更窄。报告据此取消了这部分滑动窗口缓存的物理落盘，后续唤醒会话只需通过轻度重放最近一个窗口的数据来完成近似重建。多花微量的局部重算时间，省去了大块落盘写入，持久化存储体积也跟着缩减到了上一代的约八分之一。

预填充算力省下近半、显存里的全局 KV 降到四分之一、外存持久化 KV 缩减至八分之一，三处改动分别给算力、显存与外存卸下了负荷。整套动作遵循着清晰的成本逻辑：先把服务开销摊到显存、算力和外存等具体物理维度，锁定特定负载下真正支配开销的核心项，再找出代价最低的结构冗余来对冲。

分层图：三块物理资源各有定点打击，预填充计算减半，显存里的全局 KV 降到四分之一，外存里的持久 KV 降到八分之一。

这对部署者意味着什么，以及报告没说的部分

这次线上发布伴随着明确的流量调度动作：DeepSeek 一边将缓存命中的输入单价最高下调约六成，一边宣布把流向 Pro 的请求整体切给 Flash、按 Flash 计费，让 Flash 接管绝大部分日常工作流。这份通知只提前了一天，也没留出新旧模型并行的迁移窗口，很快招来开发者的反对。按 V4 Pro 调好 Prompt 和生产流程的团队担心后台直接换模型会带偏原本稳定的任务，科研团队担心实验结果无法复现，也有人不满顶着 Pro 的名号返回 Flash 的结果。DeepSeek 随后调整了安排，把 Pro 的下线时间推到北京时间 9 月 14 日 12:00，届时才统一切到 Flash 并按 Flash 计费。这和技术报告体现的工程取舍一致，模型设计的重心正从单纯追求参数规模，转向对具体负载形态的精细匹配。Flash 的轻量化设计没有单纯扣减模型总参数，关键在于让激活参数与缓存机制去适配长输入、反复读取上下文的业务形态。

实际选型中的评估维度也跟着变了。比起追逐基准测试榜单上的分差，我们更需要先盘点自身业务的实际负载：长输入与短输出的比例处于什么水平，系统缓存的命中率能维持多高，以及会话是否需要频繁跨周期保存与重载。一个读多写少的自动化执行链路，和一个强调实时往复的人机对话系统，在这套物理开销公式下算出的最优解大不相同。

不过细看这些账面收益，证据链条上还有不少问号。前面提及的所有吞吐倍率与削减比例均出自 DeepSeek 官方技术报告，属于厂商自报数据，未经第三方独立复核；此前开放测试的也只是一个附带明确过期时限的临时端点。已有第三方实测观察到，模型的多模态理解有所提升，但在跑复杂逻辑任务的过程中，模型往往倾向于派生出大量子 agent，导致调用 token 总量激增，这与报告单次调用的成本下探并不等同。

报告原文并没有掩盖潜在的技术盲区。作者在文中承认几处激进设计引入了未决的性能边界：跨层复用可能带来位置选择偏差，舍弃落盘后单纯依赖重放窗口的近似重建，在极端长上下文场景下也存在性能劣化的风险，后续仍需针对长文本稀疏匹配和缓存恢复稳定性开展更多压测。报告还写明，现有公开基准测试大多趋于饱和，即便跑分相差无几，也不代表模型在复杂的高阶推理与长尾特例上真正追平了顶级闭源水平。

归拢这些工程实现与保留条件，V4.1 Flash 的重点在于把长上下文服务的账单逐项分摊清楚，并将优化的重心推向内存体系。这套思路在真实生产集群里究竟能省下多少成本，依然有待中立的第三方压测与复杂业务的长期检验。

这是同一系列的第一篇，讲服务侧的内存：模型推理时随身携带的 KV 缓存怎么被压小。另一篇转向容量侧，看静态知识本身如何被搬出 GPU，见《把知识搬出 GPU：DeepSeek Engram 与模型的第二条稀疏轴》。