51c大模型~合集20

原创

qq6669490e54384 2024-08-01 22:41:04 ©著作权

文章标签 大模型 文章分类 深度学习人工智能

©著作权归作者所有：来自51CTO博客作者qq6669490e54384的原创作品，请联系作者获取转载授权，否则将追究法律责任

#Transformer大模型尺寸变化

大模型尺寸正在重走CNN的老路；马斯克：在特斯拉也是这样 , Transformer大模型尺寸变化，正在重走CNN的老路！

Transformer大模型尺寸变化，正在重走CNN的老路！

看到大家都被LLaMA 3.1吸引了注意力，贾扬清发出如此感慨。

拿大模型尺寸的发展，和CNN的发展作对比，就能发现一个明显的趋势和现象：

在ImageNet时代，研究人员和技术从业者见证了参数规模的快速增长，然后又开始转向更小、更高效的模型。

听起来，是不是和GPT哐哐往上卷模型参数，业界普遍认同Scaling Law，然后出现GPT-4o mini、苹果DCLM-7B、谷歌Gemma 2B如出一辙？

贾扬清笑称，“这是前大模型时代的事儿，很多人可能都不咋记得了：）”。

而且，贾扬清不是唯一一个感知到这一点的人，AI大神卡帕西也这么觉得：

大模型尺寸的竞争正在加剧……但是卷的方向反着来了！
模型必须先追求“更大”，然后才能追求“更小”，因为我们需要这个过程，帮咱把训练数据重构成理想的、合成的格式。

他甚至拍着胸脯打赌，表示我们一定能看到又好、又能可靠地思考的模型。

而且是参数规模很小很小的那种。

连马斯克都在卡帕西的评论区连连称是：

以上，大概可以称之为“大佬所见略同”。

展开说说

贾扬清的感慨，要从只在最强王座上短暂待了一天的LLaMA 3.1说起。

那是首次实现“最强开源模型=最强模型”，不出意外，万众瞩目。

However，贾扬清在这个时候提出了一个观点：

“但我认为，行业会因小型垂直模型而真正蓬勃发展。”

至于啥是小型垂直模型，贾扬清也说得很清楚，比如以Patrouns AI的Iynx（该公司的幻觉检测模型，在幻觉任务上超过GPT-4o）为代表的那些很棒的中小模型。

贾扬清表示，就个人喜好而言，他本人是非常喜欢千亿参数模型的。

但现实情况里，他观察留意到，7B-70B参数规模之间的大模型，大家用起来更顺手：

它们更容易托管，不需要巨大的流量即可盈利；
只要提出明确的问题，就能得到质量还不错的输出——与和之前的一些看法相反。

与此同时，他听说OpenAI最新的、速度很快的模型也开始变得比“最先进的”大模型尺寸更小。

“如果我的理解是正确的，那么这绝对表明了行业趋势。”贾扬清直接表明了自己的观点，“即在现实世界中，使用适用的、具有成本效益、且仍然强大的模型。”

于是乎，贾扬清简单梳理了CNN的发展历程。

首先，是CNN的崛起时代。

以AlexNet（2012）为起点，开启了大约三年的模型规模增长时期。

2014年出现的VGGNet就是一个性能和规模都非常强大的模型。

其次，是缩小规模时期。

2015年，GoogleNet把模型大小从“GB”缩小到了“MB”级别，即缩小了100倍；但模型性能并没有因此骤减，反而保持了不错的性能。

遵循类似趋势的还有2015年面世的SqueezeNet模型等。

然后的一段时间，发展重点在追求平衡。

后续研究，如ResNet（2015）、ResNeXT（2016）等，都保持了一个适中的模型规模。

值得注意的是，模型规模的控制并没有带来计算量的减少——其实，大伙儿都愿意投入更多的计算资源，寻求一种“同等参数但更高效”的状态。

紧接着就是CNN在端侧起舞的一段时期。

举个例子，MobileNet是谷歌在2017年推出的一项有趣的工作。

有趣就有趣在它占用的资源超级少，但是性能却非常优异。

就在上周，还有人跟贾扬清提到：“Wow～我们现在还在用MobileNet，因为它可以在设备上运行，而且在出色的特征嵌入泛化（Feature Embedding Generality）。”

最后，贾扬清借用了来源于Ghimire等人的《A Survey on Efficient Convolutional Neural Networks and Hardware Acceleration》里的一张图：

并再一次发出自己的疑问：

大模型尺寸，会遵循与CNN时代相同的趋势来发展吗？

网友怎么看？

其实GPT-4o mini这样走在大模型发展道路上“不大反小”的例子不在少数。

当上述几位表达出这样的观点后，立马有人点头如捣蒜，还拿出了一些别的类似例子，证明他们看到了相同的趋势。

有人立马跟上：

我这儿有个新的正面例子！Gemma-2就是把27B参数大小的模型知识蒸馏成更小的版本。

还有网友表示，开发更大的模型，意味着能给后续几代更小、更垂直的模型的训练“上强度”。

这个迭代过程最终会产生所谓的“完美训练集”。

这样一来，较小的大模型在特定领域，能与现在参数巨大的大模型一样聪明，甚至更聪明。

一言以蔽之，模型必须先变大，然后才能变小。

大多数讨论此观点的人，还是对这个趋势比较认同，有人直言“这是一件好事，比‘我的模型比你的模型大’参数竞赛更实用和有用。”

但是，当然了！

翻遍网络评论区，也有人发出不同的声音。

比如下面这位朋友就在贾扬清推文底下留言：

Mistral Large（背后公司Mistral AI）、LLaMA 3.1（背后公司Meta）和OpenAI，持有最强竞争力模型的公司，目前可能都正在训练更大的模型。
我没发现有“更小型号模型搞定技术突破”的趋势哟。

面对这个问题，贾扬清倒也及时回复了。

他是这么说的：“没错！我说大模型尺寸可能在走CNN的老路，绝对不意味着号召大家停止训练更大的模型。”

他进一步解释道，这么说的本意是，随着技术（包括CNN和大模型）落地实践越来越广，大家已经开始越来越关注性价比更高的模型了。”

所以，或许更高效的小·大模型，能够重新定义AI的“智能”，挑战“越大越好”的假设。

你赞同这个观点不？

参考链接：
[1]https://x.com/jiayq/status/1818703217263624385[2]https://x.com/fun000001/status/1818791560697594310[3]https://www.patronus.ai/[4]https://twitter.com/karpathy/status/181403809621808349

#LLama 405B 技术报告解读

本文解读了Meta发布的Llama 3 405B版本的技术报告，重点介绍了该模型在预训练、模型结构、规模定律、训练策略和多模态能力集成等方面的创新和优化措施。文章还概述了支持Llama 3训练的硬件设施和网络架构，并讨论了模型的可用性和性能表现。

果然传的消息都是真的，meta在24号凌晨发布了llama 3的405B版本，这次还是做一个技术报告解读。值得一提的是，在技术报告的开头，meta特意强调了一个 Managing complexity，大意是管控复杂度。

为什么没用MoE却弄个405B的dense？为什么没用PPO只用DPO？

meta给的解释是：Managing complexity，大意就是这样简单吧...

评测结果如下，这个结果跟当初网上传的那个版本还是有一定出入的，没有到摁着GPT4o锤的程度。

况且，根据GPT4o的速度来看，参数量要远远小于一个405B的dense，高下立判。不过这个无可厚非，毕竟GPT4也挺慢的

51c大模型~合集20_大模型

虽然如此，但是llama3 405B中间有许多实用的trick还是值得我们学习的，整个的画风有点像打比赛刷榜那种程度，做的很细，抠每一个上分点，那么我们来总结下一些亮点吧。

一、预训练

数据部分

PII数据（个人隐私数据）清洗、去重、去黄、做模型洗数据(fasttext)，混合代码和推理数据，多语言数据

数据配比-打标签

做模型做细粒度的打标签工作，然后根据标签采样，配不同的量去试，最终敲定了：50% 通用数据, 25% 数理数据, 17% 代码数据, 8% 多语言数据。实际这个过程比这个深入很多，据消息，国内某知名大模型团队能做到上千级别的细粒度标签实验。

数据配比-scalinglaw

探索数据配比的scaling law，作者这里没有展开，大概的方法可以看我之前写过的文章，在不同的小模型上做不同的配比实验，然后用来预测大模型的最优配比。

数据退火

作者发现在大模型训练的最后阶段，用高质量的数据学习能提高性能。于是在最后40B数据上，作者逐渐将学习率衰减到0。并且发现，数据退火方法，可以用来筛数据，量少，效果明显，实验更高效。

二、模型结构

GQA，8-kv head，超大参数的常规操作，具体参数如下。

51c大模型~合集20_大模型_02

。

126 层，层数多两层，这是一个训练阶段方便流水线并行切分的技巧。
长文拼接时候，使用attention mask防止不同来源的数据串味。样本间穿越在预训练阶段影响不大，以前大家也不在乎，但作者说，在扩长序列时影响很大。
词表大小为128K，英语语料的压缩率有所提高，同样计算量能够过更多数据，并且增强了非英语的能力。这里面中文水平如何，还等着大家测试，不过根据下面实验部分的case study看，这次中文能力还是不错的。
RoPE theta 调到了500000，再次感谢苏神。

三、scalinglaw

作者说了现有的scalinglaw通常只预测loss，而不是特定的benchmark上的表现；(2)scalinglaw可能因基于小资源进行的预训练运行而变得没那么可靠。

对此，作者搞了一个两步走方法。

1.先建立计算最优模型在下游任务上的负对数似然与训练FLOPs之间的相关性。

2.利用scalinglaw模型和使用更高计算FLOPs训练的旧模型，将下游任务上的负对数似然与benchmark的准确率指标关联上。

作者在这步用了LLama2系列的模型作者在ARC上使用这个方法，能看出来拟合的还不错

51c大模型~合集20_大模型_03

四、infra/硬件/网络

GPU资源 16K H100 80GB with NVLink，有钱。
专用集群，不是之前的Meta’s AI Research SuperCluster，船新的Meta’s production clusters，240 PB SSD，7500 台机器，2TB-7TB/s 吞吐，如此高吞吐的存储集群是为了最小化ckpt的IO耗时。

网络部分，专业的机房看管员可以仔细研究下：

RoCE，单口400Gb/s

具体的拓扑结构为

3层网络架构，单体24K GPU
3072 张GPU 1:1 收敛比
往上8 个Pod 1:7 的收敛比
由于跨pod 带宽降低，所以模型并行编排和资源调度均需考虑网络架构

负载均衡

两个GPU 间使用16个流，而不是1个，来降低单流流量，以更好地负载均衡
在网络包的头部增加了特殊区域，通过hash 来使得流的选路更加均衡

拥塞控制

在spine 上使用deep-buffer 交换机以适应集合通信导致的短时拥塞，并能够降低慢节点引发持久的拥塞和反压

整体的吞吐如图

51c大模型~合集20_大模型_04

别的不说，就这万卡集群的吞吐率，要比国内小作坊的16卡微调个小模型都要高。

模型并行策略：

51c大模型~合集20_大模型_05

4D并行，TP + CP + PP + DP，多了一个上下文并行CP，或者称之为序列并行。
使用了FSDP，但是model weight 只拉取一次，以减少反向梯度计算时的weight allgather 通信

PP并行策略改进

Batch Size 限制：当前的流水线并行策略会限制 micro batch 个数为流水线stage 的整数倍，会导致global batch size 和流水线 stage 相互制约
显存不均衡：第1个stage 会多出很多显存占用，之后逐stage 降低
计算不均衡：最后一层会额外计算 output layer 和 loss，增加了计算量和延时，首尾stage 做了padding

CP并行策略的改进

和Ring CP 一样的在序列维度切分，切分为2*CP 份以负载均衡，但没有用环状通信来overlap 计算和通信，而是基于allgather 的通信。

网络架构感知的并行策略

[TP, CP, PP, DP] 的并行策略是针对网络通信优化做专门设计的
开发了显存预估和性能探查工具，用以平衡显存开销和通信性能

数值稳定性

FP32 的梯度累加和通信

集合通信

基于NCCL 开发了 NCCLX，在高延迟网络下显著提升性能
[TP, CP, PP, DP] 并行策略可能导致PP 和DP 通信跨Pod：原 allgather 和 reducescatter 实现依赖数据chunk 和拷贝，需要大量的小的控制信息的通信，进行额外的拷贝操作，且占用GPU 资源来做通信。对此，llama团队优化chunk 策略，提升小的控制包的通信优先级。

可用性

不怎么样，运行54天，崩了419次（预期外训练中断），具体的分布如下：

51c大模型~合集20_大模型_06

网络问题和GPU问题各占一半。

前面提到了那么多保障和优化措施，还是平均每天挂了8次，大约是90%的可用性。只能说操盘万卡集群不容易呀！

五、预训练

三阶段训练法：(1) 初始训练 initial pre-training, (2) 长文训练 long-context pre-training, and (3) 退火训练 annealing

有点像做菜的感觉...作者特意强调了LLama3增加了非英文部分的比例，增加了数理数据，提高逻辑推理能力。看来这次是铁了心的死磕GPT4了。

初始训练：

余弦调度 8 × 10−5 , 8,000 steps热身, 然后在1,200,000步上降到 8 × 10−7
上下文长度和BS缓慢增加，配4M的bs用4,096长度, 再配8M的bs扩展序列长度为 8,192，这个阶段大约是 252M tokens。最终16M的BS

长上下文训练

从l 8K 逐步增加到 128K

退火训练

最后40M token，用128K长度，逐渐线性缩减学习率到0

六、后训练（对齐）

对话数据格式

多种角色的输入输出的设定和特殊token

RM建模

除了好坏标注之外，增加一路人工编辑，作为最优秀的质量样本 edited > chosen > rejected

SFT

拒绝采样
1e-5 学习率训 8.5K to 9K steps

DPO

token屏蔽，一些特殊的字符不参与学习
DPO+NLL的loss，在IRPO论文里提到的方法，类似正负样本的精细化调权手段

模型融合

权重平均，RM, SFT, or DPO各个阶段独立融合

迭代式训练

同LLama2，最新的模型采样最新的偏好数据，武当总云梯，左脚踩右脚

数据方面

做的特别细，常用的方法如做细粒度标签采样，做模型打各种角度的分，精细的语义去重等
合成数据
“model-as-judge”做模型，去做数据质量筛选

数据部分大体的方法大家都用过，各种角度的数据生产在这篇技术报告中讲的非常细，这里建议大家去看看，不管什么什么O，最终还是洗数据，造数据，选数据。

下面是正文全文的部分，powered by kimi

1 引言

基础模型是设计用来支持大量人工智能（AI）任务的通用模型，它们涵盖了语言、视觉、语音等一个或多个模态。这些模型构成了许多现代AI系统的基础。

现代基础模型的发展包括两个主要阶段：(1) 预训练阶段，在这一阶段，模型通过大规模使用简单任务（如下一个词预测或字幕生成）进行训练；(2) 后续训练阶段，在这一阶段，模型被调整以遵循指令、符合人类偏好，并提高特定能力（例如编码和推理）。

