29倍吞吐量提升:一探H2O高效生成大型语言模型的秘密

373次阅读
9 条评论

在人工智能的浩瀚星海中,大型语言模型如同耀眼的恒星,它们的能力强大而深不可测。然而,这些模型的运作往往需要耗费巨大的计算资源,这也成为了阻碍 AI 技术广泛应用的一大障碍。今天,让我们一起探索那个改变游戏规则的创新项目——H2O。

29 倍吞吐量提升:一探 H2O 高效生成大型语言模型的秘密

引领潮流的创新:H2O 的诞生 🌟

在 NeurIPS’23 大会上,一项名为 H2O 的研究引起了广泛关注。这是一种被称作“重点词神器”的技术,它使得大型语言模型的生成变得更加高效。那么,H2O 到底是什么呢?

简而言之,H2O 是一种优化了的内存管理方案,它通过智能地管理键值(KV)缓存来减轻模型推理过程中的计算负担。KV 缓存通常与序列长度和批量大小成线性关系,而 H2O 能够大幅减少这些缓存的内存占用。

精华所在:重点词的力量 💡

H2O 的核心概念在于识别和利用了“重点词”——这些词在计算注意力得分时占有压倒性的重要性。研究者发现,这些词与文本中的频繁共现词强相关,若将它们从模型中移除,性能会大打折扣。H2O 正是利用了这一洞察,通过平衡最近词和重点词,优化了 KV 缓存的管理。

实践证明:H2O 的效能 🛠

H2O 不仅在理论上前卫,它的实用性也已经在各种任务和不同规模的模型上得到了验证。

实验表明:在保留两成重点词的情况下:

通过 H2O 优化的大型模型在性能上可以实现高达 29 倍的吞吐量提升!

这在当前领先的如 DeepSpeed Zero-Inference、Hugging Face Accelerate 和 FlexGen 等推理系统中表现尤为突出。

开源精神:与社区共建 🌐

值得庆幸的是,H2O 项目已经在 GitHub 上开源,任何对 AI 充满热情的开发者和研究者都可以参与其中。无论是想提高你的语言模型生成效率,还是仅仅出于好奇,你都可以在这个平台上找到价值。

结语:跨越技术的鸿沟 ✨

随着 H2O 的横空出世,那些曾经遥不可及的 AI 技术现在似乎触手可及。这个项目不仅仅是技术的飞跃,更是开启普通人使用强大 AI 工具的大门。让我们拭目以待,看看 H2O 将如何在未来的日子里,继续激起技术革新的波澜!

正文完
 
评论(9 条评论)
2023-12-21 14:56:37 回复

https://github.com/FMInference/H2O

 Macintosh  Safari  美国科罗拉多丹佛
2023-12-27 23:28:53 回复

生成式 大型 语言 模型( llm )因其 在创意 写作 、高 级代 码生 成和
复杂 自 然语 言 处理 任 务方 面 的卓 越 能力 而受 到 关注 [5 ,42 ,49 ]。
这些模 型广泛 部署 在配备 高端 和昂贵 的服 务器级 gp u 的数据
中心中 ,对 我们 的日 常生 活和 工作 实践产 生了 重大 影响 。与
此同时 ,在更 容易 访问的 本地 平台上 运行 llm 的 趋势正 在兴
起,特 别是 带有 消费 级 gp u 的个人电 脑(p c )。这种 演变 是由
增强数 据隐 私[25 ]、 模型 定制[2 2 ]和降低 推理 成本[4 2 ]的需求
驱 动 的 。 与 优 先 考 虑 高 吞 吐 量 的 数 据 中 心 部 署 相 比
[18,37,47 ],本地 部署 侧重于 处理 小批量 时的 低延迟 。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:29:10 回复

尽管 如此 ,在 消费 级 gp u 上部 署 llm 面临 着巨 大的 挑战 ,因
为 它 们需 要 大 量 的 内 存 。llm ,通常作为自回归的变形器,
按顺 序逐 个符 号生 成文 本, 每个 符号 都需 要访 问由 数千 亿个
参 数组 成 的 整 个模 型 。 因此 , 推 理 过程 从 根 本 上受到 GP U
内存 容量 的限 制。 这种 限制 在本 地部 署中 尤其 严重 ,在 本地
部署 中, 单 个请 求的 处 理(通 常 一次 只 有一 个)[6 ]留 给并 行处
理的机会很 少。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:29:56 回复

