今天的大消息莫过于meta发布llama3[1]了，作为一个AI软件系统从业人员，趁热解读一下，总结版本如下：

• llama3的发布，更强调了数据工程的重要：模型架构不变，更多的数据量和更高数据质量能够带来明显模型效果提升

• 更多的数据，依赖更多的算力，开源大模型玩家的算力需求再次提升了一个量级，即万卡H100级别，再次感受到了算力忧患

  
  

• 集群系统层面：meta的集群同时在走RoCE和InfiniBand两条路；万卡级别系统容错与故障恢复愈发重要

  
  

• meta的llama3算法改动太小，长序列、多模态等常见能力都没有支持，而官方声称目前8B和80B只是一个开始，llama3还未完成训练，后续会支持长序列、多模态这些能力，不知道是不是meta感受到了什么压力，着急先发布了？

1. llama3 与llama2的模型结构（计算）区别

llama3与llama2的模型架构完全相同，只是model的一些配置（主要是维度）有些不同，llama2推理的工程基本可以无缝支持llama3。在meta官方的代码库[2,3]，模型计算部分的代码是一模一样的，也就是主干decoder only，用到了RoPE、SwiGLU、GQA等具体技术。

• llama3-8B与llama2-7B的模型具体差别

通过对比huggingface模型中的config.json，首先可以看出，模型都是 `LlamaForCausalLM` 这个类，模型结构不变。具体差别在于：

① vocab_size：32000 ->128256。词汇表的扩大，导致embedding参数的增大 (128256-32000)*4096*2 Byte=752MB，另外模型最后一层lm_head的输出维度就是vocab_size，所以lm_head的参数同样增大752MB，总计带来模型增大1504MB；

② max_position_embeddings：4096->8192。也即context window扩大了，训练时输入的序列长度增大，推理能支持的序列长度增大，没有实际计算的差别。

③ num_key_value_heads：32 -> 8。即使用了GQA，因为num_attention_heads维持32，也就是计算时key、value要复制 4份。参数量会下降，K_proj、V_proj的参数矩阵会降为llama2-7B的1/4，共计减少 32*4096*4096*2*2/4*3 Byte（1536MB）

④ intermediate_size：11008->14336。只是FFN时的中间维度变了，计算范式不变。参数量增大：32*4096*(14336-11008)*3*2/1024/1024 Byte (2496MB)

综上：通过以上几个设置和维度的变化，最终带来模型增大了2464M，这也是7B->8B的原因，本质上的计算模式没有变化

ps：还有一个小改动(其实是huggingface自己的修改)，权重的数据格式torch.float16->torch.bfloat16。llama2和llama3都是用bf16训练的，只是huggingface官方导入llama2时转成float16去推理了，据这个issue描述[4]可能会出现NaN，后面huggingface的codellama就用了torch.bfloat16，此次llama3也是同样的操作，即与官方发布的权重保持一致

2. 效果提升主要是数据工程

① 数据量：预训练，llama3 用了超15T token（来自公开可获取的来源），是llama2的7倍多，其中代码相关的数据是llama2的4倍多；Fine-tuning阶段的数据除了公开能获取的 instruction datasets, 还有自己制作的超过1千万人工标注 examples。

② 数据质量：预训练阶段， “为确保 Llama 3 在最高质量的数据上进行训练，我们开发了一系列数据过滤pipeline。这些管道包括使用启发式过滤器、NSFW 过滤器、语义重复数据删除方法和文本分类器来预测数据质量。”

Instruction fine-tuning阶段的数据质量也非常重要。“模型质量的一些最大改进来自于对这些数据的精心整理，以及对人类注释者提供的注释进行多轮质量检查保证。”

③ 数据混合比例的探索：“我们进行了大量实验，以评估在最终预训练数据集中混合不同来源数据的最佳方法”

3. 模型训练的基础设施

3.1 集群细节

meta使用了2个定制的24K的GPU集群，通过model card[5]中的“H100-80GB (TDP of 700W)”可以推断出用的是SXM形态的H100，其fp16算力990TFLOPS。meta实现了“同时在 16K 个 GPU 上进行训练时，每个 GPU 超过 400 TFLOPS 的计算利用率”，也即超过40%的利用率

关于这两个24K的GPU集群，meta在另一篇关于AI基础设施的博客[6]中有更详细的介绍。核心的区别在于：

Cluster1采用基于RoCE方案，基于Arista 7800的RoCE网络结构解决方案，配备 Wedge400 和 Minipack2 OCP 机架式交换机

Cluster2采用Infiniband方案，采用英伟达 Quantum2 InfiniBand Fabric。两种解决方案都能实现 400 Gbps 端点互联。

目的是通过这两个方案，评估这些不同类型的互连是否适合大规模培训以及是否具有可扩展性，从而为今后如何设计和构建更大、更大规模的集群提供更多启示。

可见meta在同时走RoCE 和 InfiniBand两条线，并且它声称通过网络、软件、模型架构的协同设计大模型训练的workload没有出现网络瓶颈。其实llama2的技术报告[7]中，meta就是用了一个RoCE一个Infiniband，相同的互联带宽，两个A100集群，原文如下：

With this two-cluster setup, we were able to compare the suitability of these different types of interconnect for large scale training. RoCE (which is a more affordable, commercial interconnect network) can scale almost as well as expensive Infiniband up to 2000 GPUs, which makes pretraining even more democratizable。

说白了，核心问题还是IB太贵了，天下苦秦久矣。。。

3.2 容错和故障恢复

meta此次llama3的pretrain训练强调的一个点，为了最大限度地延长 GPU 的正常运行时间，我们开发了一种先进的新训练堆栈，可以自动检测、处理和维护错误。我们还极大地改进了硬件可靠性和无声数据损坏检测机制（detection mechanisms for silent data corruption），并开发了新的可扩展存储系统，减少了检查点和回滚的开销。这些改进使总体有效训练时间缩短了 95% 以上。与 Llama 2 相比，这些改进将 Llama 3 的训练效率提高了约三倍。

万卡级别的集训训练，容错已经成为非常重要的问题，这一点，在Grok、Google Gemini等都有强调，尤其是Google Gemini的technical report中提出，这么大规模的系统中会出现一个棘手的问题SDC-“Silent Data Corruption”

另外Google在NDSI2024有一篇paper[8]专门讲他们的大规模集群训练容错相关feature如何设计，后面有机会我们详细讲。