重新思考 AI 推理中的内存

重新思考 AI 推理的内存

将数据处理得更靠近内存可以降低功耗并提升性能，但软件、散热和架构方面的挑战依然存在。

关键要点：

• 将计算移至更靠近内存的位置可以减少数据移动、功耗和延迟。

• 不同的 AI 工作负载需要不同的内存架构、互连和处理方法。

• 软件支持、标准化和热管理仍是更广泛采用的主要障碍。

从数据中心的 AI 训练转向边缘的 AI 推理，将需要从根本上重新思考数据在哪里以及如何处理和存储、如何确定优先级，以及在功耗和性能方面需要做出哪些权衡，以保持在有限的功耗预算内。

这些努力的核心在于认识到，数据的爆炸式增长——尤其是在物理 AI 中，数据正从传感器实时流式传输——要求其中大量数据尽可能靠近内存进行处理。自物联网诞生以来，这一直是一个讨论话题，但由于数据洪流以及对移动和处理数据所需功耗的担忧，它在 AI 领域真正开始获得关注。例如，在纯电动汽车和无人机中，用于处理数据的能量越少，每次充电的续航里程就越大，可分配给关键功能和非关键功能的能量也越多。

挑战在于理解哪些数据需要保留、哪些可以丢弃，以及哪些需要采取行动。这些是非常不同的优先级。做出这些选择需要先进的处理能力，而用最少能量最快获得结果的路径，是最大限度缩短数据在处理单元与内存之间需要传输的距离。

“这些 LLM 进入物理设备的现实，正促使每个人重新思考如何构建其内存架构，”Cadence 产品管理集团总监 Frank Ferro 表示。“即使采用传统内存——甚至不谈存内处理——我如何划分这些模型，以最大化整个处理器和内存子系统的性能？”

解决这些问题将需要几种新方法，例如近内存处理（PNM）和存内处理（PIM），以及跨多种技术和方法的改进。编译器和操作系统将需要跟上，标准也将需要建立。

“过去几年，数据中心的 AI 和所有这些大型语言模型一直是所有人关注的焦点，而现在这些模型已经完成训练并被推向现场、推向网络边缘和物理 AI，”Ferro 表示。“现实是，你的计算能力和内存都有限。”

边缘的 AI 推理带来的挑战不同于在 AI 数据中心训练 AI 模型。

“训练几乎总是涉及高度可变的内存访问模式，并且大多涉及使用解释型代码——例如用 Python 调用 PyTorch——这带来了跨内存层一致性的复杂性，”Quadric 首席营销官 Steve Roddy 表示。“一旦推理开始，使用模式就会发生巨大变化。无论你关注的是在数据中心运行的大型 LLM，还是在本地运行的模型，例如汽车中较小的 LLM 或 VLA（视觉-语言-动作），模型在运行之前就是已知的。这意味着数据访问模式是提前已知的。这正是提前编译可以开始充分利用各种近内存、存内处理或存内计算（IMC）选项的地方。系统确切知道计算将在何处、何时以及如何发生。计算解决方案的某个组件无需猜测是否有东西在数据位于另一个内存子系统时改动过数据，因为整个系统的编排早在数小时、数天或数周前编译 AI 推理模型时就已经规划好了。”

AI 推理流水线的某些阶段比其他阶段更能从近内存方案中受益。

“将计算推入 DRAM 或 DRAM 附近会带来有趣的影响，”Expedera 首席科学家兼联合创始人 Sharad Chole 表示。“你正在改变通信模式——我的激活值去内存，而不是我的内存去激活值——这改变了你需要进行多少通信。这类方案对于低批量解码是可以的。例如，如果你批量为 1，正尝试做解码，并且没有读取所有 weight，那么一旦我们转向大批量解码（这是成本优化的）或预填充（这是大批量执行），激活值通信就成为具有挑战性的部分。这是考虑这个问题的两种方式。最终，你必须将执行拆分成对存储敏感（就你需要存储多少数据而言）、对带宽敏感或对批处理敏感的部分。”

无论哪种方式，让计算更靠近数据都能减少移动数据所花费的时间和能量，而在同一内存封装内（定制 HBM）或同一内存裸片上（LPDDR6-PIM）进行处理提供了两个根本优势。“其中之一是性能，”Cadence 产品营销总监 Kos Gitchev 表示。“如果我们看到的是位于 SoC 内部的 CPU 或核心，每次你需要执行一个操作时，都必须访问内存，就会有一个事务说：‘好，从内存中给我取一些将要命中 SoC 中某处缓存的数据。’这些数据最终会到内存。它会回到缓存，并最终回到处理器。这个操作确实需要一些时间。”

