在大语言模型落地部署的实际场景中，推理延迟与显存占用是制约长上下文能力的关键瓶颈。当上下文长度扩展至百万量级时，传统 Multi-Head Attention（MHA）架构的 KV 缓存将占用数十吉字节显存，注意力计算的二次复杂度更是让单次推理耗时难以接受。DeepSeek V4 作为最新一代模型，在架构层面引入了创新的注意力机制设计，通过 KV 缓存动态压缩与注意力计算剪枝两大核心策略，在保持模型性能的前提下实现了显著延迟降低。本文将从技术原理出发，结合 vLLM 推理引擎的工程实现细节，系统阐述这一优化方案的核心要点与落地参数。
KV 缓存压缩：从线性增长到多级压缩
DeepSeek V4 面临的首要挑战是 KV 缓存随上下文长度线性增长带来的显存压力。即使采用 DeepSeek 系列标志性的 Multi-Head Latent Attention（MLA）架构，相比标准 MHA 已有显著内存节省，但在百万 Token 上下文场景下，61 层模型累计的 KV 缓存仍然高达约 83.9 吉字节（以 BF16 精度计算），这已经超出绝大多数 GPU 的显存容量。为此，DeepSeek V4 设计了一套多级 KV 缓存压缩机制，核心思路是将多个连续 Token 的 Key 和 Value 向量合并为单一的压缩表示，从而在物理层面减少缓存条目数量。
具体而言，DeepSeek V4 提供了两种压缩策略供不同层选用。第一种称为 c4a，其压缩比约为四分之一，即每 8 个未压缩 Token 通过加权求和合并为 1 个压缩 Token，步长为 4。按照官方实现，第 i 个压缩 Token 对应位置范围 [4*i, 4*i+7] 内的原始 Token，RoPE 位置编码应用在压缩 Token 的锚点位置 4*i。这种设计使得 1 百万 Token 的序列在经过 c4a 压缩后仅需约 25 万个压缩条目，显存占用随之下降约四分之三。
第二种压缩策略 c128a 更为激进，压缩比达到约 128 分之一。每个压缩 Token 由 128 个连续未压缩 Token 加权求和构成，步长为 128。官方默认配置中，c4a 的 k 值设为 512，c128a 的 k 值设为 8192，这意味着经过 c128a 压缩后，1 百万 Token 序列仅产生不到 8 千个压缩条目。从数学上看，8 千个 Token 的全量注意力计算是完全可行的，这为后续的稀疏注意力优化提供了良好的计算规模基础。
值得注意的是，KV 缓存压缩引入了新的技术挑战：当 Key 和 Value 向量被共享时，直接应用标准注意力公式会导致输出携带绝对位置信息，破坏注意力机制的平移不变性。DeepSeek V4 的解决方案是在注意力输出后额外施加一次逆 RoPE（Inverse RoPE）操作，从而抵消绝对位置编码的影响，使输出重新回归相对位置信息的表达。这一设计在 vLLM 实现中体现为压缩后 K 向量立即经过 RMSNorm、RoPE 变换并插入 KV 缓存的融合 kernel 设计。
注意力计算剪枝：稀疏注意力与局部窗口
压缩 KV 缓存解决了显存瓶颈，但注意力计算的二次复杂度问题仍然存在。即便经过 c128a 压缩后仅剩 8 千个压缩条目，在深层 transformer 的逐层推理中，累计的计算量仍然相当可观。DeepSeek V4 引入 DeepSeek Sparse Attention（DSA）机制，对压缩后的注意力计算进行剪枝，仅保留与当前查询最相关的少量 Key-Value 对。
DSA 的核心思想是通过可学习的稀疏模式或固定的局部窗口来筛选关键注意力连接。在 DeepSeek V4 的实现中，稀疏注意力与 KV 压缩形成互补：对于采用 c4a 压缩的层，注意力计算在约 25 万个压缩 Token 上进行稀疏采样；对于采用 c128a 压缩的层，由于压缩后的有效 Token 数量已经降至约 8 千，可以直接进行全量注意力计算而无需额外稀疏化。实际部署中，DeepSeek V4 的 61 层模型采用混合策略，约 30 层使用 c4a 压缩以保留更多细粒度信息，约 31 层使用 c128a 压缩以最大化计算效率。
除了压缩路径上的稀疏注意力，DeepSeek V4 还保留了一个不参与压缩的滑动窗口路径。该窗口大小固定为 128 个 Token，专门用于捕获局部上下文信息。之所以需要这个局部窗口，是因为经过 c128a 压缩后，距离当前查询较近的 Token 会被排除在压缩表示之外（因果注意力约束导致压缩 Token 无法包含未来位置的信息），而滑动窗口允许查询直接访问未压缩的局部 Token，确保模型不会丢失关键的位置邻近信息。这一设计在 vLLM 的实现中被建模为 Sliding Window Attention（SWA），与压缩路径并行运行。
综合以上设计，DeepSeek V4 在 1 百万 Token 上下文下的 KV 缓存占用（BF16 精度）约为 9.62 吉字节，相比 DeepSeek V3.2 风格的同规模模型节省了约 8.7 倍。更进一步，vLLM 实现中对索引器缓存采用 FP4 精度、对注意力缓存采用 FP8 精度，相比 BF16 基线还能额外节省约 2 倍显存，使得实际部署中的缓存压力进一步降低。
工程实现：vLLM 的优化策略
从算法设计到实际部署，DeepSeek V4 的高效推理离不开 vLLM 推理引擎的深度优化。vLLM 团队针对新注意力机制的特性，在内存管理与核心计算两个维度进行了系统性的工程适配。
在内存管理方面，首要挑战在于异构缓存类型的统一调度。不同层级分别使用 c4a、c128a 和纯 SWA 三种不同的注意力模式，对应的压缩比从 4 倍到 128 倍不等，如果为每种缓存类型单独设计物理布局，将导致严重的碎片化。vLLM 的解决方案是将所有层的逻辑块大小统一固定为 256 个原生 Token 位置，然后根据各层的压缩比计算物理块的实际容量。例如，c4a 模式下每个物理块包含 256/4=64 个压缩条目，c128a 模式下每个物理块包含 256/128=2 个压缩条目。这种设计使得槽位映射、调度统计和前缀缓存检索都可以使用统一的单位，无需针对不同压缩比进行分支判断。
压缩器状态的存储是另一个关键设计点。c4a 压缩需要维护一个 8 Token 的滚动残差状态，c128a 需要维护 128 Token 的滚动残差状态。vLLM 创新性地将压缩器状态视为滑动窗口 KV 缓存进行管理，使用相同的抽象接口处理状态推进、缓存命中和预填充 - 解码解聚传输。这一设计使得前缀缓存、解聚服务和 CUDA Graphs 等现有功能可以无缝复用到压缩路径上，避免了引入独立的状态管理链路。
在核心计算方面，vLLM 通过 Kernel Fusion（内核融合）与 Multi-Stream（多流并行）两大技术提升 GPU 利用率。Kernel Fusion 的核心思想是将多个连续的 Element-wise 操作合并到单个 CUDA Kernel 中执行，从而减少显存读写次数。实际部署中主要应用三处融合：第一处是压缩后 K 向量的 RMSNorm、RoPE 和缓存插入操作，融合后相比未融合基线获得约 1.4 至 3 倍加速；第二处是注意力输出的逆 RoPE 与 FP8 量化矩阵乘法操作，融合后获得约 2 至 3 倍加速；第三处是查询归一化、KV RoPE 和 K 缓存插入的融合，通过静态 WarpID 调度实现 10 至 20 倍的加速提升。这些融合操作的共同特点是参与计算的 tensor 维度兼容且计算模式以 Element-wise 为主，为编译器手动融合提供了良好的优化空间。
Multi-Stream 并行则针对注意力计算前的三个独立分支进行计算重叠：索引器计算、主 KV 压缩和滑动窗口 Token 插入。在 c128a 层，索引器不存在，主 KV 压缩与 SWA Token 插入可以并行执行；在 c4a 层，完整的索引器流水线在独立 CUDA 流上与主压缩和 SWA 插入并行运行。实际测试表明，多流优化在低批量大小下可降低端到端延迟约 5% 至 6%，表明 GPU 在推理路径上的空闲时间得到了有效利用。
落地参数与配置建议
基于上述技术原理，针对不同的部署场景与硬件条件，以下给出可操作的配置参数建议。
对于显存受限的消费级 GPU 部署（如单卡 RTX 4090），建议优先考虑 DeepSeek-V4-Flash（285B 参数）模型，并启用 c128a 压缩模式以最大化显存节省。KV 缓存精度建议设为 FP8（通过 --kv-cache-dtype fp8 参数），块大小设为 256（--block-size 256）。如需进一步降低显存占用，可尝试在部分层级手动指定 --attention_config 中的压缩策略，将更多层切换至 c128a 模式。
对于数据中心级部署（如 8 卡 B200 或 B200x），建议使用 DeepSeek-V4-Pro（1.6T 参数）模型，并启用 --attention_config.use_fp4_indexer_cache=True 以利用 FP4 精度存储索引器缓存。数据并行规模可根据服务吞吐量需求设为 4 至 8（--data-parallel-size）。编译配置建议使用 FULL_AND_PIECEWISE 模式（--compilation-config '{"cudagraph_mode":"FULL_AND_PIECEWISE", "custom_ops":["all"]}'），以平衡首次推理延迟与持续吞吐量。
对于追求最低延迟的实时交互场景，建议在预填充阶段启用 Paged Prefill（目前 vLLM 正在开发中，预计后续版本支持），并将滑动窗口大小保持默认的 128 以确保局部信息的低延迟访问。同时，监控 GPU 利用率曲线，如果发现多流并行的增益不明显（通常在批量较大时出现），可考虑关闭多流以降低调度复杂度。
性能监控方面，建议重点关注三项指标：首 Token 延迟（TTFT）反映预填充阶段的压缩与注意力计算效率，Token 间延迟（ITL）反映解码阶段的缓存命中与计算效率，KV 缓存命中率反映前缀共享与压缩边界对齐的效果。在典型百万 Token 长文档摘要任务中，优化后的 DeepSeek V4 应能实现相较于 Dense 基线约 1.4 至 3 倍的推理加速。
小结
DeepSeek V4 通过 KV 缓存多级压缩（c4a 与 c128a）与稀疏注意力计算剪枝两大核心创新，成功将百万 Token 上下文场景下的推理延迟与显存占用降至可部署区间。vLLM 引擎在内存管理层面通过统一块大小、压缩器状态抽象和页大小池化实现了高效的异构缓存调度，在计算层面通过内核融合与多流并行实现了 GPU 计算饱和。这些工程实践为长上下文大语言模型的落地提供了可复用的技术路径。随着 Paged Prefill 和 DeepGEMM MegaMoE 等后续优化的落地，DeepSeek V4 的推理效率仍有进一步提升空间。
资料来源：本文技术细节主要参考 vLLM 官方博客《DeepSeek V4 in vLLM: Efficient Long-context Attention》（https://vllm.ai/blog/deepseek-v4）。