DeepSeek-V3 技术报告

官方源标题：DeepSeek-V3 Technical Report
作者：DeepSeek-AI｜版本：arXiv v2，2025-02-18｜论文：arXiv:2412.19437

核心结论

三个值得记住的结论

1. 它用“总量大、每次只用一小部分”控制计算。 模型共有 671B 参数，但每个 token 只激活 37B；这让容量与单次计算量不必一起增长。来源：摘要；§1；§6
2. 省成本不是一个魔法技巧，而是一整套配合。 MLA 压缩生成时的缓存，DeepSeekMoE 选择少量专家，FP8 降低训练计算与存储开销，DualPipe 尽量把跨机器通信藏在计算后面。来源：§2–§3
3. 结果很强，但“训练便宜”要带条件理解。 官方训练共用 2.788M H800 GPU 小时；按论文假设的每 GPU 小时 2 美元约为 557.6 万美元。不过这个数字不含此前的架构、算法、数据研究和消融成本。来源：§1

问题

模型变大后，计算、显存和通信会一起变贵

大模型想学到更多模式，通常需要更多参数和数据。但如果每次生成都调用全部参数，训练和推理成本也会同步膨胀。DeepSeek-V3 的问题可以概括成一句话：怎样把模型容量推到 671B，同时让每个 token 的实际计算、生成缓存和跨机器通信仍可承受？来源：§1–§3

前作已经给了骨架，这次重点是规模化补强

DeepSeek-V3 沿用 DeepSeek-V2 验证过的两块骨架：MLA 用压缩表示减少 KV cache，DeepSeekMoE 把前馈网络拆成共享专家和按需选择的路由专家。V3 新增的重点是不用主要辅助损失来维持专家负载、加入多词预测目标，并用 FP8、DualPipe 与显存优化把整套架构推到更大规模。来源：§1；§2.1；§3

方法

每次只叫少数专家来处理 token

DeepSeekMoE 把大量参数分散到许多专家中。路由器根据当前 token 与专家的匹配程度，选出少数专家参与计算；共享专家则处理更通用的信息。于是模型可以拥有 671B 总参数，却只为每个 token 激活 37B。来源：§2.1.2；表 2

用路由偏置调流量，不让均衡目标直接拉扯模型

常见做法会把“专家必须均衡”写成训练损失，这可能干扰模型学习。V3 监测整批 token 的专家负载：专家过载，就降低它下轮被选中的路由偏置；专家空闲，就提高偏置。这个偏置只影响“选谁”，不会乘到专家输出上。论文仍保留了一个权重极小的序列级均衡损失，用来防止单条序列出现极端失衡，所以“无辅助损失”并不等于完全没有任何均衡损失。来源：§2.1.2；§4.5.2–4.5.3

训练时多猜一步，推理时可以拆掉辅助模块

普通语言模型主要预测下一个 token。V3 的多词预测（MTP）还让辅助模块预测更远的 token，从同一段数据得到更密的训练信号。主模型训练完成后可以独立运行，辅助模块可直接移除，因此论文消融中的对照模型推理成本相同；它也可以保留下来做推测解码。来源：§2.2；§4.5.1

把低精度、流水线和显存优化当作一个系统

论文用 FP8 执行大部分密集矩阵乘法，同时让敏感操作保持更高精度；在约 1T tokens 的较小规模验证中，FP8 相对 BF16 的损失误差始终低于 0.25%。DualPipe 让前向、反向计算与跨节点通信尽量重叠，再配合重计算、CPU 保存参数滑动平均值等办法节省显存。作者报告整个训练没有不可恢复的 loss spike，也没有回滚。来源：§3.2–§3.3；附录 B；摘要

证据与局限

最直接的证据来自同数据、同设置的消融

MTP 消融保持训练数据和其他架构不变。在 228.7B 总参数模型上，加入 MTP 后 HumanEval Pass@1 从 44.5 升到 53.7，DROP F1 从 68.5 升到 70.6，但 MMLU 从 67.5 降到 66.6。这说明它多数任务受益，却不是每项都涨。来源：§4.5.1，表 4

无辅助损失策略也做了同类消融。在 228.7B 模型上，HumanEval 从 40.2 升到 46.3，GSM8K 从 70.7 升到 74.5；MMLU 则从 68.3 降到 67.2。进一步实验发现，按 batch 做辅助均衡能得到与无辅助损失方法相同的验证损失。这支持的更窄结论是：放松“每条序列都均衡”的约束可能有利于专家分工；它不能证明所有收益只来自移除辅助损失。来源：§4.5.2–4.5.3，表 5

完整模型在数学、代码和长上下文上表现突出

在作者统一评测的基础模型对比中，DeepSeek-V3-Base 的 MATH 为 61.6、HumanEval 为 65.2、MMLU 为 87.1；对应的 LLaMA-3.1 405B Base 分别为 49.0、54.9、84.4。聊天模型评测中，V3 的 MATH-500 为 90.2、LiveCodeBench CoT 为 40.5、LongBench v2 为 48.7。它也有明显短板：SimpleQA 为 24.9，低于 GPT-4o 的 38.2；SWE-Bench Verified 为 42.0，低于 Claude-3.5-Sonnet 的 50.8。来源：§4.4，表 3；§5.3，表 6

这些数字不能回答所有问题

大部分比较由作者自己的评测框架完成，闭源模型通过 API 测试；这能保证报告内部尽量统一，却不等于独立复现。论文没有公开 14.8T tokens 的完整数据构成，也没有给出从早期探索到最终模型的全部研发算力。作者还明确承认：推荐的部署单元较大，会给小团队带来负担；固定 benchmark 也可能让能力看起来比实际更好。来源：§4.4；§6

实际意义

真正可复制的是联合设计思路

对模型团队，最有用的启示不是照搬 671B 规模，而是把模型结构、数值精度、并行策略、通信内核和部署一起设计。某一层省下的计算，如果换来另一层更严重的通信拥堵，系统成本并不会真正下降。这是本文证据支持后的工程解读，不是作者单独验证过的产品结论。

选用它之前，先问三个现实问题

• 你的部署环境能否容纳一个很大的 MoE 服务单元，而不只是看“每 token 激活 37B”？
• 你的核心任务更像论文占优的数学、代码、中文和长上下文，还是更像它相对薄弱的事实问答与软件修复？
• 你比较的是官方训练成本，还是包含数据、失败实验、研发人员和线上冗余专家在内的总成本？

研究附录：术语、来源与待验证问题

• MoE（混合专家）：参数被分成多个专家，每个 token 只路由到少数专家；“总参数”不等于一次推理全部参与。
• MLA（多头潜在注意力）：把注意力的键和值压缩成潜在表示，主要目标是减少生成阶段的 KV cache。
• FP8：8 位浮点格式。V3 不是让所有操作都用 FP8，而是让大部分矩阵乘法用 FP8，敏感部分保留更高精度。
• 仍需独立验证：完整训练能否在别的集群复现；公开权重在不同推理框架中的真实吞吐、延迟和总拥有成本；训练数据构成对评测结果的影响。

主源：arXiv 摘要页｜arXiv HTML 全文｜PDF