服务 DeepSeek-V4：为什么百万 token 上下文是推理系统问题

benchmark 表格没有抓住 DeepSeek-V4 的重点：真正重要的变化在 architecture。V4 把百万 token context 变成了一个 serving-systems 问题。

该模型通过一种 hybrid attention 设计支持 1M-token context window：在 key-value（KV）存储之前压缩 context，混合 compressed attention 与 local attention 路径，并改变 prefix reuse 的工作方式。这些选择降低了 KV 压力，但只有当 inference engine 能够管理由此产生的 cache layouts、恢复 local state、有效 batch requests，并选择与 workload 匹配的 endpoint profiles 时，这些节省才有意义。

本文基于 Together 在 NVIDIA HGX B200 上的早期 bring-up 工作，聚焦于 V4 的 Compressed Sparse Attention（CSA）/ Heavily Compressed Attention（HCA）/ Sliding Window Attention（SWA）attention 设计对 serving 的影响。V4 还包含其他 architecture 和 training 变化，包括 Manifold-Constrained Hyper-Connections（mHC）residual connections 以及 Muon optimizer 选择，但这些不在本文主要范围内。

V4 压缩 KV cache 的 token 轴

Autoregressive inference 会把此前的 context 存入 KV cache。在 decode 期间，每个新生成的 token 都会读取并 attend 到这些已存储的 state。cache 会随 sequence length 增长：

KV cache  ∝  layers × tokens × kv_heads × head_dim × bytes

在 long context 下，KV cache 会从两方面影响 serving。它限制 concurrency，因为每个 active request 都会占用内存；它也降低 throughput，因为 decode 每一步都必须读取已存储的 context。V4 的意义在于，它同时处理了这个问题的两端：需要存储的 cache entries 更少，需要通过 attention 移动的 cache entries 也更少。

在 NVIDIA Blackwell 上，这种 cache 压力会直接映射到 serving 经济性。Long-context inference 依赖于让足够多的 KV 常驻，以支持 concurrency，同时为 decode 保留 memory bandwidth。V4 的 token-axis compression 让这种权衡更有利：engine 有更多空间来 batch requests、reuse prefixes，并把 long-context workloads 保持在高效的 serving 区间内。

近期的 model architectures 已经减少了上述乘积中的不同项。Group Query Attention（GQA）减少 KV heads。Multi-Head Latent Attention（MLA）把 KV 压缩为 latent representation。FP8、MXFP4 和 NVFP4 减少每个 element 的 bytes。DeepSeek-V3.2 sparse attention 减少了 decode 期间必须读取的 KV 数量，但完整 cache 仍然必须常驻。

DeepSeek-V4 针对的是 token 轴。它在 KV storage 之前压缩 context。

这是关键转变。

在 vanilla BF16 multi-head attention 计算下，一个 70B 级模型每个 token 可能需要数 MB 的 KV cache。确切系数取决于 layer count、KV heads、head dimension 和 precision。在 1M tokens 时，单个 request 的 cache 会变得不现实。V4 的 token-axis compression，结合 MLA-style head compression 和 low-precision KV，把每个 request 的 cache footprint 降到足以让超长 context 在实践中更可行。

在早期 bring-up 中，V4 的 serving capacity 受 compressed CSA / HCA cache 的制约较少，更多取决于 engine 如何处理 SWA state。一个 full-SWA implementation 的 per-token KV footprint 实际上高于我们的 V3 路径——大约 3.8 KB per token，而不是 3.4 KB——因为 engine 存储了完整的 sliding-window state。

实际收益来自 cache policy。通过只保留最可能被复用的 SWA states，我们在单个 NVIDIA HGX B200 node 上把总 KV-cache capacity 从大约 1.2M tokens 提升到 3.7M tokens，且改动很少。这是主要的 serving 经验：V4 的 architecture 创造了 long-context efficiency 的机会，但实际 capacity 取决于 inference engine 如何存储、重算和淘汰不同 cache types。

实际收益不只适用于完整的 1M-token requests。它也让 200K–500K-token workloads 具备更高 concurrency、也更不脆弱，因为在 memory pressure 迫使 eviction 或限制 batching 之前，engine 拥有更多 KV budget。此前的 million-token-context models 仍然在 memory、concurrency 和 cost 方面留下了主要 serving 挑战。当 serving policy 与 cache layout 匹配时，V4 让这个范围更接近真实 workload。

