核心主张：长上下文的瓶颈从来不是显存不够，而是算法效率太低。DeepSeek-V4 通过"序列维度压缩"重新定义了这场竞争的规则。适读人群：大模型架构师、Infra 工程师、需要处理长文档的应用开发者阅读时长：约 20 分钟核心收益：透彻理解 CSA/HCA 的设计动机与工程权衡，建立长上下文方案选型的判断框架一、一个被误解了很久的问题业界通常把"长上下文难"归结为硬件问题：显存不够、算力不足、多卡并行太复杂。这个判断只说对了一半。DeepSeek-V4 给出了反例：同样的 1M Token 上下文，V4-Pro 的 KV Cache 只有传统 Transformer 的10%，V4-Flash 更低至7%。这不是靠更大的显存卡，而是靠一套不同的压缩逻辑。这意味着什么？意味着同样的硬件，不同的算法，可以得到截然不同的结果。"堆显存"是一种选择，"重新设计算法"是另一种选择，DeepSeek 选了后者。理解这个选择背后的逻辑，是本文要做的事情。二、诅咒的根源：平方复杂度从哪里来要理解 V4 的创新，必须先把"诅咒"说清楚。传统 Transformer 的注意力机制，每个 Token 在推理时都需要查询所有历史 Token 的键值对（KV）。序列长度为 N，KV Cache 就要存 N 份向量，计算量正比于 N²。数字化这个代价：假设隐藏维度 4096、BF16 精度，1M Token 的 KV Cache 需要约16GB显存。一张 A100 有 80GB，扣除模型参数和激活值的 40GB 左右，剩余不足以单卡承载 1M 上下文——不是"吃力"，是"装不进去"。这就是为什么大多数模型卡在 128K-256K 窗口。不是不想做更长，是显存先到头了。序列长度KV Cache（BF16 GQA8）单卡是否可承载128K~2GB✅ 可承载256K~4GB✅ 可承载512K~8GB⚠️ 接近极限1M~16GB❌ 超出容量业界的常规解法是横向扩展：多卡并行、更大显存的芯片、张量并行。这些方法有效，但代价是运维复杂度线性增长，成本指数上升。DeepSeek 的路径是纵向突破：从算法层面减少需要存储和计算的量。三、两代架构的分叉点理解 V4 的创新，需要先看 V3 做了什么，以及 V3 没解决什么。V3/MLA：压薄特征向量DeepSeek-V3 的多头潜在注意力（MLA）思路是：压缩每个 Token 的特征向量维度。把每个 Token 的 KV 向量从高维度通过低秩分解压缩到更低维度，存储时用"压缩码"，计算时再还原。效果是每个 Token 占用的显存减少了。但序列长度 N 没变。100 万个"瘦身版"KV，还是 100 万个计算单位。平方复杂度的诅咒依然存在，只是系数变小了。V4 的问题意识：能不能减少 Token 的数量？V4 的设计者换了一个提问方式：既然平方增长来自序列长度，为什么不直接压缩序列长度本身？把 N 个 Token 聚合成 N/m 个"超级 Token"，计算量就从 O(N²) 变成 O((N/m)²)，当 m=128 时，计算量缩减到原来的 1/16384。这是一次范式层面的转移——从"压薄特征"到"减短序列"。┌──────────────────────────────────────────────────┐ │ 压缩维度 vs 压缩序列 │ ├────────────┬─────────────┬───────────────────────┤ │ │ V3 (MLA) │ V4 (CSA+HCA) │ ├────────────┼─────────────┼───────────────────────┤ │ 压缩对象 │ 特征维度 │ 序列长度 │ │ 序列长度 │ N（不变） │ N/m（减少） │ │ 复杂度 │ O(N²) │ O((N/m)²) │ │ 1M KV占用 │ ~100% │ 10%（Pro）/7%（Flash）│ └────────────┴─────────────┴───────────────────────┘代价是什么？压缩必然有信息损失。把 128 个 Token 压缩成 1 个，细节会丢失。这是 V4 的核心工程挑战：如何在激进压缩的同时，保住足够的语义质量。后面三节回答这个问题。四、双轨压缩：CSA 与 HCA 解决不同尺度的问题V4 没有用单一的压缩策略，而是用两种压缩率截然不同的机制处理不同尺度的信息需求。