面向 AI 推理的内存架构再思考

要点速览：

• 将计算移至更靠近内存的位置，可以减少数据搬运、功耗和延迟。
• 不同的 AI 工作负载需要不同的内存架构、互连和处理方式。
• 软件支持、标准化和热管理仍是更广泛普及的主要障碍。

从数据中心中的 AI 训练转向边缘侧的 AI 推理，将需要对数据在哪里处理、如何处理、如何划分优先级，以及在功耗和性能之间需要权衡什么才能维持在有限的功耗预算之内，进行根本性的重新思考。

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

挑战在于弄清楚哪些数据需要保留、哪些可以丢弃、哪些需要立即采取行动。这些是非常不同的优先级。做出这些选择需要先进的处理能力，而以最少的能量获得最快结果的路径，就是将数据在处理与内存之间需要移动的距离降到最低。

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

解决这些问题需要若干新方法，例如近存计算（PNM）和存内计算（PIM），以及在多项技术和方法上的改进。编译器和操作系统需要跟上步伐，还需要建立相关标准。

“过去几年，数据中心中的 AI 以及所有这些大语言模型一直是所有人关注的焦点，如今这些模型已经完成训练并被推送到实际应用中，进入了网络边缘和物理 AI 领域，”Ferro 说。“现实是你只有有限的算力和有限的内存。”

边缘侧的 AI 推理所面临的挑战不同于在 AI 数据中心训练 AI 模型。

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

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

Expedera 首席科学家兼联合创始人 Sharad Chole 表示：“把计算推入 DRAM 或靠近 DRAM 会带来有趣的影响。你改变了通信模式——是我的激活值去往内存，而不是内存来找我——这改变所需通信量的大小。这类方案对于小批量解码是可以的。例如，批量大小为 1 且尝试做解码、不需要读取全部权重时还可以；但一旦转向以成本优化为目标的大批量解码，或属于大批量执行的预填充(prefill),激活值的通信就成为挑战。这是看待这个问题的两种方式。归根结底，你必须把执行拆分成若干部分：要么是对存储敏感的(即需要存储多少数据)，要么是对带宽敏感的，要么是对批处理敏感的。”

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

因此，尽管芯片架构师可以让计算在 SoC 上快速运行，但 SoC 仍要等待数据到来。Gitchev 表示：“存内处理在很大程度上解决了这个问题。现在你可以说，‘内存里有这一块数据，去对它做点什么，我只需要去读取结果就行。我会跳过先读取、再计算、再写回的整个流程。我只需要做一次读取，这就够了。’”

左滑查看全部列 →

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

减少数据搬运
归根结底，需要优化整个系统才能让这一方案奏效。

“问题的框架已经从‘我们需要更多内存’，转变为‘我们需要能在不饿死其他流量的前提下持续为内存供数的互连架构’，”Baya Systems 首席商务官 Nandan Nayampally 说。“而最近则变成了‘如何围绕稀缺性本身进行架构设计’。”

其他人对此表示赞同。“AI 系统越来越多地受到在计算、内存、加速器、芯粒和裸片之间高效移动数据能力的限制，”Arteris 产品管理与营销副总裁 Andy Nightingale 说。“这使得互连和内存架构与内存器件本身同等重要。这也强化了对可扩展 NoC、芯粒、缓存一致性以及系统映射技术的需求，帮助客户在流片前优化数据搬运。”

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

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

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

多年的进程
其中一些所需的技术如今已经可用。另一些则需要数年时间开发，或需要改进到足以产生实际影响的程度。

Ayar Labs 产品管理总监 Vishal Chandrasekar 表示：“我们预计三到五年内，也许到 2030 年左右，会看到内存内应用。你希望能够连接大量 GPU，让不同的 GPU 能够访问彼此的内存。人们正在尝试提高每颗 GPU 的内存容量，但会受到数据包大小和 HBM 带宽等因素的限制。内存内计算是一条路径，它使内存的基底的某些计算能力成为可能。”

不过，这项技术还没到商业化的程度。Cadence 的 Ferro 说：“说它已经出现在市场上有点激进。可能有一些非常特定的嵌入式应用正在使用某种内存内处理，但作为一种广泛的应用，它仍处于早期阶段。”

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

