DeepSeek V4：真正有效的百万Token上下文
发布: (2026年4月26日 GMT+8 08:02)
5 分钟阅读
原文: Dev.to
Source: Dev.to
概览
大多数长上下文模型只是寻找用例的基准测试。DeepSeek V4 改变了这一点——它提供了 1 百万 token 的上下文，不是作为规格表上的一个复选框，而是作为你可以真正部署的可操作现实。
突破点不仅在于上下文长度；更在于 DeepSeek 在不大幅消耗推理预算的情况下实现了它。
架构
一个朴素的 1 M‑token 实现需要 83.9 GiB 的 KV 缓存（每个序列）使用标准注意力——这对 GPU 内存来说是一次拒绝服务攻击。DeepSeek 的解决方案是 混合注意力架构，将 KV 缓存压缩了近 9×：
- 跨层共享键值向量
- 压缩的 KV 流
- 对压缩 token 的稀疏注意力
邻近上下文的滑动窗口保持在 128 token，足以实现局部连贯性而不会导致内存炸弹。
内存节省
- 在 1 M token 时，V4 只需要 9.62 GiB，而不是 83.9 GiB。
- 使用 FP4 索引缓存和 FP8 注意力，可再降低约 2 倍。
- 这一差距使模型能够在单节点上运行，而不必依赖 8×H100 集群。
变体与定价
| 变体 | 参数（总计） | 活跃参数（每 token） | KV 内存缩减 | 价格（每 M token） |
|---|---|---|---|---|
| Pro | 1.6 T | 49 B | ~基线的 10 % | $1.74 / $3.48 |
| Flash | 284 B / 13 B（活跃） | 13 B | ~基线的 10 % | $0.14 / $0.28 |
两种变体均使用相同的注意力架构，并在将 KV 内存降至约 10 % 的同时实现 1 M‑token 上下文窗口。
使用场景
代理工作流是上下文的压力测试：
- 编码代理 在上下文中保持 300 K 行代码库。
- 研究代理 跨 50 篇论文追踪引用。
- 客服代理 拥有一年的交互历史。
这些并非小众场景；它们是被上下文限制阻塞的代理系统的核心价值主张——限制导致必须不断检索、重新排序和状态碎片化。DeepSeek V4 的压缩注意力让你能够保持状态常驻——无需在回合中往返向量数据库，无需近似，仅在推理时使用完整上下文。
基准测试
独立基准显示 V4 Pro 在代理任务上领先开源权重模型，超越 Kimi K2.6、GLM‑5.1 和 MiniMax‑M2.7 在 GDPval‑AA 工作台的表现。Flash 变体在 成本低 12 倍 的情况下保持竞争力。
部署与兼容性
- 推理吞吐量 在负载下保持稳定，得益于学习式哈希路由（源自 2021 年 ParlAI 工作，并通过自 V2 起的 MoE 迭代精炼）。
- Day‑zero vLLM 集成、针对 Apple Silicon 的 MLX 量化，以及可在 8 × B200 GPU（混合 FP4/FP8）上放下的检查点。
- 在 MIT 许可证 下发布，提供基础版和指令版，并对华为 Ascend 芯片提供首日支持。
- 足够便携，可在 Blackwell、MI355 以及通过量化的消费级 Mac 上运行。
局限性
- 长上下文检索的幻觉率仍然偏高——在 Omniscience 基准上约为 94 %。
- 推理任务的 token 消耗显著：V4 Pro 在 AA Index 上使用 190 M 输出 token，而 Flash 为 240 M。
这些权衡现在可以通过实际实验进行检验，因为基础设施已经真正支持这些实验。
结论
DeepSeek V4 是首个开源权重模型，使上下文窗口不再是持久深度上下文代理的瓶颈——无论是代码审查、法律分析还是研究综合。长上下文已从“即将推出”迈向“已交付”。剩下的工作是进一步优化。