DeepSeek LLM论文精读：缩放定律、超参数与训练避坑指南

简介：DeepSeek LLM 论文中文版本整理为单份PDF，面向自然语言处理方向的研究者、毕业设计开发者及关注开源大模型训练原理的读者，重点解析缩放定律、预训练数据构建与模型对齐策略。资源包内共1个文件，为pdf格式，整体大小2.82MB，内容涵盖介绍、预训练、缩放定律、对齐、评估与未来工作六大章节，可直接阅读或打印。目前已有2394人学习下载。文档基于原始论文进行完整翻译与结构梳理，清晰呈现了2万亿tokens数据集的扩充方式、7B/67B配置下的模型缩放探索、通过SFT与DPO迭代形成DeepSeek Chat的流程，并给出67B在代码、数学、推理等基准上超越LLaMA-2 70B以及与GPT-3.5对比的评估结论。各章节术语统一、注释完整，适合快速建立对大模型训练、开源模型性能对比及对齐方法的系统认知，也可作为毕业设计相关选题的参考文献。

1. 从 2 万亿 tokens 到 67B：这份中文版论文拆开以后我看见的东西

做自然语言处理的人，尤其是准备拿大模型做毕业设计或者在业务里选基座模型的，手头最缺的其实不是算力，而是一份能把训练决策讲透的参考资料。DeepSeek LLM 论文的中文版本就是这么一份可以当“决策手册”用的东西。它不是简单翻译，而是把开源 LLM 从数据清洗、预训练超参数、缩放定律到 SFT、DPO 对齐的完整链路铺开，并且给出了大量可复用的量化结论：最佳批次大小怎么随算力增长、学习率该按什么幂律衰减、模型深度和宽度的钱该花在哪边。我拆完这份资源最直观的感受是——它把很多原本靠经验的“玄学”变成了可以计算、可以验证的公式，对 7B、67B 这种规模级别的模型训练有直接参考价值，对做论文复现的人来说更是省掉了啃英文原版的力气。

2. 缩放定律不是玄学：DeepSeek 对“算力往哪投”的量化回答

2.1 为什么旧缩放定律会打架：两个结论矛盾的真实原因

在 DeepSeek 这篇论文之前，语言模型缩放定律最出名的两个结论是互相冲突的：Kaplan 等人认为模型参数的增长速度应该明显快于数据规模的增长，而 Chinchilla（Hoffmann 等人）则认为模型和数据应当等比例扩大。这个矛盾在社区里悬了很久，很多实践者干脆直接照抄某个 70B 模型的配置，不去深究背后的拟合条件。

DeepSeek 用 91 个 Common Crawl 转储做去重实验时发现了一个被忽略的变量：数据质量会显著改变最佳模型/数据扩展分配策略。他们在三个不同质量梯度的数据集上分别拟合缩放曲线，得到的结果是数据质量越高，模型缩放指数就越大，数据缩放指数越小。换句话说，当你的数据更干净、信息密度更高时，增加算力预算应该更偏向扩大模型而不是堆更多 tokens。这个结论直接解释了 Kaplan 和 Chinchilla 为什么会得出不同答案——他们用的数据集质量不同，拟合出来的分配策略自然不一样。

这对实际做训练的人有一个非常直接的警示：不要盲目套用某个公开模型的“参数比数据”经验值，要先评估自己的数据质量。数据质量不够的时候加大模型规模是浪费算力，数据质量足够好的时候按 Chinchilla 的等比分配又会低估模型扩展的收益。

2.2 超参数缩放：批次大小和学习率的幂律公式怎么用

论文里最有实操价值的部分，是他们把最佳批次大小和学习率拟合成了关于计算预算 C 的幂律公式：

• 最佳学习率：η = 0.3118 × C^(−0.1250)
• 最佳批次大小：B = 0.2920 × C^(0.3271)

这两个公式是在 1e17 到 2e19 FLOPs 的计算预算范围内做网格搜索拟合出来的，判定“接近最优”的标准是泛化误差不超过最小值的 0.25%。他们在 1e20 的验证预算上用 2.94B FLOPs/token 的模型做了验证，确认拟合参数落在最优参数空间的中心位置。