V4 需要多种 KV-cache layouts

许多现有 serving paths 假设的是接近单一 KV cache layout 的形态：每层每个 token 一个 cache object，在整个 stack 中 shape 相同。V4 需要三种不同的 cache types，并在 layers 之间混合使用。

Compressed Sparse Attention（CSA）以 stride 4 压缩 context，但每个 compressed entry 都来自略宽的 receptive field。在 V4 的配置中，每个 entry 总结一个 8-token neighborhood，因此相邻的 compressed entries 会在边界处重叠。当一个 query 选择 128 个 compressed entries 时，它选择的是 local neighborhoods 的 summaries，而不是孤立的 token positions。这让 CSA 在降低 stored cache footprint 的同时，仍能以更细粒度进入 million-token prefix 中被选中的区域。

Heavily Compressed Attention（HCA）使用相同的压缩思路，但 stride 为 128。在 1M-token context length 下，这会把 cache 从 1M token positions 降到大约 8K compressed entries。这是它与 CSA 的关键区别：compressed cache 足够小，因此模型可以 dense 地 attend 到全部内容，而不是选择 top-k subset。HCA 为模型提供对整个 context 的粗粒度 global read，而 CSA 则为选定区域提供更细的 sparse read。

Sliding Window Attention（SWA）保留 local path。window 很短，大约 128 tokens，并保持 recent context 的精确性。

在整个 stack 中，engine 必须管理 CSA compressed state、HCA compressed state、SWA local state，以及 CSA 和 HCA compressors 使用的短 uncompressed tail states。这些 objects 具有不同的大小、生命周期和读取模式。

新的 attention kernels 只是工作的一部分。更难的 serving 问题是 memory management：batching requests、evicting cache pages、reusing prefixes，以及在模型的不同部分依赖不同类型 stored state 时保持 decode throughput 稳定。

Prefix caching 变成一种存储策略

Prefix caching 通常从一个简单规则开始：shared prefix，shared KV。到了 V4，问题变成：哪一种 cache？

一个 shared prefix 包含 CSA state、HCA state、SWA state，以及 CSA 和 HCA compressors 使用的 uncompressed tail states。CSA 和 HCA 足够紧凑，可以高效存储。SWA 是精确的 local state，因此在 long prefixes 上存储成本更高，尤其是当 cache tier 超出 GPU memory 之后。

DeepSeek paper 描述了三种 SWA strategies。

第一种存储完整 SWA cache。reuse 很简单，因为 engine 可以直接恢复完整 prefix state，但 storage 和 write bandwidth 会快速增长。

第二种存储周期性 SWA checkpoints。engine 每隔 K tokens 保存一次 state，并在 cache hit 时重算中间的 gap。

第三种在 hit 时重算 SWA。engine 存储 compressed CSA / HCA state，并在 prefix 被复用时重建 SWA path。成本由 window size 乘以 layer count 限定。在 128-token window 和 61 layers 下，这大约是 8K tokens 的 recompute。相对于 1M-token prefix，这种权衡可能是合理的。

在我们当前的 V4 bring-up 中，我们使用第一种策略：存储完整 SWA cache。这让 prefix reuse 保持直接，并避免在 serving path 其他部分仍在成熟时增加 recompute complexity。代价是更高的 cache footprint，这会随着 context length 和 concurrency 增加，让 cache policy 和 eviction behavior 变得更重要。

V4 把 prefix caching 变成了跨 cache objects 的 policy decision：存储 CSA 和 HCA，决定如何处理 SWA，并根据各自成本淘汰每种类型。

V4 performance 取决于所在区间

V4 的收益首先出现在 KV cache 主导的场景中。

Long-context、decode-heavy workloads 会把大量时间花在读取 cache 上。V4 的 compressed cache layout 降低了这种压力。

Short-context、prefill-heavy workloads 走的是另一条路径。CSA top-k selection、HCA compressed reads 和 SWA 引入了成熟 dense-attention kernel paths 之外的操作。Kernel maturity 很重要。Precision format 也很重要：V4 对 MoE weights 使用 MXFP4，它在 NVIDIA Blackwell GPUs 上的性能特征不同于 NVFP4。这让 short-context prefill 对 kernel maturity 尤其敏感，而 long-context decode 则更直接地受益于 KV-cache reduction。

