LLM 系列（二十）：解读 DeepSeek-V4

如果回头来看社区对于 DeepSeek-V4 的期待，我觉得可以把这句诗句颠倒一下：犹抱琵琶半遮面，千呼万唤始出来.....

关于 DeepSeek-V4 的使用和切换，这两天已经有相当多的技术博客做了实践和对比。本文我主要来梳理下 DeepSeek-V4 的技术重点，从 技术报告 来看，可以概括为四条主线：MoE 稀疏扩容、百万上下文注意力窗口、长上下文缓存复用，以及面向 Agent 的协议兼容与后训练能力。

如果只看 1.6T 总参数 或 1M 上下文 这两个数字，很容易把它理解成一次常规迭代，毕竟社区已经有 1M 上下文 的模型出现了；但真正值得分析的，是它如何把超大模型、长上下文和 Agent 执行放进同一套系统设计里，所以看 DeepSeek 还得从他的工程创新上来看。

一、核心技术路径：MoE、CSA/HCA 与 Context Caching

首先看架构本身，DeepSeek-V4-Pro 采用 1.6T 总参数、49B 激活参数，V4-Flash 采用 284B 总参数、13B 激活参数。一方面参数确实相较于之前的 671B 来看更大了，这是变化的，另一个方面 V4 继续沿用 MoE 的路线，这是不没变的，在有线算力的成本下，DeepSeek-V4 还是在成本控制方面保持了克制。

MoE 是把模型总容量和单次推理计算量拆开，Dense 模型参数越大，每个 token 都要承担完整计算；MoE 则通过专家路由，只激活少量专家，从而在保留大容量知识空间的同时，控制单 token 的推理成本。

决定 V4 技术成色的，是对长上下文 attention 的重构；百万上下文下，传统全量 attention 的计算量和 KV Cache 开销都会急剧上升， V4 引入了 CSA 和 HCA 两套机制。

CSA

Compressed Sparse Attention，本质上是 “先压缩，再稀疏选择”。模型先把连续 token 的 KV 表示压缩成更少的 entry，再由 query 从这些压缩块中选择最相关的一部分参与计算。这样一来，attention 不再是对整段长序列做全量扫描，而是转为基于压缩索引的选择性读取。可以把它理解成模型内部的 “KV 检索机制”：不是外部检索文本，而是在内部表示中检索最有价值的上下文块。

HCA

Heavily Compressed Attention，处理的是更高层级的全局信息。它采用更激进的压缩方式，把更长范围的上下文压成更短的表示，再在压缩后的序列上做 attention。CSA 解决的是远程关键信息的精细访问，HCA 解决的是超长上下文下的全局结构保留。二者结合后，V4 形成了三层信息处理逻辑：近处上下文保留细节，远程信息通过 CSA 按需读取，更远的整体背景则通过 HCA 进行高度压缩记忆。

Context Caching

除了注意力机制，V4 的另一个重点是 Context Caching。长上下文推理的主要成本集中在 prefill 阶段，如果每次都重新处理完整长文档，代价很高。Context Caching 的作用，是在请求之间复用共享前缀，把已经处理过的上下文缓存下来，后续相同前缀直接命中缓存，避免重复 prefill。这个机制对长文档问答、代码仓库分析这类场景尤其重要。它意味着 KV Cache 不再只是一次推理中的临时状态，而开始变成可复用的系统资源。

从这个角度看，DeepSeek-V4 的技术主线并不复杂：MoE 负责扩容，CSA/HCA 负责降低百万上下文的建模成本，Context Caching 负责把长上下文变成可重复使用的工程能力。

二、协议兼容与 Agent 生态

从官方文档看，V4 除了模型本身变化之外，在生态接入方式上也有一些变化。它同时支持 OpenAI Format 和 Anthropic Format，这意味着它既能接入传统 LLM 应用生态，也能进入以 Agent 为中心的工具链生态。