在本文中，我们介绍了一套新的语言基础模型，称为Llama 3。Llama 3模型群原生支持多语言、编码、推理和工具使用。我们最大的模型是一个具有405B参数的密集Transformer，上下文窗口可达128K个token。本文对Llama 3进行了广泛的实证评估。我们发现，Llama 3在众多任务上提供了与领先的语言模型如GPT-4相当的品质。我们公开发布了Llama 3，包括405B参数语言模型的预训练和后训练版本，以及我们的Llama Guard 3模型，用于输入和输出安全。本文还介绍了我们将图像、视频和语音能力通过组合方法集成到Llama 3中的实验结果。我们观察到这种方法在图像、视频和语音识别任务上与最先进技术表现相当。由于这些模型仍在开发中，目前尚未广泛发布。

2 总体概述

Llama 3的模型架构在图1中进行了说明。我们Llama 3语言模型的开发包括两个主要阶段：

语言模型预训练。我们首先将一个大型多语言文本语料库转换为离散的token，并在生成的数据上预训练一个大型语言模型（LLM），以执行下一个token预测。在语言模型预训练阶段，模型学习语言的结构，并从它“阅读”的文本中获得关于世界大量的知识。为了有效地做到这一点，预训练是在大规模上执行的：我们在15.6T tokens上预训练一个带有405B参数的模型，使用8K tokens的上下文窗口。这个标准预训练阶段之后是一个持续的预训练阶段，它将支持的上下文窗口增加到128K tokens。见第3节详情。
语言模型后训练。预训练的语言模型对语言有丰富的理解，但尚未遵循指令或以我们期望助手表现的方式行事。我们在几轮中通过人类反馈与模型对齐，每轮都涉及在指令调整数据上进行监督式微调（SFT）和直接偏好优化（DPO；Rafaailov等人，2024年）。在这个后训练阶段，我们还整合了新的能力，如工具使用，并观察到在其他领域，如编码和推理，取得了显著的改进。见第4节详情。最后，安全缓解措施也在后训练阶段纳入模型，详细描述见第5.4节。

我们生成的模型具有丰富的能力集。它们可以用至少八种语言回答问题，编写高质量的代码，解决复杂的推理问题，并即兴或零样本地使用工具。

我们还进行了实验，通过组合方法将图像、视频和语音能力添加到Llama 3中。我们研究的方法包括图28所示的三个额外阶段：

多模态编码器预训练。我们分别训练图像和语音的编码器。我们在大量图像-文本对上训练图像编码器。这教会了模型视觉内容与自然语言描述之间的关系。我们的语音编码器采用自监督方法训练，通过遮蔽语音输入的部分并尝试通过离散token表示重建被遮蔽的部分。结果，模型学习了语音信号的结构。见第7节和第8节分别关于图像编码器和语音编码器的详细信息。
视觉适配器训练。我们在预训练的语言模型中训练一个适配器，将预训练的图像编码器整合进去。适配器由一系列交叉注意力层组成，将图像编码器的表示输入到语言模型中。适配器在文本-图像对上进行训练。这将图像表示与语言表示对齐。在适配器训练期间，我们也会更新图像编码器的参数，但我们故意不更新语言模型参数。我们还在图像适配器的基础上训练一个视频适配器，以配对视频-文本数据。这使模型能够跨帧聚合信息。见第7节详情。
语音适配器训练。最后，我们通过一个适配器将语音编码器整合到模型中，该适配器将语音编码转换为可以直接输入到微调语言模型的token表示。适配器和编码器的参数在监督微调阶段联合更新，以实现高质量的语音理解。在语音适配器训练期间，我们不改变语言模型。我们还集成了一个文本到语音系统。见第8节详情。

我们的多模态实验导致模型能够识别图像和视频的内容，并通过语音界面支持交互。这些模型仍在开发中，尚未准备好发布。

3 预训练

语言模型预训练包括：(1) 大规模训练语料库的整理和过滤；(2) 开发模型架构和相应的规模定律以确定模型大小；(3) 开发大规模高效预训练技术；(4) 制定预训练方案。我们分别介绍以下每个组成部分。

3.1 预训练数据

我们为语言模型预训练创建的数据集来源于包含直至2023年知识的多种数据源。我们对每个数据源应用了多种去重方法和数据清洗机制，以获得高质量的token。

3.1.1 网络数据整理

我们使用的大部分数据来源于网络，以下描述了我们的清洗流程。

PII和安全过滤：除了其他缓解措施外，我们实施了过滤器以从可能含有不安全内容或大量PII数据的网站上移除数据，包括根据各种Meta安全标准被评为有害的域名。
文本提取和清洗：我们处理非截断网络文档的原始HTML内容，提取高质量、多样化的文本。为此，我们构建了一个自定义解析器，用于提取HTML内容，并优化了去除样板文本和内容召回的精确度。我们通过人类评估比较了我们解析器的质量，与优化文章类内容的流行第三方HTML解析器相比，发现其性能更优。我们仔细处理了包含数学和代码内容的HTML页面，以保留该内容的结构。我们保留了图像alt属性文本，因为数学内容经常以预渲染图像的形式表示，其中数学内容也提供在alt属性中。我们实验性地评估了不同的清洗配置。我们发现，与普通文本相比，markdown对主要在网络数据上训练的模型性能是有害的，因此我们去除了所有的markdown标记。
去重：我们在URL、文档和行级别应用了多轮去重：

URL级别去重：我们在整个数据集上执行URL级别的去重，为每个URL对应的页面保留最新版本。
文档级别去重：我们在整个数据集上执行全局MinHash去重，以移除几乎重复的文档。
行级别去重：我们执行了与ccNet类似的积极行级别去重。我们移除了在每30M文档的桶中出现超过6次的行。尽管我们的手动定性分析显示，行级别去重不仅移除了诸如导航菜单、Cookie警告等各种网站的剩余样板文本，还移除了频繁的高质量文本，但我们的实证评估显示了强有力的改进。

启发式过滤：我们开发了启发式规则，以移除额外的低质量文档、异常值和重复过多的文档。一些启发式的例子包括：
我们使用重复n-gram覆盖率比率来移除由重复内容（如日志或错误消息）组成的行。这些行可能非常长且唯一，因此无法通过行去重过滤。
我们使用“脏字”计数来过滤出未被域名阻止列表覆盖的网站。
我们使用基于Kullback-Leibler散度的token分布来过滤出与训练语料库分布相比含有过多异常token的文档。
基于模型的质量过滤：此外，我们尝试应用各种基于模型的质量分类器来选择高质量的token。包括使用fasttext训练的快速分类器，以识别给定文本是否会被维基百科引用，以及更计算密集的基于Roberta的分类器，它们在Llama 2预测上训练。为了基于Llama 2训练质量分类器，我们创建了一个由Llama 2的聊天模型确定是否满足我们描述的质量要求的清洁网络文档训练集。我们使用DistilRoberta为每个文档生成质量分数，以提高效率。我们通过实验评估了各种质量过滤配置的有效性。
代码和推理数据：类似于DeepSeek-AI等人的工作，我们构建了特定领域的管道来提取代码和与数学相关的网页。具体来说，代码和推理分类器都是基于Roberta的模型，它们在Llama 2注释的网络数据上训练。与上述一般质量分类器不同，我们进行了针对包含数学演绎、STEM领域推理和与自然语言交织的代码的网页的提示调整。由于代码和数学的token分布与自然语言大不相同，这些管道实现了特定领域的HTML提取、定制的文本特征和过滤启发式。
多语言数据：与我们对英语的处理流程类似，我们实施了过滤器，以从可能包含PII或不安全内容的网站中移除数据。我们的多语言文本处理流程具有几个独特的特点：
我们使用基于fasttext的语言识别模型，将文档分类为176种语言。
我们在每种语言的数据中执行文档级别和行级别的去重。
我们应用语言特定的启发式和基于模型的过滤器，以移除低质量的文档。

此外，我们使用基于Llama 2的多语言分类器对多语言文档进行质量排名，以确保优先考虑高质量内容。我们通过实验确定用于预训练的多语言token数量，平衡模型在英语和多语言基准上的性能。

3.2 模型架构

Llama 3 使用的是一个标准、密集的 Transformer 架构（Vaswani 等人，2017）。与 Llama 和 Llama 2（Touvron 等人，2023a,b）在模型架构方面相比，我们的性能提升主要是由数据质量和多样性的提升以及增加的训练规模所驱动的。

与 Llama 3 相比，我们做了一些小的修改：

我们使用了分组查询注意力（Grouped Query Attention, GQA；Ainslie 等人，2023）和 8 个键值对头来提高推理速度，并在解码过程中减少键值对缓存的大小。
我们使用注意力掩码来防止同一序列内不同文档之间的自注意力。我们发现这个改变在标准预训练中的影响有限，但在继续预训练非常长序列时很重要。

以下是 Llama 3 的关键超参数的概览：

层数：8B 模型有 32 层，70B 模型有 80 层，405B 模型有 126 层。
模型维度：8B 模型为 4,096，70B 模型为 8,192，405B 模型为 16,384。
FFN（Feed-Forward Network）维度：8B 模型为 6,144，70B 模型为 12,288，405B 模型为 20,480。
注意力头数：8B 和 70B 模型有 32 个头，405B 模型有 128 个头。
键/值头数：所有模型均为 8。
峰值学习率：8B 模型为 3 × 10^-4，70B 模型为 1.5 × 10^-4，405B 模型为 8 × 10^-5。
激活函数：使用 SwiGLU。
词汇表大小：128,000。
位置嵌入：RoPE（基数频率为 500,000）。

我们还使用了 128K tokens 的词汇表。我们的 token 词汇表结合了来自 tiktoken3 分词器的 100K tokens 和额外的 28K tokens，以更好地支持非英语语言。与 Llama 2 分词器相比，我们的新分词器在样本英语数据上的压缩率从 3.17 提高到 3.94 个字符每个 token。这使得模型在相同的训练计算量下可以“阅读”更多的文本。我们还发现，添加来自特定非英语语言的 28K tokens 既提高了压缩比，也提高了下游性能，而对英语分词没有影响。

我们还增加了 RoPE 的基数频率超参数到 500,000。这使我们能够更好地支持更长的上下文；Xiong 等人（2023）表明这个值对上下文长度达到 32,768 时是有效的。

Llama 3 405B 使用的架构有 126 层，token 表示维度为 16,384，有 128 个注意力头；更详细的信息见表 3。这导致模型大小大约是我们数据上根据规模定律计算出的，对于我们的 3.8 × 10^25 FLOPs 训练预算来说是计算最优的。

3.2.1 规模定律

我们制定了规模定律（Hoffmann 等人，2022；Kaplan 等人，2020）来确定我们的旗舰模型的最佳大小，考虑到我们的预训练计算预算。除了确定最佳模型大小之外，另一个主要挑战是预测旗舰模型在下游基准任务上的性能，由于以下几个问题：(1) 现有的规模定律通常只预测下一个 token 预测损失，而不是特定的基准性能。(2) 规模定律可能是嘈杂和不可靠的，因为它们是基于小计算预算进行的预训练运行开发的（Wei 等人，2022b）。

为了解决这些挑战，我们实施了两阶段方法来开发能够准确预测下游基准性能的规模定律：

我们首先建立计算最优模型在下游任务上的负对数似然与训练 FLOPs 之间的相关性。
接下来，我们利用规模定律模型和使用更高计算 FLOPs 训练的旧模型，将下游任务上的负对数似然与任务准确率相关联。

这种方法使我们能够在给定特定数量的训练 FLOPs 的情况下，预测计算最优模型的下游任务性能。我们使用类似的方法选择我们的预训练数据混合（见第 3.4 节）。

规模定律实验。具体来说，我们通过在 6 × 10^18 FLOPs 到 10^22 FLOPs 之间的计算预算下预训练模型来构建我们的规模定律。在每个计算预算下，我们预训练大小在 4000 万到 160 亿参数之间的模型，使用每个计算预算的模型大小的一个子集。在这些训练运行中，我们使用余弦学习率计划，线性预热 2000 个训练步骤。峰值学习率根据模型大小设置在 2 × 10^-4 到 4 × 10^-4 之间。我们将余弦衰减设置为峰值值的 0.1。每个步骤的权重衰减设置为该步骤学习率的 0.1 倍。我们为每个计算规模使用固定的批量大小，范围在 250K 到 4M 之间。

这些实验产生了图 2 中的 IsoFLOPs 曲线。这些曲线上的损失是在一个单独的验证集上测量的。我们使用二度多项式拟合测量的损失值，并确定每个抛物线的最小值。我们把抛物线的最小值称为相应预训练计算预算的计算最优模型。

我们使用这种方法识别出的计算最优模型来预测特定计算预算下的最佳训练 token 数量。为此，我们假设计算预算 C 和最佳训练 token 数量 N?(C) 之间存在幂律关系：

我们使用图 2 中的数据拟合 A 和 α。我们发现 (α, A) = (0.53, 0.29)；相应的拟合如图 3 所示。将得到的规模定律外推到 3.8 × 10^25 FLOPs 表明应该在 16.55T tokens 上训练一个 402B 参数模型。

一个重要的观察是，随着计算预算的增加，IsoFLOPs 曲线在最小值附近变得平坦。这意味着旗舰模型的性能对于模型大小和训练 tokens 之间权衡的小幅变化相对稳健。基于这一观察，我们最终决定训练一个具有 405B 参数的旗舰模型。

预测下游任务的性能。我们使用得到的计算最优模型来预测旗舰 Llama 3 模型在基准数据集上的性能。首先，我们在线性相关性上将基准中正确答案的负对数似然与训练 FLOPs 相关联。在这项分析中，我们只使用在上述数据混合上训练到 10^22 FLOPs 的规模定律模型。接下来，我们使用规模定律模型和使用 Llama 2 数据混合和分词器训练的 Llama 2 模型，建立对数似然与准确率之间的 S 形关系。我们在 ARC Challenge 基准上展示了这个实验的结果（见图 4）。我们发现这种两步规模定律预测，它在四个数量级上进行外推，相当准确：它只是略微低估了旗舰 Llama 3 模型的最终性能。

3.3 基础设施、扩展性和效率

我们描述了支持 Llama 3 405B 模型在大规模上进行预训练的硬件和基础设施，并讨论了几项优化措施，这些措施带来了训练效率的提升。

3.3.1 训练基础设施

Llama 1 和 2 模型是在 Meta 的 AI 研究超级集群（Lee 和 Sengupta，2022）上训练的。随着我们进一步扩展，Llama 3 的训练转移到了 Meta 的生产集群（Lee 等人，2024）。这个设置优化了生产级别的可靠性，这在我们扩展训练时至关重要。

计算：Llama 3 405B 在多达 16K 个 H100 GPU 上进行训练，每个 GPU 运行在 700W TDP 下，配备 80GB HBM3，使用 Meta 的 Grand Teton AI 服务器平台（Matt Bowman，2022）。每个服务器配备八个 GPU 和两个 CPU。在服务器内部，八个 GPU 通过 NVLink 连接。训练作业使用 MAST（Choudhury 等人，2024）调度，这是 Meta 的全球规模训练调度器。
存储：Tectonic（Pan 等人，2021），Meta 的通用分布式文件系统，被用来为 Llama 3 预训练构建存储网络。它提供了 240PB 的存储空间，由配备 SSD 的 7,500 台服务器支持，并支持持续吞吐量 2TB/s 和峰值吞吐量 7TB/s。一个主要挑战是支持高度突发的检查点写入，这些写入在短时间内饱和存储网络。检查点保存每个 GPU 的模型状态，范围从 1MB 到 4GB 不等，用于恢复和调试。我们的目标是最小化检查点期间的 GPU 暂停时间，并增加检查点频率，以减少恢复后丢失的工作量。
网络：Llama 3 405B 使用基于 Arista 7800 和 Minipack2 开放计算项目（OCP）机架交换机的 RDMA over Converged Ethernet（RoCE）网络。Llama 3 家族中较小的模型使用 Nvidia Quantum2 InfiniBand 网络进行训练。尽管这些集群的底层网络技术不同，但我们调整了它们，以提供这些大型训练工作负载的等效性能。我们进一步讨论了我们的 RoCE 网络，因为我们完全拥有它的设计。