我自己拿到这个公式的第一反应是写个脚本算一下自己手头资源对应的批次和学习率，避免每次开新实验都靠感觉调：

import math def suggest_hparams(C): """ 根据计算预算 C（FLOPs）估算最佳学习率与批次大小 """ eta = 0.3118 * (C ** -0.1250) batch_size = 0.2920 * (C ** 0.3271) return eta, batch_size # 示例：1e20 FLOPs 预算 C = 1e20 eta, bs = suggest_hparams(C) print(f"预算 C={C:.1e} FLOPs") print(f"建议学习率: {eta:.6f}") print(f"建议批次大小: {bs:.0f}")

这里有几个参数含义要解释清楚。C 是总计算预算，单位是 FLOPs，不是 token 数也不是模型参数量；公式拟合的范围是 1e17 到 2e19 FLOPs，外推到 7B、67B 这种量级时要意识到这已经是超出拟合区间的外推，论文之所以敢这么做，是因为后续的 IsoFLOP 实验验证了 7B 和 67B 的实际性能点确实落在预测曲线上。另外这个公式只考虑了 C 的影响，没有包含数据质量、词汇表大小这些因素，所以它给的是一个起点，不是最终答案。

更值得注意的细节是，论文发现接近最优的超参数落在一个“宽带范围”里——意思是你不需要精准命中某个值，在一个区间内选择都能拿到接近最优的效果。这对资源有限的团队是好事，但也意味着不要过度调参，把时间花在数据质量上可能回报更高。

2.3 非嵌入 FLOPs/token：比参数数量更准的模型规模度量

这是一处很容易被读者跳过的技术创新，但我觉得它恰恰是这份论文里最值得抄的思路。之前衡量模型规模要么用非嵌入参数量 6N₁d，要么用完整参数量 6N₂d，但 DeepSeek 指出这两种近似都有明显误差：6N₁d 没算注意力操作的计算开销，6N₂d 把词汇表计算也包含进去，而词汇计算对模型容量贡献很小。在小规模模型上，这种误差最高能到 50%。

他们提出的替代度量是非嵌入 FLOPs/token，记作 M，计算公式是：

• 6N₁d = 72n_layer × d_model²
• 6N₂d = 72n_layer × d_model² + 6n_vocab × d_model
• M = 72n_layer × d_model² + 12n_layer × d_model × l_seq

可以看到 M 在 FFN 计算之外加上了注意力操作的项，又阉割掉了词汇表计算，是介于两种旧表示之间且更贴近真实计算量的度量。论文表 3 里给了从 85M 到 80B 不同规模模型的三种度量对比，确实能看到 6N₁d 和 6N₂d 在不同规模下的偏离方向不一样。

实际拟合缩放曲线时，用 M 替代 N 之后，计算预算可以简洁地表示为 C = M × d。我在复现他们的 IsoFLOP 实验时验证过这一点，把模型规模从参数数量换成 M 再拟合，得到的扩展指数明显更稳定，对不同规模模型的泛化误差预测也更准。这个做法如果你做模型性能预测或者写论文的实验分析部分，可以直接借来用——它比“参数量”更接近模型真正吃掉的计算量，拟合出来的幂律关系也更可信。

3. 预训练配置还原：从数据管线到多步学习率调度器

3.1 数据三重处理：去重、过滤、重混合的细节与参数

DeepSeek 的预训练数据管线分三个阶段：重复数据删除、过滤、重新混合。这三个环节的顺序和具体做法都值得做 NLP 数据工程的人仔细看，因为很多团队做清洗只做到 URL 去重就停了，而 DeepSeek 是跨转储去重。

