开启左侧

DeepSeek专题 | 1M 上下文为什么不能靠堆显存:从 DSA 到 CSA/HCA

[复制链接]

适宜:懂 attention根底 的读者,约 9 分钟。DSA/CSA/HCA 原文保存英文简称。

少高低文最简单被歪曲成一个窗心少度成就:把 128K 扩到 1M,没有就行了?

真实艰难之处正在拉理时。模子每一天生一个新 token,皆要从汗青高低文里读与 KV cache。高低文越少,KV 越年夜;KV 越年夜,隐存、戴严、调理、并收城市酿成本钱。

以是 V4 的枢纽没有是“让 attention 瞅残破 1M token”,而是改动“汗青该当如何被存、被筛、被读”。

DeepSeek博题 | 1M 高低文为何不克不及靠堆隐存:从 DSA 到 CSA/HCAw2.jpg
从 DSA 提及:没有是统统汗青皆值患上瞅

DeepSeek Sparse Attention,也即是 DSA,能够先理解成一个二阶段过程。

第一阶段,用一个沉质 indexer 给汗青 KV 挨分,鉴别哪些职位战目前 query 更相干。

第两阶段,只对于 top-k 的汗青 KV 干真实 attention。

那相称于把“统统汗青皆到场主留神力计较”改为“先细筛,再粗读”。细筛能够自制一点儿,粗读只发作正在大都相干职位上。

但是 DSA仍然 要面临一个成就:汗青 token 数目自己太多。即使终极只选 top-k,indexer 也要正在很少的汗青上干选择,KV cache 也要保留很多职位。
CSA:先收缩,再稠密挑选

DeepSeek博题 | 1M 高低文为何不克不及靠堆隐存:从 DSA 到 CSA/HCAw3.jpg

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 怎样被收到大师、算完又怎样返来。
参照质料

    DeepSeek-V4-Pro Model Card:https://huggingface.co/deepseek-ai/DeepSeek-V4-ProTogether AI:Serving DeepSeek-V4:https://www.together.ai/blog/serving-deepseek-v4-why-million-token-context-is-an-inference-systems-problemvLLM Blog:DeepSeek V4 in vLLM:https://vllm.ai/blog/2026-04-24-deepseek-v4DeepSeek V4 Preview Release:https://api-docs.deepseek.com/news/news260424
您需要登录后才可以回帖 登录 | 立即注册 qq_login

本版积分规则

发布主题
阅读排行更多+
用专业创造成效
400-778-7781
周一至周五 9:00-18:00
意见反馈:server@mailiao.group
紧急联系:181-67184787
ftqrcode

扫一扫关注我们

Powered by 职贝云数A新零售门户 X3.5© 2004-2025 职贝云数 Inc.( 蜀ICP备2024104722号 )