这形成了一个 regime split。Long-context workloads 会较早受益于 V4 的 cache savings。Short-context workloads 则更依赖 kernel bring-up 和 prefill optimization。这是新 architecture 的典型情况：第一版 implementation 建立 correctness；后续迭代把差距缩小到 hardware efficiency。

Together 正在继续推进 V4 在 prefill 和 decode paths 上的 kernel 工作。

开发者应在自己的实际 regime 中 benchmark V4。一个 1M-context coding agent 和一个 short-context chat assistant 会触发 serving stack 的不同部分。

相同 weights 需要不同 serving profiles

V4 拉大了 workload shapes 之间的差异。

Long-context agents 最直接地受益于该 architecture。它们在 decode 期间读取大量 cache，因此 V4 的 compressed KV layout、更大的 tensor-parallel configurations、batching 和 prefix reuse 都很重要。这是模型的 long-context 设计最先应当体现出来的场景。

针对 shared repositories 的 coding agents 与之相关，但 serving 问题更偏 prefix-heavy。同一组 project files、repository state 或 task scaffolds 可能会在 requests 之间重复，因此 cache tiering 和 SWA recompute policy 会成为一阶选择。瓶颈同时包含 long context 和 repeated-context reuse。

Short chat 位于光谱另一端。这类 workloads 并不会从 million-token cache compression 中获得太多收益，反而会暴露 prefill latency、small-batch overhead 和 kernel maturity。要把它们服务好，可能需要更小的 tensor-parallel groups、最小化 batching delay，并使用针对 short-context path 调优的 kernels。

RL rollouts 关注另一种经济性单位：每条 long trajectory 的成本。它们可能与 long-context agents 共享 serving machinery，但优化目标是 experiment throughput，即在给定 training budget 下可以生成多少 long-horizon rollouts，而不只是单个 request 的 latency。

相同的 weights 可以服务所有这些 workloads。每种 workload 都在不同的 endpoint configuration 下表现最佳。Together 正在评估具有不同 batching、parallelism 和 cache policies 的 endpoint profiles。

迁移到 V4 之前应 benchmark 什么

Million-token serving 对那些会在长任务中积累 state 的系统最重要：coding agents、research agents，以及其他 longer horizon tasks。对这些 workloads 来说，cost model 往往会从 price per token 转向 cost per completed trajectory。

在把流量迁移到 V4 之前，应 benchmark 四件事：context-length regime、prefix reuse、cache policy 和 endpoint profile。

对于 long-context agents，测量 cache hit rate、decode throughput 和 cost per completed task。Time-to-first-token 只反映了部分情况。

对于 short chat，在你的真实 context lengths 和 batch sizes 下比较 latency。V4 的 long-context gains 可能不会首先体现在 short-chat latency 中。

对于 shared-prefix workloads，测试 SWA full-store 与 recompute-on-hit。Prefix length、cache-tier latency 和 reuse frequency 决定答案。

对于 RL rollouts，应按 trajectory length 和每个 experiment 的 rollout 数量计算成本，而不是只看 token price。

对于 mixed traffic，要预期存在权衡。一个 endpoint 可以服务 mixed workloads，但一旦 workload shape 明确，profile-specific endpoint 通常会表现更好。

Quality 仍然必须测量。更长的 context 会带来更多容纳 useful state、retrieval noise、compression artifacts 和 latency 的空间。它也会改变 compaction strategy：builders 能更好地控制何时保留 raw state、summarize 或 reset。

结论

DeepSeek-V4 的 efficiency 是一种系统属性。该 architecture 通过沿 token 轴压缩来降低 KV 压力，但 serving engine 必须管理由此带来的 cache types、prefix policies、kernel paths 和 endpoint profiles。

这也是 full-stack co-design 重要的地方。模型改变 cache layout。Inference engine 改变 memory management 和 prefix policy。Kernels 适配新的 attention 和 precision paths。NVIDIA Blackwell platform 决定这些工作有多少会转化为实际的 throughput、concurrency 和 cost-per-token gains。

运行 V4 只是起点。要把它的 architectural savings 转化为更低 latency、更高 concurrency 和更便宜的 long-context workloads，需要 cache-policy 工作、kernel 工作，以及面向 workload 的 serving profiles。下一步是测量：per-token KV footprint、context-length throughput curves、prefix-cache policy impact，以及针对不同 traffic shapes 的 endpoint profiles。随着 V4 kernels 和 cache policies 成熟，我们会发布这些数字。

FAQ

