职贝云数AI新零售门户

标题: DeepSeek专题 | 1M 上下文为什么不能靠堆显存:从 DSA 到 CSA/HCA [打印本页]

作者: dyfowXijS 时间: 3 小时前
标题: DeepSeek专题 | 1M 上下文为什么不能靠堆显存:从 DSA 到 CSA/HCA

合适：懂 attention 基础的读者，约 9 分钟。DSA/CSA/HCA 本文保留英文简称。

长上下文最容易被曲解成一个窗口长度成绩：把 128K 扩到 1M，不就好了？

真正困难的地方在推理时。模型每生成一个新 token，都要从历史上下文里读取 KV cache。上下文越长，KV 越大；KV 越大，显存、带宽、调度、并发都会变成成本。

所以 V4 的关键不是“让 attention 看残缺 1M token”，而是改变“历史应该怎样被存、被筛、被读”。

(, 下载次数: 0)
从 DSA 说起：不是一切历史都值得看

DeepSeek Sparse Attention，也就是 DSA，可以先了解成一个两阶段流程。

第一阶段，用一个轻量 indexer 给历史 KV 打分，判别哪些地位和当前 query 更相关。

第二阶段，只对 top-k 的历史 KV 做真正 attention。

这相当于把“一切历史都参与主留意力计算”改成“先粗筛，再精读”。粗筛可以便宜一些，精读只发生在多数相关地位上。

但 DSA 依然要面对一个成绩：历史 token 数量本身太多。即便最终只选 top-k，indexer 也要在很长的历史上做挑选，KV cache 也要保存许多地位。
CSA：先紧缩，再稀疏选择

(, 下载次数: 0)

CSA 可以看作在 DSA 后面加了一步紧缩。

DSA 是从一切历史 token 里挑 top-k；CSA 是先把多个历史 token 压成一个摘要 KV，再从摘要 KV 里挑 top-k。

这个改动很关键。它不只减少了主 attention 要读的对象，也减少了需求长期管理的 KV 条目数量。

用直觉说，DSA 是在一整本书里找相关句子；CSA 是先把每几句压成一个小摘要，再从摘要里找相关段落。摘要当然会损失细节，所以 V4 还需求部分窗口留意力保留近处细节。

这就是 SWA 的地位：Sliding Window Attention 担任最近窗口里的精细依赖。最近 token 往往最重要，也最不能被粗糙摘要替代。
HCA：更狠的紧缩，但保留全局 dense attention

HCA，Heavily Compressed Attention，比 CSA 紧缩得更狠。

它异样把多个历史 token 压成 compressed KV entry，但紧缩跨度更大。紧缩后条目数量足够少，就可以在紧缩流上做 dense attention，而不是再 top-k 选择。

所以 HCA 的角色不是替代 CSA，而是补一个粗粒度全局视角。

CSA 更像“在全局历史里找几个相关区域”；HCA 更像“用很粗的地图看残缺世界”。前者更细，后者更全。SWA 则担任“脚边的部分细节”。

把三者放在一同，Hybrid Attention 的思绪就清楚了：

SWA 担任部分细节，CSA 担任较细的稀疏全局检索，HCA 担任高度紧缩后的全局读。

这不是为了让模型少了解一点上下文，而是为了让有限计算预算花在更有价值的地位上。
KV cache：长上下文服务的真实瓶颈

在很多短上下文场景里，我们讨论 attention 更关怀 FLOPs。但在 1M token 场景里，KV cache 本身就是系统成绩。

公开材料给出的一个重要数字是：在 1M-token 场景下，V4-Pro 的单 token 推理 FLOPs 和 KV cache 相比 DeepSeek-V3.2 有大幅下降；笔记里还提到，V4-Flash 会进一步降低这两项成本。

这不是某一个 trick 的结果，而是几个设计叠加：CSA/HCA 从序列维度紧缩 KV；KV 存储运用混合精度；indexer 途径运用更低精度；top-k 选择更小；服务层还引入异构 KV cache 和磁盘 KV cache。
为什么要区分 compressed KV cache 和 state cache

V4 的 cache 不再是一种外形。

compressed KV cache 存的是曾经完成紧缩的历史摘要，例如 CSA、HCA 产生的 compressed entries。

state cache 存的是短期形态：SWA 需求的最近窗口，以及还没凑够紧缩块的 tail tokens。

