文章总结： DeepSeekV4通过CSA和HCA层实现128:1的KVCache压缩，使1Mtoken上下文内存占用从83.9GiB降至9.62GiB。这导致AgentHarness范式转变：长上下文廉价化使FullHistory架构可行，RAG职责纯化为外部知识接入，工具调用可靠性需通过关键信息锚定机制保障。推理系统需采用压缩感知的内存分桶管理和对齐压缩边界的PrefixCache，kernel融合成为必备门槛。 综合评分： 87 文章分类： 技术标准,解决方案,AI安全,安全工具,其他

DeepSeek V4 的 KV Cache 革命：当推理架构变了，Agent Harness 怎么跟着变

i3eg1nner&林00 i3eg1nner&林00

SecureNexusLab

2026年4月27日 18:00 江西

在小说阅读器读本章

去阅读

❝

这不是一篇关于跑分的文章。 这是一篇关于“模型记忆的本质变了之后，围绕它构建的工程框架该往哪走”的文章。

❞

背景：两个数字说清楚问题

在 1M token 上下文下：

• DeepSeek V3.2 的 KV Cache：「83.9 GiB」
• DeepSeek V4 Pro 的 KV Cache：「9.62 GiB」

节省约 「8.7 倍」。如果用 fp8/fp4 混合精度，实际部署中再砍一半。

这不是工程优化，是架构级别的重新设计。理解它为什么能做到这一点，是理解后续所有工程影响的前提。

Agent Harness 的范式转变

Agent Harness 的影响更深——因为它不只是性能问题，而是关于“模型记忆语义变了之后，框架的职责边界该怎么重新划定”。

1M context 廉价化：上下文管理策略的地基动摇

现有 agent harness 里大量的复杂性，来自于对 context window 稀缺性的应对：

• Sliding memory（summarize and forget）
• RAG 作为 context 的廉价替代品
• Tool call 结果的截断策略
• 多轮对话的 message pruning

这些机制，本质上是在有限的窗口里做信息的取舍决策。V4 让 1M token 的 context 在同等硬件成本下变得可持续维护，「“主动遗忘”的工程必要性大幅降低」。

「“Full History by Default”架构会出现」，并且是更可靠的选择。把完整历史塞进去，不做截断——去掉了 summarizer / compressor 这一层引入噪声的环节。简单不是懒惰，是去除了一个系统性误差源。

「RAG 的定位会发生分化」。RAG 存在有两个动机：context 不够用、以及需要实时或外部知识。第一个动机在长上下文模型面前逐渐消退，RAG 模块会更纯粹地只承担“外部知识接入”的职责，不再兼任“context 压缩”的角色。这两个职责的混同，是当前很多 RAG 工程混乱的根源之一。

有损压缩状态：信任边界的重新划定

这是更根本的挑战，也是最容易被忽视的。

V4 的 KV Cache 不是“精确记住了所有内容然后压缩存储”。HCA 层的 128:1 压缩是「加权求和」——信息在压缩时就已经被有选择性地稀释了。这与 context window 截断的性质截然不同：截断是在 token 边界硬切，你知道丢了什么；压缩是加权平均之后的模糊，你不知道哪些细节被消解了。

「Reddit 社区中已有人指出」：V4 的 HCA 在信息论上与 RWKV / Mamba / RetNet 等 SSM 模型属于同一类权衡——都是用固定大小的有界状态摘要历史，区别只在于 position-conditional retrieval 的保真度。V4 Pro 在长上下文“人工分析”任务上的表现差距，可能不只是训练不足的问题，而是架构召回保真度的边界。

这对 agent harness 的意义：

「工具调用结果的可靠性假设需要重新审视」。现有 harness 的一个基础假设是：把 tool call 返回结果放进 context，模型后续可以精确引用它。在全量 KV 的模型里这基本成立。在 HCA 压缩路径下，几万 token 之前的结构化数据（精确数字、代码片段、API 返回的 JSON）已经被压缩到极少的 bit 里，保真度不确定。

「Harness 需要引入“关键信息锚定”机制」：在每个关键决策点，把重要的工具返回结果在靠近当前位置重新注入 context，而不是只依赖远端历史。这不是简单的重复，而是一种 harness 层的“状态续航”策略。

「状态追踪的责任从模型侧转移到 harness 侧」。以前 harness 信任模型“记得”前面发生了什么，最多做 prompt 层面的提示。V4 架构下，harness 需要更主动地维护关键状态的 ground truth——不是让模型去“回忆”，而是在关键决策节点把必要状态显式注入。这把 harness 的设计职责从“记录者”推向了“状态机”。

「可解释性和审计变难」。以前出了问题，翻 context 就能看到模型“看到”的所有信息，逻辑链路是清晰的。有损压缩引入了一个不透明的信息漏斗，某些错误的根因可能是“远端信息被压缩稀释了”，但 harness 层无法直接观测这一点。「Logging 策略需要从记录 token 序列升级为在执行图的关键检查点保存结构化状态快照」。

长任务执行范式：从“切割外化”到“单次 Rollout”