网络拓扑：我们的基于 RoCE 的 AI 集群包括 24K GPU，由三层 Clos 网络（Lee 等人，2024）连接。在底层，每个机架托管 16 个 GPU，分布在两台服务器之间，并通过一个 Minipack2 机架顶部交换机连接。在中间层，192 个这样的机架通过集群交换机连接，形成一个拥有 3,072 个 GPU 的 pod，具有完整的双工带宽，确保没有过订阅。在顶层，同一数据中心大楼内的八个这样的 pod 通过聚合交换机连接，形成一个 24K GPU 的集群。然而，聚合层的网络连接没有保持完整的双工带宽，而是有一个 1:7 的过订阅比率。我们的模型并行方法（见第 3.3.2 节）和训练作业调度器（Choudhury 等人，2024）都针对网络拓扑进行了优化，旨在最小化跨 pod 的网络通信。
负载均衡：LLM 训练产生难以使用传统方法（如 Equal-Cost Multi-Path（ECMP）路由）在所有可用网络路径上进行负载均衡的胖网络流。为解决这一挑战，我们采用了两种技术。首先，我们的集合库在两个 GPU 之间创建 16 个网络流，而不是仅仅一个，从而减少了每个流的流量，并提供了更多的流用于负载均衡。其次，我们的 Enhanced-ECMP（E-ECMP）协议通过在 RoCE 数据包头中散列额外的字段，有效地在不同的网络路径上平衡这些 16 个流。
拥塞控制：我们使用深缓冲交换机在脊柱（Gangidi 等人，2024）上容纳由集体通信模式引起的瞬态拥塞和缓冲。这种设置有助于限制由慢服务器引起的持续拥塞和网络背压的影响，这在训练中很常见。最后，通过 E-ECMP 进行更好的负载均衡显著降低了拥塞的可能性。通过这些优化，我们成功地运行了一个 24K GPU 集群，而无需使用传统的拥塞控制方法，如数据中心量化拥塞通知（DCQCN）。

3.3.2 模型扩展的并行性

为扩展我们最大模型的训练，我们使用 4D 并行性 - 结合四种不同类型的并行性方法 - 来分片模型。这种方法有效地在许多 GPU 上分布计算，并确保每个 GPU 的模型参数、优化器状态、梯度和激活都适合其 HBM。我们在图 5 中展示了 4D 并行性的实现。它结合了张量并行性（TP；Krizhevsky 等人（2012）；Shoeybi 等人（2019）；Korthikanti 等人（2023））、流水线并行性（PP；Huang 等人（2019）；Narayanan 等人（2021）；Lamy-Poirier（2023））、上下文并行性（CP；Liu 等人（2023a））和数据并行性（DP；Rajbhandari 等人（2020）；Ren 等人（2021）；Zhao 等人（2023b））。

张量并行性将个别权重张量分割成不同设备上的多个块。流水线并行性通过层将模型垂直划分为多个阶段，以便不同的设备可以并行处理模型管道的不同阶段。上下文并行性将输入上下文分割成段，减少了非常长序列输入的内存瓶颈。我们使用完全分片的数据并行性（FSDP；Rajbhandari 等人（2020）；Ren 等人（2021）；Zhao 等人（2023b）），它在处理数据时在多个 GPU 上并行同步每个训练步骤后的模型、优化器和梯度。我们对 Llama 3 使用 FSDP 来分片优化器状态和梯度，但对于模型分片，我们在前向计算后不重新分片，以避免在反向传递期间进行额外的全收集通信。

GPU 利用率。通过仔细调整并行性配置、硬件和软件，我们实现了在表 4 所示配置中 BF16 模型 FLOPs 利用率（MFU；Chowdhery 等人（2023））为 38-43%。在 16K GPU 上，DP=128 的 MFU 略降至 41%，而在 8K GPU 上，DP=64 的 MFU 为 43%，这是由于在训练期间需要保持全局批次中的 token 数量不变，因此每 DP 组的批量大小较小。

流水线并行性改进。我们在使用现有实现时遇到了几个挑战：

批量大小限制：当前实现对每个 GPU 支持的批量大小有限制，要求它能够被流水线阶段的数量整除。例如，在图 6 中，流水线并行性的深度优先调度（DFS）要求 N = PP = 4，而广度优先调度（BFS；Lamy-Poirier（2023））要求 N = M，其中 M 是微批次的总数，N 是同一阶段的前向或后向的连续微批次的数量。然而，预训练通常需要灵活性来调整批量大小。
内存不平衡：现有的流水线并行性实现导致资源消耗不平衡。第一阶段由于嵌入和热身微批次而消耗更多的内存。
计算不平衡：在模型的最后一层之后，我们需要计算输出和损失，这使得这个阶段成为执行延迟的瓶颈。

为解决这些问题，我们修改了流水线计划，如图 6 所示，它允许灵活地设置 N —— 在这种情况下 N = 5，可以运行每个批次中的任意数量的微批次。这使我们能够：(1) 当我们在大规模时遇到批量大小限制时，运行少于流水线阶段数量的微批次；或者 (2) 运行更多的微批次以隐藏点对点通信，找到 DFS 和 BFS 最佳通信和内存效率之间的最佳平衡点。为了平衡流水线，我们分别从第一和最后阶段减少了一个 Transformer 层。这意味着第一阶段的第一个模型块只有嵌入，最后阶段的最后一个模型块只有输出投影和损失计算。为了减少流水线气泡，我们使用了一个交错计划（Narayanan 等人，2021），在 V 个流水线阶段上使用一个流水线等级。总体流水线气泡比率是 ( (PP-1) \times \frac{V \times M}{M+1} )。此外，我们在 PP 中采用了异步点对点通信，这在训练中大大加快了速度，特别是在文档掩码引入额外计算不平衡的情况下。我们启用了 TORCH_NCCL_AVOID_RECORD_STREAMS 来减少异步点对

点通信的内存使用。最后，为了减少内存成本，基于详细的内存分配分析，我们主动释放了未来计算中不会使用的张量，包括每个流水线阶段的输入和输出张量。

上下文并行性用于长序列。我们利用上下文并行性（CP）在扩展 Llama 3 的上下文长度时提高内存效率，并支持训练长达 128K 的极长序列。在 CP 中，我们跨序列维度进行分割，具体来说，我们将输入序列分割成 2 × CP 块，以便每个 CP 等级接收两个块以实现更好的负载均衡。第 i 个 CP 等级接收第 i 个和第 (2 × CP − 1 − i) 个块。

与现有的 CP 实现不同，它们在环状结构中重叠通信和计算（Liu 等人，2023a），我们的 CP 实现采用了基于 all-gather 的方法，我们首先 all-gather 键（K）和值（V）张量，然后计算局部查询（Q）张量块的注意力输出。尽管 all-gather 通信延迟在关键路径上暴露出来，但我们仍然采用这种方法，主要有两个原因：(1) 在 all-gather 基础的 CP 注意力中，支持不同类型的注意力掩码（如文档掩码）更容易、更灵活；(2) 由于使用 GQA（Ainslie 等人，2023），通信的 K 和 V 张量比 Q 张量小得多，因此注意力计算的时间复杂度比 all-gather 大一个数量级（O(S^2) 相对于 O(S)，其中 S 表示全因果掩码中的序列长度），使 all-gather 延迟可以忽略不计。

网络感知并行性配置。并行性维度的顺序 [TP, CP, PP, DP] 针对网络通信进行了优化。内部并行性需要最高的网络带宽和最低的延迟，因此通常限制在同一个服务器内。外部并行性可以跨越多跳网络，并应容忍更高的网络延迟。因此，基于对网络带宽和延迟的要求，我们按照 [TP, CP, PP, DP] 的顺序放置并行性维度。DP（即 FSDP）是外部并行性，因为它可以通过异步预取分片模型权重和减少梯度来容忍更长的网络延迟。识别具有最小通信开销的最优并行性配置，同时避免 GPU 内存溢出是具有挑战性的。我们开发了一个内存消耗估计器和性能预测工具，帮助我们探索各种并行性配置，并有效地预测整体训练性能，识别内存差距。

数值稳定性。通过比较不同并行性设置之间的训练损失，我们确定了影响训练稳定性的几个数值问题。为确保训练收敛，我们在多个微批次的反向计算中使用 FP32 梯度累积，并在 FSDP 中跨数据并行工作进行 FP32 reduce-scatter 梯度。对于在前向计算中多次使用的中间张量，例如视觉编码器输出，反向梯度也以 FP32 累积。

3.3.3 集体通信

我们的 Llama 3 集体通信库基于 Nvidia 的 NCCL 库的一个分支，称为 NCCLX。NCCLX 显著提高了 NCCL，特别是对于更高延迟网络的性能。回想一下，平行性维度的顺序是 [TP, CP, PP, DP]，其中 DP 对应于 FSDP。最外层的平行性维度，PP 和 DP，可能通过多跳网络通信，延迟可能高达数十微秒。原始的 NCCL 集合体 —— FSDP 中的 all-gather 和 reduce-scatter，以及 PP 中的点对点 —— 需要数据分块和阶段性数据复制。这种方法引入了几个效率低下的问题，包括：(1) 需要在网络上交换大量的小控制消息以促进数据传输；(2) 额外的内存复制操作；(3) 使用额外的 GPU 周期进行通信。对于 Llama 3 训练，我们通过调整分块和数据传输以适应我们的网络延迟，解决了这些问题的子集，这些网络延迟可能高达大型集群的数十微秒。我们还允许小控制消息以更高的优先级穿越网络，特别是避免在深缓冲核心交换机中被阻塞。我们正在进行的 Llama 版本未来的工作涉及在 NCCLX 中进行更深入的更改，以全面解决前述所有问题。

3.3.4 可靠性和操作挑战

16K GPU 训练的复杂性和潜在故障场景超过了我们操作过的更大的 CPU 集群。此外，训练的同步性质使其对故障的容忍度更低 —— 一个 GPU 故障可能需要整个作业重新启动。尽管存在这些挑战，对于 Llama 3，我们实现了超过 90% 的有效训练时间，同时支持自动化集群维护，如固件和 Linux 内核升级（Vigraham 和 Leonhardi，2024），这导致至少每天有一次训练中断。有效训练时间衡量的是在经过时间中用于有用训练的时间。

在 Llama 3 405B 预训练的 54 天快照期间，我们经历了总共 466 次作业中断。其中，47 次是计划内的中断，由于自动化维护操作，如固件升级或操作员启动的操作，如配置或数据集更新。其余 419 次是意外的中断，如表 5 所示。大约 78% 的意外中断归因于确认或疑似硬件问题，如 GPU 或主机组件故障，或疑似与硬件相关的问题，如静默数据损坏和计划外的单个主机维护事件。GPU 问题是最大部分，占所有意外问题的 58.7%。尽管失败数量众多，但在此期间，仅需要三次重大手动干预，其余问题由自动化处理。

为了增加有效训练时间，我们减少了作业启动和检查点时间，并开发了快速诊断和问题解决工具。我们广泛使用 PyTorch 内置的 NCCL 飞行记录器（Ansel 等人，2024），这是一个在环形缓冲区中捕获集体元数据和堆栈跟踪的功能，使我们能够在大规模上快速诊断挂起和性能问题，特别是与 NCCLX 相关的。使用此功能，我们有效地记录了每个通信事件和每个集体操作的持续时间，并且在 NCCLX 看门狗或心跳超时时自动转储跟踪数据。我们通过在线配置更改启用了更多计算密集型的跟踪操作和元数据收集，并且根据需要实时在生产中进行，无需代码发布或作业重新启动。

调试大规模训练中的问题由于 NVLink 和 RoCE 在我们的网络中的混合使用而变得复杂。通过 CUDA 内核发出的 load/store 操作通常进行 NVLink 上的数据传输，远程 GPU 或 NVLink 连通性的故障通常表现为 CUDA 内核中的 load/store 操作停滞，而没有返回清晰的错误代码。NCCLX 通过与 PyTorch 的紧密设计，提高了故障检测和定位的速度和准确性，允许 PyTorch 访问 NCCLX 的内部状态并跟踪相关信息。虽然不能完全防止由于 NVLink 故障引起的停滞，但系统会在检测到此类停滞时自动超时。此外，NCCLX 跟踪每次 NCCLX 通信的内核和网络活动，并提供失败的 NCCLX 集合体的内部状态快照，包括所有等级之间完成和待定的数据传输。我们分析这些数据以调试 NCCLX 扩展问题。

有时，硬件问题可能导致仍然运行但运行缓慢的落后者，这很难检测。即使一个落后者也可以减慢数千个其他 GPU，通常表现为通信功能正常但速度慢。我们开发了工具，以优先处理选定进程组中可能存在问题的通信。通过仅调查少数主要嫌疑人，我们通常能够有效地识别落后者。

一个有趣的观察是环境因素对大规模训练性能的影响。对于 Llama 3 405B，我们注意到基于一天中的时间，吞吐量有 1-2% 的波动。这种波动是由于中午温度较高影响 GPU 动态电压和频率缩放。在训练期间，数万个 GPU 可能同时增加或减少功耗，例如，由于所有 GPU 等待检查点完成或集体通信结束，或者整个训练作业的启动或关闭。当这种情况发生时，它可能导致数据中心的功耗瞬间波动数十兆瓦，拉伸电网的极限。随着我们为未来的更大 Llama 模型扩展训练，这是我们面临的一个持续挑战。

3.4 训练方案

用于预训练 Llama 3 405B 的方案包括三个主要阶段：(1) 初始预训练，(2) 长上下文预训练，和 (3) 退火。下面分别描述这三个阶段。我们使用类似的方案来预训练 8B 和 70B 模型。

3.4.1 初始预训练

我们使用余弦学习率计划对 Llama 3 405B 进行预训练，峰值学习率为 8 × 10^-5，线性预热 8,000 步，然后在 1,200,000 个训练步骤中衰减到 8 × 10^-7。我们在训练初期使用较小的批量大小以提高训练稳定性，并随后增加它以提高效率。具体来说，我们最初使用 4M tokens 的批量大小和 4,096 的序列长度，然后在预训练了 252M tokens 后，将这些值翻倍到 8M tokens 和 8,192 的序列长度。我们再次将批量大小翻倍到 16M，达到 2.87T tokens 的预训练量。我们发现这种训练方案非常稳定：我们观察到很少的损失峰值，并且不需要干预来纠正模型训练发散。

调整数据混合。我们在训练期间对预训练数据混合进行了几次调整，以提高模型在特定下游任务上的性能。特别是，我们增加了非英语数据在预训练中的比例，以提高 Llama 3 的多语言性能。我们还上采样数学数据以提高模型的数学推理性能，我们在预训练的后期增加了更多的最新网络数据以推进模型的知识截止日期，并且我们对后来被识别为质量较低的预训练数据子集进行了下采样。

3.4.2 长上下文预训练