举个简化例子。假如 CSA 每 4 个 token 压成一个 compressed KV，如今只来了 2 个新 token，它们还不能立刻被紧缩，也不能丢掉，就要先放在 state cache 里。等后面又来了 2 个 token，凑够 4 个，再压成一个新的 compressed KV entry。

这也是为什么 V4 的推理服务比传统模型复杂：它要同时管理部分窗口、紧缩块、尾部 token、磁盘缓存和 prefix 命中恢复。
磁盘 KV cache：用存储换反复 prefill

企业场景里，很多央求会共享长前缀。比好像一个代码仓库、同一份法律文档、同一组历史会议记录，能够被不同用户反复发问。

假如每次都从头 prefill，一百万 token 的成本会非常高。磁盘 KV cache 的价值就是把共享 prefix 的计算结果保存上去，后续央求命中时直接恢复一部分形态。

但 SWA 又带来一个新选择：要不要把一切地位的部分窗口 KV 也存上去？

Full SWA caching 是全存，命中最快，但最耗存储。

Periodic checkpointing 是隔一段存一次，命中时从最近 checkpoint 重算一小段，存储和延迟折中。

Zero caching 是完全不存 SWA，命中后靠重算恢复部分形态，最省存储，但恢复最慢。

所以这三种策略本质是：Full 用存储换工夫，Periodic 在两者之间折中，Zero 用重算换存储。
一个缓存恢复例子：为什么 tail tokens 不能忽略

假设一个央求曾经处理了 1,000,000 个 token，系统把大部分历史都压成 CSA/HCA compressed entries，同时保留最近窗口给 SWA。

后续另一个央求命中了同一个长 prefix，但命中点不一定刚好落在紧缩块边界。它能够停在某个紧缩块中间，也能够只多出几个 tail tokens。

这些 tail tokens 的费事在于：它们还没凑够一个残缺紧缩块，但下一步生成又必须能看到它们。假如直接丢掉，模型会得到最近上下文；假如强行写入 compressed KV，紧缩规则又不残缺；假如每次都从很远处重算，延迟就会下去。

因此 state cache 的存在非常自然。它像一个暂时缓冲区，保存“还不能进入长期紧缩记忆，但马上会被用到”的短期形态。等 tail tokens 凑够紧缩块，再把它们转入 compressed KV cache。

这就是长上下文缓存和普通 KV cache 的区别：普通模型只需求问“后面的 KV 存在哪里”；V4 这类模型还要问“这段历史处于什么生命周期，是部分窗口、紧缩块、未完成 tail，还是可落盘 prefix”。
三个取舍：读得准、存得下、恢复快

CSA/HCA 的设计可以从三个取舍了解。

第一个取舍是读得准。模型需求从 1M token 里找到相关证据。假如紧缩太粗，能够丢失细节；假如 top-k 太小，能够漏掉远处信息；假如只看部分窗口，又会得到全局记忆。

第二个取舍是存得下。KV cache 规模大到一定程度后，不只是显存容量成绩，还会影响 batch 并发和 decode 带宽。紧缩序列维度、降低 KV 精度、引入磁盘 KV，都是为了让服务系统能承受。

第三个取舍是恢复快。真实服务里，很多央求不是从空上下文末尾，而是命中某个共享 prefix。命中后系统要疾速恢复 attention state。Full caching、Periodic checkpointing、Zero caching，其实就是在恢复速度和存储成本之间选点。

所以评价长上下文方案，不能只看“最大上下文长度”。更应该问：在这个长度下，单 token decode 成本是多少？KV cache 占多少？prefix 命中后恢复要重算多少？并发下降多少？这些才是服务化成绩。
小结

明天这篇文章的核心结论是：1M context 不是一个窗口参数，而是一套留意力紧缩和缓存管理成绩。

DSA 处理“不要看一切历史”；CSA 处理“历史地位太多，先紧缩再选择”；HCA 处理“需求一个低成本全局粗读”；SWA 处理“部分细节不能丢”；异构 KV cache 和磁盘 KV cache 处理“真实服务里怎样存、怎样恢复、怎样复用”。

下一篇，我们换一个角度：当模型用了 MoE，真正的瓶颈往往不是专家本身，而是 token 如何被送到专家、算完又如何回来。
参考材料

欢迎光临职贝云数AI新零售门户 (https://www.taojin168.com/cloud/)