V4 之前，长任务 agent 的主流模式是：把长任务拆成短任务，每个短任务在新的短 context 里执行，用外部状态（数据库、文件）串联。这是在 context 稀缺下的合理工程选择。

V4 之后，单次 Rollout 到底变得可行：agent 从任务开始到结束都在同一个 context 里执行，不切割，不做外部状态传递。对 harness 意味着：

• 「执行图粒度变粗」：多上下文协调的复杂度降为单上下文监控。
• 「约束管理难度上升」：长 rollout 下目标漂移的风险积累。Harness 需要更强的动态约束注入能力——在关键节点插入提醒、已完成子目标摘要、边界条件重申。
• 「评测复现性问题加剧」：单次长 rollout 的随机性积累效应强，相同初始 prompt 的两次运行可能在几千 token 后完全分叉。评测 harness 需要引入「轨迹级别的确定性控制」——固定 seed、mock 工具返回值、对执行轨迹做结构化 diff 而不只是最终输出 diff。

    团队成员进行IoT漏挖测试时发现，命中缓存命中极高，总花费个位数

【DeepSeekv4 Pro的缓存命中效果】

【DeepSeek v4 Flash的缓存命中效果】

V4 做了什么

从 MLA 到 CSA + HCA：压缩逻辑的代际跃迁

要理解 V4，先要理解它的前代。

「DeepSeek V3 / V3.1」 使用 MLA（Multi-head Latent Attention）。MLA 的核心思路是低秩压缩：不存储每个 head 的完整 KV，而是存储一个共享的低维 latent 向量，推理时再解压回多头。每 token 每层需要存储：