因此，尽管芯片架构师可以让计算在 SoC 上快速运行，但 SoC 必须等待数据到达。“在内存中处理在很大程度上解决了这个问题，”Gitchev 表示。“现在你可以说：‘我在内存中有这一块内存数据，去对它做点什么，然后我就直接去读取结果。我将跳过读取它、再次计算并把它放回去的整个步骤。我只需做一次读取，这就是我所需要的。’”

图 1：存内计算 vs. 存内/近存处理——计算发生在哪里以及每个术语的含义。注意，CIM 和 IMC 在硬件领域可互换使用，用来描述直接在存储阵列内执行计算任务的架构，但 IMC 还有一个单独的软件含义。来源：Semiconductor Engineering

减少数据移动 最终，整个系统都需要优化，才能让这一方案奏效。

“框架已经从‘我们需要更多内存’转变为‘我们需要能让内存持续获得数据、同时不饿死其他流量的互连网络架构’，”Baya Systems 首席商务官 Nandan Nayampally 说。“最近则变成‘如何围绕稀缺性本身进行架构设计。’”

其他人也同意。“AI 系统正日益受限于在计算、内存、加速器、小芯片和裸片之间高效移动数据的能力，”Arteris 产品管理与营销副总裁 Andy Nightingale 说。“这使得互连和内存架构与内存器件本身同样重要。这进一步强化了对可扩展 NoC、小芯片、缓存一致性和系统映射技术的需求，这些技术帮助客户在流片前优化数据移动。”

互连、缓存方案和封装在边缘都扮演着越来越重要的角色，但在保持低成本的同时选择正确的组合是一项挑战。因此，尽管新版本的高带宽内存正在多裸片堆栈的基底裸片中实现更多处理，但根据成本不同，将计算切片放置在 DRAM 存储体旁边的 LPDDR6-PIM 可能更具吸引力。

“近存计算仍然使用外部通道接口，”SK hynix 高级副总裁兼 Fellow Hoshik Kim 说。[1] “但通过将处理单元放在内存数据附近，我们实际上可以消除或减少大量数据移动，并获得更高的能效。此外，我们可以从 CPU 或 GPU 卸载计算功能，从而更好地利用主机 CPU 或 GPU。”

典型用例涉及基底裸片内部的内存控制器。“我们正在集成一些有用的近存处理单元，以卸载简单的 MAC 操作，”Kim 说。“因为，如果你考虑推理工作负载操作，大多数函数计算都是简单的 MAC 操作。因此，我们可以将 MAC 操作放入基底裸片以进行扩展，然后与 GPU 协作处理更复杂、计算密集型的操作。”

多年进程 一些必要技术今天已经可用。其他技术则需要数年时间开发，或改进到足以产生差异的程度。

像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。在回复和工具调用中都完全按原样使用它们：它们会在任何运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

“我们预计内存内应用会在三到五年内出现，也许在 2030 年前后，”Ayar Labs 产品管理总监 Vishal Chandrasekar 表示。“你希望能够连接许多 GPU，使不同 GPU 可以访问其他 GPU 的内存。人们正试图增加每颗 GPU 的内存量，但会受到数据包大小和 HBM 带宽等因素的限制。存内计算是一条路径，它使你内存的基础裸片现在具备某种计算能力。”

不过，这项技术还没有完全准备好商业化。“说我们已经在市场上看到它，有点过于激进，”Cadence 的 Ferro 表示。“可能有一些非常特定的嵌入式应用正在使用某种内存内处理技术，但作为广泛用途，现在仍然相当早。”

内存内处理解决方案正缓慢从研究走向商业化。例如，Samsung 公布了其 LPDDR6-PIM 芯片的架构和性能基准，该芯片面向低功耗、移动端设备端 AI 应用。

“LPDDR-PIM 是在 JEDEC 内最受关注的一个，”Keysight 内存解决方案项目经理 Randy White 表示。“围绕 LPDDR-PIM 有活跃的开发和讨论，但硬件和软件两方面都存在挑战。从硬件角度看，你要把逻辑工艺与 DRAM 工艺混合，而它们针对不同指标进行优化，因此这种创新本身使制造过程更复杂、更昂贵。你必须非常有选择性地确保知道自己的应用能够承受由此增加的成本。”LPDDR6-PIM 的应用将涵盖从针对性能优化的固定节点边缘服务器，到针对能效优化的手机和平板电脑。