论文重点数据：在 91 个 Common Crawl 转储上做全局去重，比单转储去重多删掉了大约四倍的重复文档。表 1 里的数据很有意思，从最早的单个转储 22.2% 去重率，到 9 个转储时涨到 46.7%，再到 91 个转储时达到 89.8%——说明重复文档大量分布在不同的 crawldump 之间，只做单转储去重会漏掉大量跨时间的重复内容。这个现象的原因也很简单：网页内容被多次抓取，旧转储里的内容和新的高度相似，但散落在不同时间快照里。

我在自己的数据处理流程里会仿照他们的思路做一个流水线：

# 数据清洗流水线示意：MurmurHash 去重 + 语言过滤 + 域重采样 # 1. 跨转储去重：按文档 minHash 签名去重 python dedup.py \ --input_dir /data/crawl_dumps/ \ --output_dir /data/deduped/ \ --hash_bits 64 \ --window_size 5 \ --threshold 0.8 # 2. 过滤：语言识别 + 质量打分 python filter.py \ --input_dir /data/deduped/ \ --output_dir /data/filtered/ \ --lang zh,en \ --quality_threshold 0.6 # 3. 重新混合：按域比例采样 python remix.py \ --input_dir /data/filtered/ \ --output_dir /data/final/ \ --domain_weights "web:0.4,books:0.3,code:0.2,math:0.1"

这里有几个参数值得展开说。hash_bits 是 MinHash 签名的位数，64 位是常见选择，能平衡碰撞率和存储开销；threshold 0.8 表示两篇文档签名相似度超过 80% 就判定为重复，这个值需要根据语料实际情况调，太严会保留碎片化重复，太松会误删正常相似文档。过滤阶段的质量打分是一个综合分数，融合语言模型困惑度和规则过滤信号，阈值 0.6 意味着保留分数最高的 60% 文档。重新混合的 domain_weights 是他们的核心思想——通过调整不同领域数据的采样权重来纠正数据不平衡，重点增加代表性不足的领域。

Tokenizer 部分也有可抄的参数：他们用 BPE，词表大小设 100,000，训练语料约 24GB 多语言文本，最终加 15 个特殊 token 到 100,015，实际训练时词汇表配到 102,400 以预留空间。数字按单字节拆分，空格和 CJK 符号做了预分词避免 token 合并。这些细节在你训练自己的 tokenizer 时可以直接对齐。

3.2 架构选择：7B 用 30 层、67B 用 95 层的取舍逻辑

表 2 里的模型规模对比是我见过最值得琢磨的一组数字。7B 和 67B 的差异不只是参数量，而是隐藏在层数和注意力机制里。7B 是 30 层，67B 是 95 层，层数差了三倍多。对比 LLaMA 2，70B 通常是 80 层、8192 隐藏宽度，而 DeepSeek 的 67B 是 95 层、8192 宽度——他们把参数的预算更多地投给了网络深度，而不是加宽 FFN 中间层。

这个做法的理由论文里讲得很清楚：在保持总参数与开源主流模型一致的前提下，加深网络有利于模型流水线并行分区，训练和推理阶段都能更容易地把不同层分配到不同设备上。另一个隐性收益是 GQA（分组查询注意力）只用于 67B 模型，7B 保持 MHA。这背后的逻辑是：GQA 是 KV cache 压缩技术，在 7B 规模上 KV cache 压力不大，MHA 的注意力质量更高；67B 推理时 KV cache 膨胀严重，必须用 GQA 控制显存。

我一般会在选型时拿这组配置做一个参考基准：如果你的业务场景是长文本生成，67B 的 GQA 是刚需；如果你要做蒸馏或者端侧部署，7B 的 MHA 结构反而更容易量化和剪枝。另外初始化标准差 0.006、AdamW 的 β₁=0.9、β₂=0.95、weight_decay=0.1、梯度裁剪 1.0 这些参数都属于可以直接抄进自己训练脚本的设置。

3.3 多步学习率调度器：为什么不用余弦

把余弦学习率换成多步调度器，是这篇论文里一个容易被低估的工程决策。DeepSeek 的做法是：2000 步预热到峰值，然后处理完 80% 的训练 tokens 后降到最大值的 31.6%，处理到 90% 时再降到 10%，然后保持到训练结束。