解决这类内存问题的现有方法包括模型压缩和卸载。量
化[1 2 ,46 ]、蒸馏[4 8 ]和剪枝[2 3 ]等压缩技术减少了模型的大
小。 然而 ,即 使是 深度 压缩 的模 型对 于消 费级 gpu 来说 仍然
太大 。例 如,4 位精度 的 OPT-66B 模型仅 加载 其参 数就 需要
大约 4 0 GB 的 内存[2 0 ],甚至 超 过了 N VI DI A RT X 40 90 等高
端 gp u 的容 量。 模型 卸载 , 在 Tra n sfo rm e r 层将模 型划 分为
GP U 和 CP U[3 ,14 ,37 ]。最先进的系统,如 lla ma .cp p [14 ]在
CPU 和 GP U 内存 之间 分配 层, 利用 两者 进行 推理 ,从 而减
少所 需的 GPU 资源 。然 而, 这 种方 法受 到慢速 P CIe 互连和
cpu 有限的计 算能 力的 阻碍 ,导 致较 高的 推理 延迟 。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:30:15 回复

在本 文中 ,我 们认为 L LM 推 理中 内存 问题 的关 键原 因是
硬 件架 构与 LL M 推理 特 性 之间 的局部性不匹配 。当前 的硬
件架 构设 计了 针对 数据 局部 性优 化的 内存 层次 结构 。理 想情
况下 ,应 该 在 GP U 中 存 储一 个小 的、 经 常访 问的 工作 集,
这样 可以 提供 更高 的内 存带 宽, 但容 量有 限。 相比 之下 ,更
大的 、访 问频 率更 低的 数 据更 适合 c p u ,它提 供更 广泛 的内
存容 量, 但带 宽更 低。 然而 ,每 次 LLM 推理 迭代 所需 的大
量参 数导 致单 个 GP U 的 工作 集太 大, 从 而阻 碍了 有效 的局
部性利用。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:31:34 回复

在 OPT 模 型中 , 激活 图中 只 有不 到 10 % 的 元素 是非 零 的,
而这些元素在运行时的预测准确率可以达到 93% 以 上[2 1 ]。
值得注意的 是 ,LLM 中的 神经 元 激活 遵循倾斜的幂律分布 :
一小部分神 经 元始 终参 与 各种 输 入(热激活)的 大 多数 激活
(超过 80 % ), 而大 多数 神 经元 参 与剩 余的 激 活, 这些 激 活
是根据运行 时 的输 入(冷激 活 )确定 的 。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:32:33 回复

在局 部性 见解 的基 础上 ,我 们介 绍 了 PowerInfer,这 是一
个高效的 L LM 推理系统, 使用单个消 费级 GPU 对 本地部署
进行了优化。Po we rInfe r 的关键 思想是利用 L LM 推 理中的局
域性,将少量 的热神经 元分配给 GP U,而 构成大多 数的冷神
经元由 CP U 管理。Po w- e rInfe r 离线预选 和预加载 热激活的
神经元到 GPU 上 ,并在运行 时利用在线 预测器来识 别激活的
神经元。这种方 法允许 GP U 和 CP U 独 立处理各自 的神经元
集,从而最大限度 地减少对昂 贵的 PCI e 数据传 输的需求。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:32:53 回复

然而 ,有 一些 重大 的挑 战 使 Po we rInf er 的设 计复 杂化 。首
先, 在线 预测 器对 于识别 L LM 层中 的活 动神 经元 至关 重要 ,
通常 位于 G PU 上, 占用 了大 量 的 GPU 内存 。否 则, 这些 内
存 可以 用于 LL M 。为 了 解 决这 个 问 题,Po we rInf e r 引 入了
一种自适应方法,用于为具有较高激活稀疏度和偏度的层
构建较小的预测器。这个迭代过程减少了预测器的大小,
同时 保 持 了它 们 的 准确 性 , 从而 为 L LM 推 理释 放 了 GP U
内存。

 Windows  Edge  美国密苏里堪萨斯城
2023-12-27 23:33:39 回复

Po we rInf e r 的 在 线 推 理 引 擎 是 通 过 添 加 4 200 行 c ++ 和
C U D A 代 码 来扩 展 lla ma .cp p 来实现 的 。它 的离 线 组件 ,包
括一 个 分析 器 和一 个 求 解器 , 建立 在 变压 器 框架 [44 ]上 ,大
约 有 4 00 行 Py th on 代码。p o we re rin f e r 兼 容 各 种 流 行 的
LL M 家 族 , 包 括 OP T (7 B-175 B) , LLa M A (7 B-7 0 B)和
Fa lcon – 40 B, 并 支持 消 费级 gpu , 如 N VI DI A RT X 40 90 和
NVI DI A RTX 2080Ti。

 Windows  Edge  美国密苏里堪萨斯城