DeepSeek-V4 的 context window 是多少？ DeepSeek-V4 支持 1M-token context window。它通过一种 hybrid attention 设计实现这一点：在 key-value（KV）存储之前压缩 context，混合 compressed attention 与 local attention 路径，并改变 prefix reuse 的工作方式。正是这种 architectural change 让 million-token context 成为可行的 serving workload。

DeepSeek-V4 中的 Compressed Sparse Attention（CSA）是什么？ CSA 以 stride 4 压缩 context，其中每个 compressed entry 总结一个 8-token neighborhood，因此相邻 entries 会在边界处重叠。Queries 会选择大约 128 个这样的 compressed entries，让模型在降低 stored cache footprint 的同时，以细粒度 sparse path 进入 prefix 中被选定的区域。

Heavily Compressed Attention（HCA）是什么？ HCA 使用与 CSA 相同的 compression mechanism，但 stride 为 128。在 1M-token context 下，这会把 cache 从 1M positions 降到大约 8K compressed entries，小到足以让模型 dense 地 attend 到全部内容。HCA 提供粗粒度 global read，而 CSA 提供对选定区域的细粒度 sparse read。

DeepSeek-V4 如何相较早期模型减少 KV cache size？ DeepSeek-V4 沿 KV cache 的 token 轴进行压缩。早期技术减少了 cache product 中的不同项：Group Query Attention 减少 KV heads，Multi-Head Latent Attention 压缩 head dimension，FP8/MXFP4/NVFP4 减少每个 element 的 bytes。DeepSeek-V3.2 减少了 decode 时必须读取的 cache 数量，同时仍让完整 cache 常驻。V4 减少的是存储的 token entries 本身的数量。

为什么 serving DeepSeek-V4 需要多种 KV cache layouts？ 该模型使用三条 attention paths（CSA、HCA 和 Sliding Window Attention），并在 layers 之间混合。每条路径都会产生大小、生命周期和读取模式不同的 cache objects。Inference engine 必须为每个 request 并发管理这三类对象，因此 memory management、eviction 和 prefix reuse 都比单一 cache 设计更难。

DeepSeek-V4 中 prefix caching 如何工作？ Prefix caching 变成了针对每种 cache type 的 policy decision。CSA 和 HCA state 足够紧凑，可以存储。SWA state 是精确的 local state，在 long prefixes 下成本很高。DeepSeek paper 描述了三种选项：存储完整 SWA、存储周期性 checkpoints，或在 cache hit 时重算 SWA。Recompute-on-hit 的成本由 window size 乘以 layer count 限定，相对于 1M-token prefix，大约是 8K tokens 的 recompute。

哪些 workloads 最能受益于 DeepSeek-V4？ Long-context、decode-heavy workloads 最先受益，包括 coding agents、research agents，以及在长任务中积累 state 的 RL rollouts。对这些场景来说，cost model 会从 price-per-token 转向 cost-per-completed-trajectory。Short-context chat workloads 的收益较小，因为它们暴露的更多是 prefill latency 和 kernel maturity，而不是 KV cache pressure。

我应该把 short-chat traffic 迁移到 DeepSeek-V4 吗？ 先 benchmark。V4 的收益出现在 KV cache 主导的地方。Short-context、prefill-heavy workloads 会触发仍在成熟中的新 kernel paths（CSA top-k selection、HCA dense reads、MXFP4 MoE weights）。切换前，请在你的真实 context lengths 和 batch sizes 下比较 latency。即使使用相同 weights，long-context agents 和 short chats 也可能需要不同 endpoint profiles。

为什么 Together 选择 NVIDIA HGX B200 来服务 DeepSeek V4？

NVIDIA HGX B200 与 DeepSeek V4 中主导 serving cost 的部分相匹配：long-context decode 期间的 KV-cache pressure，以及 prefill 期间的 MoE weight bandwidth。Blackwell 的 inference performance 让单个 HGX B200 node 能够让 V4 的 compressed CSA / HCA / SWA cache layouts 在大量并发 long-context requests 中保持常驻，而其原生 MXFP4 支持与 DeepSeek 为 V4 的 MoE weights 发布的格式相匹配——因此我们可以端到端运行模型的 quantization，而无需 re-cast step。Together 的 HGX B200 deployment 继承了同样的 MXFP4 path 和 KV-compression headroom，这就是我们选择它作为 V4 launch platform 的原因。