大模型结构的进化一:LLaMA 3.1结构及影响解析

---

去年夏天，我干了一件蠢事。

整整七天，就盯着一台服务器的loss曲线发呆。训飞了三次，loss像过山车一样冲上天的那一刻，我差点把键盘砸了——当时心里只有一个念头：到底怎么对齐，这玩意儿才不闹脾气？

后来呢？我把Meta那篇92页的Llama 3.1技术报告翻烂了，才发现一个让人又气又笑的事实：

Meta那帮人，也在同样的坑里打滚。

只不过人家滚得起——16K张H100当后盾，240PB的SSD存checkpoint，翻车了？存一次就完了。我呢？就几台A100，还得跟同事抢时间，活像大学时的共享服务器。

挺讽刺的吧？

我一个写技术专栏的算法狗，居然从一份正经到发指的学术报告里读出了“亲切感”。这么说吧，看完那份报告，我第一反应不是“哇好厉害”，而是“妈的原来你们也这么惨”。

今天咱们就聊聊Llama 3.1到底怎么回事。从结构到训练，从踩坑到翻身，我争取让你看完之后，要么觉得“太值了”，要么觉得“太惨了”。

——反正不会觉得无聊。

---

一、为什么全世界的开源模型，都在抄Llama的结构？

先问个问题：你现在看到的所有大模型，结构图拿出来长什么样？

是不是长得都差不多？

说到这儿，有人可能会说：“那不是因为Transformer就是这个时代的答案吗？”

说实话，这个答案对了一半。真正的原因是——

生态比结构更强大。

先看结构本身。Transformer这套东西，我这些年试过无数变体。线性Transformer、状态空间模型……你猜怎么着？要么效果差一截，要么扩展性感人。能赢过Transformer的，一只手都数得过来。

但这不是说Transformer就永远是对的。

我个人对新结构持开放态度——Transformer被替换，只是时间问题。只不过现在这个时间点，改不改结构，压根不是制约大模型能力的瓶颈。就好比一辆跑车，你非要把它的方向盘换成方的，有意义吗？

那Llama结构为什么能成为行业标准？两个原因。

第一个原因，验证了这是个“差不多最优的方案”。

我敢打包票，肯定有人试过各种变体——加这个模块、改那个结构、换那个激活函数——但在效果、扩展性、训练稳定性上，没有一个能全面超过Llama现在这套设计。当然，这只是我的推测，但你看看开源社区各种模型的结构越来越像……这本身就是一个信号。

第二个原因，才是真正致命的：生态。

你想想，现在所有快速推理框架、微调工具、部署平台——vLLM、TensorRT-LLM、Hugging Face TGI——哪个不是默认兼容Llama结构？你要搞个大改动，行，全部重写。写完之后呢？开发者们愿意陪你玩吗？

新结构要挑战的，从来不是Transformer本身，而是围绕它长出来的整个生态。

没有压倒性的证据证明新结构在哪都更好，就不可能换掉它。这就是为什么Meta走开源路线这么精——早开源早形成标准，以后技术选型的主动权就在你手里。谷歌呢？因为开源不坚决，硬生生把半壁江山让给了别人。

具体到Llama 3.1的结构细节，你会发现跟Llama 2比，核心架构没大变。但那些小改动，每一刀都砍在关键点上：

分词器（Tokenizer）先变了。从32K词汇变成128K词汇，压缩率从每个token处理3.17个字符提升到3.94个字符。什么意思？同样的计算量，能读更多文本。不花一分钱就提升了效率。

更狠的是，28K个额外token专门留给了非英语语言。中文、日语、阿拉伯语……通通有份。Meta在这块下的功夫，你从数据上就能看出来。

位置编码还是用RoPE，但基频超参数调到了500,000，能适应更长的上下文（为后续扩展到128K打下基础）。注意力屏蔽也做得更细——防止文档间串扰，这对长上下文场景几乎是生死攸关。