Keysight 内存解决方案项目经理 Randy White 说：“LPDDR-PIM 是 JEDEC 内最受关注的技术。围绕 LPDDR-PIM 有积极的开发和讨论，但硬件和软件都面临挑战。从硬件的角度看，你要把逻辑工艺与 DRAM 工艺混合在一起，而两者的优化指标不同，这种创新本身就使制造过程更加复杂和昂贵。你必须非常有选择性地评估，确保你的应用能够承受增加的成本。”LPDDR6-PIM 的应用范围将涵盖为性能优化的固定节点边缘服务器，以及为能效优化的手机和平板电脑。

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

PIM 架构需要从其对系统其余部分的影响来考虑。White 说：“硬件必须经过设计和优化，使你拥有合适数量的计算系数之类的东西。然后内存必须以某种方式进行分隔，分辨率不能太细，从而在分隔的粗细之间取得恰当的权衡。”

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

此外，内存编程模型仍处于不断变化之中，尤其是随着 PIM、CIM、CXL 连接的分层内存以及异构内存架构等非传统内存系统的兴起。

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

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

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

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

此外，芯片内部还需要标准化。“你如何把这些东西连接起来？”Gitchev 说，“就从事务类型的角度而言——从处理器到 SoC 互连再到内存的事务——今天我们还没有一个很好的方式可以说‘去在内存里执行这个操作’。这样的基础设施并不存在。我们需要硬件和协议能够指示内存去完成这些工作，然后还需要软件和操作系统支持整个系统来实现这一点，并判断什么是高效的。”

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

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

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

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

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

内存控制器面临双重挑战。“一部分是内存子系统，它由一个 PHY 和一个控制器组成，”Cadence 的 Gitchev 说。“控制器本身正是这些命令需要真正执行工作的地方。但现在你面对的是一套不同的命令。在此之前，从根本上说只有两种不同的命令——读数据和写数据，基本如此。控制实际上比这复杂得多，但从高层来看，它就是这么做的：以尽可能高效的方式读取和写入数据。现在一个新的挑战出现了，我们需要一套不同的命令和规则来说，‘嘿，现在你能不能取这份数据做乘法，或者对内存内的这份数据做除法，或执行某个运算。’对控制器来说做到这一点并不是什么重大挑战。我们添加更多命令，然后弄清楚它如何运作，并努力使其高效。”

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

热学、物理与 CIM
在内存附近进行处理有助于减少数据流量，但它可能放大现有的物理问题，例如热问题。

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

因此，内存公司往往在发布新架构的同时宣布新的散热技术。例如，SK hynix 宣布了一种集成式 HBM（iHBM）方案，在 HBM 封装内嵌入集成冷却元件（ICE）。Micron 最近的路线图包含了采用热感知设计和 PHY 上方散热片的垂直 HBM（vHBM）。三星则通过一系列方案应对发热问题，包括混合铜键合（HCB）和热通路块（HPB），并计划将其纳入 HBM5。[2]

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

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

结语
软件支持仍然是近存计算硬件与其对 AI 的承诺之间缺失的一环。对于编译器和 AI 框架而言，近存处理和存内计算架构是新兴的目标平台，可以让开发者将数学运算符直接下放到内存子系统，但支持这一转变所需的软件仍在追赶。

可用的计算能力——以及对其的限制——因架构而异。LPDDR6-PIM 仅限于 MAC 单元或适合矩阵-向量乘法和逐元素运算的简单 ALU。定制 HBM4/HBM4E 逻辑工艺基底裸片可以添加其他内存控制功能。但这种灵活性伴随着散热上限——能容纳多少计算取决于它给 DRAM 下方增加的热量。

“过去两年里，我们花了大量时间讨论定制 HBM 以及如何使用那个基底层，”Cadence 的 Ferro 指出。

AI 正在推动将计算拉近内存的进程，但仅靠物理接近本身并不能带来收益。更广泛的采用取决于将工作负载与硬件相匹配、管理热量，以及为编译器和操作系统提供决定卸载内容的工具。移动计算只是解决方案的一部分；让系统高效地使用它才是下一个考验。

参考资料

1. DAC 2026 研究专题分会：“近内存处理正在成为现实”（SK hynix）
2. 散热设计成为下一代 AI 内存的战场（Korea Times）

相关阅读
定制 HBM 业务将如何运作？
目前还没有一刀切的方案。