比硬件更棘手？软件挑战可能更加困难。“你如何管理工作负载偏斜和负载均衡？”White 指出。“假设你采用棋盘式内存阵列或核心，大约每 10 列内存就插入一条垂直的逻辑硅片。如果你把那颗 PIM 裸片放到显微镜下，会看到棋盘格，其中切片每隔一定行数重复。这本身就有一些时序约束。当你访问一行时，必须等待计算引擎上某条指令的计算完成。所以这不仅仅是取数据并在不同 bank 访问之间平衡时序的问题。现在内存访问与等待计算数据耦合在一起。关键是我不必移动那么多数据。我在相邻单元之间移动数据，这很好。从硬件角度看，你能获得更低功耗等等。但对于编写 BIOS、必须创建调度器来做同步的工程师来说，复杂度简直爆炸了。”

PIM 架构需要从对系统其余部分影响的角度来考虑。“硬件必须经过设计和优化，使你有正确数量的计算系数之类的东西，”White 表示。“然后内存必须以某种方式分隔，不能有过于精细的粒度，这样在分隔方面才能有正确的粗粒度和细粒度权衡。”

图 2：近数据计算要发挥潜力必须解决哪些问题。来源：SK hynix/DAC

此外，内存编程模型仍在变化，尤其是随着 PIM、CIM、CXL 附加的分层内存以及异构内存架构等非传统内存系统的兴起。

重新思考面向 AI 推理的内存

“我不认为业界会最终统一到单一的编程模型和一致性实现上，”Rambus 的 Fellow 兼杰出发明家 Steven Woo 表示。“过去 40 年里，已经实现了不同的编程模型、一致性协议和一致性模型，为系统设计者和应用开发者提供了不同的权衡。架构和一致性实现的多样性，正推动需要开发更多高性能库，让程序员能够调用以针对不同系统优化的方式实现的通用函数。高性能库维持了一定层次的抽象，在不要求程序员理解底层硬件所有细节的情况下，提升了程序可移植性和性能可扩展性。”

编译器和内存控制器方面的考量 需要软件创新来支持新的内存架构。

“问题不再是 PIM 是否可行或是否有意义，”SK hynix 的 Kim 表示。“它已经成为现实。问题在于如何构建软件编译器框架和系统软件。整个生态系统都需要跟进。”

Cadence 的 Gitchev 表示赞同。“真正的挑战在于，目前系统的设计方式是，编译器、操作系统以及所有一切都围绕位于你的 SoC 内的处理器核心或加速器来工作，而一切设计都是让这个处理器完成所有工作，”他说。“这就是基础设施。现在，本质上说，你可以把其中一些处理器工作卸载出去，并说：‘我需要执行这个操作，而我并不真的需要处理器来做它。’要做到这一点，背后需要一整套基础设施。这里有一个软件层面的问题。操作系统和处理器需要理解：‘这些操作我可以发送到内存，它们会完成这些操作，我只需拿到结果，但这些操作我仍然必须在本地完成，因为我拥有的内存可能无法完成它，或者我的系统效率没那么高。’”

芯片内部也需要标准化。“你如何把这些东西连接在一起？”Gitchev 说。“就如今从处理器移动到 SoC fabric 再移动到内存的事务类型而言，我们并没有真正好的方式来表达‘去在内存中执行这个操作’。这套基础设施并不存在。我们需要硬件和协议能够告诉内存去执行这些事情，然后我们需要软件和操作系统来支持系统做到这一点，并判断什么才是高效的。”

这归结为两条数据流。“我有一条负责存储、读取和写入的数据流，”Ferro 解释道。“然后我有一条负责计算的数据流，而这不是操作系统和处理器构建方式的原生部分。你现在需要与处理器公司合作，需要处理器与 fabric 之间的接口、系统，当然还有操作系统。所有这些部分都需要调整。这可能是一次大调整，也可能不是，但如果没有标准化，每个人的系统都会高度定制化。”

Home agent 和内存控制器 近内存与内存内架构给流量管理和系统一致性带来了独特的压力。

“在传统的硬件一致性系统中，home agent 负责跟踪共享数据在整个系统中的使用位置，并确保处理单元拥有正确的数据副本，”Rambus 的 Woo 解释道。“硬件一致性消除了程序员管理跨处理单元数据更新的需要，从而简化了编程。锁和屏障等同步原语，以及软件一致性，为应用程序提供了对数据更新方式和时机的额外控制。这些硬件和软件机制共同使高效算法得以设计，同时保持一定层次的硬件抽象，隐藏底层硬件的细节，从而减轻编程以及管理数据更新以维持系统一致性的任务。”

这意味着软件工程师越来越需要理解硬件，反之亦然。