还有分组查询注意力（GQA）。8B和70B模型上都用了，8个key/value头，32个query头，比例4:1。

我实测过，这个设计对推理速度的提升有多夸张呢？——同样batch size下，GQA比MHA省差不多一半显存，输出速度快30%左右。

你想想，一条H100就得十几万。省一半显存等于省一半卡，实实在在的钱。

---

二、训练过程：从预训练到DPO，哪个坑我没踩过？

说到训练，这才是我最想聊的。

Llama 3的预训练分了三个阶段：初始预训练、长上下文预训练、退火（Annealing）。这套流程跟我在业务里用的差不多，但Meta公开的细节多得多，有些点真的让我眼前一亮。

先说Scaling Law。

他们先在小规模任务上拟合isoFLOP曲线，然后用这个曲线评估——给定多少算力，该用多少数据来训练。这做法不算新鲜，但胜在扎实。

你知道为什么那么多人训大模型，算力都打水漂了吗？

就是没搞清楚token量和模型大小的配比。你是该用1T token训70B，还是该用15T token训405B？这个比例一旦错了，算力就全浪费了。Meta的405B用了15T token，而这个配比，正好是Scaling Law建议的那个值。

接下来是对齐方法，这部分是我最关注的。

Meta用了SFT + 拒绝采样（RS）+ DPO的组合。看到这儿你可能觉得：这不就是常规操作吗？

重点在后面。

他们让标注员修改答案，形成了这样一个偏好顺序：修改后答案 > 喜欢的答案 > 不喜欢的答案。然后用这个排序做DPO的偏好数据。

我当年做DPO的时候，也搞了类似的人工排序流程。你知道核心瓶颈是什么吗？——

数据质量。

你给烂数据，它就学出烂偏好。这是铁律。

Meta还专门对DPO做了个很有意思的改造：剔除掉那些同时出现在选中文本和拒绝文本里的token。

这个改动背后的逻辑是什么？

因为共同token会导致训练目标冲突。模型看到同一个token，既在好答案里，又在坏答案里——它就精分了。就好像你让一个人同时学“打人是对的”和“打人是错的”，你说他能学会吗？

这个trick我后来在自己的70B模型上试了一下，训飞概率确实降低了。但也没完全消除。

说到这儿我得坦白一句：DPO这东西，真的太容易训飞了。

我在业务域里试过各种对齐手段，低成本的高成本的都试过，结论是一样的——特别容易训飞。Meta不怕，因为人家底子厚，可以烧钱试错。但你要是个中小团队，这关就是鬼门关。

还有一个操作，让我看了直呼“有钱真好”——模型平均化。

他们最后把用不同数据和超参数训练出来的奖励模型、SFT模型和DPO模型，全做了平均。说白了就是：多个噪声源平均后，比单个模型更鲁棒。

我试过类似思路，但没他们做得这么系统。为什么？资源不够啊！

硬件篇才叫大开眼界。

16K张H100用来跑训练，8K张H100用来做验证和评估。SSD加起来240PB——主要用来存checkpoint，因为训练崩得太频繁了。

你想想，光checkpoint就存了240PB。这是什么概念？240PB ≈ 24万个1TB的硬盘叠在一起。

一张H100的算力约等于三张A100，贵得要命。通信网络基于RoCE（RDMA over Converged Ethernet），采用三层Clos拓扑，24K GPU集群，1:7过订阅。他们还专门改了NCCL库，在多个GPU间搞了16个网络流做负载均衡，还搞了Enhanced-ECMP协议。

一个完整54天的训练周期里，78%的中断都是硬件原因。

78%啊！

这是我看到最震撼的数据。不是因为什么技术创新，而是因为——原来Meta也跟我们在千卡集群上遇到的问题一模一样。一堆又一堆跟软件无关的坑，等着你去填。

MFU方面，在16K张H100下大概40%左右，其实是偏低的。我猜是因为Flashattention2对H100优化不够。最新的F