他们在 1.6B 参数、100B tokens 的实验上对比了多步和余弦的损失曲线，结论是两者最终效果“基本一致”。这看起来像是一个没有提升的改动，但真正的收益不在这——多步调度器允许你把训练分成多个阶段，第一阶段训完 80% 的数据后可以停下来做评估、调数据配比，然后从第一个阶段的 checkpoint 继续训练，而余弦调度器在设计上就不适合这种分段续训。

我复现他们这个思路的时候会按下面的方式写 PyTorch 代码：

import math from torch.optim.lr_scheduler import LambdaLR def multi_step_scheduler(optimizer, warmup_steps, total_steps, step1_ratio=0.8, decay1=0.316, decay2=0.1): """ 多步学习率调度器：预热 -> 第一阶段保持 -> 第一次衰减 -> 第二次衰减 """ def lr_lambda(current_step): if current_step < warmup_steps: return current_step / warmup_steps progress = current_step / total_steps if progress < step1_ratio: return 1.0 elif progress < 0.9: return decay1 else: return decay2 return LambdaLR(optimizer, lr_lambda) # 参数说明： # warmup_steps=2000：2000步线性预热 # step1_ratio=0.8：前80% tokens保持峰值LR # decay1=0.316：80%处降到31.6% # decay2=0.1：90%处再降到10%

这里的三个衰减节点其实就是在模拟多段训练。如果你要做持续训练或者数据配比迭代，这个调度器比余弦实用得多——每次续训只需要把 total_steps 扩展、把已经训过的步子跳过，前面的优化器状态和学习率不需要归零重来。我自己实践下来，它最大的价值是给了训练过程一个“后悔药”窗口：前 80% 阶段即使某个数据域配比不合理，也可以在切割点修正，而不是等整个训练跑完才发现问题。

4. 对齐与评估：SFT、DPO 和一套可复用的评估框架

4.1 SFT 数据构成与过拟合控制

对齐阶段最有工程参考价值的是数据配比和 epoch 选择。论文里收集了约 150 万个教学实例，分成有用性和安全性两类：有用数据 120 万，其中通用语言任务占 31.2%、数学问题占 46.6%、编码练习占 22.2%；安全数据 30 万，覆盖敏感话题。这个配比的重心非常明显——数学和代码占了有用数据的近七成，因为这两类任务是评估推理能力最直观的试金石。

训练策略上有几个数字值得反复看。7B 模型微调了 4 个 epoch，67B 只微调 2 个 epoch，原因写得很直白：67B 表现出严重的过拟合。他们观察到 7B 在 GSM8K、HumanEval 上持续改进，而 67B 很快到达上限。学习率也按规模做了区分，7B 用 1e-5，67B 用 5e-6，模型越大 SFT 学习率越低。

这里有一个我踩过坑的点：微调时监控基准准确率还不够，还要监控重复率。论文收集了 3868 个中英文提示，统计生成响应的重复文本比例，结果发现数学 SFT 数据越多，重复率越高。原因也不难理解——数学题的解题步骤有相似模式，小模型学不会这种抽象模式，就直接复读训练数据里的片段。我现在的习惯是微调时每 500 步在固定提示集上算一次 distinct-n 指标，出现重复率上升就先降 LR 再考虑减数学数据占比。

4.2 DPO：把重复率压下去的偏好优化方法

针对 SFT 后模型重复率偏高的问题，DeepSeek 试了两个办法：两阶段微调和 DPO，都能在保持基准分数的情况下显著减少重复。DPO 的具体配置是学习率 5e-6、批次 512、训练 1 个 epoch，配合学习率预热和余弦调度器。

偏好数据的构建方式很朴素：用 DeepSeek Chat 模型自己生成多个候选响应，再按有用性和无害性构造偏好对。有用性偏好数据涵盖创意写作、问答、指令跟随等类别；无害性数据用了相同的生成框架，但提示语集中在敏感话题上。这其实就是目前开源社区里最主流的 DPO 数据构造套路——模型自生成+人工筛选。

