免费的企业网站源码,郑州seo优化外包公司,wordpress仪表盘修改,手机网站生成app在过去的一年里#xff0c;生成式 AI 发展迅猛#xff0c;在这当中#xff0c;文本生成一直是一个特别受欢迎的领域#xff0c;很多开源项目如 llama.cpp、vLLM 、 MLC-LLM 等#xff0c;为了取得更好的效果#xff0c;都在进行不停的优化。 作为机器学习社区中最受欢迎框…在过去的一年里生成式 AI 发展迅猛在这当中文本生成一直是一个特别受欢迎的领域很多开源项目如 llama.cpp、vLLM 、 MLC-LLM 等为了取得更好的效果都在进行不停的优化。 作为机器学习社区中最受欢迎框架之一的 PyTorch自然也是抓住了这一新的机遇不断优化。为此让大家更好的了解这些创新PyTorch 团队专门设置了系列博客重点介绍如何使用纯原生 PyTorch 加速生成式 AI 模型。 代码地址https://github.com/pytorch-labs/gpt-fast 在第一篇博客中PyTorch 团队展示了仅使用纯原生 PyTorch 重写 Segment AnythingSAM模型比原始实现快 8 倍。在本博客中他们又为我们带来了新的内容即如何加快 LLM 推理。 我们先来看看结果该团队重写 LLM推理速度比基线足足快了 10 倍并且没有损失准确率只用了不到 1000 行的纯原生 PyTorch 代码 所有基准测试都在 A100-80GB 上运行的功率限制在 330W。 这些优化包括 Torch.compilePyTorch 模型编译器 PyTorch 2.0 加入了一个新的函数叫做 torch.compile ()能够通过一行代码对已有的模型进行加速 GPU 量化通过降低运算精度来加速模型 Speculative Decoding一种大模型推理加速方法使用一个小的「draft」模型来预测大的「目标」模型的输出 张量并行通过在多个设备上运行模型来加速模型推理。 接下来我们看看每一步都是如何实现的。 6 步加快大模型推理 该研究表示在没有优化之前大模型的推理性能为 25.5 tok/s效果不是很好 经过一番探索后终于找到了原因CPU 开销过大。然后就有了下面的 6 步优化过程。 第一步通过 Torch.compile 和静态 KV 缓存减少 CPU 开销实现 107.0 TOK/S torch.compile 允许用户将更大的区域捕获到单个编译区域中特别是在 mode”reduce-overhead” 时参考下面的代码这一功能对于减少 CPU 开销非常有效除此以外本文还指定 fullgraphTrue用来验证模型中没有「图形中断」即 torch.compile 无法编译的部分。 然而即使有 torch.compile 的加持还是会遇到一些障碍。 第一个障碍是 kv 缓存。即当用户生成更多的 token 时 kv 缓存的「逻辑长度logical length」会增长。出现这种问题有两个原因一是每次缓存增长时重新分配和复制kv 缓存的成本非常高其次这种动态分配使得减少开销变得更加困难。 为了解决这个问题本文使用静态 KV 缓存静态分配 KV 缓存的大小然后屏蔽掉注意力机制中未使用的值。 第二个障碍是 prefill 阶段。用 Transformer 进行文本生成可视为一个两阶段过程1. 用来处理整个提示的 prefill 阶段 2. 解码 token. 尽管 kv 缓存被设置为静态化但由于提示长度可变 prefill 阶段仍然需要更多的动态性。因此需要使用单独的编译策略来编译这两个阶段。 虽然这些细节有点棘手但实现起来并不困难而且性能的提升是巨大的。这一通操作下来性能提高了 4 倍多从 25 tok/s 提高到 107 tok/s。 第二步通过 int8 权重量化缓解内存带宽瓶颈实现 157.4 tok /s 通过上文我们已经看到应用 torch.compile 、静态 kv 缓存等带来的巨大加速但 PyTorch 团队并不满足于此他们又找了其他角度进行优化。 他们认为加速生成式 AI 训练的最大瓶颈是将权重从 GPU 全局内存加载到寄存器的代价。换句话说每次前向传播都需要「接触touch」GPU 上的每个参数。那么理论上我们能够以多快的速度「接触」模型中的每个参数 为了衡量这一点本文使用模型带宽利用率MBU计算它非常简单如下所示 举例来说对于一个 7B 参数模型每个参数都存储在 fp16 中每个参数 2 字节可以实现 107 tokens/s。A100-80GB 理论上有 2 TB/s 的内存带宽。 如下图所示将上述公式带入具体的数值可以得到 MBU 为 72%这个结果是相当不错的因为很多研究很难突破 85%。 但 PyTorch 团队还想将这个数值在提高一些。他们发现无法改变模型中参数的数量也无法改变 GPU 的内存带宽。但他们发现可以更改每个参数存储的字节数 因此他们打算用 int8 量化。 请注意这仅是量化权重计算本身仍然在 bf16 中完成。此外有了 torch.compile可以轻松生成 int8 量化的高效代码。 就像上图所展示的从深蓝色线torch.compile int8可以看出使用 torch.compile int8 仅权重量化时性能有显着提升。 将 int8 量化应用于 Llama-7B 模型性能提高了约 50%达到 157.4 tokens/s。 第三步使用 Speculative Decoding 即使在使用了 int8 量化等技术之后该团队仍然面临着另一个问题即为了生成 100 个 token必须加载权重 100 次。 即使权重被量化一遍又一遍地加载权重也避免不了这种问题该如何解决呢事实证明利用 speculative decoding 能够打破这种严格的串行依赖性并获得加速。 该研究使用草稿draft模型生成 8 个 token然后使用验证器模型并行处理丢弃不匹配的 token。这一过程打破了串行依赖。整个实现过程大约 50 行原生 PyTorch 代码。 第四步使用 int4 量化和 GPTQ 方法进一步减小权重实现 202.1 tok/s 本文发现当权重为 4-bits 时模型的准确率开始下降。 为了解决这个问题本文使用两个技巧来解决第一个是拥有更细粒度的缩放因子另一种是使用更先进的量化策略。将这些操作组合在一起得到如下 第五步将所有内容组合在一起得到 244.7 tok/s 最后将所有技术组合在一起以获得更好的性能得到 244.7 tok/s。 第六步张量并行性 到目前为止本文一直是在单个 GPU 上最大限度地减少延迟。其实使用多个 GPU 也是可以的这样一来延迟现象会得到进一步改善。 非常庆幸的是PyTorch 团队提供了张量并行的低级工具只需 150 行代码并且不需要任何模型更改。 前面提到的所有优化都可以继续与张量并行性组合将这些组合在一起能以 55 tokens/s 的速度为 Llama-70B 模型提供 int8 量化。 最后简单总结一下文章主要内容。在 Llama-7B 上本文使用「compile int4 quant speculative decoding」这一套组合拳实现 240 tok/s。在 Llama-70B本文还通过引入张量并行性以达到约 80 tok/s这些都接近或超过 SOTA 性能。
