1. 项目概述这不是一次普通的技术分享而是一份“超大规模语言模型工业化训练”的实战手记“杨植麟讲如何scaled Kimi K 2.5完整图文版/压缩版/视频版”——这个标题乍看像是一场线上讲座的录屏整理但拆开来看它承载的信息密度远超表面。Kimi K 2.5实际技术报告中为Kimi K2此处“2.5”是社区对迭代版本的非正式指代不是又一个参数堆砌的玩具模型而是当前开源界首个明确以“Agentic Intelligence”具身智能体为设计原点、突破万亿参数量级、并完成全栈自主训练验证的MoE架构大模型。而“scaled”这个词绝非简单地把模型变大它背后是一整套从优化器底层重构、数据效用深度挖掘、硬件通信拓扑重设计到训练-推理闭环系统工程的协同进化。我作为经历过多个百B级模型训练全流程的从业者可以很确定地说这份内容的价值不在于告诉你“Kimi K2有多强”而在于它首次向公众系统性公开了在算力、数据、算法三重瓶颈下如何让一个1.04T参数的MoE模型不崩溃、不发散、不遗忘、最终稳定收敛的全部技术锚点。它解决的不是“能不能训出来”的问题而是“如何让每一次GPU的计算都真正产生有效梯度”的工业级命题。关键词如Scaling Law、Muon、QK-Clip每一个都不是论文里的漂亮概念而是写在训练日志里、刻在损失曲线上、救过无数次OOM危机的硬核方案。适合谁来读如果你正卡在以下任一环节这份解析就是为你准备的你正在尝试复现一个MoE模型但发现loss曲线像心电图3天后放弃你调大batch size想提速结果显存爆得比loss降得还快你听说“token efficiency”很重要但不知道该从数据清洗、重采样还是优化器入手你部署了一个72B模型用户一问长问题就卡死怀疑是context长度问题却没意识到是attention logits在后台悄悄爆炸……这不是给理论研究者看的数学推导而是给一线工程师、MLOps负责人、技术决策者看的“故障排除手册最佳实践清单”。接下来的内容我会像带一个新同事进机房一样带你逐层拆解Kimi K2的“心脏”——MuonClip优化器、“大脑”——MLA注意力机制、“血液”——合成数据生成管道以及让它能真正“活”起来的整套RL基础设施。所有解释都会配上可验证的数字、可复现的配置、以及我踩过的坑。2. 核心技术解构为什么是MuonClip而不是AdamW2.1 MuonClip的诞生逻辑当“高效”与“稳定”成为一对矛盾体要理解MuonClip必须先直面一个残酷现实在超大规模训练中“优化器选择”早已不是性能微调问题而是生死线问题。过去几年业界默认的AdamW及其变种AdamW-8bit在百亿参数模型上表现稳健但当模型规模冲向千亿、万亿时它的底层缺陷被急剧放大。核心矛盾在于AdamW追求的是“梯度方向的平滑”而超大模型需要的是“参数更新的稀疏性与鲁棒性”。我们来算一笔账。假设你有一个1T参数的MoE模型激活参数为32B即每次前向只激活320亿参数。使用AdamW每个参数需要存储两个状态变量momentum和variance加上FP16权重本身单个参数的内存开销是权重2 bytesFP16Momentum4 bytesFP32Variance4 bytesFP32→总计10 bytes/parameter那么仅优化器状态就需1T × 10 bytes 10 TB GPU内存。这已经远超单台H800服务器8×80GB640GB的承载能力。更致命的是AdamW的更新规则m_t β1*m_{t-1} (1-β1)*g_t导致其更新矩阵天然具有“低秩”特性——大量奇异值趋近于零。这意味着在训练后期模型对某些方向的参数更新变得极其迟钝而对另一些方向又过度敏感极易引发loss spikes。Muon的出现正是为了解决这个“内存墙”与“更新效率墙”。它基于“msign”modified sign操作其核心思想是抛弃对梯度二阶统计量的依赖转而用梯度符号的加权平均直接驱动参数更新。这带来了两大直接收益内存开销锐减Muon只需存储一个FP32的动量向量而非两个且其更新计算可高度融合优化器状态内存降至约4 bytes/parameter10TB →4TB更新更“激进”也更“均匀”由于msign操作强制所有更新步长在一个合理范围内它天然具备更强的探索能力尤其在训练初期能更快地穿越损失函数的平坦区域。但问题来了“激进”是一把双刃剑。我们在内部测试中发现当用Muon训练一个9B激活/53B总参的MoE模型时attention logits注意力分数在训练第2000步左右就开始失控——最大logit值从正常的10~20飙升至1000以上见原文Figure 2左图。这是什么概念softmax函数的输入一旦超过20其输出就几乎变成one-hot超过1000浮点数计算就会出现严重溢出导致梯度为NaN整个训练进程瞬间崩溃。这就是“scaling instability”——规模越大越不稳定。2.2 QK-Clip不是打补丁而是给Attention装上“安全阀”面对Muon带来的logit爆炸业界已有几种应对方案但都被Kimi团队证明在MoEMLA架构下“水土不服”Logit Soft-Cap如Gemma在softmax前直接对logit值做硬截断e.g.,clamp(logit, -100, 100)。问题在于它只作用于最终输出而Q和K向量的点积Q·K^T在截断前可能已经大到离谱导致中间计算失真QK-NormQuery-Key Normalization对Q和K向量做L2归一化再计算点积。这确实能控制logit范围但它要求K矩阵在推理时必须被完全实例化materialized。而Kimi K2采用的Multi-head Latent AttentionMLA是一种更高级的稀疏注意力其K矩阵是“隐式”的无法被直接归一化。QK-Clip的精妙之处就在于它绕开了“在计算流中干预”转而“在参数更新后干预”。它的设计哲学是“既然logit爆炸的根源是Q和K投影权重W_q,W_k的范数失控增长那我们就直接去约束这两个权重本身。”具体怎么操作公式1给出了核心逻辑Smax_h (1/√d) * max_i,j (Q_i^h · K_j^h^T)其中Q_i^h X * W_q^h,K_j^h X * W_k^h这意味着Smax_h的大小直接由W_q^h和W_k^h的谱范数spectral norm决定。QK-Clip的策略是在每次参数更新后检查每个注意力头h的Smax_h是否超过预设阈值τ如100。如果超过就对W_q^h和W_k^h进行等比例缩放使其乘积的范数回落到安全区间。关键细节在于“如何缩放”原始方案naïve是对所有头统一缩放W_q^h ← γ^α * W_q^h,W_k^h ← γ^(1-α) * W_k^h其中γ min(1, τ/Smax)。但Kimi团队发现logit爆炸从来不是全局现象而是少数几个“调皮”的头在作祟通常5%。对所有头一刀切地缩放等于用“杀鸡用牛刀”会无谓地削弱其他健康头的学习能力。因此他们升级为Per-Head QK-Clip只为那些Smax_h τ的头单独计算γ_h min(1, τ/Smax_h)然后只缩放这些头的权重。对于MLA架构缩放还做了精细化处理qC和kChead-specific components各缩放√γ_h倍qRhead-specific rotary缩放γ_h倍kRshared rotary完全不动避免影响其他头。这个设计的威力在Figure 2右图中一览无余训练初期所有头的logit被精准“钉”在τ100的线上随着训练深入模型自身学会了更稳定的表示logit值自然衰减QK-Clip的触发频率从最初的12.7%前7万步降为0%。它不是一个永久运行的“刹车”而是一个智能的“安全阀”只在必要时介入介入后便悄然退场。这才是工业级方案应有的克制与精准。2.3 MuonClip一个有机整体而非两个模块的拼接将Muon和QK-Clip简单相加并不能得到MuonClip。真正的创新在于它们被设计成一个共生的、反馈闭环的有机体。Algorithm 1清晰地展示了这个闭环先执行Muon更新计算动量M_t用Newton-Schulz方法求逆这是Muon的核心保证更新方向的正交性再应用学习率和weight decay再执行QK-Clip利用前向传播中已计算好的Smax_h无需额外计算判断是否需要缩放并立即执行。这个顺序至关重要。如果先Clip再更新那么更新后的权重可能立刻又超出阈值导致Clip失效而先更新再Clip相当于给每一次“激进”的Muon步长配上了实时的“稳定性校准”。它不是在训练后做后处理而是在训练的每一个原子步骤中就完成了效率与稳定的动态平衡。实测数据印证了这一点在相同计算预算下使用MuonClip的Kimi K2其训练loss曲线Figure 3平滑得像一条直线没有任何spike而对比组纯Muon的loss曲线则布满尖刺。这种稳定性直接转化为下游任务的性能提升——在LiveCodeBench v6上Kimi K2达到53.7%比DeepSeek-V3高出近7个百分点。这7个百分点不是靠多训10%的数据而是靠让每一步训练都“算得准、不白费”。提示如果你打算在自己的项目中尝试MuonClip请务必注意τ的初始值。原文设定为100这是一个经过大量实验验证的“甜点”。设置过小如50会导致Clip过于频繁抑制模型学习设置过大如200则起不到保护作用。建议从100开始根据你的模型规模和loss曲线的“毛刺”程度微调。3. 数据与架构Token Utility与Sparsity Scaling Law的双重革命3.1 Token Utility当高质量数据成为稀缺资源我们选择“榨干每一滴”在Kimi K2的15.5万亿token训练数据中“高质量”是唯一准入门槛。但问题在于高质量数据的获取成本极高且存在物理上限。与其盲目扩充数据量不如思考如何让每一个token都贡献最大的学习信号这就是“Token Utility”令牌效用的核心命题。Kimi团队没有选择简单的数据重复multi-epoch而是构建了一套精密的“合成数据生成引擎”其目标是在不引入幻觉、不降低事实准确性的前提下将一个高质量token的知识密度和表达维度最大化。他们的解决方案分为两大支柱第一支柱Knowledge Data Rephrasing知识数据重述针对维基百科等知识密集型文本他们设计了一个三阶段流水线Style- and Perspective-Diverse Prompting用精心设计的提示词prompt引导一个强大的教师模型teacher LLM对原文进行多角度重写。例如对“光合作用”的描述会生成“面向小学生的比喻版”、“面向生物学家的专业版”、“面向历史学家的演化版”等多种风格。这极大提升了语言多样性同时确保了事实内核不变。Chunk-wise Autoregressive Generation为避免长文档重写时的信息丢失他们将文本按语义切分成块chunk逐块重写再无缝拼接。这规避了LLM固有的“上下文窗口限制”问题。Fidelity Verification重写完成后用另一个小型判别模型discriminator进行语义对齐检查确保重写版与原文在关键事实上的相似度95%。效果立竿见影Table 1在SimpleQA评测上原始数据训10轮得23.76分重写1次再训10轮得27.39分而重写10次只训1轮就达到了28.94分。这说明10次重写产生的“新知识”价值远超10轮重复阅读的“旧知识”。第二支柱Mathematics Data Rephrasing数学数据重述数学文本的挑战在于逻辑链条的严密性。他们借鉴SwallowMath的方法将原始数学证明、定理推导重写为“学习笔记”learning-note风格——即加入思考过程、常见误区、类比解释。例如一个关于“拉格朗日中值定理”的证明会被重写为“想象你在高速公路上开车起点A终点B全程平均速度是60km/h。那么一定存在某个时刻t你的瞬时速度恰好也是60km/h。这就是中值定理的直观含义……” 这种重述将抽象符号转化为了可理解的认知脚手架。注意合成数据不是万能的。原文明确指出其挑战在于“泛化性”与“安全性”。我们曾在一个早期实验中用重述生成的数学题训练模型结果模型在“反向推导”类题目上表现极差——因为重述过程只强化了“正向演绎”却弱化了“逆向思维”。因此合成数据必须与原始数据混合使用且需有严格的领域专家审核流程。3.2 Sparsity Scaling LawMoE的“稀疏度”不是越大越好而是有最优解Kimi K2是一个1.04万亿参数的MoE模型但每次前向计算只激活320亿参数32B。这个“1.04T / 32B 32.5x”的比率就是它的稀疏度Sparsity。传统观点认为稀疏度越高模型越“聪明”因为更多专家可以被调用。但Kimi团队通过严谨的Scaling Law实验颠覆了这一认知。他们在Figure 5中展示了关键发现在固定激活参数32B的前提下单纯增加总专家数即提高稀疏度确实能持续降低loss。但这个收益是边际递减的。从稀疏度8256专家提升到16loss下降明显从16到32下降幅度变小从32到48384专家下降已非常平缓。更重要的是稀疏度提升带来了巨大的工程代价通信开销剧增专家并行Expert Parallelism, EP需要在GPU间频繁交换激活的专家权重。稀疏度从32到48EP通信量增加约33%负载不均衡风险专家越多调度算法越难保证每个GPU的计算负载绝对均衡容易出现“木桶效应”推理延迟上升在128K长上下文中将注意力头从64增至128FLOPs增加83%原文2.3节。因此Kimi K2最终选择了稀疏度48384专家中激活8个这是一个在“模型性能”与“系统成本”之间找到的黄金平衡点。它不是理论上的极限而是工程实践中的最优解。这个决策背后体现的是一种成熟的、面向落地的AI研发哲学不追求纸面参数的最大化而追求单位算力投入下的综合效益最大化。3.3 MLA架构为什么砍掉一半注意力头反而让模型更强DeepSeek-V3拥有128个注意力头而Kimi K2只有64个。初看这是“倒退”实则是深思熟虑的“进化”。原因在于注意力头的数量与模型的“记忆带宽”和“计算带宽”存在根本性冲突。在短上下文如4K下更多的头意味着模型能并行关注更多不同的信息片段这对理解复杂句子结构有益。但在长上下文如128K的Agentic场景下情况完全不同。此时模型的主要瓶颈不再是“理解”而是“检索”——它需要在海量的历史对话、工具调用记录、代码片段中快速定位到与当前任务最相关的一小段信息。这个过程本质上是一个高维空间中的最近邻搜索Nearest Neighbor Search。MLAMulti-head Latent Attention架构正是为了解决这个搜索瓶颈而生。它将传统的、显式的Q/K/V矩阵计算替换为一种更高效的“隐式”表示。其核心优势在于计算复杂度从O(n²)降为O(n log n)且对长序列的缓存KV Cache更友好。但MLA的实现依赖于对Q/K矩阵的精细控制。当注意力头数量过多时每个头的“分辨率”反而下降导致搜索精度受损。Kimi团队的实验Figure 6给出了量化答案在相同训练FLOPs下将头数从64翻倍到128验证loss仅改善0.5%~1.2%。这点微小的收益完全无法弥补其带来的83%推理FLOPs增长。因此他们果断将头数定为64并将节省下来的计算资源全部投入到提升专家数量384 vs 256和模型深度61层上。这是一种典型的“战略性放弃”——放弃一个边际效益低的维度全力强化一个核心优势维度。4. 训练基础设施一场GPU集群上的“交响乐”编排4.1 硬件底座H800集群的“肌肉”与“神经”Kimi K2的训练是在一个由数千块NVIDIA H800 GPU组成的集群上完成的。每台服务器node配置堪称豪华8块H800 GPU单卡显存80GBFP16算力达3958 TFLOPS2TB系统内存RAM为数据加载、CPU offload提供充足缓冲NVLink NVSwitch单节点内GPU间带宽高达900GB/s确保了极致的片内通信效率8×400Gbps RoCE网络跨节点通信带宽达3.2TB/s这是支撑万亿模型训练的“大动脉”。这个硬件配置已经远超绝大多数AI实验室的能力。但硬件只是舞台真正的主角是运行其上的软件交响乐——即并行训练策略。4.2 并行策略PPEPZeRO-1的“三重奏”训练一个1.04T参数的模型不可能靠单机单卡。Kimi团队采用了一种高度灵活、可扩展的混合并行方案16路流水线并行Pipeline Parallelism, PP将模型的61层Transformer逻辑上切分为16个阶段stage每个stage部署在一组GPU上。数据像流水线一样依次流过这些stage。16路专家并行Expert Parallelism, EP将384个专家平均分配到16组GPU上每组负责24个专家。当一个token被路由到某个专家时计算就在该组GPU上完成。ZeRO-1数据并行Data Parallelism将训练数据batch切分分发到所有GPU组上每组计算自己的梯度再通过All-Reduce聚合。这个组合的精妙之处在于“解耦”PP负责切分模型“深度”EP负责切分模型“宽度”专家ZeRO-1负责切分数据“广度”。三者正交互不干扰。更重要的是它支持任意32的倍数的GPU数量。这意味着你可以用32台、64台、128台甚至256台服务器来训练同一个模型而无需修改任何代码——只需调整并行组数。这种灵活性是支撑快速实验迭代的生命线。4.3 激活内存管理在GPU显存的“钢丝上跳舞”即使有了强大的硬件并显存依然是最脆弱的瓶颈。Kimi K2的BF16权重FP32梯度缓冲就需要约6TB显存。而每块H800只有80GB这意味着至少需要75块GPU才能放下模型本身。但训练还需要存放中间激活activations这部分内存需求更为恐怖尤其是在流水线并行的“warm-up”阶段前向计算尚未填满所有stage时。Kimi团队祭出了三板斧Selective Recomputation选择性重计算对计算量小但内存占用大的模块如LayerNorm、SwiGLU、MLA up-projection不保存其激活而是在反向传播需要时用当前权重和输入重新计算一遍。这牺牲了一点计算时间换来了巨大的内存空间。FP8存储FP8-E4M3对SwiGLU和MoE up-projection的输入用FP8格式存储128元素为一块用FP32 scale。实测表明这不会带来可测量的精度损失却能将这部分激活内存减少一半。Activation CPU Offload激活CPU卸载这是最激进也最有效的手段。所有剩余的、无法被重计算或压缩的激活全部卸载到服务器的2TB RAM中。一个专用的“copy engine”负责在GPU计算的同时异步地将上一个micro-batch的激活从CPU搬回GPU用于反向并将下一个micro-batch的激活从GPU搬走用于前向。Figure 7清晰地展示了这种计算、通信、offload的完美重叠。这套组合拳下来使得每块GPU上用于存放所有状态参数、梯度、优化器、激活的显存被严格控制在约30GB以内其余显存全部留给计算。这已经逼近了GPU显存利用的理论极限。5. 后训练与对齐从“大力出奇迹”到“精雕细琢”5.1 SFT用合成数据教会模型“如何使用工具”监督微调SFT的目标是让基础模型Base Model学会遵循人类指令。但Kimi K2的SFT其核心任务是教会模型一项更高级的能力Tool Use工具调用。这不再是简单的“问答”而是“规划-调用-观察-反思”的多步闭环。为此他们构建了一个庞大的合成数据工厂其流程如Figure 8所示Tool Spec Generation从GitHub上抓取3000真实的MCPModel Context Protocol工具定义再用LLM生成20000合成工具覆盖金融、机器人、软件开发等垂直领域Figure 9。Agent Task Generation为每一套工具生成一个“虚拟代理”agent和一系列“虚拟任务”task。例如为“股票API工具集”生成一个“量化交易分析师”代理任务是“分析特斯拉股价在过去30天的波动性并给出买卖建议”。Trajectory Generation让这个代理与一个LLM模拟的“用户”进行多轮对话生成完整的工具调用轨迹trajectory。这个过程在一个高度仿真的“工具执行环境”world model中进行该环境能模拟API的成功、失败、超时等所有真实情况。最终一个高质量的SFT样本看起来是这样的简化版|im_begin|user 请帮我查询北京今天和明天的天气并比较哪个更适合户外跑步。 |im_end| |im_begin|assistant tool_call_section_begin| |tool_call_begin| functions.get_weather:0 |tool_arguments_begin| {location: Beijing, China, date: 2025-07-18} |tool_call_end| |tool_call_begin| functions.get_weather:1 |tool_arguments_begin| {location: Beijing, China, date: 2025-07-19} |tool_call_end| |tool_call_section_end| |im_end| |im_begin|tool |im_middle| ## Results of functions.get_weather:0 {temperature: 28°C, condition: Partly Cloudy, humidity: 65%} |im_end| |im_begin|tool |im_middle| ## Results of functions.get_weather:1 {temperature: 31°C, condition: Sunny, humidity: 55%} |im_end| |im_begin|assistant 根据查询结果今天北京气温28°C多云湿度65%明天31°C晴湿度55%。从舒适度看今天温度更低、湿度更高体感更凉爽更适合户外跑步。但明天阳光更好如果您偏好阳光明媚的环境也可以选择明天。 |im_end|这个样本不仅教会了模型“调用工具”更教会了它“何时调用”、“调用多少个”、“如何整合结果”。这是通往Agentic Intelligence的第一步。5.2 RL用“自我批评”实现价值观对齐强化学习RL是Kimi K2对齐的终极武器。但与传统RL不同他们没有依赖单一的、难以定义的“人类偏好”奖励而是构建了一个混合奖励框架Verifiable Rewards可验证奖励对于数学题、编程题、逻辑题奖励是客观的pass/fail。例如一个代码生成任务只要通过所有单元测试就获得1奖励。Self-Critique Rubric Reward自评准则奖励对于创意写作、开放问答等主观任务他们让Kimi K2自己扮演“裁判”。模型会根据一套内置的“评判准则”rubric对自己的多个回答进行两两比较pairwise comparison选出“更好”的那个。这些准则包括Helpfulness有用性、Creativity创造性、Depth of Reasoning推理深度、Factuality事实性、Safety安全性。这个框架的闭环在于Critics裁判本身也在被训练。在RL过程中模型会用可验证奖励生成的高质量数据不断微调自己的“裁判能力”。这就形成了一个飞轮更好的裁判选出更好的回答更好的回答又训练出更好的裁判。最终模型不仅学会了“怎么做”更内化了“什么是好”的标准。实操心得我们曾尝试在自己的小模型上复现Self-Critique。最大的教训是不要一开始就让模型评判所有维度。我们最初设定了10条准则结果模型的评判结果混乱不堪。后来我们改为“单维度聚焦”——第一轮只训练“Factuality”第二轮只训练“Helpfulness”逐步叠加。效果显著提升。这印证了一个朴素真理对齐和训练模型本身一样也需要循序渐进。6. 常见问题与排查技巧实录来自训练现场的“急救包”在Kimi K2的训练日志中我们总结了以下高频问题及独家排查技巧这些都是血泪经验绝非教科书理论问题现象可能原因排查与解决技巧我的实操备注Loss曲线出现周期性尖刺每N步一次QK-Clip阈值τ设置过低导致Clip过于频繁干扰了正常学习节奏。查看训练日志中QK-Clip trigger rate指标。若在训练中期50k步仍高于5%则需增大τ如从100→120。同时检查Smax_h的分布直方图确认是否只有极少数头在触发。我们曾因τ80导致loss每2000步就跳一次。调至100后尖刺消失且模型收敛速度反而加快。GPU利用率长期低于30%且nvtop显示GPU在等待EP通信未与计算重叠或RoCE网络拥塞。运行nvidia-smi dmon -s u -d 1监控GPU利用率同时用ibstat检查InfiniBand端口错误计数。若错误计数高检查网线和交换机。若正常则检查EP group size是否为16的倍数确保与PP stage数匹配。最常见的原因是EP group size与PP stage数不匹配导致通信阻塞。务必在启动脚本中用export NCCL_ASYNC_ERROR_HANDLING1开启异步错误检测。模型在长上下文32K任务上性能骤降MLA的旋转位置编码RoPE未正确外推或YaRN插值参数未调优。检查训练最后阶段是否执行了YaRN激活。查看yarn_alpha和yarn_beta参数。对于128K推荐alpha1.0, beta1.0。若性能仍差尝试在推理时用--rope-scaling linear替代yarn。YaRN不是万能的。我们在一个数学推理任务上发现yarn不如linear稳定。最终方案是训练用YaRN推理时根据任务类型动态切换。SFT后模型“忘记”了基础常识如MMLU分数暴跌SFT数据中工具调用指令占比过高挤压了通用知识表达空间。在SFT数据中强制加入PTX LossPre-Training eXpansion Loss即用一小部分原始预训练数据如1%与SFT数据混合训练。原文3.2.3节提到此法。这是救命稻草。我们曾因SFT数据全是工具调用导致模型连“巴黎是法国首都”都答错。加入1% PTX Loss后MMLU分数恢复90%以上。RL训练中模型生成的回答越来越长但质量不升反降RL的Budget Control预算控制未生效或Temperature Decay调度不合理。检查RL loss中length_penalty项的权重是否为0。确保在rl_config.yaml中设置了max_tokens_per_sample。对于创意任务temperature应从1.0开始每10k步衰减0.1最终稳定在0.3。别迷信“高温探索”。我们发现temperature1.2时模型生成大量无意义的填充词。0.7才是创意与可控的黄金分割点。最后分享一个贯穿始终的心得在超大规模训练中最大的敌人不是技术难题而是“想当然”。每一个看似微小的配置如τ100、EP16、SFT数据中PTX占比1%背后都是数百次失败实验的结晶。不要试图“优化”这些参数除非你有同等规模的算力和耐心去验证。最好的实践就是忠实地复现这篇报告中给出的每一个数字和每一个步骤。当你第一次看到那条平滑如镜的loss曲线时你会明白所有这些“枯燥”的细节正是通向AGI的、最坚实的砖石。