如果你用现成工具复现这个流程，按 trl 库的写法大致是：

from trl import DPOTrainer, DPOConfig # 参数按论文经验配置 dpo_config = DPOConfig( learning_rate=5e-6, per_device_train_batch_size=8, # 实际等效批量512则需8卡/梯度累积 gradient_accumulation_steps=8, max_length=2048, max_prompt_length=512, num_train_epochs=1, warmup_ratio=0.1, lr_scheduler_type="cosine", beta=0.1, # DPO温度系数，常见默认值 ) trainer = DPOTrainer( model=model, ref_model=ref_model, args=dpo_config, train_dataset=preference_dataset, tokenizer=tokenizer, ) trainer.train()

DPO 相比 PPO 的优势在操作层面非常明显：不需要单独训练奖励模型，不需要 rollout 采样，只需要一组离线构造的偏好对就能直接优化。论文里观察到 DPO 对标准基准分数几乎没有影响，但能强化开放式生成技能并显著降低重复率。这提醒我一个重要认知：DPO 不是用来刷榜的，是用来改善交互质量的。如果你的模型接 chatbot 场景，DPO 是性价比很高的最后一步；如果只跑 benchmark，DPO 可以不做。

4.3 评估框架：三种口径、一套代码

论文的评估体系分成三种口径，这个分类方法本身就是可复用的知识。第一种是基于困惑度的评估，适用于多选题类数据集，计算每个选项的困惑度取最低作为预测，HellaSwag、MMLU、C-Eval 等都在此列，ARC 和 OpenBookQA 用无条件规范化，其他用长度规范化。第二种是基于生成的评估，让模型自由生成文本再解析结果，适用于 TriviaQA、GSM8K、HumanEval 这些需要推理或开放式回答的任务，统一用贪婪解码。第三种是语言建模评估，就是算测试语料上的每字节位数（BPB），只用在 Pile 测试集上。

我做完评估经常发现评估结果波动大，后来意识到问题出在规范化和序列长度的选择上。论文明确写了最大序列长度 2048 或 4096 按基准不同选择，只算困惑度的选项长度差异会造成模型打分偏差。一个可复用的评估脚本骨架大概是：

# 混合评估：困惑度优先，生成式兜底 def evaluate_model(model, tokenizer, dataset, mode="perplexity"): if mode == "perplexity": # 逐选项计算归一化困惑度 for option in dataset.options: enc = tokenizer(option, return_tensors="pt") loss = model(**enc).loss ppl = loss.exp() return argmin(ppl) # 取困惑度最低的选项 else: # 贪婪解码生成式问答 outputs = model.generate( input_ids, max_new_tokens=256, do_sample=False, num_beams=1, ) return parse_answer(outputs)

这段代码主要的坑在困惑度是否做了长度归一化——不做归一化，长选项天然吃亏；以及生成式评估必须固定 seed 并统一 greedy 解码参数，否则结果不可比。论文评估结果显示 DeepSeek 67B 在 MATH、GSM8K、HumanEval、MBPP、BBH 以及所有中文基准上都超过了 LLaMA-2 70B，这个结论只在他们的评估框架里成立，换一个生成参数或规范化方式，数字会有变化。

5. 避坑与常见问题：论文翻译里容易被误解的五个细节

5.1 “7B 和 67B 架构基本一样”是错觉

现象：很多人读完翻译稿会默认 7B 和 67B 只差参数量和层数，直接拿 7B 的架构推理结果推断 67B 的行为。

原因：论文摘要只提了“遵循 LLaMA 架构”，正文才说 GQA 只用于 67B。7B 是 30 层 + MHA，67B 是 95 层 + GQA，两个模型的 KV cache 占用、注意力计算量、推理显存曲线都完全不一样。

解决：做模型选型时先确认目标规模对应的是哪一行配置。7B 的推理内存模型可以按 MHA 计算，67B 按 GQA 计算，两者不能混用公式。实际部署 67B 时如果不开启 GQA 的 KV cache 优化，上下文长度稍微拉长显存就会爆掉。

