基准测试表格忽略了DeepSeek-V4的核心要点：重要的变化在于架构。V4将百万token上下文转化为一个服务系统问题。
该模型通过一种混合注意力设计支持1M 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头数、头维度和精度。在1M token时，缓存对于单个请求来说变得不切实际。V4的token轴压缩，结合MLA风格的头压缩和低精度KV，将每个请求的缓存占用减少到足以使极长上下文变得切实可行。
在早期适配中，V4的服务能力更多地受引擎如何处理SWA状态的限制，而不是受压缩的CSA/HCA缓存的限制。完整的SWA实现实际上每个token的KV占用比我们的V3路径更高——大约3.8 KB每token对比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压缩器使用的短未压缩尾部状态。这些对象具有不同的大小、生命周期和读取模式。
新的注意力内核只是工作的一部分。更困难的服务问题是内存管理：批处理请求、驱逐缓存页面、重用前缀以及在模型不同部分依赖于不同类型存储状态时保持解码吞吐量稳定。
前缀缓存成为一种存储策略
前缀缓存通常从一个简单的规则开始：共享前缀，共享 KV。到了 V4，问题变成了：哪个缓存？
共享前缀包含 CSA 状态、HCA 状态、SWA 状态，以及 CSA 和 HCA 压缩器使用的未压缩尾部状态。CSA 和 HCA 足够紧凑，可以高效存储。SWA 是精确的局部状态，这使得它在长前缀下存储成本更高，尤其是当缓存层级超出 GPU 内存时。
DeepSeek 论文描述了三种 SWA 策略。
第一种存储完整的 SWA 缓存。重用很简单，因为引擎可以直接恢复完整的前缀状态，但存储和写入带宽增长很快。
第二种存储周期性的 SWA 检查点。引擎每 K 个 token 保存一次状态，并在缓存命中时重新计算间隙。
第三种在命中时重新计算 SWA。引擎存储压缩的 CSA/HCA 状态，并在前缀被重用时重建 SWA 路径。成本受限于窗口大小乘以层数。对于 128 token 的窗口和 61 层，大约需要重新计算 8K token。对于 1M token 的前缀，这种权衡是合理的。
在我们当前的 V4 部署中，我们使用第一种策略：存储完整的 SWA 缓存。这保持了前缀重用的简单性，并避免了在服务路径的其他部分尚未成熟时增加重新计算的复杂性。代价是更高的缓存占用，这使得随着上下文长度和并发度的增加，缓存策略和驱逐行为变得更加重要。
V4 将前缀缓存转变为跨缓存对象的策略决策：存储 CSA 和 HCA，决定如何处理 SWA，并根据每种类型的成本进行驱逐。
V4 性能取决于场景
V4 的优势首先在 KV 缓存占主导地位的地方显现。
长上下文、解码密集型工作负载大部分时间用于读取缓存。V4 的压缩缓存布局减轻了这种压力。
短上下文、预填充密集型工作负载则走不同的路径。CSA top-k 选择、HCA 压缩读取和 SWA 引入了成熟密集注意力内核路径之外的操作。内核成熟度很重要。精度格式也很重要：V4 对 MoE 权重使用 MXFP4，其在 NVIDIA Blackwell GPU 上的性能特性与 NVFP4 不同。这使得短上下文预填充对内核成熟度特别敏感，而长上下文解码则更直接受益于 KV 缓存的减少。
这就产生了场景划分。长上下文工作负载早期就能从 V4 的缓存节省中受益。短上下文工作负载则更依赖于内核的开发和预填充优化。这对于新架构来说是典型的：第一次实现确立正确性；后续迭代缩小与硬件效率的差距。
Together 正在继续 V4 在预填充和解码路径上的内核工作。
开发者应该在实际场景中对 V4 进行基准测试。一个 1M 上下文的编码助手和一个短上下文聊天助手会用到服务栈的不同部分。
相同的权重需要不同的服务配置
V4 扩大了工作负载形态之间的差距。
长上下文代理最直接受益于该架构。它们在解码期间读取大量缓存，因此 V4 的压缩 KV 布局、更大的张量并行配置、批处理和前缀重用都很重要。这是模型长上下文设计应该首先显现的场景。
共享仓库上的编码智能体与此相关，但服务问题更侧重于前缀。相同的项目文件、仓库状态或任务脚手架可能在多个请求中重复出现，因此缓存分层和SWA重计算策略成为首要选择。瓶颈既包括长上下文，也包括重复上下文的复用。
短聊天则处于另一个极端。这些工作负载从百万级令牌缓存压缩中获益不多，反而暴露了预填充延迟、小批量开销和内核成熟度问题。要很好地服务它们，可能需要更小的张量并行组、最小的批处理延迟以及针对短上下文路径优化的内核。
强化学习推演关注的是不同的经济单位：每条长轨迹的成本。它们可能与长上下文智能体共享服务机制，但优化目标是实验吞吐量——每个训练预算能生成多少长视野推演，而不仅仅是单次请求的延迟。
相同的权重可以服务于所有这些工作负载。每种工作负载在不同的端点配置下表现最佳。Together正在评估具有不同批处理、并行度和缓存策略的端点配置。
迁移到V4前需要基准测试的内容
百万级令牌服务对于在长任务中积累状态的系统最为重要：编码智能体、研究智能体以及其他更长视野的任务。对于这些工作负载，成本模型通常从每令牌价格转向每完成轨迹的成本。
在将流量迁移到V4之前，请对以下四项进行基准测试：上下文长度范围、前缀复用、缓存策略和端点配置。
对于长上下文智能体，测量缓存命中率、解码吞吐量和每完成任务的成本。首令牌时间仅能反映部分情况。
对于短聊天，比较在实际上下文长度和批量大小下的延迟。V4在长上下文方面的优势可能不会首先体现在短聊天的延迟上。
对于共享前缀工作负载，测试SWA全存储与命中时重计算。前缀长度、缓存层延迟和复用频率决定了答案。
对于强化学习推演，根据轨迹长度和每次实验的推演次数计算成本，而不仅仅是令牌价格。
对于混合流量，需要权衡取舍。一个端点可以服务混合工作负载，但一旦工作负载形态明确，特定配置的端点通常表现更好。
质量仍需衡量。更长的上下文为有用状态、检索噪声、压缩伪影和延迟创造了更多空间。它还会改变压缩策略：构建者能更好地控制何时保留原始状态、总结或重置。
结论
DeepSeek-V4的效率是一个系统属性。该架构通过沿令牌轴压缩来减少KV压力，但服务引擎必须管理由此产生的缓存类型、前缀策略、内核路径和端点配置。
这也是全栈协同设计至关重要的地方。模型改变了缓存布局，推理引擎调整了内存管理和前缀策略，内核适配了新的注意力机制和精度路径。NVIDIA 在 Blackwell 上为 v4 提供 MXFP4 的 Day 0 支持，并允许开发者通过 NVFP4 优化性能。通过广泛的协同设计，Together AI 和 NVIDIA 持续通过软件优化（如 NVIDIA Dynamo）提升硬件效率。极致的协同设计在 DeepSeek V4 等领先开源模型上实现了最低的每 token 成本，并在 NVIDIA Blackwell 上解锁了更高性能。
运行 V4 只是起点。将其架构优势转化为更低的延迟、更高的并发以及更便宜的长上下文工作负载，需要缓存策略、内核以及针对特定工作负载的服务配置。下一步是测量：每 token 的 KV 占用、上下文长度吞吐量曲线、前缀缓存策略影响以及不同流量形态的端点配置。随着 V4 内核和缓存策略的成熟，我们将发布这些数据。
常见问题
DeepSeek-V4 的上下文窗口是多少？ DeepSeek-V4 支持 100 万 token 的上下文窗口。它通过混合注意力设计实现这一点，该设计在键值（KV）存储之前压缩上下文，混合压缩和局部注意力路径，并改变前缀重用的方式。架构上的变化使得百万 token 上下文作为服务负载成为可能。
DeepSeek-V4 中的压缩稀疏注意力（CSA）是什么？ CSA 以步长 4 压缩上下文，每个压缩条目总结一个 8 token 邻域，因此相邻条目在边界处重叠。查询选择大约 128 个这样的压缩条目，为模型提供进入前缀选定区域的细粒度稀疏路径，同时减少存储的缓存占用。
重度压缩注意力（HCA）是什么？ HCA 使用与 CSA 相同的压缩机制，但步长为 128。在 100 万 token 上下文中，这将缓存从 100 万个位置减少到约 8000 个压缩条目，小到模型可以密集关注所有条目。HCA 提供粗略的全局读取，而 CSA 提供选定区域上的精细稀疏读取。
与早期模型相比，DeepSeek-V4 如何减少 KV 缓存大小？ DeepSeek-V4 沿 KV 缓存的 token 轴进行压缩。早期技术减少了缓存乘积中的不同项：分组查询注意力减少 KV 头数，多头潜在注意力压缩头维度，FP8/MXFP4/NVFP4 减少每个元素的字节数。DeepSeek-V3.2 在保持完整缓存驻留的同时减少了解码时需读取的缓存量。V4 减少了存储的 token 条目本身的数量。
为什么服务 DeepSeek-V4 需要多种 KV 缓存布局？ 该模型在层间混合使用了三种注意力路径（CSA、HCA 和滑动窗口注意力）。每种路径产生的缓存对象具有不同的大小、生命周期和读取模式。推理引擎必须同时为每个请求管理这三种缓存，这使得内存管理、驱逐和前缀重用比单一缓存设计更加困难。
DeepSeek-V4 的前缀缓存是如何工作的？ 前缀缓存变成了每个缓存类型的策略决策。CSA 和 HCA 状态足够紧凑，可以存储。SWA 状态是精确的局部状态，在长前缀下会变得昂贵。DeepSeek 论文描述了三种选项：存储完整的 SWA、存储周期性检查点、或在缓存命中时重新计算 SWA。命中时重新计算的代价受限于窗口大小乘以层数，大约在 1M 令牌前缀下重新计算 8K 令牌。
哪些工作负载最能从 DeepSeek-V4 中受益？ 长上下文、解码密集型工作负载首先受益，包括编码代理、研究代理以及在长任务中累积状态的强化学习 rollout。对于这些工作负载，成本模型从每令牌价格转向每完成轨迹成本。短上下文聊天工作负载的收益较小，因为它们更多地暴露了预填充延迟和内核成熟度，而非 KV 缓存压力。
我是否应该将短聊天流量迁移到 DeepSeek-V4？ 先进行基准测试。V4 的优势在 KV 缓存占主导地位时显现。短上下文、预填充密集型工作负载会使用较新的内核路径（CSA top-k 选择、HCA 密集读取、MXFP4 MoE 权重），这些仍在成熟过程中。在切换之前，请在实际上下文长度和批量大小下比较延迟。长上下文代理和短聊天即使在相同权重下也可能需要不同的端点配置。
为什么 Together 选择 NVIDIA HGX B200 来服务 DeepSeek V4？
NVIDIA HGX B200 与 DeepSeek V4 中主导服务成本的部分相匹配：长上下文解码期间的 KV 缓存压力和预填充期间的 MoE 权重带宽。NVIDIA Blackwell 推理性能 使得单个 HGX B200 节点能够将 V4 压缩的 CSA / HCA / SWA 缓存布局驻留在许多并发长上下文请求中，其原生 MXFP4 支持与 DeepSeek 为 V4 的 MoE 权重提供的格式相匹配，因此我们端到端地运行模型的量化，无需重新转换步骤。Together 的 HGX B200 实例继承了相同的 MXFP4 路径和 KV 压缩空间，这就是我们选择它作为 V4 发布平台的原因。