论文: DeepSeek LLM: Scaling Open Source Language Models with Longtermism
作者: DeepSeek-AI
发表时间: 2024-01
arXiv: 2401.02954
DeepSeek-LLM 是 DeepSeek 系列大语言模型的奠基之作。该论文通过在 2T token 中英双语数据上的系统性 Scaling Law 研究，发现数据质量会改变最优模型-数据配比，并首次实践了 HPC Co-Design（模型架构与高性能计算协同设计）理念，训练出 67B 参数的双语基础模型，在数学和代码任务上超越 LLaMA-2 70B。
这篇论文奠定了 DeepSeek 后续 V2/V3/R1 系列的全部技术基础——从数据策略、训练工程到开源哲学的整套方法论。
OpenAI 的奠基性论文发现模型参数 、数据量 与计算量 之间存在幂律关系：
其中系数 6 来自前向传播（2 FLOPs/param/token）和反向传播（4 FLOPs/param/token）的合计。在固定计算预算 下，最优配比为：
数值示例：若计算预算增加 10 倍（），则：
Chinchilla 论文反驳了 Kaplan 的结论，发现之前的研究低估了数据的重要性：
数值示例：同样计算预算增加 10 倍：
两种结论的矛盾：Kaplan 说扩参数为主，Chinchilla 说等比扩展。以 10B 模型、200B token 作为基线，扩展到 70B 的参数-数据配比差异：
| 扩展策略 | 70B 模型所需数据 | 70B 模型总计算量 | 适用场景 |
|---|---|---|---|
| Kaplan 最优 | ~350B token | 低质量数据更优 | |
| Chinchilla 最优 | ~700B token | 高质量数据更优 | |
| DeepSeek-LLM 实践 | 2T token | 双语+高质量数据 |
| 问题 | 说明 | DeepSeek-LLM 的应对 |
|---|---|---|
| 数据质量的影响 | 前人假设数据质量恒定，实际差异巨大 | 首次量化数据质量×最优配比关系 |
| 多语言数据 | 英文最优配比是否适用于中文？ | 双语实地验证 |
| 计算定义精度 | 忽略注意力 | 细化为 |
| 训练稳定性 | 大模型发散问题未被纳入 | HPC Co-Design 保障 |
DeepSeek-LLM 将计算预算细化为：
其中 是非嵌入层 FLOPs per token，精确反映各层的实际前向/反向计算量。
的具体构成（以 67B 模型为例）：
其中：
数值计算（67B 模型，80 层）：
对比 的粗估计：。细粒度模型 比 低 3.7 倍，因为嵌入层（约 10B 参数，主要用于词嵌入和输出投影）的计算量在 中被高估了。
核心发现：高质量数据可以支撑更大的模型。用公式表达：
给定数据集的信息熵 ，模型在 个 token 上可学习的有效信息量为：
其中 是数据集的熵， 是模型架构能容纳的最大信息量。
实际训练中的观察：
| 数据质量 | 训练 Loss @100B tokens | 训练 Loss @500B tokens | Loss 衰减率 | 最优模型-数据比 |
|---|---|---|---|---|
| 低质量（网页噪声） | 2.85 | 2.72 | 每100B降 0.033 | 1:1（Chinchilla） |
| 中等质量（通用语料） | 2.64 | 2.41 | 每100B降 0.058 | 1:1.2 |
| 高质量（精选+代码） | 2.38 | 2.05 | 每100B降 0.083 | 1:1.8 |
| 双语高质量 | 2.45 | 2.12 | 每100B降 0.066 | 1:1.5 |
数值示例：假设你有 FLOPs 的计算预算：
中文与英文的 token 效率差异显著：
| 语言 | 每词平均 token 数 | 2T token 等效词汇量 | 信息密度因子 |
|---|---|---|---|
| 英文 | ~1.3 | ~1.54T 词 | 1.0（基准） |
| 中文 | ~2.5 | ~0.8T 词 | 0.7 |
| 代码 | ~1.0 (per token/char) | ~2.0T 字符 | 1.5（高密度） |
DeepSeek-LLM 采用中英 1:1 配比，总 2T token：
因语言差异导致的有效数据量修正：
对于 2T token（1:1 配比）：
这意味着双语 2T token 的训练效果约等于纯英文 1.7T token。为达到等价的 Chinchilla 最优配比，DeepSeek-LLM 需要额外约 18% 的数据，论文也证实了这一结论。
传统做法：
模型设计 → 代码实现 → 硬件部署 → 发现瓶颈 → 修改模型
↘ 迭代 3-5 轮 ↙
HPC Co-Design：
硬件特性分析 → 并行策略设计 → 模型架构适配 → 一次高效执行
（协同进行，不迭代）
| 层级 | 配置 | 带宽 | GPU 数 |
|---|---|---|---|
| 节点内 | 8 × A100 (80GB) + NVLink | 600 GB/s | 8 |
| 节点内互联 | NVSwitch | 全互联 | 8 |
| 跨节点 | InfiniBand NDR | 200 Gbps/链路 | 多节点 |
| 总集群 | — | — | 数百 GPU |
┌─────────────────────────┐
│ 数据并行 (DP) │
│ 跨节点，粗粒度复制 │
└──────────┬──────────────┘
│
┌────────────────────┼────────────────────┐
│ 流水线并行 (PP) │ 流水线并行 (PP) │
│ 跨节点，4 阶段 │ 跨节点，4 阶段 │
└────────┬───────────┘ └────────┬─────────┘
│ │
┌────────┴───────┐ ┌─────────┴────────┐
│ TP (8路) │ │ TP (8路) │
│ Node 1: GPU │ │ Node 2: GPU │
│ [0-7] NVLink │ │ [8-15] NVLink │
└────────────────┘ └──────────────────┘
创新点：
效果对比：
| 策略 | 传统 naive 3D 并行 | DeepSeek Co-Design | 提升 |
|---|---|---|---|
| TP 通信耗时 | 15 ms/步 | 3 ms/步 | 5x |
| PP 气泡比率 | 15-20% | 8-10% | 2x |
| 有效计算利用率 | 35-40% | 55-60% | 1.5x |
| 端到端吞吐 | 100% (baseline) | 140-150% | 40-50% |
训练 67B 模型的理论显存需求：
| 组件 | 每参数大小 | 67B 需求 | 说明 |
|---|---|---|---|
| 模型权重 (FP16) | 2 bytes | 134 GB | 半精度存储 |
| 优化器状态 (Adam) | 12 bytes | 804 GB | m + v + FP32 copy |
| 梯度 (FP16) | 2 bytes | 134 GB | 反向传播累积 |
| 激活值 (per layer) | ~800 MB | ~64 GB | 取决于 seq_len × batch |
| 总计 | ~1.1 TB | 远超单卡 80 GB |
DeepSeek-LLM 的优化策略：
| 技术 | 节省显存 | 额外计算 | 实现方式 |
|---|---|---|---|
| 激活检查点 (选择性) | 60% | 15% | 只存 1/4 层的激活，其余重计算 |
| 8-bit Adam (FP32→INT8) | 50% (优化器) | 0% | 将 m/v 状态量化为 8-bit |
| 序列并行 (Sequence Parallelism) | 50% (激活) | 0% | 结合 TP，分解长序列 |
| ZeRO Stage 1 | 33% (优化器) | 0% | 分布式存储优化器状态 |
综合效果：将激活内存需求从 64 GB 降到约 12 GB，加上权重、梯度和优化器状态的分片，使单卡峰值显存在 72-76 GB 之间，留出余量用于计算。
传统同步训练的通信-计算时间线：
GPU 0: [计算]██████████[通信 ████████][计算]██████████[通信 ████████]
GPU 1: [计算]██████████[通信 ████████][计算]██████████[通信 ████████]
↑ 气泡 ↑ 等待 ↑ 重复
Co-Design 的异步重叠优化：
GPU 0: [计算]██████████[通信 ██░░][计算]██████████[通信 ██░░]
[计算待办] [计算待办]
GPU 1: [计算]██████████[通信 ██░░][计算]██████████[通信 ██░░]
[计算待办] [计算待办]
██ = 计算 ░░ = 后台通信（不阻塞）
实现细节（伪代码）：
# 传统做法：同步 all-reduce
loss.backward()
optimizer.step(all_reduce=True) # 阻塞 50-100ms
# Co-Design：异步梯度累积 + 通信重叠
for micro_batch in micro_batches:
loss = model(micro_batch)
loss.backward(retain_graph=False)
# 每完成一个梯度 bucket，立即启动异步通信
for bucket_id, bucket_grad in enumerate(model.grad_buckets):
if bucket_grad.is_ready():
# 异步启动 all-reduce，不等待完成
dist.all_reduce(bucket_grad, async_op=True)
# 当前线程继续处理下一 bucket
accumulate_next_bucket()
# 所有异步操作完成后再执行 optimizer.step()
dist.barrier()
optimizer.step()
效果量化：
| 通信类型 | 传统同步耗时 | Co-Design 耗时 | 隐藏比例 |
|---|---|---|---|
| TP 通信（NVLink） | 3 ms | <0.5 ms | 85% |
| PP 通信（IB） | 8 ms | 2 ms | 75% |
| DP 梯度同步 | 50 ms | 12 ms | 76% |
| 总体步耗时 | 1.2 s | 0.9 s | 25% 加速 |
| 配置项 | 数值 | 选择理由 |
|---|---|---|
| 层数 (n_layers) | 80 | 深度有利于深层语义理解 |
| 隐藏维度 (d_model) | 8192 | 标准 70B 级模型配置 |
| 注意力头数 (n_heads) | 64 | 每头 128 维，标准设计 |
| FFN 中间维度 (d_ff) | 22016 | SwiGLU 激活函数要求非对称维度 |
| 词表大小 (vocab_size) | 102,400 | 中英双语 BPE，覆盖更多汉字+英文字根 |
| 上下文长度 (pre-train) | 4096 | 稳定训练的初始长度 |
| 上下文长度 (fine-tune) | 16384 | 扩展到 4x，后续通过 YaRN 到 128K |
| 位置编码 | RoPE | 支持长度外推 |
| LayerNorm | Pre-LN + RMSNorm | 训练更稳定，无需均值中心化 |
| 归一化 eps | 1e-6 | 标准值 |
| 激活函数 (FFN) | SwiGLU | 比 ReLU/GELU 效果好，参数略多 |
SwiGLU 的数学定义：
其中 SiLU（Sigmoid Linear Unit）：
与常见激活函数的对比（在 7B 模型上的实验数据）：
| 激活函数 | MMLU (5-shot) | 训练稳定性 | FFN 参数占比 | 推理速度 |
|---|---|---|---|---|
| ReLU | 44.8 | 稳定 | 24.6B | 100% (基准) |
| GELU | 46.2 | 稳定 | 24.6B | 95% |
| SwiGLU | 48.3 | 稳定 | 26.3B | 88% |
| GeGLU | 47.9 | 略不稳定 | 26.3B | 86% |
SwiGLU 多出的 7% 参数换来了约 3-4% 的 MMLU 提升，是值得的权衡。
| 维度 | DeepSeek-LLM 67B | LLaMA-2 70B | 差异意义 |
|---|---|---|---|
| 词表大小 | 102,400 | 32,000 | 中文编码效率高 2x |
| 数据配比 | 代码:数学:语言 = 4:2:4 | 通用网页为主 | DeepSeek 代码倾向明显 |
| 训练数据量 | 2T token | 2T token | 量相同，质不同 |
| 训练硬件 | 自建 A100 集群 | Meta 大规模集群 | 工程约束不同 |
| 并行策略 | TP:8, PP:4, DP:自适应 | TP:8, PP:不定 | DeepSeek 更精细匹配硬件 |
| 对齐方法 | SFT + DPO | RLHF (PPO) | DPO 更简单 |
| 开源协议 | MIT 完全开源 | 受限开源 | 社区友好度 |
训练 67B 模型时——这是当时 DeepSeek 训练的最大模型——团队遇到了典型的大规模训练问题。
现象：训练到约 10 万步时，Loss 突然从 2.1 跳变为 NaN，约 30% 的训练实验曾遇到此问题。
解决方案：
# 梯度裁剪（防止梯度爆炸）
total_norm = torch.nn.utils.clip_grad_norm_(
model.parameters(),
max_norm=1.0, # 最大梯度范数
norm_type=2.0 # L2 范数
)
# 学习率回退（遇到 NaN 时自动恢复）
if torch.isnan(loss) or torch.isinf(loss):
# 回退到上一检查点
load_checkpoint(last_ckpt)
# 降低学习率
current_lr *= 0.8
logger.warning(f"NaN detected, rollback LR to {current_lr}")
continue
效果：NaN 崩溃率从 30% 降至 <1%。
现象：softmax 输入 logits 的绝对值在深层不断增长，导致 softmax 输出过于尖锐（近似 one-hot）。
原因：深层注意力层的值域累积放大，残差连接无法完全抑制。
解决方案：
增加缩放因子 （标准是 ）。实际效果：
| 缩放因子 | 最大 logit 值 (80 层) | softmax 熵 | 训练 Loss |
|---|---|---|---|
| 0.8 | 85.3 | 0.12 | 2.18 |
| 1.0 (标准) | 42.1 | 0.35 | 2.05 |
| 1.2 | 18.7 | 0.52 | 2.03 |
| 1.5 | 9.2 | 0.61 | 2.08 |
最优——既控制了 logit 爆炸，又没有过度平滑导致信息损失。
现象：深层（靠近输出层）的权重更新幅度是浅层的 10-20 倍，导致深层参数不稳定、浅层参数欠拟合。
解决方案：层自适应学习率（Layer-wise Adaptive LR）：
即：梯度范数大的层使用更小的学习率，反之亦然。
| 层区间 | 梯度范数 | 自适应 LR 乘子 | 原始更新幅度 | 调整后幅度 |
|---|---|---|---|---|
| Layer 1-20 | 0.002 | 5.0 | 0.002 | 0.010 |
| Layer 21-40 | 0.008 | 1.25 | 0.008 | 0.010 |
| Layer 41-60 | 0.015 | 0.67 | 0.015 | 0.010 |
| Layer 61-80 | 0.030 | 0.33 | 0.030 | 0.010 |
效果：各层更新幅度均匀在 0.010 附近，训练曲线更平滑。
当从 4096 扩展到 16384 上下文时：
| 上下文长度 | 稳定训练所需 Batch Size | 显存需求/GPU | Loss 异常率 |
|---|---|---|---|
| 4096 | 4M tokens | 72 GB | <1% |
| 8192 | 8M tokens | 76 GB | 3% |
| 16384 | 16M tokens | >80 GB (OOM) | 12% |
解决方案：使用位置编码插值+渐进式长度扩展，每次仅增加 2x 长度，配合更长 warmup。
Loss
│
2.6┤ warmup
│ ┌──┐
2.4┤ │ └──────────────────────────┐
│ │ 恒定学习率 │
2.2┤ │ └──────┐
│ │ cosine decay
2.0┤ │ └───
│ │
1.8┤ └──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──
0 20 40 60 80 100 120 140 160 180 200
训练步数 (K)
详细参数：
| 阶段 | 步数区间 | 学习率 | Batch Size | 持续时间 |
|---|---|---|---|---|
| Warmup | 0-4K | 0 → 1.5e-4 | 1M → 2M tokens | 2% |
| 恒定 | 4K-160K | 1.5e-4 | 2M → 4M tokens | 78% |
| Cosine Decay | 160K-200K | 1.5e-4 → 1.5e-5 | 4M tokens | 20% |
Batch Size 动态增加策略：
这样做的原因是：大 batch size 在训练初期会导致优化困难，先用小 batch 快速探索，稳定后逐步扩大提高吞吐。
原始数据（500TB+）
│
▼
[质量过滤]
├── 语言检测 (fastText): 过滤非中英文
├── 困惑度筛选: 排除 ppl > 30 的文档
├── 长度过滤: 排除 <200 token 或 >500K token 的文档
└── 去重: MinHash LSH 去重（阈值 0.7）
│
▼
[安全过滤]
├── PII 脱敏
├── 成人内容过滤: 基于关键词 + 分类器
└── 版权内容移除
│
▼
[质量评分]
├── 用 7B 语言模型计算每个文档的困惑度
├── 评分维度: 流畅度、信息密度、可预测性
└── 高分文档加权采样
│
▼
[数据混合]
└── 代码:数学:语言 = 4:2:4 的最终混合
│
▼
训练数据（2T token）
去重效果：
| 语言 | 原始数据 | MinHash 去重后 | 去重率 |
|---|---|---|---|
| 英文 | 180T | 1.2T | 99.3% |
| 中文 | 320T | 0.8T | 99.75% |
| 代码 | 50TB (文本) | 0.5T (token) | ~99% |
实验设置：在 1.3B 参数模型上测试不同数据配比，训练 200B token。
| 配比 (代码:数学:语言) | MMLU | HumanEval | GSM8K | C-Eval | 平均 |
|---|---|---|---|---|---|
| 2:1:7 | 45.2 | 14.5 | 12.3 | 38.7 | 27.7 |
| 3:1.5:5.5 | 47.1 | 17.2 | 13.8 | 40.2 | 29.6 |
| 4:2:4 | 48.3 | 20.1 | 15.4 | 42.1 | 31.5 |
| 5:2.5:2.5 | 46.8 | 21.3 | 15.9 | 35.4 | 29.9 |
| 6:3:1 | 44.2 | 22.0 | 16.1 | 28.3 | 27.7 |
结论：代码比例增加提升 HumanEval/GSM8K，但过度牺牲语言数据会显著降低 C-Eval 和 MMLU。4:2:4 是最优平衡点。
| 基准 | 指标 | DeepSeek 7B | DeepSeek 67B | LLaMA-2 7B | LLaMA-2 13B | LLaMA-2 70B | Mistral 7B |
|---|---|---|---|---|---|---|---|
| MMLU | 5-shot | 48.3 | 71.3 | 45.5 | 54.8 | 69.9 | 62.5 |
| GSM8K | 8-shot | 15.4 | 58.9 | 14.6 | 28.7 | 56.8 | 33.0 |
| HumanEval | pass@1 | 20.1 | 42.1 | 12.2 | 18.3 | 25.6 | 26.2 |
| MBPP | pass@1 | 33.2 | 52.3 | 21.5 | 32.8 | 38.7 | 40.5 |
| BBH | 3-shot | 38.5 | 68.7 | 35.2 | 46.9 | 64.9 | 57.7 |
| TriviaQA | 1-shot | 58.3 | 78.5 | 55.6 | 63.2 | 75.2 | 68.8 |
| Natural Questions | 1-shot | 22.1 | 38.7 | 19.8 | 25.4 | 33.5 | 27.6 |
关键观察：
| 基准 | 指标 | DeepSeek 7B | DeepSeek 67B | Qwen-7B | Baichuan2-7B | InternLM-7B |
|---|---|---|---|---|---|---|
| C-Eval | 5-shot | 42.1 | 68.5 | 62.3 | 54.0 | 53.6 |
| CMMLU | 5-shot | 45.3 | 71.2 | — | 57.2 | 51.0 |
| C3 | 0-shot | 65.4 | 78.9 | — | 65.8 | 63.4 |
| CLUEWSC | 0-shot | 68.7 | 82.3 | — | 70.1 | 72.3 |
67B 在中文任务上大幅领先同期 7B 级中文模型（合理，因为参数规模大 10x），但 7B 版本在中文上并不突出——说明 7B 级的双语模型在中文上仍有提升空间。
DeepSeek-LLM 在代码任务上的表现尤其亮眼：
| 任务 | DeepSeek 67B | LLaMA-2 70B | CodeLLaMA 34B | StarCoder 15B | CodeGeeX2 6B |
|---|---|---|---|---|---|
| HumanEval (pass@1) | 42.1 | 25.6 | 48.8 | 33.6 | 35.9 |
| HumanEval (pass@10) | 70.3 | 51.2 | 73.5 | 58.7 | 60.1 |
| MBPP (pass@1) | 52.3 | 38.7 | 55.6 | 45.9 | 45.2 |
| DS-1000 | 28.7 | 18.9 | 32.4 | 23.5 | 21.8 |
分析：
| 模型 | GPU 数量 | 训练时长 | 有效吞吐 | MFU (Model FLOPs Utilization) |
|---|---|---|---|---|
| DeepSeek-LLM 7B | 64 A100 | ~7 天 | 120 TFLOPs/GPU | 52% |
| DeepSeek-LLM 67B | 512 A100 | ~21 天 | 150 TFLOPs/GPU | 58% |
| LLaMA-2 7B (Meta) | 1024 A100 | ~3 天 | — | ~42% |
| LLaMA-2 70B (Meta) | 2048 A100 | ~21 天 | — | ~38% |
分析：
按 A100 (80GB) $1.5/GPU-hour 估算：
| 模型 | GPU | 时长 | GPU-hours | 估算成本 |
|---|---|---|---|---|
| DeepSeek-LLM 7B | 64 | 168h | 10,752 | ~$16K |
| DeepSeek-LLM 67B | 512 | 504h | 258,048 | ~$387K |
| 对齐 (SFT+DPO) | 128 | 48h | 6,144 | ~$9K |
| 总计 | ~275K | ~$412K |
对比 LLaMA-2 70B 的训练成本（估计 2M GPU-hours、$3M+），DeepSeek 通过 HPC Co-Design 将训练成本降低了约 7-8 倍。
预训练模型 (67B, 2T tokens)
│
▼
[SFT 监督微调]
├── 数据: ~100K 人工标注的高质量对话
├── 来源: 内部标注团队，涵盖中英文
├── 覆盖: 问答、写作、代码、数学推理、翻译
└── 训练: 3 epochs, LR 1e-5
│
▼
[DPO 直接偏好优化]
├── 数据: ~50K 偏好对
├── 生成: 对同一 prompt，用 SFT 模型采样 4-8 个回答
├── 标注: 人工排序 (Best-to-Worst)
└── 训练: 1 epoch, LR 5e-6
│
▼
对齐后模型 (Chat)
DPO (Direct Preference Optimization) 的数学核心：
传统 RLHF 需要训练一个独立的奖励模型 ，然后用 PPO 优化策略：
DPO 绕过奖励模型，直接从偏好数据推导最优策略：
其中 是偏好的回答， 是不偏好的回答， 是 sigmoid 函数。
实际效果对比（在 DeepSeek-LLM 67B 上）：
| 指标 | SFT 后 | SFT + DPO | SFT + RLHF (PPO) |
|---|---|---|---|
| 有用性 (Helpful) | 72% | 86% | 85% |
| 无害性 (Harmless) | 68% | 79% | 80% |
| MT-Bench | 5.8 | 6.8 | 6.7 |
| 训练时间 | - | ~12h (128 GPU) | ~36h (128 GPU) |
DPO 在效果上接近 RLHF，但训练时间仅为 1/3。
DeepSeek-LLM 最核心的理论发现：
数据质量改变 Scaling Law 的最优配比。
| 数据质量等级 | 最优 对 的指数 | 最优 对 的指数 | 适用场景 |
|---|---|---|---|
| 低质量 | 0.73 (Kaplan) | 0.27 (Kaplan) | 网络爬虫原始数据 |
| 中等质量 | 0.60 | 0.40 | 过滤后的通用数据 |
| 高质量 | 0.50 (Chinchilla) | 0.50 (Chinchilla) | 精选语料 |
| 超高质量 | 0.42 | 0.58 | 代码+数学+学术 |
这意味着：数据越好，越应该在小模型上投入更多数据（而非扩参数）。
| 数据配比偏好 | 模型特征 | 代表模型 |
|---|---|---|
| 代码 > 语言 | 推理能力强，但对话流畅度一般 | DeepSeek 系列 |
| 语言 > 代码 | 对话自然，但复杂推理弱 | 部分通用对话模型 |
| 学术 > 网页 | 知识密度高，但长尾知识缺失 | 学术领域模型 |
| 多语言均衡 | 语言覆盖广，但单语性能不足 | 多语言通用模型 |
DeepSeek-LLM 选择代码:数学:语言 = 4:2:4 的配比，直接决定了它"理工男"的模型性格——数学和代码强，但在开放式对话上需要对齐来弥补。
DeepSeek-LLM 证明了 HPC Co-Design 可以让小团队用较少资源训练大模型：
| 资源维度 | 传统方法 | HPC Co-Design |
|---|---|---|
| GPU 数量 | 2048 (LLaMA-2 70B) | 512 (DeepSeek 67B) |
| 训练时长 | ~21 天 | ~21 天 |
| GPU 利用率 | ~38% | ~58% |
| 单位算力产出 | 1x | 1.5x |
| 训练成本 | ~$3M+ ~$400K |
这一范式在后续 V2 的 MoE 架构和 V3 的 FP8 训练中得到延续和深化。
| 技术 | LLM 中的形态 | 后续演进 | 变化 |
|---|---|---|---|
| 标准 MHA | 64 头，4096d | V2: MLA | 低秩压缩 KV Cache，推理成本降 5-10x |
| Dense FFN | SwiGLU, 22016d | V2: DeepSeekMoE | 稀疏激活，计算量不变下扩参数 4x |
| RoPE | 标准 4096 | V2: 与 MLA 耦合 | 支持 128K 上下文 |
| HPC Co-Design | 初步实践 (TP:8, PP:4) | V2/V3: 系统方法论 | 支持超大规模 MoE 训练 |
| 双语数据 | 1:1 中英配比 | V2/V3: 多语言扩展 | 覆盖更多语种 |
| 开源哲学 | 全 MIT 开源 | 全系列开源 | 建立社区生态 |
| 局限 | 表现 | 后续改进 |
|---|---|---|
| 上下文长度有限 | 预训练仅 4096 | V2 支持 128K |
| 标准注意力 | 复杂度 | V2 被 MLA 替代 |
| 密集模型 | 67B 全参数激活 | V2 MoE 稀疏化 |
| 通用推理能力 | 复杂推理仍需提升 | R1 强化学习 |
| 多任务泛化 | 特定任务需微调 | 后续减少微调需求 |
| 能力维度 | DeepSeek-LLM 67B | LLaMA-2 70B | Mistral 7B | GPT-3.5 (参考) |
|---|---|---|---|---|
| 知识广度 | 良好 | 优秀 | 一般 | 优秀 |
| 代码能力 | 优秀 | 一般 | 良好 | 优秀 |
| 数学推理 | 优秀 | 良好 | 一般 | 优秀 |
| 中文理解 | 优秀 | 一般 | 差 | 良好 |
| 对话流畅度 | 需对齐 | 需对齐 | 良好 | 优秀 |
| 推理效率 | 低 (67B dense) | 低 | 高 | 中等 |
| 开源程度 | 完全开源 | 受限 | 完全开源 | 闭源 |
解读日期：2026-05-28
解读人：Lucy
版本：v2（已优化扩展）