简介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 等人认为模型参数的增长速度应该明显快于数据规模的增长而 ChinchillaHoffmann 等人则认为模型和数据应当等比例扩大。这个矛盾在社区里悬了很久很多实践者干脆直接照抄某个 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): 根据计算预算 CFLOPs估算最佳学习率与批次大小 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_modelM 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 270B 通常是 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_decay0.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_ratio0.8, decay10.316, decay20.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_steps20002000步线性预热 # step1_ratio0.8前80% tokens保持峰值LR # decay10.31680%处降到31.6% # decay20.190%处再降到10%这里的三个衰减节点其实就是在模拟多段训练。如果你要做持续训练或者数据配比迭代这个调度器比余弦实用得多——每次续训只需要把 total_steps 扩展、把已经训过的步子跳过前面的优化器状态和学习率不需要归零重来。我自己实践下来它最大的价值是给了训练过程一个“后悔药”窗口前 80% 阶段即使某个数据域配比不合理也可以在切割点修正而不是等整个训练跑完才发现问题。4. 对齐与评估SFT、DPO 和一套可复用的评估框架4.1 SFT 数据构成与过拟合控制对齐阶段最有工程参考价值的是数据配比和 epoch 选择。论文里收集了约 150 万个教学实例分成有用性和安全性两类有用数据 120 万其中通用语言任务占 31.2%、数学问题占 46.6%、编码练习占 22.2%安全数据 30 万覆盖敏感话题。这个配比的重心非常明显——数学和代码占了有用数据的近七成因为这两类任务是评估推理能力最直观的试金石。训练策略上有几个数字值得反复看。7B 模型微调了 4 个 epoch67B 只微调 2 个 epoch原因写得很直白67B 表现出严重的过拟合。他们观察到 7B 在 GSM8K、HumanEval 上持续改进而 67B 很快到达上限。学习率也按规模做了区分7B 用 1e-567B 用 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_rate5e-6, per_device_train_batch_size8, # 实际等效批量512则需8卡/梯度累积 gradient_accumulation_steps8, max_length2048, max_prompt_length512, num_train_epochs1, warmup_ratio0.1, lr_scheduler_typecosine, beta0.1, # DPO温度系数常见默认值 ) trainer DPOTrainer( modelmodel, ref_modelref_model, argsdpo_config, train_datasetpreference_dataset, tokenizertokenizer, ) trainer.train()DPO 相比 PPO 的优势在操作层面非常明显不需要单独训练奖励模型不需要 rollout 采样只需要一组离线构造的偏好对就能直接优化。论文里观察到 DPO 对标准基准分数几乎没有影响但能强化开放式生成技能并显著降低重复率。这提醒我一个重要认知DPO 不是用来刷榜的是用来改善交互质量的。如果你的模型接 chatbot 场景DPO 是性价比很高的最后一步如果只跑 benchmarkDPO 可以不做。4.3 评估框架三种口径、一套代码论文的评估体系分成三种口径这个分类方法本身就是可复用的知识。第一种是基于困惑度的评估适用于多选题类数据集计算每个选项的困惑度取最低作为预测HellaSwag、MMLU、C-Eval 等都在此列ARC 和 OpenBookQA 用无条件规范化其他用长度规范化。第二种是基于生成的评估让模型自由生成文本再解析结果适用于 TriviaQA、GSM8K、HumanEval 这些需要推理或开放式回答的任务统一用贪婪解码。第三种是语言建模评估就是算测试语料上的每字节位数BPB只用在 Pile 测试集上。我做完评估经常发现评估结果波动大后来意识到问题出在规范化和序列长度的选择上。论文明确写了最大序列长度 2048 或 4096 按基准不同选择只算困惑度的选项长度差异会造成模型打分偏差。一个可复用的评估脚本骨架大概是# 混合评估困惑度优先生成式兜底 def evaluate_model(model, tokenizer, dataset, modeperplexity): if mode perplexity: # 逐选项计算归一化困惑度 for option in dataset.options: enc tokenizer(option, return_tensorspt) loss model(**enc).loss ppl loss.exp() return argmin(ppl) # 取困惑度最低的选项 else: # 贪婪解码生成式问答 outputs model.generate( input_ids, max_new_tokens256, do_sampleFalse, num_beams1, ) 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 层 MHA67B 是 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. 从论文到训练清单一份可以照着检查的落地动作表读这篇中文版论文的正确方式不是从头到尾看一遍而是边读边把它翻译成自己的实验计划。我复盘了这份资源里所有我能直接落地的信息整理成一张清单每次要训练自己的模型或做微调实验时都会先过一遍这张表论文给出的内容我的落地动作超参数幂律公式 η0.3118C^-0.125、B0.2920C^0.3271用脚本算自己预算下的学习率和批次起点不拍脑袋设多步学习率调度器80%-31.6%、90%-10%训练脚本里替换余弦调度器分段存储 checkpoint留续训余地数据三重处理去重-过滤-重混合先做单转储去重数据量够大再加跨转储重混合按域权重采样SFT7B 用 4 epoch、67B 用 2 epoch模型参数翻倍时 epoch 数先减半时刻盯过拟合信号SFT 数据配比通用 31.2%、数学 46.6%、代码 22.2%推理增强优先堆数学和代码数据但控制同类题目比例防重复率飙升DPOlr5e-6、batch512、1 epoch只做偏好优化时按这个配置起步不动基准期望评估三分法困惑度、生成式、语言建模多选题用长度归一化困惑度生成的用 greedy 解码固定 seed非嵌入 FLOPs/token 度量 M做缩放预测或扩展分析时代替参数量作为模型规模坐标我自己把这套清单用在一个 7B 模型的数据迭代实验上核心收益是两点多步调度器让我在中途更换了数据配比而没有重头训练评估三分法让我提前发现了多选题评测中选项长度带来的偏差。这些细节如果不读原文光看摘要和一个翻译版本里的图表是拿不到的。最后说一个我个人的习惯——从那以后我每次拿到一份大模型技术报告都强制自己按上面这张表走一遍先抽超参数公式再抽调度器配置然后抽数据配比最后抽评估口径。四步走完这篇论文能给你的就全在你手里了剩下的是拿自己的资源去验证。希望帮到你。本文还有配套的精品资源点击获取