ounter(line(kv_lora_rank=512 + qk_rope_head_dim=64) × FP16 = 1152 字节

注意：64 维的 RoPE 分量是“解耦”存储在 512 维 latent 之外的——这是 MLA 的关键设计，让 latent 保持旋转无关，位置信息单独携带。两者是相加不是相减。61 层 × 1M token ≈ 「68.6 GiB」。

「DeepSeek V3.2」 在 MLA 基础上引入了 DSA（DeepSeek Sparse Attention）和 Lightning Indexer。Indexer 需要额外存储每 token 128 字节的索引缓存，使 KV Cache 反而上涨到 「83.9 GiB」。DSA 降低了计算量，但增加了存储开销——这个看似矛盾的结果，是为了后来 V4 的架构铺路的。

「DeepSeek V4」 引入了两种全新的 Attention 层：

「CSA（Compressed Sparse Attention）」：V4 Pro 有 30 个 CSA 层。核心操作是把相邻的 「8 个原始 token 做加权求和，压缩成 1 个」，步长为 4（即 c4a，4x 压缩），再对压缩后的 token 做稀疏 attention。每 token 每层：

ounter(line(512 + 128) × FP16 ÷ 4 = 320 字节

「HCA（Hyper-Compressed Attention）」：V4 Pro 有 31 个 HCA 层。压缩比更极端——「128 个原始 token 压缩成 1 个」（c128a，128x 压缩）。每 token 每层：

ounter(line512 × FP16 ÷ 128 = 8 字节

合并计算：(320×30 + 8×31) × 1M token ≈ 9.62 GiB。

除此之外，V4 还叠加了两个机制保证效果：

• 「K/V 共享」：Key 和 Value 向量合并，节省约 2x 内存。但共享后 attention 输出会混入绝对位置信息，需要在输出后施加**逆 RoPE（inverse RoPE）**操作来恢复平移不变性。
• 「短滑动窗口（SWA=128）」：c128a 层存在一个问题——当前 token 无法 attend 到任何压缩 token（因果性约束），会丢失局部信息。128 token 的滑动窗口作用于未压缩的原始 token，保证近端局部信息的可访问性。

关键数字汇总

| 模型 | 1M token KV Cache (BF16) | 相对 V3.2 节省 | KV 占参数比 | | — | — | — | — | | V3 / V3.1 (671B) | 68.6 GiB | — | 5.11% | | V3.2 (671B) | 83.9 GiB | — | 6.25% | | 「V4 Flash (285B)」 | 「6.72 GiB」 | 「12.5x」 | 「1.18%」 | | 「V4 Pro (1600B)」 | 「9.62 GiB」 | 「8.7x」 | 「0.30%」 |

「V4 Pro 有 1600B 参数，却只用了比 Flash 多 43% 的 KV Cache。」 这是因为 KV Cache 大小主要由层数决定（Flash 43 层，Pro 61 层），与 MoE expert 数量无关。

推理系统（Inference Harness）的工程变化

理解了架构，再看它给推理系统带来的工程挑战。

内存管理：从均匀分配到分桶感知

传统 transformer 每层 KV Cache 结构相同，内存分配器只需管理一种页面大小。V4 在同一模型里混有三种 attention 类型（c4a / c128a / SWA），物理 block 大小各异。如果为每种类型独立建池，跨池碎片化会严重侵蚀显存利用率。

vLLM 的解法提供了一个可复用的范式：

「统一逻辑块大小」：固定以 「256 个原始 token 位置」为逻辑块单位。c4a 块物理上存 64 个压缩条目，c128a 块存 2 个。分配时始终以“256 原始位置”为单位，消除了针对不同压缩比分支处理的必要性。

「分桶内存池」：通过仔细选择 block_size × compress_ratio × per_entry_size 的组合，让五种不同类型的 Cache（c4a 主 KV、c128a 主 KV、c4a compressor state、c128a compressor state、SWA KV）归并为 「三个页面大小分桶」，每个 bucket 在 load time 一次性分配，无运行时重分区。

这个设计的本质是：「把模型拓扑的异构性在 load time 静态消化，让运行时的分配路径保持简单」。未来支持混合 attention 架构的推理系统，都需要类似的“压缩拓扑感知”内存规划器，而不只是读 num_layers 和 head_dim。

Prefix Cache：边界语义的重构

V4 的压缩器有滚动残差状态（c4a 需要 8 token 的 overlap，c128a 需要 128 token）。如果 cache hit 的边界不与压缩步长对齐，残差状态就是错的，需要重算，命中优势被完全抵消。

vLLM 的解法是把 compressor state 注册在滑动窗口 KV Cache 规范下，sliding_window = coef × compress_ratio（c4a 为 8，c128a 为 128）。这样 Prefix Cache、P/D 分离、CUDA Graph 等功能可以无缝复用同一套抽象，无需为 compressor 单独实现一套状态管理路径。

结论是：「Prefix Cache 的 key 不再是纯 token hash，而需要在压缩边界上对齐」。Radix Tree / PagedAttention 的 block 边界必须感知压缩语义，否则命中后的 partial replay 代价会侵蚀收益。

Kernel 层：Fusion 从优化变成门槛

未融合版本的性能差距最高达 「10-20x」，这已不是“优化空间”而是“可用性门槛”。vLLM 部署了三组关键融合：

• 「压缩器 + RMSNorm + RoPE + Cache 插入」 → 1.4–3x 提速
• 「逆 RoPE + fp8 量化」 → 2–3x 提速
• 「Q Norm + KV RoPE + K 插入（warpID 横向融合）」 → 「10–20x 提速」

多流并行（indexer stream / main stream 解耦执行）在低 batch size 下带来 5–6% 的端到端延迟下降。

这意味着：「未来支持混合压缩模型的 harness 需要在模型加载时根据 attention 配置动态生成 fused kernel，而不是手工编写。Kernel Fusion 正在从运维选项变成框架层的编译器 pass。」

长期趋势——Transformer Harness 向 SSM Harness 靠拢

这是最值得关注的方向，也是目前讨论最少的。

V4 的 HCA 层（128:1 压缩）本质上是一个「有界状态」：它不保留全量历史，而是用固定大小的压缩表示摘要过去。如果 KV Cache 实质上是一个摘要状态，那么它可以像 RNN hidden state 一样被序列化、存储、恢复——这为「超长期对话持久化」打开了工程上的可能性，不依赖完整 KV replay。

Transformer-only harness 和 SSM harness 的边界正在模糊。未来的通用推理引擎需要同时处理三种内存语义：

1. 「全量 KV」（精确，贵）
2. 「压缩 KV」（有损，廉价）
3. 「Recurrent state」（有界，最廉价）

这三种语义在 V4 的模型里实际上已经共存了。Harness 需要对每种语义有不同的信任模型、不同的状态管理策略、不同的审计方式。

「评测框架也需要跟上」。RULER、NIAH 等现有长上下文 benchmark 是在全量 KV 假设下设计的，测的是“能不能找到针”。但对于有损压缩的模型，更关键的问题是“压缩后的遗忘模式是什么”——哪类信息容易被稀释（精确数字、低频词、结构化嵌套），哪类信息相对稳定（高频语义、段落主题）。这需要新的 benchmark 设计。

结语：一条核心矛盾线

把所有内容整合成一句话：

❝

「模型侧的“记忆”变得更廉价但更模糊；harness 侧的“状态管理”必须对应地变得更精确但更轻量。」

❞

旧的平衡点是：模型精确记忆，harness 粗放管理（反正 context 里有）。新的平衡点是：模型廉价但有损，harness 在关键节点做精确的状态锚定，其余时间退出管理，让模型自由处理长历史。

这推动 agent harness 向「稀疏干预、密集观测」的设计方向演化——平时不打扰模型，在状态转换点（工具调用、决策分支、错误恢复）精确注入和记录，形成可审计的执行骨架。其余的上下文流动，交给模型的有损压缩自己处理。

DeepSeek 做了一件很深刻的事：他们不是在做“更大的 context window”，而是在重新定义“模型能记住什么”这件事本身。围绕这个重新定义，工程框架需要从头想清楚自己的职责边界。

参考资料：

• vLLM Blog: DeepSeek V4 in vLLM: Efficient Long-context Attention (2026-04-24)
• Reddit r/LocalLLaMA: The exact KV cache usage of DeepSeek V4
• DeepSeek V4 Technical Report

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：SecureNexusLab i3eg1nner&林00 i3eg1nner&林00《DeepSeek V4 的 KV Cache 革命：当推理架构变了，Agent Harness 怎么跟着变》