对 OpenAI Format 的兼容，解决的是传统应用迁移问题。大量企业知识库、RAG 系统、智能问答系统，以及 Spring AI、LangChain、LlamaIndex 这类框架，默认都是围绕 OpenAI 风格接口构建的。DeepSeek-V4 支持这一格式后，开发者通常只需要替换 base_url、api_key 和模型名，就能把已有系统平滑切换到 V4 上。

Anthropic Format 的意义则更偏向 Agent 工具链。Claude Code、OpenCode、OpenClaw 这类 Agent Runtime，更依赖结构化的工具调用、thinking 管理、状态传递和多轮任务执行能力。DeepSeek-V4 支持 Anthropic 风格接口，实际上是在主动适配这类执行环境。因为 Agent 场景不是普通聊天，它要求模型能够读取文件、调用工具、执行命令、接收结果、修正计划，并在多轮过程中持续维持执行状态。

这里其实有意思的点在于，V4 在有意的将 普通对话上下文与 Agent 执行上下文明确区分开了。在普通多轮对话里，上一轮的 reasoning content 可以不继续参与上下文；但在工具调用场景里，中间 reasoning 状态必须保留，否则任务链条会断裂。这个机制说明，V4 的上下文管理已经不再只是服务 “对话生成”，而是在服务 “连续执行”。

三、T 级训练的关键挑战

这部分其实是听了 张晓珺对罗福莉 3.5小时访谈，刚好谈到了 T 级参数的模型训练的挑战。

DeepSeek-V4-Pro 的 1.6T 总参数，说明前沿模型竞争已经进入 T 级 MoE 阶段。这里摘取几个点：

• • 预训练稳定性。T 级 MoE 训练不仅规模巨大，还涉及专家路由、负载均衡、跨节点通信、梯度稳定性等问题。模型一旦增大，任何小的不稳定都会被放大。特别是在 MoE 架构下，如果专家利用率不均衡，或者跨节点通信开销过大，训练效率和收敛质量都会受到影响。
• • Agent 后训练与 RL。Chat 时代，竞争重点更多放在预训练基座能力；Agent 时代，模型需要学会在环境中做事，包括工具调用、任务分解、执行反馈、错误恢复和多轮规划。这类能力很难单靠预训练自然获得，必须依赖更强的后训练系统，包括高质量任务轨迹、工具调用数据、环境反馈和 RL 训练基础设施。也就是说，T 级参数只是能力底座，真正决定模型执行边界的，是后训练体系。
• • 长上下文推理成本。模型支持 1M 上下文，并不意味着它能低成本地处理 1M 上下文。KV Cache 占用、prefill 延迟、吞吐表现和调用价格，都会直接影响模型的实际可用性。DeepSeek-V4 通过 CSA、HCA 和 Context Caching 去压缩这部分成本，正说明长上下文能力必须和推理系统一起设计，不能单靠模型结构硬撑。
• • 芯片与推理框架协同。T 级模型训练和部署已经不是单一算法问题，而是模型结构、训练框架、推理引擎、低精度算子、通信优化和硬件适配的系统工程。谁能在这条链路上做更深的协同，谁才能把“超大模型”真正变成“可用模型”。

所以，T 级训练的核心结论可以归结为一句话：1T 只是入场券，后训练、推理系统和工程协同，才决定模型能否形成真实竞争力。

四、总结

最后总结下DeepSeek-V4 的技术价值：

• • 第一，延续 MoE 路线，但重点已经不再是单纯扩参数，而是通过 CSA、HCA 和 Context Caching 把百万上下文的成本压下来，让长上下文走向可落地。
• • 第二，同时支持 OpenAI Format 和 Anthropic Format，对应两条不同的生态路径：一条面向传统应用接入，一条面向 Agent 执行接入。
• • 第三，反映出大模型竞争重心的变化。T 级参数已经不是最终壁垒，真正的壁垒在于后训练能力、推理系统能力、缓存体系能力，以及模型与硬件、框架、协议之间的协同能力。

搞工程也是懂文艺和哲学的：「不诱于誉，不恐于诽，率道而行，端然正己」。在这种模型竞赛白热化的阶段，还能秉持技术路线，保持极客精神，也值得我们我们每一个技术人员敬佩。