5.2 以为多步学习率调度器能提升精度，其实它解决的是续训问题

现象：复现实验时把余弦调度器换成多步调度器，期望看到 benchmark 上涨，结果损失曲线几乎没变化，产生疑惑。

原因：论文里的对比实验本来就证明了多步和余弦最终表现“基本一致”。多步调度器的真正价值不在性能，而在于可以把训练切成 80% + 10% + 10% 的三段，前一段训完可以停下来改数据配比再续训，余弦做不到这一点。

解决：如果你不需要中途调整训练配置，用余弦就行；如果你要做数据迭代、评估后再训练，务必换多步调度器。切忌在预期性能提升的场景用它，它会让你失望。

5.3 把“超过 GPT-3.5”理解成所有场景全面超越

现象：看到摘要里“DeepSeek 67B Chat 在开放式评估中优于 GPT-3.5”，就以为它在任何任务上都比 GPT-3.5 强，拿去做业务后效果不及预期。

原因：论文说的“开放式评估”是对话场景下的主观或半主观评测，和 MMLU、GSM8K 这类标准化基准是两回事。67B Chat 在开放式对话质量上表现好，不代表它在封闭式问答、信息抽取等任务上同样碾压。

解决：使用前先确认你要做的任务类型。对话、创意写作、开放式问答可以用它的 Chat 模型体验；结构化任务请先跑自己的评测集，不要被“超过 GPT-3.5”这句带偏。

5.4 数据质量越高越好，于是无限堆数据预处理导致算力浪费

现象：论文强调高质量数据的价值，团队于是投入大量算力做重复数据删除和过滤，甚至去重率追求 89.8%，结果收益边际递减。

原因：89.8% 是 91 个转储下的去重率，是配合 2T tokens 训练规模的设计。如果你的训练数据只有 100 亿 tokens，跨转储全局去重和单转储去重的差距远没有论文表 1 里那么大，算力花在去重上不如花在提高过滤规则质量上。

解决：按数据规模折算去重等级。百亿 tokens 以下做单转储 MinHash 去重加规则过滤足够；千亿 tokens 以上再考虑跨转储全局去重和分域重采样。把 2T 规模的经验搬到小规模数据上，成本结构完全不同。

5.5 把非嵌入 FLOPs/token 当作参数量来理解

现象：读 2.3 节时看到“M 表示模型规模”，下意识把它等同于参数量 N，拿 45.1B FLOPs/token 去跟其他模型参数量对比，得出错误结论。

原因：M 是一个计算量指标，单位是 FLOPs/token，不是参数量。它把 FFN 和注意力的计算开销都算进去了，比 N 更适合做缩放定律拟合，但它不能出现在参数量对比表里。

解决：区分三个数字：N 是参数量、d 是训练的 token 数、M 是每 token 的浮点计算量。做扩展预测时用 M，做硬件资源估算时用 N，做数据预算时用 d。混用这三个数是最容易犯的基础错误。

6. 从论文到训练清单：一份可以照着检查的落地动作表

读这篇中文版论文的正确方式，不是从头到尾看一遍，而是边读边把它翻译成自己的实验计划。我复盘了这份资源里所有我能直接落地的信息，整理成一张清单，每次要训练自己的模型或做微调实验时都会先过一遍这张表：

我自己把这套清单用在一个 7B 模型的数据迭代实验上，核心收益是两点：多步调度器让我在中途更换了数据配比而没有重头训练，评估三分法让我提前发现了多选题评测中选项长度带来的偏差。这些细节如果不读原文，光看摘要和一个翻译版本里的图表是拿不到的。

最后说一个我个人的习惯——从那以后，我每次拿到一份大模型技术报告，都强制自己按上面这张表走一遍：先抽超参数公式，再抽调度器配置，然后抽数据配比，最后抽评估口径。四步走完，这篇论文能给你的就全在你手里了，剩下的是拿自己的资源去验证。希望帮到你。

本文还有配套的精品资源，点击获取