在预训练的最后阶段，我们训练长序列以支持长达 128K tokens 的上下文窗口。我们不在早期训练长序列，因为自注意力层中的计算在序列长度上呈二次方增长。我们以增量方式增加支持的上下文长度，直到模型成功适应增加的上下文长度。我们通过测量以下两点来评估成功的适应：(1) 模型在短上下文评估中的性能是否完全恢复；(2) 模型是否完美解决了长达该长度的“大海捞针”任务。在 Llama 3 405B 预训练中，我们从原始的 8K 上下文窗口开始，逐步增加上下文长度，分为六个阶段，最终达到 128K 上下文窗口。这个长上下文预训练阶段使用了大约 800B 训练 tokens。

3.4.3 退火

在预训练的最后 40M tokens 期间，我们线性地将学习率退火到 0，同时保持 128K tokens 的上下文长度。在退火阶段，我们还调整了数据混合，以提高选择特定领域的高质量数据的比例。最后，我们计算了退火期间模型检查点的平均值（Polyak（1991）平均），以产生最终的预训练模型。

3.4 训练方案

用于预训练 Llama 3 405B 的方案由三个主要阶段组成：(1) 初始预训练，(2) 长上下文预训练，和 (3) 退火。下面将分别描述这三个阶段。我们也使用类似的方案来预训练 8B 和 70B 模型。

3.4.1 初始预训练

我们使用余弦学习率计划对 Llama 3 405B 进行初始预训练，峰值学习率为 (8 \times 10^{-5})，线性预热 8,000 步，然后在 1,200,000 个训练步骤中衰减到 (8 \times 10^{-7})。我们在训练初期使用较小的批量大小以提高训练稳定性，并随后增加它以提高效率。具体来说，我们最初使用 4M tokens 的批量大小和 4,096 的序列长度，然后在预训练了 252M tokens 后，将这些值翻倍到 8M tokens 和 8,192 的序列长度。我们再次将批量大小翻倍到 16M，达到 2.87T tokens 的预训练量。我们发现这种训练方案非常稳定：我们观察到很少的损失峰值，并且不需要干预来纠正模型训练发散。

3.4.2 长上下文预训练

3.4.3 退火

在预训练的最后 40M tokens 期间，我们线性地将学习率退火到 0，同时保持 128K tokens 的上下文长度。在退火阶段，我们还调整了数据混合，以提高选择特定领域的高质量数据的比例。最后，我们计算了退火期间模型检查点的 Polyak 平均值，以产生最终的预训练模型。

4.1 建模

我们的后训练策略的支柱是一个奖励模型和一个语言模型。我们首先在预训练检查点之上训练一个奖励模型，使用人类标注的偏好数据（见第4.1.2节）。然后，我们在监督式微调（SFT；见第4.1.3节）后使用奖励模型进行拒绝采样，并对预训练检查点进行微调，并进一步通过直接偏好优化（DPO；Rafaailov等人，2024）与人类偏好对齐。这个过程在图7中进行了说明。除非另有说明，我们的建模过程适用于Llama 3 405B，并且为了简便，我们将Llama 3 405B简称为Llama 3。

4.1.1 对话格式

为了调整大型语言模型（LLM）进行人类-AI交互，我们需要为模型定义一个对话协议，以便它理解人类指令并执行会话任务。与其前身相比，Llama 3具有新的能力，如工具使用（第4.3.5节），可能需要在单个对话回合中生成多个消息并将其发送到不同位置（例如，用户，ipython）。为支持这一点，我们设计了一种新的多消息聊天协议，使用各种特殊的头部和终止符标记。头部标记用于指示对话中每个消息的来源和目的地。同样，终止符标记指示何时轮到人类和AI交替发言。

4.1.2 奖励建模

我们在预训练检查点之上训练一个奖励模型（RM），涵盖不同的能力。训练目标与Llama 2相同，只是我们从损失中移除了边际项，因为我们观察到在数据扩展后改进逐渐减少。根据Llama 2，我们使用所有偏好数据进行奖励建模，在过滤掉具有相似响应的样本之后。除了标准的偏好对（被选择的，被拒绝的）响应外，注释还为某些提示创建了第三个“编辑过的响应”，其中选择的响应进一步编辑以改进（见第4.2.1节）。因此，每个偏好排名样本都有两个或三个具有明确排名的响应（编辑过的 > 被选择的 > 被拒绝的）。我们在训练期间将提示和多个响应合并成单行，响应随机打乱。这是将响应分别放在不同行中并计算分数的标准场景的近似，但在我们的消融研究中，这种方法在不损失准确性的情况下提高了训练效率。

4.1.3 监督式微调

然后，我们使用奖励模型在我们的人类标注提示上执行拒绝采样，详细信息在第4.2.2节中描述。与此拒绝采样数据和其他数据源（包括合成数据）一起，我们使用标准交叉熵损失对目标tokens进行微调（同时掩盖提示tokens的损失）。关于数据混合的更多细节可以在第4.2节找到。我们称这个阶段为监督式微调（SFT；Wei等人，2022a；Sanh等人，2022；Wang等人，2022b），即使许多训练目标是模型生成的。我们最大的模型使用1e-5的学习率在8.5K到9K步的过程中进行微调。我们发现这些超参数设置在不同的回合和数据混合中都表现良好。

4.1.4 直接偏好优化

我们进一步使用直接偏好优化（DPO；Rafaailov等人，2024）训练我们的SFT模型，以符合人类偏好。在训练中，我们主要使用以前一轮对齐中表现最好的模型收集的最新一批偏好数据。因此，我们的训练数据更好地符合正在优化的策略模型的分布。我们还探索了像PPO（Schulman等人，2017）这样的策略算法，但发现DPO对于大规模模型需要的计算量更少，并且在像IFEval（Zhou等人，2023）这样的指令跟随基准测试中表现更好。对于Llama 3，我们使用1e-5的学习率，并将β超参数设置为0.1。此外，我们对DPO应用了以下算法修改：

在DPO损失中屏蔽格式化标记：我们从损失中屏蔽特殊的格式化标记，包括头部和终止符（在第4.1.1节中描述），从选择的和拒绝的响应中。我们观察到，让这些标记贡献到损失可能导致不期望的模型行为，如尾部重复或突然生成终止符。我们假设这是由于DPO损失的对比性质 - 两个响应中存在共同标记导致学习目标冲突，因为模型需要同时增加和减少这些标记的可能性。
通过NLL损失进行正则化：我们在选择的序列上增加了一个额外的负对数似然（NLL）损失项，缩放系数为0.2，类似于Pang等人（2024）。这有助于通过保持生成的期望格式和防止选择响应的对数概率下降来进一步稳定DPO训练（Pang等人，2024；Pal等人，2024）。

4.1.5 模型平均

最后，我们在每个RM、SFT或DPO阶段使用不同版本的数据或超参数进行实验，平均获得的模型（Izmailov等人，2019；Wortsman等人，2022；Li等人，2022）。

4.1.6 迭代轮次

按照Llama 2的做法，我们应用上述方法进行六轮。在每一轮中，我们收集新的偏好注释和SFT数据，从最新模型中采样合成数据。

4.2 后训练数据

后训练数据的组成在语言模型的有用性和行为中起着关键作用。在本节中，我们将讨论我们的人类注释程序和偏好数据收集（第4.2.1节），SFT数据的组成（第4.2.2节），以及数据质量控制和清洗的方法（第4.2.3节）。

4.2.1 偏好数据

我们的偏好数据注释过程与Llama 2类似。我们在每一轮后部署多个模型进行注释，并为每个用户提示采样两个来自不同模型的响应。这些模型可能使用不同的数据混合和对齐配方，允许不同的能力强度（例如，编码专业知识）和增加数据多样性。我们要求注释者根据他们更喜欢选择的响应而不是拒绝的响应的程度，将其偏好强度分为四个等级之一：明显更好，更好，稍微更好或略好。我们还在偏好排名后增加了一个编辑步骤，鼓励注释者进一步改进首选响应。注释者可以直接编辑首选响应或提示模型以改进其自身响应。因此，我们的偏好数据的一部分有三个排名的响应（编辑过的 > 被选择的 > 被拒绝的）。

在表6中，我们报告了用于Llama 3训练的偏好注释的统计数据。一般英语涵盖了多个子类别，如基于知识的问答或精确指令跟随，这些不在特定能力范围之内。与Llama 2相比，我们观察到提示和响应的平均长度增加，表明我们正在训练Llama 3处理更复杂的任务。此外，我们还实施了质量分析和人类评估流程，以严格评估收集的数据，使我们能够完善我们的提示并为注释者提供系统、可操作的反馈。例如，随着Llama 3在每一轮后改进，我们相应地增加提示的复杂性，以针对模型滞后的领域。

在每一轮后训练中，我们使用当时可用的所有偏好数据进行奖励建模，同时仅使用来自各种能力的最新批次进行DPO训练。对于奖励建模和DPO，我们使用被标记为选择的响应明显优于或优于拒绝的对应物的样本进行训练，并丢弃响应相似的样本。

4.2.2 SFT数据

我们的微调数据主要由以下来源组成：

人类注释收集的提示，拒绝采样的响应
针对特定能力（见第4.3节的更多细节）的合成数据
少量人类策划的数据（见第4.3节的更多细节）

随着我们后训练轮次的进展，我们开发了更强的Llama 3变体，我们使用它们来收集涵盖广泛复杂能力的大型数据集。在本节中，我们讨论了拒绝采样过程的细节和我们最终SFT数据混合的组成。

拒绝采样。在拒绝采样（RS）期间，对于在人类注释期间收集的每个提示，我们从最新的聊天模型策略（通常是以前后训练迭代中表现最佳的检查点，或特定能力的最表现良好的检查点）采样K（通常在10到30之间）个输出，并使用我们的奖励模型选择最佳候选，与Bai等人（2022）一致。在后训练的后期，我们引入系统提示以引导RS响应符合期望的语气、风格或格式，这些可能因不同能力而异。

为了提高拒绝采样的效率，我们采用了PagedAttention（Kwon等人，2023）。PagedAttention通过动态键值缓存分配提高内存效率。它支持任意输出长度，通过根据当前缓存容量动态调度请求。不幸的是，这带来了内存不足时的交换风险。为了消除这种交换开销，我们定义了最大输出长度，并仅在有足够的内存容纳该长度的输出时才执行请求。PagedAttention还使我们能够在所有相应的输出中共享提示的键值缓存页面。总的来说，这在拒绝采样期间将吞吐量提高了超过2倍。

整体数据组成。表7显示了我们“有用

性”混合中每个广泛类别的数据统计信息。虽然SFT和偏好数据包含重叠的领域，但它们被不同地策划，产生了不同的计数统计数据。在第4.2.3节中，我们描述了用于对我们的数据样本进行主题、复杂性和质量分类的技术。在每一轮后训练中，我们仔细调整这些轴上的整体数据混合，以在广泛的基准测试中调整性能。我们最终的数据混合在一些高质量资源上多次采样，并降低其他资源的采样。

4.2.3 数据处理和质量控制

由于我们的大部分训练数据是模型生成的，因此需要仔细清洗和质量控制。

数据清洗。在早期轮次中，我们观察到数据中存在一些不良模式，例如过度使用表情符号或感叹号。因此，我们实施了一系列基于规则的数据删除和修改策略，以过滤或清洗有问题的数据。例如，为了缓解过于道歉的语气问题，我们识别过度使用的短语（如“I’m sorry”或“I apologize”），并仔细平衡我们数据集中这类样本的比例。

数据修剪。我们还应用了一系列基于模型的技术来删除低质量的训练样本并提高整体模型性能：

主题分类：我们首先将 Llama 3 8B 微调为一个主题分类器，并在所有数据上进行推理，将其分类为粗粒度（如“数学推理”）和细粒度（如“几何和三角学”）的桶。
质量评分：我们使用奖励模型和基于 Llama 的信号为每个样本获得质量分数。对于基于 RM 的分数，我们认为处于 RM 分数最高四分位数的数据是高质量的。对于基于 Llama 的分数，我们提示 Llama 3 检查点对每个样本在三点量表上进行一般英语数据（准确性、指令跟随和语气/呈现）评分，以及对编码数据（错误识别和用户意图）进行两点量表评分，并将获得最高分数的样本视为高质量。RM 和基于 Llama 的分数有很高的不一致率，我们发现结合这些信号在我们的内部测试集上获得了最佳的召回率。最终，我们选择被 RM 或基于 Llama 的过滤器标记为高质量的示例。
难度评分：因为我们还对优先考虑模型更复杂的示例感兴趣，所以我们使用两种难度度量：Instag（Lu等人，2023）和基于 Llama 的评分。对于 Instag，我们提示 Llama 3 70B 对 SFT 提示进行意图标记，其中更多的意图意味着更高的复杂性。我们还提示 Llama 3 在三点量表上测量对话的难度（Liu等人，2024c）。
语义去重：最后，我们执行语义去重（Abbas等人，2023；Liu等人，2024c）。我们首先使用 RoBERTa（Liu等人，2019b）对完整对话进行聚类，然后在每个聚类内按质量分数 × 难度分数排序。然后我们通过迭代所有排序的示例，只保留与迄今为止在聚类中看到的示例的最大余弦相似度小于阈值的示例，进行贪婪选择。

4.3 能力

我们强调了提高特定能力的性能的特别努力，如代码（第4.3.1节）、多语言（第4.3.2节）、数学和推理（第4.3.3节）、长上下文（第4.3.4节）、工具使用（第4.3.5节）、事实性（第4.3.6节）和可引导性（第4.3.7节）。

5 结果

我们对Llama 3进行了广泛的评估，调查了以下方面的表现：(1) 预训练语言模型；(2) 后训练语言模型；以及 (3) Llama 3的安全特性。我们在下面的各个小节中分别介绍了这些评估的结果。

5.1 预训练语言模型

在本节中，我们报告了我们的预训练Llama 3（见第3节）的评估结果，并将其与具有相似规模的各种其他模型进行了比较。我们尽可能地复现了竞争对手模型的结果。对于非Llama模型，我们报告了公开报告的或（尽可能）我们自己复现的最佳分数。这些评估的具体情况，包括配置，如示例数量、指标以及相关的超参数和其他设置，可以在我们这里的Github存储库中找到。此外，我们还发布了与公开可用基准一起使用的数据生成的评估结果，这些可以在Huggingface这里找到。我们在标准基准（第5.1.1节）、对多项选择题设置变化的鲁棒性（第5.1.2节）以及对抗性评估（第5.1.3节）上评估了我们模型的质量。我们还进行了污染分析，以估计我们的评估在多大程度上受到预训练语料库中评估数据的污染影响（第5.1.4节）。

5.1.1 标准基准

为了与当前的最先进水平进行比较，我们在表8中显示的大量标准基准评估上评估了Llama 3。这些评估涵盖了八个顶级类别：(1) 常识推理；(2) 知识；(3) 阅读理解；(4) 数学、推理和问题解决；(5) 长上下文；(6) 代码；(7) 对抗性评估；以及 (8) 综合评估。

5.1.2 模型鲁棒性

除了在基准测试上的表现外，鲁棒性是预训练语言模型质量的一个重要因素。我们使用MMLU基准测试来评估我们的预训练模型对多项选择题（MCQ）设置中的设计选择的鲁棒性。先前的工作报道说，模型性能可能对此类设置中的看似任意的设计选择敏感，例如，模型分数甚至排名可能会随着上下文中示例的顺序和标签（Lu等人，2022；Zhao等人，2021；Robinson和Wingate，2023；Liang等人，2022；Gupta等人，2024）而改变，提示的确切格式（Weber等人，2023b；Mishra等人，2022）或答案选项的格式和顺序（Alzahrani等人，2024；Wang等人，2024a；Zheng等人，2023）。

