部署DeepSeek-V4：为何百万Token上下文是推理系统的问题
DeepSeek-V4通过混合注意力设计（CSA、HCA、SWA）压缩KV缓存，将百万Token上下文从模型挑战转变为推理系统挑战。Together AI在NVIDIA HGX B200上的早期部署经验展示了缓存策略、前缀缓存和端点配置对长上下文工作负载性能的关键影响。
文章情报
要点
- DeepSeek-V4的压缩稀疏注意力（CSA）和高度压缩注意力（HCA）减小了KV缓存大小，但推理引擎需要管理多种缓存布局。
- 滑动窗口注意力（SWA）在长上下文时成为性能瓶颈，需谨慎选择存储策略。
- 前缀缓存变成跨越CSA、HCA和SWA的存储策略决策。
- V4的性能依赖于工作负载：长上下文解码受益明显，短上下文预填则依赖内核成熟度。
为什么重要
这条新闻值得关注，因为DeepSeek-V4的压缩稀疏注意力（CSA）和高度压缩注意力（HCA）减小了KV缓存大小，但推理引擎需要管理多种缓存布局。
技术影响
可能影响模型选型、推理成本、产品能力和评测基准。
DeepSeek-V4的百万Token上下文窗口并非仅靠模型架构实现，其关键在于将存储和计算压力转移到了推理系统层面。该模型采用混合注意力机制，包括压缩稀疏注意力（CSA）、高度压缩注意力（HCA）和滑动窗口注意力（SWA），大幅压缩了键值（KV）缓存。然而，这些压缩操作的有效性完全取决于推理引擎能否高效管理生成的多种缓存布局。
在NVIDIA HGX B200硬件上的早期部署显示，V4的KV缓存容量受限于对SWA状态的处理。全量存储SWA会导致每Token缓存占用高达3.8KB，超过V3的3.4KB。通过优化缓存策略——仅保留最可能被复用的SWA状态——单个节点的KV缓存容量从约120万Token提升至370万Token。这表明，V4的架构为长上下文效率创造了机会，但实际容量取决于引擎的存储、重计算和逐出策略。
V4需要三种不同的缓存布局：CSA以步长4压缩上下文，每个条目覆盖8个Token的词宽，实现细粒度稀疏读取；HCA以步长128压缩，将百万Token缩减至约8000个条目，支持全局密集注意力；SWA保持128Token的精确局部上下文。推理引擎必须同时管理这些生命周期和读取模式不同的缓存对象。
前缀缓存在V4中变得更为复杂。共享前缀包含CSA、HCA和SWA状态。DeepSeek论文提出了三种SWA策略：全量存储、周期性检查点存储和命中时重计算。当前部署采用全量存储以保持简单，但这也意味着缓存策略在上下文长度和并发度增加时更为关键。
V4的性能呈现明显的工况依赖性。长上下文解码密集型负载因KV缓存压缩而显著受益；短上下文预填密集型负载则受限于内核成熟度，因为CSA的top-k选择、HCA压缩读取和SWA都偏离了成熟的密集注意力内核路径。开发者应根据实际使用场景进行基准测试。
同一套权重需要不同的服务配置：长上下文代理适合大张量并行和批量处理；短聊天需优化预填延迟；强化学习 rollout 关注每条长轨迹的成本。Together AI正在评估不同端点配置，以匹配各类工作负载。
在迁移至V4之前，应针对上下文长度范围、前缀复用率、缓存策略和端点配置四项指标进行基准测试。对于长上下文任务，衡量缓存命中率、解码吞吐量和任务完成成本；对于短聊天，比较实际上下文长度下的延迟；对于共享前缀负载，测试SWA全量存储与命中时重计算的权衡；对于强化学习，计算每rollout的吞吐量。