DeepSeek-V4服务：百万token上下文成为推理系统难题

基准表忽略了DeepSeek-V4的要点：重要的变化在于架构。V4将百万token上下文变成了一个服务系统问题。

该模型通过一种混合注意力设计支持100万token的上下文窗口，这种设计在键值（KV）存储之前压缩上下文，混合了压缩注意力路径和局部注意力路径，并改变了前缀重用方式。这些选择减少了KV压力，但只有在推理引擎能够管理由此产生的缓存布局、恢复局部状态、有效批量处理请求，以及选择与工作负载匹配的端点配置文件时，这种节省才有意义。

本文基于Together在NVIDIA HGX B200上的早期适配工作，聚焦于V4的压缩稀疏注意力（CSA）/ 重度压缩注意力（HCA）/ 滑动窗口注意力（SWA）注意力设计对服务的影响。V4还包括其他架构和训练变化，包括流形约束超连接（mHC）残差连接和Muon优化器选择，但这些不在本文主要讨论范围内。

V4压缩KV缓存的token轴

自回归推理将先前上下文存储在KV缓存中。在解码过程中，每个新生成的token都会读取并关注这些存储的状态。缓存随序列长度增长： KV缓存 ∝ 层数 × token数 × KV头数 × 头维度 × 字节数

在长上下文中，KV缓存会在两方面对服务造成影响。它会限制并发性，因为每个活动请求都会占用内存；同时会降低吞吐量，因为解码每一步都必须读取存储的上下文。V4之所以重要，是因为它同时解决了这两个问题：需要存储的缓存条目更少，并且需要经过注意力机制传输的缓存条目也更少。

在NVIDIA Blackwell上，这种缓存压力直接转化为服务经济学。长上下文推理依赖于在解码期间保持足够的KV驻留以实现并发，同时为解码保留内存带宽。V4的token轴压缩使这种权衡更加有利：引擎有更多空间来批量处理请求、重用前缀，并将长上下文工作负载保持在高效的服务区域内。

近期的模型架构已经减少了上述乘积中的不同项。分组查询注意力（GQA）减少了KV头。多头潜在注意力（MLA）将KV压缩为潜在表示。FP8、MXFP4和NVFP4减少了每个元素的字节数。DeepSeek-V3.2稀疏注意力减少了解码期间必须读取的KV量，而完整缓存仍需驻留。

DeepSeek-V4针对的是token轴。它在KV存储之前压缩上下文。 这是重要的转变。

在普通的BF16多头注意力计算下，一个70B类模型每个token可能需要数兆字节的KV缓存。确切的系数取决于层数、KV头数、头维度和精度。在100万token时，单个请求的缓存变得不切实际。V4的token轴压缩，结合MLA式头部压缩和低精度KV，将每个请求的缓存占用减少到足以使极长上下文变得实际可行的程度。

在早期适配中，V4的服务能力更多受引擎处理SWA状态的方式限制，而非受压缩的CSA/HCA缓存限制。实际上，完全SWA实现的每token KV占用比我们的V3路径更高——大约每token 3.8 KB对比3.4 KB——因为引擎存储了完整的滑动窗口状态。

实际收益来自缓存策略。通过只保留最可能被重用的SWA状态，我们在单个NVIDIA HGX B200节点上将总KV缓存容量从大约120万token提升到370万token，且改动最小。这是主要服务教训：V4的架构为长上下文效率创造了机会，但实际容量取决于推理引擎如何存储、重新计算和驱逐不同类型的缓存。

实际胜利不仅限于完整的100万token请求。它使20万到50万token的工作负载更具并发性和更低的脆弱性，因为引擎在内存压力迫使驱逐或限制批处理之前，有更多的KV预算可支配。早期的百万token上下文模型仍然在内存、并发性和成本方面留下了主要的服务挑战。当服务策略与缓存布局匹配时，V4使该范围更接近实际工作负载。

V4需要多种KV缓存布局

许多现有的服务路径假定接近单一KV缓存布局：每层每个token一个缓存对象，堆栈中形状相同。V4需要三种不同的缓存类型，在层间混合使用。

压缩稀疏注意力（CSA）以步长4压缩上下文，但每个压缩条目由稍宽的接收域构建而成。在V4的配置中，每个条目总结一个8 token的邻域，因此相邻的压缩条目在边界处重叠。当查询选择128个压缩条目时，它选择的是局部邻域的摘要，而非孤立的token位置。这使得CSA能够以更细粒度的路径进入百万token前缀的选定区域，同时仍然减少存储的缓存占用。

重度压缩注意力（HCA）使用相同的压缩思想，但步长为128。在100万token的上下文长度下，这将缓存从100万token位置减少到大约8000个压缩条目。这是与CSA的关键区别：压缩缓存足够小，以至于模型可以密集地关注它，而不是选择top-k子集。HCA为模型提供了对整个上下文的粗略全局读取，而CSA则为选定区域提供了更精细的稀疏读取。

滑动窗口注意力（SWA）保留了局部路径。窗口很短，大约128个token，并保持最近上下文的精确性。

在整个堆栈中，引擎必须管理CSA压缩状态、HCA压缩状态、SWA局部状态，以及CSA和HCA压缩器使用的短未压缩尾部状态。这些对象具有不同的大小、生命周期和读取模式。

新的注意力内核只是工作的一部分。更困难的服务问题是内存管理：批量处理请求、驱逐缓存页面、重用前缀，以及在模型不同部分依赖于不同种类的存储状态时保持解码吞吐量稳定。

阅读完整博客：这是我们从DeepSeek V4 Pro适配中得出的第一个服务教训。完整文章涵盖了多种KV缓存布局、前缀缓存策略、特定于工作负载的服务配置文件，以及团队在将流量迁移到V4之前应该进行的基准测试。

在此阅读完整博客 在此观看完整网络研讨会 在此试用DeepSeek V4 Pro