5.1.3 对抗性基准

除了上述基准测试外，我们还评估了几个领域的对抗性基准：问题回答、数学推理和释义检测。这种测试探测模型在特意创建的具有挑战性的任务上的能力，并且可能也会指向在基准测试上的过拟合。对于问题回答，我们使用了Adversarial SQuAD（Jia和Liang，2017）和Dynabench SQuAD（Kiela等人，2021）。对于数学推理，我们使用了GSM-Plus（Li等人，2024c）。对于释义检测，我们使用了PAWS（Zhang等人，2019）。

5.1.4 污染分析

我们进行了污染分析，以估计基准测试分数在多大程度上可能受到预训练语料库中评估数据的污染影响。在以前的工作中，使用了许多不同的污染方法，具有各种不同的超参数 - 我们参考Singh等人（2024）的概述。这些方法都可能存在误报和漏报，如何最好地运行污染分析仍然是一个开放的研究领域。在这里，我们主要遵循Singh等人（2024）的建议。

#FLUX.1

全员离开老东家，Stable Diffusion一作带团创业，出手即击败MJ v6、SD3，还开源

AI 图像和视频生成领域又加入了一个颇有实力的玩家。

还记得今年 3 月底，从 AI 初创公司 Stability AI 离职的研究科学家 Robin Rombach 吗？作为开发出文生图模型 Stable Diffusion 的两位主要作者之一，他于 2022 年加入 Stability AI。

如今，在从 Stability AI 离职近五个月后，Robin Rombach 发推宣布了自己创业的好消息！

他成立了「Black Forest Labs」，旨在推进用于图像和视频的 SOTA 高质量生成式深度学习模型，并开放给尽可能多的人使用。

团队成员由杰出的 AI 研究者和工程师组成，他们之前的代表性工作包括 VQGAN 和 Latent Diffusion、图像和视频生成领域的 Stable Diffusion 模型（包括 Stable Diffusion XL、Stable Video Diffusion 和 Rectified Flow Transformers）以及用于超快实时图像合成的 Adversarial Diffusion Distillation。

值得注意的是，除了 Robin Rombach 之外，Stable Diffusion 还有三位作者成为了创始团队成员，包括 Andreas Blattmann、 Dominik Lorenz 和 Patrick Esser。他们都在今年早些时候离开了 Stability AI，有人猜测他们当初离开就是为了自己创业。

目前，该 Labs 已经完成 3100 万美元的种子轮融资，由 Andreessen Horowitz 领投。其他投资者包括了天使投资人 Brendan Iribe、Michael Ovitz、Garry Tan、Timo Aila、Vladlen Koltun 以及一些知名 AI 研究和创业专家。此外还获得了来自 General Catalyst 和 MätchVC 的后续投资。

该 Labs 还成立了顾问委员会，成员包括在内容创作行业具有广泛经验的科技大佬 Michael Ovitz 和神经风格迁移先驱、欧洲开放 AI 研究的顶级专家 Matthias Bethge 教授。

当然，Black Forest Labs 推出了首个模型系列「FLUX.1」，包含了以下三个变体模型。

第一个变体是 FLUX.1 [pro]，它是全新的 SOTA 文生图模型，具有极其丰富的图像细节、极强的 prompt 遵循能力和多样化风格。目前可以通过 API 使用。

API 地址：https://docs.bfl.ml/

第二个是 FLUX.1 [dev]，它是 FLUX.1 [pro] 的开放权重、非商用变体，并直接基于后者蒸馏而成。该模型的表现优于 Midjourney 和 Stable Diffusion 3 等其他图像模型。推理代码和权重已经放在了 GitHub 上。下图是与竞品图像模型的比较。

GitHub 地址：https://github.com/black-forest-labs/flux

第三个是开源的 FLUX.1 [schnell]，它是超高效的 4-step 模型，遵循了 Apache 2.0 协议。该模型在性能上与 [dev]、[pro] 非常接近，可以在 Hugging Face 上使用。

Hugging Face 地址：https://huggingface.co/black-forest-labs/FLUX.1-schnell

与此同时，Black Forest Labs 也开始宣传自己了。

下一步的目标是推出所有人可用的 SOTA 文生视频模型，大家可以期待一波了！

一出手即王炸：文生图模型系列「FLUX.1」来袭

这次 Black Forest Labs 推出的三款模型，均采用了多模态和并行扩散 Transformer 的混合架构。不同于其他家将一系列模型按参数量分为「中杯」、「大杯」、「超大杯」，FLUX.1 家族的成员统一扩展为 120 亿参数的庞大规模。

研究团队采用了流匹配（Flow Matching）框架对之前 SOTA 扩散模型进行了升级。从官方博客的注释中可以推测，研究团队沿用了还在 Stability AI 任职时（今年 3 月）提出的 Rectified flow+Transformer 方法。

论文链接：https://arxiv.org/pdf/2403.03206.pdf

他们还引入了旋转位置嵌入和并行注意力层。这些方法有效提高了模型生成图片的性能，在硬件设备上生成图片的速度也变得更快了。

这次 Black Forest Labs 并未公开模型的详细技术，不过更详细的技术报告将很快公布。

这三款模型在各自的领域都确立了新标准。无论是生成图像的美观度、图像与文本提示词的附和度、尺寸 / 宽高比可变性、还是输出格式的多样性， FLUX.1 [pro] 和 FLUX.1 [dev] 都超越了一系列当红图片生成模型，如 Midjourney v6.0、DALL・E 3 (HD) 以及老东家 SD3-Ultra。

FLUX.1 [schnell] 是迄今为止最先进的少步骤模型（few-step model），不仅超越了同类竞争对手，还超越了像 Midjourney v6.0 和 DALL・E 3 (HD) 这样的强大非蒸馏模型。

模型经过专门微调，以保留预训练阶段的全部输出多样性。与当前最先进的技术相比，FLUX.1 系列模型还保留了充分的进步空间。

所有 FLUX.1 系列的模型都支持多种纵横比和分辨率，从 0.1 到 2 百万像素，都能拿下。

已经有动作快的网友抢先体验上了，看来 Black Forest Labs 反复强调的「最强」，并不只是自卖自夸。

简单的提示词，就可以打造出这样的效果，仔细看羊驼身上垫子的花纹，也没有出现扭曲和变形。

提示词：An emerald Emu riding on top of a white llama.

如果不说这是 AI 生成的图片，也挺难分辨这是不是摄影师拍下的照片。

提示词：A horse is playing with two aligators at the river.

含有文字的图像，也能轻松拿捏，景深也处理得很符合真实的镜头感。

三款模型中，性能稍弱的 FLUX.1 [schnell]，用起来也是又快又强，有网友晒出在 Mac 上运行的体验，不得不感慨，真是立等可取。

不太了解 Stable Diffusion 的作者们和 Stability AI 之间「恩怨情仇」的网友感叹道：不知道从哪里冒出来了个文生图模型，简直强到可怕。

除了三款最强的文生图模型，Black Forest Labs 还憋着「大招」呢。有了如此强大的图片生成模型的能力，Black Forest Labs 为视频生成模型打下了坚实的基础，正如他们所预告的，这些计算机视觉的顶级科学家们正朝着为所有人提供的最先进文生视频技术的目标前进。

参考链接：

公司博客：https://blackforestlabs.ai/announcements/

#Gemini 1.5 Pro

谷歌终于赢了OpenAI一回：实验版本Gemini 1.5 Pro超越GPT-4o

这么强的模型，谷歌给大家免费试用。

近两日，谷歌在不断发布最新研究。继昨日放出最强端侧 Gemma 2 2B 小模型后，刚刚，Gemini 1.5 Pro 实验版本 (0801) 已经推出。

用户可以通过 Google AI Studio 和 Gemini API 进行测试和反馈。

既然免费，那我们帮大家测试一下最近比较火的比大小问题。当我们问 Gemini 1.5 Pro (0801) 9.9 和 9.11 哪个数大时，模型一次就能回答正确，并给出了理由。

当我们继续追问「Strawberry 单词里面有多少个 r」时，然而 Gemini 1.5 Pro (0801) 却翻车了。在提示语中施加「咒语」一步一步来，模型分析到第四步就出错了。

Google AI Studio 测试地址：https://aistudio.google.com/app/prompts/new_chat

不过，从官方评测来看，Gemini 1.5 Pro (0801) 各项指标还是很能打的。新模型迅速夺得著名的 LMSYS Chatbot Arena 排行榜榜首，并拥有令人印象深刻的 ELO 分数，得分为 1300。

这一成就使 Gemini 1.5 Pro (0801) 领先于 OpenAI 的 GPT-4o（ELO：1286）和 Anthropic 的 Claude-3.5 Sonnet（ELO：1271）等强大竞争对手，这或许预示着人工智能格局的转变。

Gemini 团队关键成员 Simon Tokumine 称 Gemini 1.5 Pro (0801) 是谷歌迄今为止制造的最强大、最智能的 Gemini （模型）。

除了拿到 Chatbot Arena 榜首，Gemini 1.5 Pro (0801) 在多语言任务、数学、Hard Prompt 和编码等领域也表现相当出色。

具体而言，Gemini 1.5 Pro (0801) 在中文、日语、德语、俄语方面均表现第一。

但在编码、Hard Prompt 领域，Claude 3.5 Sonnet、GPT-4o、Llama 405B 仍然处于领先地位。

在 win-rate 热图上：Gemini 1.5 Pro (0801) 对阵 GPT-4o 的胜率为 54%，对阵 Claude-3.5-Sonnet 的胜率为 59%。

Gemini 1.5 Pro (0801) 在 Vision 排行榜上也第一！

网友纷纷表示，谷歌这次真是出乎所有人的预料，没有提前官宣就突然开放测试最强模型，这次压力给到了 OpenAI。

虽然 Gemini 1.5 Pro (0801) 取得了很高的成绩，但它仍处于实验阶段。这意味着该模型在广泛使用之前可能会进行进一步的修改。

网友评测

有网友对 Gemini 1.5 Pro (0801) 的内容提取能力、代码生成能力、推理能力等进行了测试，我们来看下他的测试结果。

来源：https://x.com/omarsar0/status/1819162249593840110

首先，Gemini 1.5 Pro (0801) 的图像信息提取功能很强，例如输入一张发票图像，将发票细节用 JSON 格式编写出来：

再来看下 Gemini 1.5 Pro (0801) 的 PDF 文档内容提取功能，以经典论文《Attention Is All You Need》为例，提取论文章节目录：

让 Gemini 1.5 Pro (0801) 生成一个帮助学习大型语言模型（LLM）知识的 Python 游戏，该模型直接生成了一整段代码：

值得一提的是，Gemini 1.5 Pro (0801) 还给出了详细的代码解释，包括代码中函数的作用、该 Python 游戏的玩法等等。

这段程序可以直接在 Google AI Studio 中运行，并且可以试玩，例如做道关于 Tokenization 定义的选择题：

如果觉得选择题太简单无聊，可以进一步让 Gemini 1.5 Pro (0801) 生成一个更复杂的游戏：

得到一个 LLM 专业知识句子填空游戏：

为了测试 Gemini 1.5 Pro (0801) 的推理能力，网友提问了一个「吹蜡烛」问题，但模型回答错误：

尽管有一些瑕疵，但 Gemini 1.5 Pro (0801) 的确表现出接近 GPT-4o 的视觉能力，以及接近 Claude 3.5 Sonnet 的代码生成和 PDF 理解、推理能力，值得期待。

参考链接：

https://www.youtube.com/watch?v=lUA9elNdpoY

https://x.com/lmsysorg/status/1819048821294547441

#LazyLLM

苹果让大模型学会偷懒：更快吐出第一个token，准确度还保住了

偷懒才能更好地工作。

Llama 3.1 刚刚发布，你是否已经尝试了呢？就算你的个人计算机是最近的顶尖配置，运行其中最小的 8B 版本可能也依然会有明显延迟。为了提升模型的推理效率，研究者想出了多种多样的方法，但其中很多都会让模型牺牲一些准确度。

近日，苹果和 Meta AI 的一个研究团队提出了一种新方法，可在保证准确度不明显下降的同时，将 Llama 2 预填充阶段的推理速度提升到原来的 2 倍以上，这或许能为 Llama 3.1 的加速提供一些启发。他们把这种方法称为 LazyLLM，即懒惰大型语言模型。

论文标题：LazyLLM: Dynamic Token Pruning for Efficient Long Context LLM Inference
论文地址：https://arxiv.org/abs/2407.14057

那么他们是怎么让 LLM 偷懒的呢？要理解他们的方法，我们首先需要知道标准的基于 prompt 的 LLM 推理过程是怎样的。简单来说，该过程分为两个阶段：预填充和解码，如图 1 所示。

51c大模型~合集20_大模型_07

在预填充阶段，模型计算和保存 prompt 中每个 token 的 KV 缓存，并预测首个 token。我们将预填充阶段所耗费的时间称为「首个 token 时间（TTFT）」。

预填充阶段之后是解码阶段。在这个阶段，模型再次使用缓存的 KV 来迭代式地解码下一个 token，直到满足停止标准。

在预填充阶段，所有 Transformer 层都会使用 prompt 中的所有 token。当 prompt 较长时，TTFT 可能很慢，因为当前最佳的基于 Transformer 的 LLM 既深又宽，并且计算注意力的成本会随 prompt 中 token 数量而呈二次增长。举个例子，Llama 2（7B 版本）堆叠了 32 层 Transformer，模型维度为 4096。在这种情况下，TTFT 需要的 walltime 是每个后续解码步骤的 21 倍，在 LongBench 基准上这些时间大约占用了总生成时间的 23%。

因此，要让 LLM 推理高效进行，优化 TTFT 是非常关键的步骤。

尽管 LLM 推理优化方面是一个活跃的研究领域，但很多方法关注的重心都是提升解码阶段的推理速度。研究者很少关注 TTFT 的改进。一些基于压缩的研究成果可通过减少 LLM 的大小隐式地提升 TTFT。

另一个研究方向是在静态的 Transformer 架构下实现对 TTFT 的改进。对于这个研究方向，很自然会引出一个问题：在生成首个 token 时，所有 prompt token 都必不可少吗？

图 2 给出了在 LongBench 基准上的 LLM 分析结果。

51c大模型~合集20_大模型_08

可以看到，对于首个生成的 token，输入 token 的注意力分数非常稀疏，这说明输入 prompt 中的许多 token 是多余的，就算移除也不会影响到下一 token 预测。这一观察正是该团队提出 LazyLLM 的基础。

LazyLLM 的优势包括适用范围广、无需训练、效果好。图 3 对比了标准 LLM 与 LazyLLM。

51c大模型~合集20_大模型_09

LazyLLM

图 4 展示了 LazyLLM 的整体框架。

51c大模型~合集20_大模型_10

从完整上下文开始，LazyLLM 会逐渐对 token 进行剪枝，从而逐渐减少得到最终模型所使用的计算数量。请注意，LazyLLM 允许模型在不同的生成步骤选取不同的 token 子集，即便它们中的一些可能在之前的步骤中被剪枝了。相比于静态剪枝（一次性对所有 token 进行剪枝），动态剪枝会在每个生成步骤对下一 token 预测进行优化，这有助于维持模型的性能表现。

