部署 DeepSeek-V4：为什么百万 token 上下文是一个推理系统问题
百万 token 上下文推理不是模型问题，而是系统工程问题；Together AI 拆解了关键优化手段。
DeepSeek-V4 支持百万 token 上下文，带来了推理系统的全新挑战。Together AI 在 NVIDIA HGX B200 上探索了背后的推理工作，包括压缩 KV 布局（一种减少内存占用的注意力缓存技术）、前缀缓存（复用公共前缀的计算结果）、内核成熟度（Kernel 优化的完善程度）以及针对长上下文工作负载的端点配置。
正文摘录
Serving DeepSeek-V4：为什么百万 token 上下文是一个推理系统问题 基准测试表遗漏了 DeepSeek-V4 的核心：重要的变化在于架构。V4 把百万 token 上下文变成了一个服务系统问题。 该模型通过混合注意力设计支持 1M token 上下文窗口，这种设计在键值存储前压缩上下文，混合压缩与局部注意力路径，并改变了前缀复用方式。这些选择降低了 KV 压力，但节省的效果只有推理引擎能管理好缓存布局、恢复局部状态、有效批处理请求、并选择匹配工作负载的端点配置时才有意义。 本文基于 Together 在 NVIDIA HGX B200 上的早期搭建工作，聚焦于 V4 的 Compressed Sparse Attention（CSA，压缩稀疏注意力）/ Heavily Compressed Attention（HCA，重度压缩注意力）/ Sliding Window Attention（SWA，滑动窗口注意力）注意力设计对服务的影响。V4 还包括其他架构与训练变化，比如 Manifold-Constrained Hyper-Connections（mHC，流形约束超连接）残差连接和 Muon 优化器选择，但这些不在本文主要讨论范围内。 V4 压缩 KV 缓存的 token 维度 自回归推理将之前的上下文存储在 KV 缓存中。解码时，每个新生成的 token 读取并关注这个存储的状态。缓存大小随序列长度增长： KV cache ∝ layers × tokens × kvheads × headdim × bytes 在长上下文场景下，KV 缓存会两次打击服务性能。它限制了并发性，因为每个活跃请求都占用内存；它降低了吞吐量，因为解码每一步都必须读取存储的上下文。