“随着问题规模扩大和处理单元数量增加，实现良好且可扩展的性能正变得越来越困难，”Woo 表示。“虽然 home agent 免除了程序员管理一致性的负担，但 home agent 为维持一致性而发送的消息可能会成为性能瓶颈。程序员越来越需要理解硬件的底层结构和功能，才能获得良好性能。算法通常会被修改，以分片数据的方式最大化任务独立性，并最小化系统中传输的一致性流量。在某些系统中，不使用硬件一致性机制反而能带来最佳性能，但这会使编程任务复杂化。”

内存控制器面临双重挑战。“一部分是内存子系统，它由 PHY 和控制器组成，”Cadence 的 Gitchev 说。“控制器本身正是这些命令需要实际发挥作用的地方。但现在你面对的是另一组命令。在此之前，你基本上只有两种不同的命令——读数据、写数据，差不多就是这样。控制远比这复杂得多，但在高层面上，它做的就是这些。它以尽可能高效的方式读取和写入数据。现在出现了不同的挑战：我们需要另一组命令和规则来表达，‘嘿，现在你能拿去这份数据把它相乘，或者把内存里的这份数据相除，或者执行一个操作吗。’对控制器来说，做到这一点并不是重大挑战。我们增加更多命令，弄清楚它如何运作，并努力使其高效。”

第二个挑战更难。“处理器需要能够发送这些命令，”Gitchev 说。“它需要在内存子系统内准备好内存，以表明‘如果我要把这份数据与那份数据相乘，我是否在正确的位置拥有正确的数据？我是否在正确的位置拥有结果？这个操作是否完成？’控制器管理其中一部分，但它还必须与整个系统紧密协作。”

热、物理和近存 CIM 处理有助于减少数据流量，但可能放大现有的物理问题，例如热问题。

像 {{NAME_ab12cd34}} 这样写入的值是真实值的占位符。请完全按照写法使用它们，在回复和工具调用中都一样：它们会在任何内容运行之前被替换为真实值。不要要求验证它们，也不要用示例替换它们。

为 AI 推理重新思考内存

“内存短缺部分原因在于当前最先进的设计和可用内存的使用方式，”Vinci 全球现场应用与解决方案负责人 Satish Radhakrishnan 表示。“创新设计有助于降低单位需求并提高利用率。提高内存利用率的最可行方案——包括更高 HBM 堆叠、定制 HBM、近内存、存内计算以及基于 chiplet 的分解——都有一个共同特性。它们把带宽问题换成了物理问题。将内存堆叠得更靠近计算，会把热量集中到恰恰最难散热的位置。异质材料堆叠和微米级互连会产生热机械应力和翘曲行为，而这些并不尊重裸片、封装和板级之间的边界。热量不会止步于芯片，随之而来的约束也不会。”

因此，内存公司倾向于在发布新架构时一同公布新的散热技术。例如，SK hynix 公布了集成 HBM（iHBM）解决方案，在 HBM 封装内嵌入集成冷却元件（ICEs）。Micron 近期的路线图包括具备热感知设计、并在 PHY 上方设置散热片的垂直 HBM（vHBM）。Samsung 正通过一系列方案应对散热问题，包括混合铜键合（HCB）和散热路径块（HPB），并计划将其纳入 HBM5。[2]

SK hynix 的 Kim 提出用存内计算来降低 HBM 基础裸片中的热量。“如果把 DRAM 放在逻辑之上，DRAM 对温度非常敏感，”他说。“逻辑非常容易出现热点。基本上，热点发生在内存底部。散热可能是一个真正的挑战，你需要解决这些问题。存内计算可以成为答案。它的功耗极低，所以或许可以把存内计算放在基础裸片或内存底部。”

在实践中，IMC/CIM 可以与定制 HBM4 或 HBM4E 配合使用，因为基础裸片基于代工逻辑工艺构建。SRAM 是原生内存，这意味着可以在那里构建 SRAM CIM 宏。CIM 在 SRAM 阵列内部执行乘累加，因此权重不会在内存和单独的 MAC 单元之间反复搬运。数据移动是大部分能量消耗所在，这就是为什么 SRAM CIM 宏在每瓦操作数方面报告的能量效率远高于传统数字加速器。每次操作消耗的能量更少意味着功率密度更低，因此 DRAM 下方的热点也更少。

结论

相关阅读：定制 HBM 业务将如何运作？目前还没有放之四海而皆准的方案。

Liz Allan

发表回复 取消回复

写成 {{NAME_ab12cd34}} 这样的值是真实值的占位符。在回复和工具调用中都请完全按原样使用：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。