渐进式 token 剪枝

之前也有一些研究成功使用过 token 剪枝来优化 LLM 推理。但是，这些方法需要积累预测前几个 token 的完整注意力图，以便在剪枝开始之前分析 prompt token 的重要性。也因此，它们不适合用于降低 TTFT，因为它们在预填充阶段仍需要计算所有 KV 缓存。

相较之下，LazyLLM 「很懒」，会从推理的第一轮迭代（预填充步骤）开始，只计算对预测下一 token 重要的 token。

在第一轮迭代中，一大关键难题是确定各个 token 的重要性。受之前已有研究（其中表明 token 隐藏状态会在穿过 Transformer 层时发生演进）的启发，该团队的解决方案是在每个生成步骤使用逐层 token 剪枝。具体来说，他们是使用各层的注意力图来确定输入 token 对将要预测的 token 的重要性。

在计算了 token 的置信度分数之后，另一个难题是确定剪枝 token 的阈值。

具体来说，对于不同的层和不同的任务，该阈值可能会随注意力分数的变化而改变。该团队的解决思路是使用 top-k 百分位数选取策略。具体来说，如果一个 token 的置信度分数小于输入 token 中的第 k 个百分位数，便将其剪枝掉。一旦 token 被剪枝去掉了，它就不再参与所有后续层的计算。

也就是说，后续层使用的 token 是之前层所使用 token 的子集。

后面的实验表明，剪枝层的位置和剪枝的 token 数量不同时，也会导致性能发生变化。具体来说，对于同一 Transformer 层，随着被剪枝去掉的 token 越来越多，模型的性能也会逐渐下降。

他们还发现，相比于早期层的剪枝，在后期层执行剪枝时会得到更好的性能，这说明后期层对 token 剪枝的敏感度更低。为了更好地平衡速度与准确度，该团队使用了如图 4 所示的渐进式剪枝法，从而在早期层保留更多 token，然后在 token 流向后期层的过程中逐渐减少 token 的数量。

Aux Cache（辅助缓存）

预填充阶段没有 KV 缓存，每个 token 都表示成隐藏状态。因此，可通过移除已被剪枝 token 的隐藏状态来实现渐进式 token 剪枝。但是，要将渐进式 token 剪枝扩展到后续的解码步骤，却并不简单。原因是每个解码步骤都会使用预填充阶段计算的 KV 缓存来计算注意力。由于 LazyLLM 是在预填充阶段执行渐进式 token 剪枝，因此在某一层被剪枝的 token 的 KV 不会出现在下一层的 KV 缓存中。

这里提醒一下，LazyLLM 框架允许在每一步让每个生成步骤从完整的输入 token 序列中挑选一个不同的 token 子集，无论它们是否已在之前的步骤中被剪枝。举个例子，在接下来的解码步骤中，那些在 KV 缓存中不存在的已被剪枝的 token 可能会被重新选取出来用于计算注意力。在这种情况下，模型无法检索到这些 token 的 KV 缓存。

对此，一个基于直觉的解决方案是再让这些 token 通过该 Transformer 的起点。但是，这会导致对同一 token 的重复计算，并最终减慢整体的生成速度。

为解决这个难题，该团队在原有的 KV 缓存之外引入了另一种缓存：Aux Cache（辅助缓存）。

如果已被剪枝 token（如图 4 中 T4 和 T7）的 KV 并未出现在后续层的 KV 缓存中，则会由 Aux Cache 保存它们的隐藏状态以供后续迭代检索。

如图 4 所示，在每个解码步骤，每个 Transformer 层首先会检索过去 token 的 KV 缓存（如果存在的话）。对于那些不在 KV 缓存中的 token，则直接从其前一层的 Aux Cache 中检索它们的隐藏状态，而不必再次经过之前的层。Aux Cache 可确保每个 token 在每个 Transformer 层中最多被计算一次，还能确保 LazyLLM 最慢时也比标准 LLM 快。

实验

该团队在两个大型语言模型上检验了这种「懒惰」新方法：Llama 2 7B 和 XGen 7B。作为对比的标准 LLM 是同样的公开发布的预训练检查点模型，同时不进行任何附加训练。

实验基准是 LongBench，这是一个针对长内容理解的多任务基准。LongBench 基准包含 16 个数据集，涉及 6 个任务，包括单文档问答、多文档问答、总结、少样本学习、合成任务和代码补全。

评估指标是每种方法在 TTFT 加速与准确度权衡方面的效果和效率。

结果

表 1 给出了 LazyLLM、标准 LLM 和其它基线方法的 TTFT 加速和准确度结果。

51c大模型~合集20_大模型_11

在此表中，baseline 是指标准 LLM 推理。random token drop 是指对 token 执行随机剪枝。static token pruning 是指在预填充阶段基于前面几个 Transformer 层的注意力方法来对输入 token 执行一次性剪枝。Prompt Compression 就是 prompt 压缩方法，也就是使用 LLM 去除输入上下文中的冗余。

从表 1 可以看到，LazyLLM 在 TTFT 加速方面全面优胜，同时准确度方面的下降基本可以忽略不计。需要指出，使用 LLM 来压缩 prompt 需要大量计算。因此，即使 Prompt Compression 能让推理速度更快，但其实际的 TTFT 却比标准 LLM 还长。

对总体生成速度的影响

为了评估新方法对总体生成速度的影响，该团队分析了计算使用的 prompt token 百分比和生成加速情况，见表 2。

51c大模型~合集20_大模型_12

可以看到，LazyLLM 计算使用的 token 的占比总是低于 100%，这说明 LazyLLM 在生成结束时也没有用完 prompt 中的所有 token，但理论上讲该模型可以使用所有 token。这能为不同任务的整体生成过程提供额外的加速。

不同层的丢弃率

该团队也分析了剪枝层的位置和被剪枝 token 的数量的影响。结果见图 6。

51c大模型~合集20_大模型_13

可以看到，当在同一 Transformer 层进行剪枝时，留下的 token 越少，模型的性能越差。这也符合我们的直观认知。此外，相比于在更前期 Transformer 层执行剪枝，在后期层进行剪枝会得到更好的性能，这说明后期层对 token 剪枝的敏感度更低。

基于这些观察，可以说渐进式 token 剪枝的效果得到了证明。

渐进式 KV 增长

最后，该团队也尝试了理解使用 token 剪枝逻辑的模型的内部情况。具体来说，他们想要了解 prompt token 中的累积使用比例以及相应的不被使用的比例。这种「累积 token 使用量」可以等价地定义成每一步的 KV 缓存大小。图 7 给出了 LazyLLM 的每个阶段这些累积的 prompt token 使用量。

51c大模型~合集20_大模型_14

该结果支持这一假设：许多 token 永远不会被模型选择（即便理论上讲模型可以使用 prompt 中的所有 token。

考虑到模型依然能维持执行任务的准确度，因此可以得出结论：模型可以有效地丢弃不影响输出质量的 token。

#大模型Agent开发者必读

热门通用大模型 Agent 平台。

今年 3 月，「全球首位 AI 软件工程师」Devin 引爆了 AI 圈。与此前 AI 编程助手不同的是，Devin 并不只是辅助编程的角色，而是能够独立地、端到端地完成整个开发项目。

Devin 的出世让我们领略了大模型 Agent 的强大能力。很快，业界就出现了众多尝试复刻它的开源项目，其中 OpenDevin 脱颖而出，受到了人们最多的关注。

OpenDevin 是一个开发通过软件与世界互动的通用智能体的平台，其特点包括：

大模型 Agent、接口和环境之间交互的交互机制；
Agent 可用的沙盒操作系统 + Web 浏览器环境；
可创建和执行代码的接口；
多 Agent 支持；
评估框架。

目前，OpenDevin 的 GitHub 已经获得了超过 2.9 万 Star 量。

近日，OpenaDevin 团队发布了该工具的技术报告。

报告地址：https://arxiv.org/pdf/2407.16741

在技术报告中，OpenDevin 的作者，来自伊利诺伊大学香槟分校、卡耐基梅隆大学等机构的学者们详细介绍了 OpenDevin，这是一个社区驱动的平台，旨在开发通过软件与世界交互的通用和专业 AI Agent。

更重要的是，OpenDevin 不仅是一个概念框架，它还包括一个全面且可立即使用的 Agent、环境和评估实现。截至本报告发布时，OpenDevin 包含一个 Agent 中心，其中已实现 10 多个智能体，包括一个基于 CodeAct 架构实现的强大的通用智能体，并增加了用于 Web 浏览和代码编辑功能。用户与智能体的交互是通过聊天界面实现的，该界面可视化智能体当前操作并允许实时反馈。此外，评估框架目前支持 15 个基准，可使用它们来评估智能体性能。

OpenDevin 架构

本文中，作者从以下几个方面描述 OpenDevin：（1）如何定义和实现智能体；（2）动作执行如何促进观察；（3）如何管理和扩展智能体常用的技能；（4）如何将多个智能体组合在一起以解决任务。

如何定义和实现智能体

智能体可以感知环境状态，并在解决用户指定的任务时生成要执行的操作。

状态和事件流。在 OpenDevin 中，状态是一种数据结构，它封装了智能体执行任务的所有相关信息。此状态的一个关键组成部分是事件流，是按照时间顺序收集过去的动作和观察。

动作。受 CodeAct 的启发，OpenDevin 通过一组核心的动作将智能体与环境连接起来。动作 IPythonRunCellAction 和 CmdRunAction 使智能体能够在沙盒环境（例如，安全隔离的 Linux 操作系统）内执行任意 Python 代码和 bash 命令。而 BrowserInteractiveAction 支持智能体与 Web 浏览器交互。

观察。观察描述了智能体观察到的环境变化。它可能由智能体的动作引起，也可能不是：它可以是 1) 用户提出的自然语言指令，2) 智能体先前动作的执行结果（例如，代码执行结果等）。

实现新的智能体。智能体设计简单但功能强大，从而允许用户轻松创建和定制用于各种任务的智能体。核心在于 step 函数，它将当前状态作为输入并根据智能体的逻辑生成适当的动作。图 2 显示了智能体抽象的简化示例代码。

观察动作执行结果

Agent Runtime 为智能体提供了与人类软件开发人员相当的动作空间，使 OpenDevin 能够处理各种软件开发和基于 Web 的任务，包括复杂的软件开发工作流程、数据分析项目、Web 浏览任务等。它允许智能体访问 bash 终端来运行代码和命令行工具，利用 Jupyter notebook 即时编写和执行代码，并与 Web 浏览器交互以执行基于 Web 的任务（例如，信息搜索）。

可扩展的智能体 - 计算机接口

作者构建了一个 AgentSkills 库，这是一个旨在增强智能体功能的工具箱，能够提供基本 bash 命令或 python 代码无法轻松获得的实用程序。

多智能体交互

OpenDevin 允许多个智能体进行交互。为了实现这一目标，作者使用了一种特殊的动作类型 AgentDelegateAction，它允许智能体将特定的子任务委托给另一个智能体。

评估

本节将 OpenDevin （以下实验结果中简写为 OD）与开源可复现的基线方法进行了比较。这 15 个基准涵盖软件工程、网页浏览等任务。

表 3 表明，虽然 OpenDevin 智能体可能无法在每个类别中都达到最佳性能，但其设计考虑了通用性。

表 4 报告了智能体在软件工程基准上的结果。

具体而言

SWE-bench 旨在评估智能体解决 GitHub 问题的能力，如 bug 报告或功能请求。如表 4 所示，本文最新版本的 CodeActAgent v1.8 ，基于 claude-3.5-sonnet，与其他专门用于软件开发的开源智能体相比，解决问题率高达 26%。

HumanEvalFix。OpenDevin CodeActAgent 成功修复了 Python 拆分中 79.3% 的错误，明显优于所有非智能体方法，几乎是 StarCoder2-15B 性能的两倍。

基于 GPT-4o 的 OpenDevin 智能体在 ML-Bench 上实现了 76.47% 的最高成功率，优于 SWE-Agent（42.64%）。

Gorilla APIBench 考察智能体使用 API 的能力。使用 GPT-4o 的 OpenDevin 的成功率为 36.4%，优于未针对 API 调用进行专门微调的基线。

ToolQA 评估智能体使用外部工具的能力。与所有基线相比，采用 GPT-4o 的 OpenDevin 表现出最高的性能。智能体在与 CSV 和数据库工具使用相关的任务上表现更好，但在数学和计算器工具使用方面需要改进。

表 5 报告了网页浏览基准的评估结果。

表 6 报告了各种辅助基准的结果。

其中，GAIA 用于评估智能体解决一般任务的能力，结果显示，智能体在 GAIA 上取得了 32.1 分，比原来的 AutoGPT 有了明显的提高。

GPQA 用于评估智能体在解决具有挑战性的研究生水平问题时协调使用工具的能力。结果如表 6、7 所示，OpenDevin 集成了支持多种工具使用以及 web 搜索的功能，使得智能体能够更好地解决复杂的多步骤问题。

了解更多结果，请参考原论文。

#AFlow

MetaGPT开源自动生成智能体工作流，4.55%成本超GPT-4o

AFLOW 作者团队来自于 MetaGPT 开源社区。AFLOW 论文共同第一作者为香港科技大学（广州）的博士生张佳钇和 DeepWisdom 研究员向劲宇，共同通讯作者为 DeepWisdom 创始人兼 CEO 吴承霖（MetaGPT 代码作者、论文通讯作者）和香港科技大学（广州）的助理教授骆昱宇。作者还包括中国人民大学的于兆洋、滕枫蔚和程信，南京大学 LAMDA 实验室博士生陈雄辉，复旦大学的陈家祺和郑炳南，阿卜杜拉国王科技大学的博士生诸葛鸣晨（MetaGPT 论文共同一作），DeepWisdom 研究员洪思睿（MetaGPT 论文共同一作）和王金淋，蒙特利尔大学与 MILA 实验室的助理教授刘邦。

对于 LLM 从业者来说，让 LLM 落地应用并发挥作用需要手动构建并反复调试 Agentic Workflow，这无疑是个繁琐过程，一遍遍修改相似的代码，调试 prompt，手动执行测试并观察效果，并且换个 LLM 可能就会失效，有高昂的人力成本。许多公司甚至专职招聘 Prompt Engineer 来完成这一工作。

现在，Agentic Workflow 也有自己的自动优化工具了。

MetaGPT 开源了 AFLOW，它使用 MCTS 进行 Agentic Workflow 的自动搜索，可以完全自动地构建与优化 Agentic Workflow 问题，让我们不再需要手写代码、调试提示词。

51c大模型~合集20_大模型_15

AFLOW 通过蒙特卡洛树搜索优化工作流，极低成本实现 GPT-4o 级能力

这是对提示词自动优化的进一步探索，通过蒙特卡洛树搜索，完全接管了 Agentic Workflow 的生成与优化过程，表现远超其他工作流自动优化工作，甚至超越了对比的所有手工工作流基线。

论文标题：AFlow: Automating Agentic Workflow Generation
论文地址：https://arxiv.org/abs/2410.10762
项目地址：https://github.com/geekan/MetaGPT/tree/main/examples/aflow

什么是自动工作流优化问题？

