Skip to content
是时候用CPU通用服务器跑千亿参数大模型了！
马斯克19天建成由10万块H100串联的世界最大超算，已全力投入Grok 3的训练中。
与此同时，外媒爆料称，OpenAI和微软联手打造的下一个超算集群，将由10万块GB200组成。
在这场AI争霸赛中，各大科技公司们卯足劲加大对GPU的投资，似乎在暗示着拥有更多、更强大的GPU，就能让自己立于不败之地。
然而，这种对高端GPU的狂热追求，并非在所有情况下，都是完美无缺的解决方案。
Pytorch之父表示，技术报告中暗藏了很多基础设施的有趣细节，包括如何并行化，如何让系统更可靠等等
就拿稳定性来说，在Llama 3.1训练的54天里，Meta的1.6万块H100集群总共遇到了419次意外中断，相当于平均每3小时发生一次。
而在这之中，有148次（30.1%）是由于各种GPU故障引起的。
相比之下，由CPU故障引发的中断，只有2次。
另一方面，想要把Llama 3.1 405B跑起来，还得搭配2台8×H100的DGX工作站才行——即1280GB的显存。
曾经有位勇士尝试用一张4090运行，结果等了30分钟，模型才缓缓吐出一个「The」。
完整的回复，花了整整20个小时
熟悉模型的训练和推理的朋友都知道，这些事情一点都不奇怪。
集群搭建（GPU配置、网络设计、轨道优化等）、集群管理（实时监控、故障排除等）……个个都是「拦路虎」。
对于缺乏相关经验和资金的公司来说，该怎么办？
最近，浪潮信息的研发工程师，仅靠4颗CPU，就让千亿参数的「源2.0」在通用服务器上跑起来了！
面对用Java编写程序的代码任务，「源2.0」非常迅速地给出了结果。
再给它上一道推理题——船边挂着软梯，离海面2米，海水每小时涨半米，几小时海水能淹没软梯？
同样，AI几乎0延迟给出了详细的解题步骤和答案。
用通用服务器运行千亿参数大模型，可谓是前无古人，这一领域的积累完全是空白，没有任何经验可借鉴。
浪潮信息，究竟是怎么做到的？
用4颗CPU，撬动千亿参数大模型
若要在单台服务器中，实现千亿参数大模型的推理，包含了2个主要阶段，均对计算能力提出了硬性需求。
首先，是预填充阶段，也叫做前向传播阶段。
这一阶段涉及到输入数据的处理、模型参数第一次读取。
比如，当你输入「给我写一篇有关AI的文章」提示，预填充阶段便会将问题中所有token、模型参数，一次性输入计算。
有时，这一输入可能是几个字，也可能是几千个字，或者是一本著作。
第一阶段的计算需求有多大，主要取决于我们输入的长度。
而在计算第一个token过程中，由于模型首次加载，会在内存中存放全部的权重参数，以及KV Cache等数据。
这是模型参数本身所占内存空间的2-3倍。
对于千亿参数模型来说，大量的参数和数据输入，需要在强大计算单元中处理。对此，它需要支持向量化指令集、矩阵计算指令集，来实现大量的矩阵乘法和张量运算。
其次，是解码阶段，即在问题全部输入之后，模型开始输出结果的阶段。
在这个阶段，对大模型唯一要求便是，输出尽可能快。同时，挑战不再是算力挑战，转而为「数据搬运」的挑战。
它包含了两部分「数据搬运」：
预填充阶段生成的大量KV Cache，需要从显存/内存，搬运到计算单元中（工作量非常大）
模型参数本身的搬运
这些搬运对大模型的计算和推理速度，起到了一个决定性的作用。数据搬运很快，LLM吐字的速度也会快。
LLM输出主要通过KV Catch，逐一生成token，并在每步生成后存储新词块的键值向量。
因此，千亿大模型的实时推理，服务器需要具备较高的计算能力，以及较高的存储单元到计算单元的数据搬运效率。
总而言之，在大模型推理的两阶段中，有着截然不同的计算特征，需要在软硬件方面去做协同优化。
GPU不是万能的
传统上，GPU因其具备优越的并行处理能力，一举成为了AI训练和推理的首选。
成本
然而，高端GPU服务器在市场中经常出现供不应求，极难获取的现象。
仅有资金雄厚的科技巨头们，诸如微软、谷歌，才能够承担起这笔费用。
另一方面，不仅买不起，更是用不起。
基于GPU的云服务租用，在推理任务中的代价却是高昂的。对于科研人员和应用厂商来说，需要实现更高的成本效益，就得另谋他路。
显存
此外，GPU最大的劣势之一在于，显存容量受限。
当前业界LLM的网络架构，已从GPT逐渐走向MoE。通向AGI的大模型参数规模，只会呈指数级增长。
这意味着，闭源/开源主流模型的尺寸只会越来越大，千亿参数，甚至万亿参数模型将会成为主流。
对于百亿参数模型，20-30GB显存就够了。然而，若想跑千亿参数，大约需要200-300GB的显存空间。
目前主流的AI芯片，显存通常只有几十GB，显然放不下这么大的模型。（目前最强的AI芯片也没还没达到200GB）
被低估的通用服务器
GPU不行，那就从CPU入手。
虽然目前还搞不定模型的大规模训练，但通用服务器在推理任务上，却意外有着不小的优势。
在具体实践的过程中，浪潮信息的工程师们分别从硬件资源和算法层面入手，攻克了一个个「拦路虎」。
超大内存+高速带宽
算力方面， 目前领先的服务器CPU都已经具备了AI加速功能。
类似于GPU的Tensor core，AMX高级矩阵扩展可以将低精度的计算做加速，编成指令集给CPU的核，利用专用的核做加速。
算法方面， 浪潮信息的通用服务器可同时支持PyTorch、TensorFlow等主流AI框架，以及DeepSpeed等流行开发工具，满足了用户更成熟、易部署、更便捷的开放生态需求。
通信方面， 全链路UPI（Ultra Path Interconnect）总线互连的设计，则实现了CPU之间高效的数据传输：
允许任意两个CPU之间直接进行数据传输，减少了通信延迟
提供了高传输速率，高达16GT/s（Giga Transfers per second）
此外，浪潮信息的研发工程师还优化了CPU之间、CPU和内存之间的走线路径和阻抗连续性。
依据三维仿真结果，他们调整了过孔排列方式，将信号串扰降低到-60dB以下，较上一代降低了50%。
并且，通过DOE矩阵式有源仿真，找到了通道所有corner的组合最优解，让算力性能可以得到充分发挥。
内存方面， 可以说是通用服务器的最大优势了。
容量
对于4路服务器来说，只需给每颗CPU插上8根32GB内存，就能轻松达到1TB。插满之后甚至可以扩展到16TB，最大可支持万亿参数的模型。
带宽
搭配DDR5的内存，则可以实现4800MHz × 8bit × 8通道 × 4颗 ÷ 1024 = 1200GB/s的理论上带宽。
实测结果显示，读带宽为995GB/s、写带宽为423GB/s，以及读写带宽为437GB/s。
这个数据，对于一些搭载GDDR显存的GPU或加速卡，可以说是毫不逊色。
但仅靠硬件远远不够
仅仅依靠硬件创新，是远远不够的，CPU很难进行大模型算法的大规模并行计算。
正如开篇所述，大模型对通信带宽的要求是非常高的，无论是数据计算、计算单元之间，还是计算单元与内存之间。
如果按照BF16精度计算，想要让千亿大模型的运行时延小于100ms，内存和计算单元之间的通信带宽，就至少要达到2TB/s以上。
不仅如此，对于基于擅长大规模并行计算的加速卡设计的AI大模型，通用服务器的处理器与之并不适配。
原因很明显：后者虽然拥有高通用性和高性能的计算核心，但并没有并行工作的环境。
通常来说，通用服务器会将先将模型的权重传给一个CPU，然后再由它去串联其他CPU，实现权重数据的传输。
然而，由于大模型在运行时需要频繁地在内存和CPU之间搬运算法权重，这样造成的后果就是，CPU与内存之间的带宽利用率不高，通信开销极大。
如何解题？用算法创新
针对以上难题，浪潮信息提出了「张量并行」（Tensor Parallel）和「NF4量化」两项技术创新，成功实现了千亿大模型Yuan2.0-102B的实时推理。
根据性能分析结果，可以清晰地看到模型中不同部分的计算时间分布——
线性层运行时间占比50%，卷积运行时间占比20%，聚合通信时间占比20%，其它计算占比10%。
注意，在整个推理过程中，计算时间占比达到了80%！
跟使用多个PCIe的AI加速卡相比，这就形成了鲜明的对比——后者的通信开销可能高达50%，从而导致严重的算力浪费。
Yuan2.0-102B模型推理性能分析结果图
张量并行
所谓张量并行，就先将卷积算子进行张量切分，然后把大模型中的注意力层和前馈层的矩阵计算权重，分别输入到多个处理器的内存中。
如此一来，通用服务器中的4颗CPU便可同时获取算法权重，进行计算加速。
不过，张量并行对模型参数的切分粒度较细，要求CPU在每次张量计算后都要进行数据同步。
对于这个需求，前文提到的全链路UPI总线互连技术，完全可以满足（通信带宽高达16GT/s）。
最终，这种协同并行工作，直接让计算效率提升了4倍！
NF4量化
至于内存带宽不足的问题，则需要在不影响精度的情况下对模型进行「瘦身，也就是量化。
其优势在于，一方面可以将LLM参数量化成低比特数据，权重会变小。另一方面，权重缩小之后，在计算时传输的数据量也会变小。
这里，浪潮信息采用了一种并不多见的分位数量化方法——NF4（4位NormalFloat）。
NF4量化方法可将Yuan2.0-102B的尺寸压缩到原来的1/4
具体来说，NF4的核心思想是，确保量化区间内输入张量的值数量相等。
这个特点，恰恰非常适合呈现近似正态分布的LLM权重。
由于可以通过调整标准差来适配量化数据类型的范围，NF4相较于传统的4位整数或4位浮点数量化，可以获得更高的精度。
如此一来，量化之后的模型既能满足精度需求，又能大幅降低大规模并行计算的访存数据量，从而达到了实时推理的解码需求。
整数或浮点数量化方法的数据间隔通常是平均分布或指数分布的
为了进一步压缩模型的权重参数，团队还采用了嵌套量化（Double Quant）技术。
这是在NF4量化基础上，进行了二次量化。
因为NF4量化后会产生大量的scale参数，如果使用32位浮点数（FP32）存储，会占用大量内存。
对于一个千亿参数的LLM，若以每64个参数作为一个量化块（block size=64）来计算，仅存储scale参数就需要额外的6GB内存：(100B ÷ 64) × 4 = 6GB。
团队通过将这些scale参数量化到8位浮点数（FP8），显著减少了所需的存储空间。
在采用256为量化块大小（block size=256）的情况下，存储所有scale参数所需的额外空间仅为1.57GB：(100B ÷ 64 ÷ 256) × 4 + (100B ÷ 64) × 1 = 1.57GB.
通过嵌套量化，模型的每个权重参数最终仅占用4字节的内存空间，比原始FP32节省了大量的内存占用空间。
与此同时，它将从内存到CPU的数据搬运效率，提高了4倍。
这样的优化显著减轻了内存带宽对Yuan2.0-102B模型推理解码效率的限制，从而进一步提升了模型的推理性能。
所谓通用，就是让大家都用上
到这里，浪潮信息就成功交卷了！
通过系统优化，浪潮信息的NF8260G7，在业界首次实现了仅基于通用处理器，支持千亿参数大模型的运行。
至此，通用算力可支持的AI大模型，参数规模突破了千亿，彻底填补了行业空白，成为了企业拥有AI的新起点。
千亿参数AI的模型的部署，从此有了性能更强、成本更经济的选择；AI大模型应用，可以和云、大数据、数据库，实现更紧密的融合。
科技进步的最终目的，一定是落入凡间。
放眼当下，AIGC已经渗透进千行百业。AI已经以惊人的速度，渗透进了每一个计算设备。
2024年1-4月，国内大模型的中标数量，已经超越了2023全年总数，中标披露金额已经达到了2023年全年的77%。
在金融行业、医院门诊部，企业的IT部门，从业者都发现了这一点：传统行业的算力基础设施，已经不够用了！
如今，千亿参数大模型，是千行百业智能涌现的关键。而通用算力能否运行千亿参数大模型，正是衡量其能否支撑千行百业智能涌现的关键。
浪潮信息的创举，让互联网、金融、医疗等行业客户可实现高效部署，首次投入就可节约80%以上的建设成本。
无论是金融防欺诈、财务数据分析、企业CRM营销洞察、医疗智能诊断、个性化诊疗方案、教育培训等等，都将见证AI的广泛应用。
从此，一切计算皆AI。
参考资料：
https://mp.weixin.qq.com/s/1wYt7dfoVy2J1FFkOJjRTg
偷懒才能更好地工作。
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 所示。
在预填充阶段，模型计算和保存 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 分析结果。
可以看到，对于首个生成的 token，输入 token 的注意力分数非常稀疏，这说明输入 prompt 中的许多 token 是多余的，就算移除也不会影响到下一 token 预测。这一观察正是该团队提出 LazyLLM 的基础。
LazyLLM 的优势包括适用范围广、无需训练、效果好。图 3 对比了标准 LLM 与 LazyLLM。
LazyLLM
图 4 展示了 LazyLLM 的整体框架。
从完整上下文开始，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 加速和准确度结果。
在此表中，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。
可以看到，LazyLLM 计算使用的 token 的占比总是低于 100%，这说明 LazyLLM 在生成结束时也没有用完 prompt 中的所有 token，但理论上讲该模型可以使用所有 token。这能为不同任务的整体生成过程提供额外的加速。
不同层的丢弃率
该团队也分析了剪枝层的位置和被剪枝 token 的数量的影响。结果见图 6。
可以看到，当在同一 Transformer 层进行剪枝时，留下的 token 越少，模型的性能越差。这也符合我们的直观认知。此外，相比于在更前期 Transformer 层执行剪枝，在后期层进行剪枝会得到更好的性能，这说明后期层对 token 剪枝的敏感度更低。
基于这些观察，可以说渐进式 token 剪枝的效果得到了证明。
渐进式 KV 增长
最后，该团队也尝试了理解使用 token 剪枝逻辑的模型的内部情况。具体来说，他们想要了解 prompt token 中的累积使用比例以及相应的不被使用的比例。这种「累积 token 使用量」可以等价地定义成每一步的 KV 缓存 大小。图 7 给出了 LazyLLM 的每个阶段这些累积的 prompt token 使用量。
该结果支持这一假设：许多 token 永远不会被模型选择（即便理论上讲模型可以使用 prompt 中的所有 token。
考虑到模型依然能维持执行任务的准确度，因此可以得出结论：模型可以有效地丢弃不影响输出质量的 token。