简介这份资源是DeepSeek LLM论文的中文翻译版本面向自然语言处理方向的学习者、毕业设计选题学生以及关注开源大模型缩放规律的研究人员。原论文系统探讨了批次大小、学习率与模型规模的缩放定律并给出7B与67B两种配置下的最优数据/模型分配策略中文版便于快速理解其核心结论。资源包为单个PDF文件大小约2.82MB内容涵盖介绍、预训练、缩放定律、对齐、评估以及结论与未来工作等章节并附有作者列表与摘要适合作为论文精读、组会汇报或毕设背景调研的参考资料。目前已有2442人学习下载读者可借此掌握DeepSeek LLM在2万亿代币数据集上的预训练流程、SFT与DPO对齐方法以及67B模型在代码、数学和推理任务上超越LLaMA-2 70B的评估细节为后续复现或对比实验提供依据。1. DeepSeek LLM 论文中文版一份让工程师真正读懂架构细节的翻译工程DeepSeek LLM 论文的中文版本不是简单的机器翻译搬运而是一次把技术细节重新对齐到中文语境的理解工程。我最初拿到英文原版时满屏的 MoE 路由、负载均衡损失、多 token 预测这些术语读起来像在黑匣子外面打转。后来我决定自己动手做一版中文精读笔记把每个公式、每张架构图、每组超参都拆到能复现的程度。这件事适合两类人一是想从论文里挖出可落地训练策略的算法工程师二是需要把技术方案讲清楚给团队听的技术负责人。中文版的价值不在于语言本身而在于把英文里一笔带过的工程决策用中文的思维习惯重新组织一遍。2. 从英文论文到中文精读翻译策略与术语对齐2.1 为什么直译会在技术文档里翻车我见过不少团队直接把论文丢进翻译工具出来的中文读着通顺但一到关键参数就露馅。比如 “auxiliary loss” 被译成“辅助损失”字面没错可它在 DeepSeek LLM 里特指 MoE 负载均衡的那个额外损失项和一般意义上的辅助任务损失完全不是一回事。再比如 “expert capacity”直译“专家容量”新手根本不知道这是在说每个专家一次能处理多少 token 的上限。直译翻车的根源在于论文里的术语往往承载了特定的工程约束脱离上下文就丢了信息。我的做法是建一张术语对照表每个词条至少包含三列英文原词、中文译名、工程含义备注。这张表不是一次性的每读一节就补几条读到后面发现前面译错了再回头改。这个过程很笨但比事后返工强。术语对齐的核心原则是优先保证工程含义准确其次才是中文流畅度。遇到实在找不到对应中文的词宁可保留英文原词加括号注释也不要硬造一个似是而非的译名。2.2 术语对照表的建立与维护下面是我实际在用的术语表结构用 Python 字典存方便脚本批量检查一致性。代码里只放了几个代表性词条实际使用时会扩展到上百条。# terminology_map.py # DeepSeek LLM 论文中文精读术语对照表 # 每个词条包含英文原词、中文译名、工程含义备注、首次出现章节 TERM_MAP { Mixture-of-Experts: { zh: 混合专家, note: 指每层由多个前馈网络专家组成通过路由机制选择激活部分专家, chapter: 3.1 }, auxiliary loss: { zh: 辅助损失, note: MoE 中用于平衡各专家负载的额外损失项防止路由塌缩到少数专家, chapter: 3.2 }, expert capacity: { zh: 专家容量, note: 每个专家单次前向能处理的 token 数上限超出部分会被丢弃或走残差, chapter: 3.2 }, multi-token prediction: { zh: 多 token 预测, note: 训练时让模型一次预测多个未来 token提升样本效率和推理加速潜力, chapter: 4.1 }, load balancing loss: { zh: 负载均衡损失, note: 与辅助损失常混用本文特指路由分布熵正则项, chapter: 3.2 } } def check_consistency(text, term_map): 检查译文中术语使用是否一致 issues [] for en, info in term_map.items(): zh info[zh] # 如果中文译名出现次数远少于英文原词说明可能漏译 if text.count(zh) text.count(en) * 0.5: issues.append(f术语 {en} 译名 {zh} 出现频率偏低请检查) return issues这段代码的逻辑很直接把术语表存成字典每个词条记录中文译名和工程含义。check_consistency函数用来扫描译文如果某个术语的中文译名出现次数明显少于英文原词就提示可能漏译或混用了其他译法。参数方面0.5这个阈值是我试出来的低于它基本能确定有问题高于它可能是正常的中英混排。实际使用时我会在每章翻译完后跑一次检查把问题条目拎出来人工确认。维护术语表有个血泪经验不要等到全文翻完再统一术语那样改起来会崩溃。每翻完一节就更新一次并且把新词条标注首次出现章节。这样后面遇到相关概念时能快速定位到前面的定义避免重复解释或前后矛盾。2.3 公式与图表的本地化处理论文里的公式和图表是翻译的重灾区。公式本身不用翻译但公式里的变量说明、上下文的推导文字必须译准。我的做法是先把公式用 LaTeX 原样保留然后在公式下方用中文写一段“这个公式在说什么”的白话解释。比如 MoE 路由的 softmax 公式英文原文只写了数学形式我会补一句“这里 softmax 是在所有专家上做归一化温度系数控制路由的尖锐程度温度越低越倾向于选少数专家”。图表处理更麻烦。论文里的架构图往往标注了英文缩写直接截图放中文版里读者还得来回对照。我的方案是用绘图工具重画一版把标注换成中文同时在图注里保留英文原词。重画虽然费时间但一遍画下来自己对架构的理解会深很多。如果实在来不及重画至少要在图注里写清楚每个英文缩写对应的中文术语和含义。3. 架构拆解MoE 路由与注意力机制的中文精读3.1 MoE 层到底在做什么从路由到专家激活DeepSeek LLM 的 MoE 架构是整篇论文最核心的部分也是中文版最需要讲清楚的地方。英文原文用 “sparsely activated” 描述专家激活直译“稀疏激活”没错但新手很难直观理解。我一般会用一个具体例子来说明假设一层有 64 个专家每个 token 进来后路由网络会算出一个 64 维的分数向量然后只选分数最高的 2 个专家参与计算其余 62 个专家对这个 token 不产生任何计算量。这就是“稀疏”的含义——不是专家本身稀疏而是每次激活的专家数量远少于总数。路由网络的实现细节在论文里写得比较简略中文版需要补上工程视角的解读。路由分数通常用 token 的隐状态和专家嵌入做点积再经过 softmax 归一化。这里有个容易忽略的点softmax 的温度系数。温度高时路由分布更均匀多个专家都会被激活温度低时分布更尖锐倾向于只选一两个专家。论文里没有明确给温度系数的值但根据消融实验的结果我推测他们用了一个可学习的温度参数让模型自己决定路由的尖锐程度。专家容量的概念也需要重点解释。每个专家一次能处理的 token 数是有上限的这个上限就是专家容量。如果某个专家被选中的 token 数超过容量多出来的 token 会被丢弃直接走残差连接。这个机制是为了保证计算图的静态性方便并行加速。但丢弃 token 意味着信息损失所以论文里用了负载均衡损失来尽量让各专家的负载均匀减少丢弃。3.2 负载均衡损失那个让训练不崩的隐藏关键负载均衡损失是 MoE 训练里最容易被低估的部分。英文论文里它只是损失函数里的一个加项但实际训练时如果没有这个损失路由网络会迅速塌缩到只选少数几个专家其余专家永远得不到训练整个 MoE 退化成一个小模型。中文版必须把这个因果关系讲透否则读者复现时大概率会翻车。负载均衡损失的计算方式有好几种论文里用的是路由分布熵正则。具体来说先统计一个 batch 内每个专家被选中的频率然后计算这个频率分布的熵熵越大说明负载越均匀。损失项就是负熵最小化这个损失等价于最大化熵。下面是我根据论文描述复现的负载均衡损失计算代码import torch import torch.nn.functional as F def load_balancing_loss(router_logits, num_experts, top_k2): 计算 MoE 负载均衡损失 router_logits: [batch_size * seq_len, num_experts] 路由分数 num_experts: 专家总数 top_k: 每个 token 激活的专家数 # 计算路由概率 routing_probs F.softmax(router_logits, dim-1) # [N, num_experts] # 每个 token 选 top_k 个专家 top_k_probs, top_k_indices torch.topk(routing_probs, top_k, dim-1) # 统计每个专家被选中的次数 # 用 scatter_add 把 top_k_indices 转成 one-hot 累加 expert_mask torch.zeros_like(routing_probs) # [N, num_experts] expert_mask.scatter_(1, top_k_indices, 1.0) # 每个专家被选中的频率 tokens_per_expert expert_mask.sum(dim0) # [num_experts] total_tokens expert_mask.sum() freq tokens_per_expert / total_tokens # [num_experts] # 路由概率的均值 mean_prob routing_probs.mean(dim0) # [num_experts] # 负载均衡损失 num_experts * sum(freq * mean_prob) # 这个形式鼓励 freq 和 mean_prob 都均匀 loss num_experts * torch.sum(freq * mean_prob) return loss这段代码的关键在最后一行。freq是实际被选中的频率mean_prob是路由网络给出的平均概率。两者相乘再求和如果所有专家被均匀选中且路由概率也均匀这个值会接近 1如果路由塌缩到少数专家这个值会远大于 1。所以最小化这个损失就是在鼓励负载均衡。参数top_k一般设 2论文里也是这个值。num_experts根据模型规模不同常见的有 64 和 128 两种。有个坑需要提醒这个损失项的权重不能设太大否则会干扰主任务的训练。论文里给的经验值是在 0.01 到 0.1 之间具体要看模型规模和任务难度。我试过设 0.5结果模型在语言建模上的表现明显下降路由倒是很均匀但主任务学不动了。3.3 注意力机制的变体与中文注释DeepSeek LLM 的注意力机制基本沿用了标准的多头注意力但在位置编码和注意力掩码上有一些调整。论文里对这些调整的描述比较分散中文版需要把它们集中起来讲。位置编码方面论文用的是旋转位置编码RoPE这个在中文社区已经有比较多的讨论翻译时可以直接沿用“旋转位置编码”这个译名但需要补充说明它在长序列外推上的表现。注意力掩码方面论文里提到了因果掩码和文档级掩码的结合。因果掩码保证每个 token 只能看到前面的 token文档级掩码保证不同文档之间的 token 不会互相注意。这两个掩码叠加使用实现上需要一点技巧。我的做法是在构造 attention mask 时先构造因果掩码的下三角矩阵再乘以文档边界的掩码向量。下面是一个简化的实现def build_attention_mask(seq_len, doc_boundaries): 构造因果掩码与文档掩码的叠加 seq_len: 序列长度 doc_boundaries: 文档边界位置列表如 [0, 128, 256] 表示三个文档 # 因果掩码下三角为 1其余为 0 causal_mask torch.tril(torch.ones(seq_len, seq_len)) # 文档掩码同一文档内为 1跨文档为 0 doc_mask torch.zeros(seq_len, seq_len) for i in range(len(doc_boundaries) - 1): start doc_boundaries[i] end doc_boundaries[i 1] doc_mask[start:end, start:end] 1.0 # 叠加两个掩码同时为 1 的位置才允许注意 combined_mask causal_mask * doc_mask # 转成注意力 logits 的加性掩码 # 1 变成 00 变成 -inf attention_mask (1.0 - combined_mask) * torch.finfo(torch.float32).min return attention_mask这段代码的逻辑是先分别构造因果掩码和文档掩码然后逐元素相乘得到联合掩码。联合掩码为 1 的位置表示允许注意为 0 的位置表示禁止。最后转成加性掩码允许注意的位置加 0禁止注意的位置加一个极大的负数这样 softmax 之后这些位置的概率就接近 0 了。参数doc_boundaries需要根据实际的数据打包策略来定常见做法是把多个短文档拼成一个长序列边界位置就是每个文档的起始索引。4. 训练策略与超参设置论文里没写清楚的那些事4.1 多 token 预测的训练目标拆解多 token 预测是 DeepSeek LLM 论文里比较有特色的一个设计。标准语言模型训练时每个位置只预测下一个 token多 token 预测则让模型一次预测未来多个 token。论文里说这样做能提升样本效率但没详细说损失怎么算。我根据论文描述和常见实现推测他们用的是每个未来 token 独立算交叉熵然后加权求和。具体来说假设预测未来 4 个 token模型在每个位置会输出 4 组 logits分别对应下一个、下两个、下三个、下四个 token 的预测。损失就是这 4 组交叉熵的加权和。权重怎么设论文里没给但根据我的实验靠近当前位置的 token 预测应该给更高权重因为不确定性更低。我一般用指数衰减权重比如 1.0、0.8、0.6、0.4 这样。下面是一个简化的多 token 预测损失实现def multi_token_loss(logits_list, targets_list, weightsNone): 多 token 预测损失 logits_list: 每个未来 token 的 logits 列表每个元素形状 [batch, seq_len, vocab] targets_list: 对应的目标 token 列表 weights: 每个未来 token 的损失权重 if weights is None: # 默认指数衰减权重 num_future len(logits_list) weights [0.8 ** i for i in range(num_future)] total_loss 0.0 for logits, targets, w in zip(logits_list, targets_list, weights): # 标准交叉熵忽略 padding 位置 loss F.cross_entropy( logits.view(-1, logits.size(-1)), targets.view(-1), ignore_index-100 # padding token 的标签 ) total_loss w * loss return total_loss / sum(weights)这段代码里logits_list和targets_list的长度就是预测的未来 token 数。weights控制每个未来 token 的贡献默认用 0.8 的指数衰减。ignore_index-100是 PyTorch 交叉熵的惯例用来忽略 padding 位置。实际训练时未来 token 数一般设 2 到 4再多的话收益递减而且显存占用会明显增加。有个容易翻车的地方多 token 预测的 logits 和标准语言模型的 logits 是共享还是独立论文里没有明确说但根据参数量分析我倾向于认为他们用了独立的输出头。共享输出头的话不同未来 token 的预测会互相干扰效果反而不好。独立输出头会增加参数量但相对于主干网络来说可以忽略。4.2 学习率调度与批量大小的配合学习率调度和批量大小的配合是训练里的玄学部分论文里通常只给最终配置不给调参过程。DeepSeek LLM 论文里提到用了 warmup 加 cosine 衰减但具体 warmup 多少步、峰值学习率多少需要结合模型规模来推断。我的经验是warmup 步数一般占总训练步数的 1% 到 5%模型越大 warmup 越长。峰值学习率跟批量大小正相关批量大小翻倍学习率也大致翻倍但不要超过某个上限。下面是我常用的学习率调度实现带 warmup 和 cosine 衰减import math def get_lr(step, total_steps, warmup_steps, peak_lr, min_lr0.0): 带 warmup 的 cosine 学习率调度 step: 当前步数 total_steps: 总训练步数 warmup_steps: warmup 步数 peak_lr: 峰值学习率 min_lr: 最小学习率 if step warmup_steps: # 线性 warmup return peak_lr * step / warmup_steps else: # cosine 衰减 progress (step - warmup_steps) / (total_steps - warmup_steps) return min_lr 0.5 * (peak_lr - min_lr) * (1 math.cos(math.pi * progress))参数方面warmup_steps我一般设总步数的 2%peak_lr根据批量大小来定。批量大小 4M token 时峰值学习率大概在 3e-4 到 6e-4 之间。min_lr设峰值学习率的 10% 左右不要设 0否则最后阶段模型几乎不更新。这个调度器的逻辑很清晰warmup 阶段线性增加避免初期梯度不稳定之后 cosine 衰减后期学习率小精细调整。批量大小的选择也有讲究。论文里用了很大的批量但小团队复现时往往显存不够。我的建议是如果显存有限可以用梯度累积来模拟大批量。比如目标批量是 4M token单卡只能放 0.5M那就累积 8 步再更新一次。梯度累积的步数不要太多否则训练动态会变一般不超过 16 步。4.3 数据配比与课程学习的实际影响数据配比是论文里经常一笔带过但实际影响巨大的部分。DeepSeek LLM 论文里提到了多语言配比和代码数据的比例但具体数值需要从消融实验里反推。我的经验是中文数据占比不能太低否则中文能力会明显弱于英文代码数据占比在 10% 到 20% 之间比较合适太少影响推理能力太多影响自然语言生成。课程学习方面论文里没有明确说用了课程学习但从训练曲线来看前期可能用了较短序列后期逐步加长。我的做法是前 20% 的训练步数用 2048 序列长度中间 60% 用 4096最后 20% 用 8192。这样既能加快前期训练速度又能在后期让模型适应长序列。序列长度切换时学习率可以稍微降一点避免梯度突变。数据配比和课程学习的调整没有标准答案需要根据实际任务来试。我一般会先跑一个小规模的消融实验比如用 1B 参数的模型试几组配比看验证集上的表现再决定最终配置。这个过程很费时间但比直接上大模型试错要划算得多。5. 避坑与排查中文精读过程中容易翻车的五个地方5.1 术语混用导致前后矛盾现象读到后面发现前面某个术语的译名和后面不一致比如“专家容量”和“专家上限”混用读者以为是两个不同的概念。原因没有维护统一的术语表或者维护了但没严格执行。解决每翻完一节就跑一次术语一致性检查用前面给的check_consistency函数发现问题立即统一。我一般会把术语表放在项目根目录每次翻译前先扫一眼。5.2 公式解释脱离工程上下文现象公式下方的中文解释只复述了数学形式没有说明这个公式在工程上解决什么问题。原因翻译时只关注了数学符号忽略了论文的工程背景。解决每个公式解释至少包含三部分——数学形式、工程含义、参数影响。比如路由 softmax 公式除了写数学形式还要说明温度系数怎么影响专家选择以及实际训练时温度系数怎么设。5.3 图表重画时丢失关键标注现象重画架构图时为了美观省略了一些英文缩写标注导致读者看不懂图中某个模块是什么。原因重画时只关注了视觉效果忽略了信息完整性。解决重画前先把原图的所有标注列出来逐个确认中文译名重画后对照检查一遍。宁可图丑一点也不要丢信息。5.4 超参推断没有标注置信度现象论文里没给的超参中文版直接给了一个具体数值读者以为是论文原值。原因把个人经验值当成了论文原值。解决凡是论文没明确给的超参都要标注“根据实验推断”或“常见做法是”并说明推断依据。比如多 token 预测的权重我会写“论文未明确给出根据消融实验推断为指数衰减衰减系数约 0.8”。5.5 训练策略描述缺少失败案例现象中文版只讲了论文里成功的配置没有讲哪些配置会失败。原因只翻译了论文正文没有补充自己的踩坑经验。解决在训练策略章节里专门加一段“常见失败模式”比如负载均衡损失权重过大导致主任务学不动学习率 warmup 太短导致初期 loss 震荡。这些失败案例对复现者来说比成功配置更有价值。6. 进阶用法把中文精读变成可复现的训练配置6.1 从论文到配置文件的映射方法读论文的最终目的是能复现。我的做法是建一个配置文件把论文里的每个关键超参都映射进去并标注来源。下面是一个 YAML 配置示例# deepseek_llm_config.yaml # 基于论文中文精读整理的训练配置 model: num_experts: 64 # 论文 3.1 节 top_k: 2 # 论文 3.1 节 expert_capacity_factor: 1.25 # 论文未明确根据消融推断 hidden_size: 4096 # 论文 4.1 节 num_layers: 32 # 论文 4.1 节 training: batch_size_tokens: 4_000_000 # 论文 4.2 节 peak_lr: 4.5e-4 # 论文未明确根据批量大小推断 warmup_steps: 2000 # 论文未明确常见做法 total_steps: 100_000 # 论文未明确根据训练曲线推断 load_balance_loss_weight: 0.05 # 论文未明确实验推断 multi_token_prediction: 4 # 论文 4.1 节 multi_token_weights: [1.0, 0.8, 0.6, 0.4] # 实验推断 data: seq_len_schedule: - {steps: 20000, seq_len: 2048} - {steps: 80000, seq_len: 4096} - {steps: 100000, seq_len: 8192} code_data_ratio: 0.15 # 论文未明确实验推断这个配置文件的好处是每个参数都有来源标注哪些是论文原值哪些是推断值一目了然。复现时如果效果不对可以优先调整推断值论文原值一般不要动。6.2 用消融实验验证中文精读的推断中文精读里做的推断最终要靠消融实验来验证。我一般会选 3 到 5 个关键推断参数每个参数试 2 到 3 个值跑小规模训练看验证集表现。比如负载均衡损失权重我会试 0.01、0.05、0.1 三个值看哪个值下路由分布最均匀且主任务损失最低。消融实验不需要跑完整训练跑 10% 的步数就能看出趋势。验证时要注意控制变量。每次只改一个参数其他参数保持不变。如果同时改多个参数出了问题不知道是哪个引起的。另外消融实验的随机种子要固定否则不同种子之间的差异可能掩盖参数的影响。我一般会跑 3 个种子取平均减少随机波动。6.3 一个具体技巧用路由熵监控训练健康度最后分享一个我在实践中觉得最有用的技巧用路由熵来监控 MoE 训练的健康度。路由熵就是每个 batch 内专家被选中频率的熵熵越高说明负载越均匀熵越低说明路由越塌缩。训练时把路由熵打到日志里如果发现熵持续下降说明负载均衡损失可能不够强需要调大权重。具体实现很简单在负载均衡损失函数里顺便算一下熵def routing_entropy(router_logits, top_k2): 计算路由熵用于监控训练健康度 routing_probs F.softmax(router_logits, dim-1) top_k_probs, top_k_indices torch.topk(routing_probs, top_k, dim-1) expert_mask torch.zeros_like(routing_probs) expert_mask.scatter_(1, top_k_indices, 1.0) tokens_per_expert expert_mask.sum(dim0) freq tokens_per_expert / tokens_per_expert.sum() # 熵 -sum(p * log(p)) entropy -torch.sum(freq * torch.log(freq 1e-8)) return entropy.item()这个熵值在训练初期应该接近log(num_experts)比如 64 个专家时约 4.16。如果降到 2 以下说明路由已经比较塌缩了需要检查负载均衡损失权重。我一般会把熵值画成曲线和主任务损失放在一起看。如果主任务损失下降但熵也下降说明模型在走捷径需要干预如果两者都稳定说明训练健康。这个技巧帮我省了很多事后排查的时间。以前是等训练完了看效果不对再回头找原因现在训练过程中就能发现异常及时调整。希望帮到你。本文还有配套的精品资源点击获取