现有的 Agentic Workflow 自动生成工作难以生成有效的工作流，它们往往需要人工介入初始设置，且无法全面捕捉到完成任务所需的工作流多样性。为了克服这些挑战，研究人员提出了 AFLOW 框架。利用蒙特卡洛树搜索（MCTS）技术来系统地探索和优化 LLM 的工作流。AFLOW 通过将工作流定义为代码可表示的节点和边，从而有效地捕捉 LLMs 调用之间的复杂交互。通过引入操作符的概念，AFLOW 进一步简化了搜索空间，提高了搜索效率。在多个基准数据集上的实验结果表明，AFLOW 能够自动发现和优化工作流，显著提高了任务执行的性能，同时减少了对人工干预的依赖。

51c大模型~合集20_大模型_16

AFLOW 的动态演示。通过不断迭代的选择、扩展、评估和反向传播实现工作流的自动化生成和优化

AFLOW 首先将工作流优化问题重新构建为一个搜索问题，其中工作流被表示为代码化的节点序列，每个节点代表 LLM 的一个具体操作，节点之间的边定义了操作的逻辑、依赖关系和执行流程。这种表示方法将工作流转化为一个可以搜索和优化的图结构。具体来说，工作流 W 被定义为一个 LLM 调用节点序列

51c大模型~合集20_大模型_17

，其中每个节点

51c大模型~合集20_大模型_18

包含模型 M，提示 P，温度，输出格式 F（如 xml、json、markdown、raw）四个参数。节点通过边连接，边可以由各种结构表示，如图，神经网络，代码。

自动化工作流优化的目标是在给定任务 T 和评估函数 G 的情况下，发现一个工作流 W ，使得 G(W,T) 最大化。这可以被表述为一个搜索过程，其中算法 A 探索搜索空间 S 来确定最优的工作流配置。搜索空间 S 包括所有可能的节点参数和边结构的配置。

51c大模型~合集20_大模型_19

Node、Operator 和 Edge 示例。此处展示 Node 的可选参数、Operator 常见结构和 Edge 的常见表示

AFLOW 如何自动优化工作流？

AFLOW 利用蒙特卡洛树搜索（MCTS）来自动化地生成和优化 Agentic Workflow。在 AFLOW 框架中，Operator 扮演着至关重要的角色，它们是预定义的、可重用的节点组合，代表常见的智能体操作（比如审查，投票，生成）。这些 Operator 作为构建工作流的基础构件，被集成到搜索空间中，确保探索过程可以利用已知的有效智能体操作模式。引入 Operator 能够显著提升 AFLOW 框架的搜索效率和工作流的优化效果，减少在庞大搜索空间中的盲目探索。

AFLOW 的目标是在给定任务和评估函数的情况下，发现一个能够最大化任务性能的工作流。AFLOW 算法开始于初始化模板工作流，这个模板提供了一个基本的工作流框架，包括 LLM 节点的调用和 Operator 的使用。然后，算法通过 MCTS 的四个主要步骤进行迭代：选择（Selection）、扩展（Expansion）、评估（Evaluation）和反向传播（Backpropagation）。

51c大模型~合集20_大模型_20

AFLOW 整体框架：通过设置一个由仅具有灵活 prompt 参数的节点、给定的运算符集和表示边的代码组成的搜索空间，AFLOW 在此空间内执行基于 MCTS 的搜索。通过为工作流优化而设计的 MCTS 变体，AFLOW 迭代执行软混合概率选择、基于 LLM 的扩展、执行评估和经验反向传播的循环，直到达到最大迭代次数或满足收敛标准

选择阶段 AFLOW 使用软混合概率选择机制来选择一个节点进行扩展。这种机制结合了均匀概率分布和基于分数的加权概率分布，以平衡探索和利用，避免陷入局部最优解。选择过程中，AFLOW 会考虑候选节点的得分和探索的需要，从而选择一个既有可能带来性能提升又具有探索价值的节点。

扩展阶段 AFLOW 使用 LLM 作为优化器来生成新的工作流。优化器利用选定工作流的经验来生成新的提示或通过修改代码来改变节点连接，从而产生新的工作流变体。这些新的工作流变体是通过对现有工作流的微小调整来实现的，例如添加、修改或删除节点和边。

评估阶段 AFLOW 直接执行生成的工作流以获得反馈。由于推理任务具有明确的评估函数，AFLOW 可以通过在验证集上多次运行工作流来计算平均分和标准差，从而获得更准确的优化器反馈。

反向传播阶段工作流的性能信息被反向传播到 MCTS 的树结构中，用于更新节点的得分，并指导未来的搜索迭代。这些信息包括工作流的执行结果和相对于其父工作流的优化成功与否。通过这种方式，AFLOW 能够从每次迭代中学习，并逐渐改进工作流的性能。

为了避免在优化达到极限后继续执行的不必要成本，当连续几轮中分数优先的前 k 个工作流没有改进时，AFLOW 将停止上述迭代过程。

AFLOW 带来的 Agentic Workflow 变革

显著的性能优势 AFLOW 选取了六个文本推理的任务，覆盖了代码（HumanEval, MBPP），数学（GSM8K, MATH），知识问答（HotpotQA, DROP）三个场景。相比现有手动方法平均提升 5.7%，较其他自动化方法更是提升了 19.5%。在所有六个任务中，AFLOW 展现出全面的领先优势，证明了其在不同任务类型上的稳定性和适应性。

51c大模型~合集20_大模型_21

与其他方法的性能比较。为了评估该方法的性能，我们在不同的数据集中采用了各种指标：Math 和 GSM8K 的求解率、HotpotQA 和 DROP 的 F1 分数以及 HumanEval 和 MBPP 的 pass@1。我们的 AFLOW（以黄色突出显示）在所有六个基准测试中始终优于所有自动工作流程优化和手动设计的方法

显著成本降低 AFLOW 为 Agent 领域带来的最大变革在于其显著的成本降低。较小尺寸的模型通过 AFLOW 找出的工作流，仅需 GPT-4o 推理成本的 4.55% 就能实现同等性能。这一突破意味着企业可以用更小的模型实现大模型的效果，为 AI 应用的规模化部署提供了经济可行的解决方案。

51c大模型~合集20_大模型_22

成本（Cost）指执行分割后 HumanEval 测试集的总费用。AFLOW（模型）指 AFLOW 使用该模型执行工作流，获得反馈。图例中的颜色代表在测试数据集中执行工作流所使用的不同 LLM

自动化的效率提升 AFLOW 彻底改变了传统的人工调试模式。通过自动化的工作流生成与优化机制，显著减少了人工参与的需求。开发者不再需要花费大量时间进行反复调试和优化，系统能够自动发现最优的工作流组合，大幅缩短了开发周期。

广泛的适用性实验结果表明，AFLOW 展现出优秀的迁移能力。它不仅支持多种主流 LLM 模型，还能适应不同类型的任务需求。在问答、代码生成、数学问题求解等多个领域的测试中，AFLOW 都表现出色，证明了其作为通用优化框架的价值。此外，用户可以通过简单的提供数据集与 Evaluation Function 来将 AFLOW 使用在自己的任务上。

展望

AFLOW 提出了一种有效生成 Agentic Workflow 的方法，并全面展示了其在降低人力与推理成本上的惊人能力。这一研究成果有望加速 Agent 在各个领域落地的速度，将 Agentic Workflow 的构建过程从专家手工构建转变为小白自动构建。

使用

目前，作者已在 GitHub 上开源了完整代码。用户可通过自定义 Benchmark 与数据集，快速为个性化任务搜索最佳性能或性能成本平衡的工作流方案，帮助个人和企业节省大量时间。

51c大模型~合集20_大模型_23

AFLOW 的 Github 指南。可以参照分步指南配置和运行 AFLOW，高效生成和优化工作流

#OpenAI的「员工叛逃」

我为什么离开OpenAI？六年元老发离职长文：AGI将至，我们远没准备好

6年元老为何加入离职大军？AGI的未来，我们到底需要面对什么？OpenAI前高级顾问Miles Brundage最近发表长文，细述了自己的思考和感受。

OpenAI的「员工叛逃」还没有结束。

近日，OpenAI又有一位6年元老、研究主管Miles Brundage发表长文官宣离职，并详细解释了自己为何「出走」。

作为一家年轻的AI独角兽，成立于2015年的OpenAI如今刚刚9岁，因此在公司待了6年之久的Brundage足以被称为「元老」，见证了OpenAI如何一路起伏、筚路蓝缕地走到今天。

在博文中，Brundage也在开头强调：为OpenAI的高管和董事会提供建议，为AGI的到来做准备，这实际上是他梦想中的工作；甚至就在2015年OpenAI刚成立时，Brundage兴奋得一夜不睡，写下一篇博文强调这个组织的重要性。

原文地址：https://www.milesbrundage.com/blog-posts/archives/12-2015

因此，离开OpenAI对他来说并不是一个容易的决定。但是为了有更多时间研究自己认为重要的课题，更独立、自由地发表观点和作品，Brundage决定转而加入（甚至自己创办）非营利组织，将重点放在AI政策研究和倡导上。

Miles Brundage本科毕业于乔治华盛顿大学，本科期间担任过美国能源部的特别助理，之后前往亚利桑那州立大学攻读博士，研究方向为科技的人类和社会维度，博士后期间曾在牛津大学担任AI政策研究员。

2018年，Miles Brundage加入了刚刚成立3年的OpenAI担任政策方面的研究科学家，之后又在2021年升任研究主管，目前是AGI准备工作的高级顾问。

为何离开OpenAI

总体来看，Brundage的离职是希望从行业外部而非内部影响AI的发展，这与今年Geoffrey Hinton离开谷歌的原因如出一辙，具体有如下几个考虑因素：

机会成本

本职工作已经占去了几乎全部的时间，因此Brandage感觉很难从事自己认为重要的研究课题。甚至在某些情况下，身处行业之外时，从事这些研究能更有影响力和说服力。

而且，OpenAI目前已经如此引人注目，成果发布前就需要从许多不同的角度进行审查，以至于无法发表某些主题的文章。

但值得注意的是，Brundage并不是完全反对OpenAI在出版物审查方面的立场，他认为行业中存在出版限制是合理的，他本人也帮助编写了OpenAI政策的几个迭代版本，但公司目前施加的限制确实已经太多了。

减少偏见

如果选择成为某个组织的一部分，并且每天都和那里的同事们密切合作，你就很难对这个组织保持公正。

Brundage表示，他在分析中尽力追求公正，但仍然会有偏见的存在。而且在OpenAI工作这件事本身，就会影响到外界如何看待自己的观点和研究。考虑到财务利益上的冲突，人们有理由质疑来自行业的政策想法。

在有关政策的对话中，有更多独立于行业的声音至关重要，而Brundage计划成为其中之一。

在OpenAI，能做的都做了

从入职至今，Brundage认为自己作为「AGI准备状态高级顾问」的工作已经完成了大部分。

「AGI准备状态」（AGI Readiness）主要分为两种：一是OpenAI要准备好管理日益强大的AI能力，二是整个世界也要准备好有效管理AI能力，包括通过监管OpenAI和其他公司。

对于前者，Brundage已经向他的负责对象——OpenAI的高管和董事会——详细介绍了他认为OpenAI需要做什么，以及差距在哪里；而对于后者，他认为自己在OpenAI外部能够更加有效。

虽然失去了一些在OpenAI发挥影响力的机会，但Brandage希望在更大程度上影响整个生态系统。

AGI，我们都没准备好

Brundage认为，对于即将到来的AGI，OpenAI或任何其他的前沿实验室都还没有准备好，这个世界也还没有准备好。

原文地址：https://medium.com/@miles_24227/scoring-humanitys-progress-on-ai-governance-5a5131cb84c7

但需要明确的是，他不认为这种「没准备好」的状态与OpenAI领导层的声明相冲突；同时他也暗示，虽然距离理想的标准存在相当的差距，但是我们仍可以在相关时间点步入正轨，为此Brundage将在余下的职业生涯中致力于人工智能政策。

科技公司和这个世界是否走上了AGI准备的正轨，是一个复杂的函数，取决于安全和保障方面的文化如何随着时间的推移而发挥作用、监管如何影响组织的激励措施、各种有关AI能力和安全方面困难的事实，以及各种其他因素。

此处，Brundage特别表扬了OpenAI最近新增加董事会成员的决定，新吸纳的成员包括前陆军上将Paul M. Nakasone和CMU机器学习系主任Zico Kolter，这都是朝着正确方向迈出的一步。

顺便一提，Brundage表示，「AGI」这个术语承载了太多意义，它现在更多地暗示着一种二元思维方式，而不是实际意义，因此有必要澄清一下，此处的「为AGI做好准备」，指「准备好安全、可靠且有益地开发、部署和管理能力日益强大的AI系统」。

最近，他和团队正在充实OpenAI提出的AGI五级框架，不久后或许会发表一篇正式的论文。这个框架曾被彭博社披露，引来了不少争议。

虽然Brundage对AI政策抱持着谨慎和批判的态度，但对于AGI前景的预测，他的确称得上是一个「技术乐观主义者」，观点与硅谷的风投大佬Khosla非常一致。

他认为，在未来短短的几年内，人工智能很可能能够实现足够的经济增长。假设我们能制定出适当的政策来确保公平分配，人类就能实现高生活水平的提前退休。

但在此之前的短期时间中，AI很可能会抢走一些迫切需要工作的人的机会，尤其是那些可以远程完成的、容易自动化的任务。

但事实是，人类最终应该摆脱为谋生而工作的义务，这也为构建AI和AGI提供了最强有力的论据之一。从长远来看，有些人可能会继续工作，但不会像现在这样有如此迫切的激励因素。

一个「后工作世界」（post-work world）的风险之一就是文明的停滞（比如电影「机器人总动员」所展现的），但我们目前还没有在政治、文化或其他方面为此做好准备，因此需要更多的思考、辩论和政策讨论。

2008年电影「机器人总动员」（WALL-E），由皮克斯工作室制作、迪士尼出品

很多人都描绘过「AI造福人类」的前景，这些描述似乎是出于好意而非阴谋论。但目前存在效率低下的问题，很大程度上是由于民间社会和政府的技术专业知识不足，以及缺乏良好的规范和理论基础。

例如，对于出现的问题，我们是否应该期望市场机制给出解决方法？什么时候应该构建定制化、应用范围狭窄的AI解决方案，什么时候应该提高通用AI系统的能力来解决？在各种情况中，正确的方法是继续补足现有的技术，还是创造全新的技术，等等。

要不要在OpenAI工作

「要不要在OpenAI工作」，这个问题听起来有点凡尔赛，可以类比下「斯坦福和MIT该选哪个」。

但如果屏幕前的你拿到了offer正在纠结该去OpenAI还是谷歌DeepMind，Miles Brundage的经验或许能帮助你解决这个甜蜜的烦恼。

在OpenAI工作是大多数人希望能做到的最有影响力的事情之一，所以在大多数情况下，答案是肯定的。

考虑到每个人拥有的技能和机会不同，很难做出笼统的陈述，但有一点是确定的——OpenAI 的每一个角色，以及每个人对待工作的谨慎程度都很重要，对OpenAI组织文化的每一项贡献也很重要。

在通往更强大AI的道路上，每一次产品的部署都会发挥重要作用，比如影响行业规范，以及人们认知和监管AI的方式。

在OpenAI工作，无论是AI的安全与保障，抑或是AI能力和产品方面的研究，发挥个人的能动作用来推动AI安全都是非常有影响力的。

下面这段话，似乎是Brundage的一段隔空喊话，写给他仍在OpenAI工作的前同事们：

「任何在OpenAI工作的人都应该认真对待这样一个事实：他们的行为和言论有助于组织文化，并且当这个组织开始掌管极其先进的能力时，可能会创造正面或负面的路径依赖。文化对任何组织都很重要，但在前沿AI的背景下尤其重要，因为大部分决策不取决于监管法规，而是来自公司中的人。」

正如Brundage在前文所表示的，他认为某些政策研究最好在外部进行，AI的安全和保障工作有时也是如此。尽管OpenAI内部确实需要一些人来推动公司采取良好的政策立场，但存在独立的安全研究也很有价值。

参考资料：

https://milesbrundage.substack.com/p/why-im-leaving-openai-and-what-im

https://www.reddit.com/r/singularity/comments/1gagocj/openai_senior_advisor_for_agi_readiness_leaving/

#vLLM这一年的新特性以及后续规划

本文来自The State of vLLM | Ray Summit 2024 && RoadMap的分享，带大家一起回顾下vllm发展历史、过去一年的发展及接下来Q4规划。感兴趣的也可以查看原视频：https://www.youtube.com/watch?v=4HPRf9nDZ6Q^[1]

过去一年vLLM的工作内容

记得vLLM在九月初更新了一个版本^[2]，性能有了明显的提升（支持了multi step，因为减少了CPU overhead，会对吞吐会有提升，但是带来的副作用是TTFT和ITL会变大），某些场景确实带来了收益。

vLLM在2024年更新了很多内容～首先是模型支持，支持几乎所有的llm和vlm模型且效率非常高，这点确实要比TRT-LLM支持更快更方便，涉及到底层改动支持的模型，TRT-LLM因为底层限制只能提个issue等官方支持。而vLLM就很方便，目前vLLM支持的模型有：

包括LLama系列模型/Mixtral系列模型/LLava多模态/State-Space模型/reward模型等

51c大模型~合集20_大模型_24

除了GPU也支持很多其他的硬件，如amd GPU/Intel GPU/Google TPU等，当然还有CPU！

51c大模型~合集20_大模型_25

当然核心还是依赖的Pytorch，PyTorch 作为核心，为不同的上层模型和底层实现提供了一个统一的接口。

PyTorch as a Narrow Waist，“narrow waist”概念来源于计算机网络结构，通常指的是一个核心层，它连接了上层和下层的各种模块

51c大模型~合集20_大模型_26

同样对vLLM社区来说，性能优化是第一个目标。

矩阵乘法有专门深层次的cuda kernel^[3]优化。此外特定层（如 ffn 层）专门优化了 Triton 内核以提升性能，利用cutlass库优化GEMM，实现kernel fusion等功能，提供专门的flashatention kernel等。

为了优化通信性能，vLLM还开发了一个定制的 all-reduce CUDA 内核（尤其是 all-reduce 操作，计算时异步数据传输/优化内存访问、增加并行度等优化allreduce通信）。还有transformer的核心注意力机制，现在已经采用了许多基于 CUDA 的内核和其他注意力内核，包括 Flash Attention 和 FlashInfer。

还有量化支持变得愈发重要，首先开发一个通用的量化方法抽象层，然后实现这些量化方法，最后优化这些量化操作的性能；目前vLLM支持了几乎所有流行的量化方法，包括 FP8、IN8、GPTQ、AWQ 量化方法。此外，vLLM中还引入了许多高效的量化内核，例如 Marlin^[4]。

vLLM还有个 LLM Compressor^[5]，帮助量化模型的库，支持多种量化方法，高效地将模型量化成vLLM能理解的格式，从而获得更佳性能。这个可以理解为TRT-LLM的ModelOPT。

51c大模型~合集20_大模型_27

性能优化

vLLM除了LLM基本的kernel优化、并行优化、量化策略，还有很多其他优化。

CUDA Graph

Cuda Graph对vLLM的性能提升很大，毕竟vLLM是采用pytorch原生的op配合拓展op搭建的，有很多额外的消耗：user-written logic, PyTorch dispatcher logic, memory allocation overhead, and GPU driver/kernel overhead。使用了cuda graph可以避免掉这些开销。

We find that without CUDA graphs, LLaMA-7B inference executes at 30 tokens/sec, but with CUDA graphs enabled it executes at 69 tokens/sec for a 2.3x speedup.

51c大模型~合集20_大模型_28

唯一可能的缺点就是因为要适配dynamic shape，占用的显存相比之前大些，同时启动时间也因为要捕获graph慢了些。

Multi-step Scheduling

Multi-step Scheduling提出的原因很简单，之前vllm被诟病python/cpu overhead一直很大，也就是每次decoder时候，CPU与GPU的同步操作导致了较高的性能开销（你可以亲自打下vLLM运行时候的timeline，中间间隙比TRT-LLM要大些）。

具体就是GPU在每次从CPU接收下一步的输入，以及从GPU传输采样后的token，到CPU生成用户响应时，都会产生一定的“GPU bubble”（GPU等待CPU处理的时间，5-13ms of GPU bubble），具体是这四个：

Transfer of the sampled token from GPU to CPU for de-tokenization and response to client
Generation of output for user - Pythonization of tensors into python objects
CPU preparation and generation of next step’s input metadata
vLLM scheduler

多步解码指的是在调用 vLLM 调度器并处理采样的 tokens 之前，执行多次解码。

51c大模型~合集20_大模型_29

之前每次解码步骤中 GPU->CPU 的内存传输都是同步进行的，导致 GPU 出现空闲时间。多步解码后，这种内存传输可以在一个独立的 CUDA 流中进行，而此时 CPU 已经领先于 GPU，因此几乎没有额外开销。

Multi-step decoding will be able to amortize all these overheads over n-steps at a time.

下方两个图是官方提供的对比图，这两个时长大约为 200ms。第一行是 CUDA 核心操作，底部是 Python 跟踪。每个红框大约代表 4ms 的 GPU 空闲时间，两张图均如此。

首先是baseline，每个decode步骤都会导致4毫秒的GPU空泡（这里使用Pytorch profiler打印）：

51c大模型~合集20_大模型_30

Baseline 8B on 1xH100

使用Multi-Step-8之后，4毫秒的开销仅在每8次解码中出现一次：

51c大模型~合集20_大模型_31

Multi-Step-8 8B on 1xH100

通过使用Multi-Step，基于H100的8B Llama模型的请求吞吐量从20.66请求/秒提升至40.06请求/秒，性能显著提升。

具体提升指标：

51c大模型~合集20_大模型_32

不过需要注意这个只针对decoder阶段，prefill阶段还和之前一样

更多的细节可以看这两个链接:

Chunked prefill

Chunked prefill 技术也属于LLM标配了，可以简单聊一聊。

这个功能的作用在于，可以将非常长的输入prompt拆分成更小的块进行处理，以避免长prompt阻塞其他请求，从而减少延迟并提高整体的吞吐。相比不用的情况，用户的性能延迟有了 2 倍的提升，吞吐量更高，延迟更低。

51c大模型~合集20_大模型_33

前面提到，vLLM 将请求的处理分为prefill阶段和decode阶段，同一批被调度的请求要么都处于prefill阶段，要么都处于decode阶段。而 Chunked prefill 将填充请求的 prompt^[8] 分成多个块，并与解码请求一起处理。Prefill是计算密集型（compute-bound），而decode则是内存密集型（memory-bound），通过重叠这两种请求可以大大提高系统效率，正如上图（右上角 prefill 进行数学上等价的切分；在 prefill 切成的这些 chunks 的气泡处捎带其他 request 的 decode pass，可以看到R2的Prefill和R1的Decode在一起计算）。

不过也需要注意，做了 chunked prefill 后，prefill 的开销会略微增大。因为计算后续 chunk 的 KV 时需要不断地从 GPU memory 中里读出当前 chunk 的 KV 到 kernel 里面；而不做 chunked prefill 时，最开端的那些 KV Cache 可以不用反复从 GPU memory 中反复读取进入 kernel，毕竟他们一直在 kernel 里面。

关于 Chunked prefill 细节可以阅读：

DeepSpeed-FastGen^[9]
SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills^[10]

官方RFC：

[RFC] Upstream Chunked Prefill · Issue #3130 · vllm-project/vllm^[11]

Speculative Decoding

Speculative Decoding也就是俗称的投机推理或者叫预测推理。

vLLM 这里讲了两个，分别是speculative decoding (draft-verification) && dynamic speculative deccoding（根据系统负载和推测精度动态调整长度）

Speculative Decoding，其目标是利用小模型来预测大型模型的行为，从而加速大型模型的执行。例如，我们可以让小模型生成候选序列，然后将此候选序列提供给大模型，允许大模型并行处理以验证这些候选序列的正确性。如果验证通过，我们可以一次性生成多个token，大大提升生成速度：

51c大模型~合集20_大模型_34

再详细些，看下面的例子。下面是一个关于随机采样工作方式的示例。图中每一行表示算法的一次迭代。绿色标记表示近似模型生成的token建议，目标模型则负责判断是否接受这些建议。红色和蓝色标记分别表示被目标模型拒绝的token及其修正。

例如，在第一行中，近似模型生成了5个token，生成的句子是“[START] japan’s benchmark bond”。目标模型将这些token与前缀拼接成一句话进行验证。在这次推理中，目标模型接受了前四个token（“japan”，“’s”，“benchmark”），但拒绝了最后一个token “bond”，并重新采样生成“n”。

通过这种方式，虽然每次都对近似模型的输出进行一次性验证，但目标模型在仅9次推理后就生成了37个token。尽管目标模型的总体计算量没有变化，但一次性验证多个token的延迟与逐个生成token相似（并行总是比一个一个吐字快），从而显著提高了生成速度。

51c大模型~合集20_大模型_35

不过还有另一种情况，当系统负载很高时，vLLM已经可以很好地处理批量请求，因此在这种情况下使用预测解码可能并不会提升性能。然而，在系统负载较低时，利用预测解码可以减少延迟。因此，Dynamic Speculative Decoding的核心是如何动态调整预测解码量，以在系统负载不同的情况下获得最佳性能。

51c大模型~合集20_大模型_36

Hash-Based Automatic Prefix Caching

vLLM还实现了基于哈希的自动prefix caching。

一般我们的LLM服务会有一个较长的系统提示来描述模型的行为。若两个请求共享同样的系统提示，则可以缓存并共享该系统提示的 KV 缓存，从而减少重复计算。此外，多轮对话也可以受益于这种缓存机制。vLLM实现了基于哈希的前缀缓存自动化，通过为每个缓存块分配哈希值，使其在不同请求之间实现共享。

51c大模型~合集20_大模型_37

基于hash的自动前缀缓存，缓存system prompt及多轮对话，减少请求数据量，这与sglang中采用的radix树维护kv cache不同，但都提高了缓存重用：

51c大模型~合集20_大模型_38

51c大模型~合集20_大模型_39

其他功能支持

vLLM也支持多个lora adapter^[12]及热加载，同时支持结构化输出等；也支持了基于prometheus/grafana的实时监控，包括gpu内存使用/kvcache重用率/访问延迟吞吐等指标。

在多任务服务方面，vLLM现在支持同时加载多个 LoRA 适配器，并能将不同适配器的请求批处理。

分布式支持

VM 从一开始就支持张量并行（Tensor Parallelism），不过当使用多 GPU 和多节点时，Tensor Parallelism会引入许多潜在的通信问题和故障。vLLM修复了大量通信相关的 Bug，并提供了调试指南来处理分布式系统中的故障和崩溃。

51c大模型~合集20_大模型_40

后来vLLM还增加了流水线并行（Pipeline Parallelism）的支持，从vLLM版本 0.5.1 开始支持跨多节点的流水线并行，对于那些跨多个节点的超大模型和低带宽连接，流水线并行是一种更优的选择。

51c大模型~合集20_大模型_41

CPU Offloading

vLLM还可以将部分模型权重卸载到 CPU 上，从而在小 GPU 上运行更大模型。

尽管这种方法比直接在 GPU 上运行速度要慢，但对于资源有限的用户来说，可以更高效地利用现有资源来运行模型（有时候能跑起来更重要）。

51c大模型~合集20_大模型_42

Q4计划

vLLM之后TODO：

为了性能，默认启用Chunked Prefill和Prefill Cache。此外，我们将加快结构化解码的速度，并通过通信融合来减少开销。会继续提升batch推理的性能，并进行更多内核优化

将支持将 KV 缓存offload到 CPU上从而增加cache空间（已经有很多民间实现）。此外还将支持 KV cache的传输，这对于disaggregated prefill场景十分有用。我们还会调整缓存策略和调度器，以提高缓存命中率，并在 Q4 推出一系列调度和预测解码（Speculative Decoding）优化。

vLLM正在进行一次重大的架构重构，但我们保证这一过程将会很快完成。我们正在开发新的 vLLM Engine V2，这将包括异步调度和基于Prefill Cache的设计。已经实现了对 Torch Compile 的全面支持，以便用户可以优化他们的模型。此外还新增了一个内存管理器，以便更好地支持多模态模型。

51c大模型~合集20_大模型_43

异步调度是重构的一个重点。通过在当前步骤执行的同时调度下一个步骤，会大幅减少了 GPU 的空闲时间。这样可以让 GPU 在完成当前步骤后立即开始执行下一个步骤。与之前相比，这种新的异步架构让调度和执行可以并行进行，显著降低了 GPU 的空闲时间。

51c大模型~合集20_大模型_44

通过Prefill Cache简化了设计。在当前的架构中需要复杂的逻辑来处理并行采样或抢占的情况。在未来，vLLM将使用Prefill Cache来自动识别并行采样和抢占场景中的可重用 KV 缓存，从而减少对手动处理的需求。之前，调度器直接与并行采样和前缀缓存模块进行通信。未来，调度器将只需与前缀缓存模块通信，自动识别重用机会。

重构内存分配器，以更好地适应不同类型的 KV 缓存。由于 KV 缓存大小不兼容，导致 GPU 内存浪费严重。以新的 LLaMA 模型为例，文本部分有全层的 KV 缓存，而图像部分只有 1/4 层的 KV 缓存，我们实际上为所有层分配了内存，导致浪费。我们计划通过新的内存分配器来优化这种情况。我们的方案是将 GPU 内存首先分区成较大的页面，然后进一步将每个大页面划分为不同的大小，以适应不同的 KV 缓存大小。

51c大模型~合集20_大模型_45

开启对 Torch Compile 的全面支持。目前，vLLM已经手动优化了最流行的模型，例如 LLaMA 模型的 CUDA 内核和缓存重用优化。我们的工作正在进行中，我们将利用 Torch Compile 来优化所有模型，从而使用户的自定义模型和架构也能高效运行。

51c大模型~合集20_大模型_46

优化预测解码。当前的预测解码功能已经不错，但在QPS很高时可能会影响性能。我们即将引入动态预测解码机制，以确保预测解码始终让vLLM运行得更快。与之前的机制不同，新的解码机制将无论在何种负载下都能带来更好的性能。

还将支持将更多的 KV 缓存存储到 CPU 上，从而增加多轮对话和系统提示的缓存空间。目前的vLLM只在 GPU 中存储 KV 缓存，未来将支持自动将缓存转移到 CPU，甚至可以与远程缓存数据库（如 LM Cache 和 Redis）配合使用，进一步扩展 KV 缓存存储。之前的vLLM只能在 GPU 中存储 KV 缓存供未来重用，而未来版本的vLLM可以将 KV 缓存存储在 GPU、CPU 甚至远程数据库中。

51c大模型~合集20_大模型_47