存储与互连创新：近内存计算(PNM)

CH-18-08-017·约 13 分钟·AI硬件与算力·更新 2026-08-12

想象你经营一家巨型餐厅：大厨炒菜只要几秒钟，但每道菜都得让服务员穿过一百米走廊，去仓库把食材搬回来。客人越催，走廊越挤，厨师再快也没用。AI 硬件今天也卡在同样的地方——计算芯片不是算得不够快，而是数据在“仓库”和“厨房”之间搬得太久、太费电。近内存计算（PNM，Near-Memory Computing）的思路很直接：既然走廊太长，那就在仓库门口摆一张备菜台，把加工动作挪到食材旁边做。如果把 CPU/GPU 看作大厨，DRAM/HBM 就是食材仓库，那么“内存墙”就是那条又长又堵的走廊。PNM 用先进封装技术把计算单元紧贴在存储旁边，让数据少跑腿；HBM 堆叠则像给仓库装上电梯，把更多数据垂直送到备菜台。这篇文章会用“后厨备菜”的故事，带你理解 PNM 的原理、与存内计算的区别，以及它如何帮大模型推理突破带宽瓶颈。

岗位关联

对 AI 从业者来说，理解 PNM 能帮你在选型加速卡、优化推理引擎、评估大模型部署成本时，一眼看穿“算力高但跑不快”背后的带宽瓶颈。

可视化演示
内存墙问题：后厨到仓库的漫长走廊
近存计算原理：在仓库门口摆一张备菜台
与存内计算区别：货架上做饭还是门口备菜
HBM堆叠方案：多层仓库与垂直电梯
大模型推理优化：给千人宴席高效备菜
工程挑战与趋势：让新后厨真正开起来
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

展示传统冯诺依曼架构与PNM近内存计算的数据搬运对比、HBM堆叠中计算单元部署方案及带宽优化效果，交互切换查看近内存计算核心机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

架构对比：传统架构 vs PNM 传统架构数据需经总线往返搬运产生高延迟 PNM将计算单元置于存储器旁减少数据搬运 data_movement = bandwidth x latency 近内存计算缓解内存墙瓶颈

内存墙问题：后厨到仓库的漫长走廊

大型餐厅后厨里，大厨炒菜只花几秒，但每道菜都要派服务员穿过一百米走廊去仓库搬菜。客人催得越急，走廊就越堵，厨师再快也无济于事。AI 硬件里也有同样的“内存墙”：芯片不是不会算，而是长时间在等数据。每次矩阵计算都要从 DRAM 或 HBM 里读取权重和中间结果，数据搬运的耗时和能耗往往比计算本身还高。

在传统冯·诺依曼架构中，处理器与存储器物理分离，中间靠总线搬运数据。AI 模型参数动辄几十亿，每生成一个 token 都要遍历全部权重，数据搬运次数非常多。算力提升的速度远快于访存带宽，于是系统整体性能被“搬数据”卡住。

如果把这条一百米走廊压缩到一米，备菜速度会大幅提升；PNM 要做的正是这件事——让数据不跑远路。

\displaystyle T_{\text{搬运}} = \frac{D_{\text{数据}}}{B_{\text{有效带宽}}}

搬运时间等于要搬的数据量除以通道每秒能搬的字节数。数据越多、通道越窄，等得越久。

$D$ 数据搬运量模型权重、激活值和 KV Cache 等需要进出存储的字节总量。
$D_{\text{数据}} = W_{\text{模型}} + A_{\text{激活}} + C_{\text{KV}}$
$B$ 有效带宽存储接口实际能提供的平均传输速率，单位是字节每秒。
$B_{\text{有效}} = \frac{\text{搬运字节数}}{\text{搬运秒数}}$
$T$ 搬运耗时总数据量除以有效带宽，就是数据移动占据的时间。
$T_{\text{搬运}} = \frac{D_{\text{数据}}}{B_{\text{有效}}}$

近存计算原理：在仓库门口摆一张备菜台

既然走廊太长，不如在仓库门口设一个备菜台。小工把食材从货架上取下，在台子上洗净切好，大厨转身就能取用。这样既不用改造仓库结构，也不需要重写做菜流程，只是把“加工点”挪到离食材更近的地方。

近内存计算采用类似思想：通过 2.5D/3D 先进封装，把逻辑计算单元放置在存储阵列旁边，而不是把存储芯片和计算芯片分开放在主板上。计算单元与 DRAM 之间使用大量短而宽的互连线，单位时间能搬运的数据量变大，单次搬运的物理距离变短。

仓库门口的备菜台不能替代大厨，但它能让大厨少跑路。PNM 的价值不在于让计算更快，而在于让计算不用再等数据。

\displaystyle T_{\text{总}} = T_{\text{计算}} + T_{\text{搬运}}

完成一次操作的总时间由真正计算的耗时和数据搬运耗时相加而成。PNM 不减少计算量，而是大幅压缩后面那一项。

$T$ 总耗时系统完成一次存储访问或运算所花的总时间。
$T_{\text{总}} = T_{\text{计算}} + T_{\text{搬运}}$
$T$ 计算耗时逻辑单元执行加法、乘法等操作的时间，通常较短。
$T_{\text{计算}} = \frac{\text{操作数}}{\text{计算吞吐}}$
$T$ 搬运耗时数据在存储和计算单元之间移动的时间，是内存墙主要来源。
$T_{\text{搬运}} = \frac{D}{B}$

与存内计算区别：货架上做饭还是门口备菜

存内计算（PIM）更像是直接在货架上架起锅灶，在存储单元内部完成运算，连把食材搬下货架都省了；近内存计算则是把备菜台放在仓库门口，食材还是要从货架搬到门口，但距离非常短。两者经常被混淆，其实工程路径完全不同。

PIM 需要在存储阵列里嵌入计算能力，对 DRAM 单元和制造工艺改动较大，做高精度浮点运算受限；PNM 则在存储芯片的逻辑基底或旁边放置成熟的 CMOS 计算逻辑，灵活性更高，也更接近现有芯片制造流程。PNM 不追求“零搬运”，而是追求“少搬远路”。

货架做饭听起来很省事，但会压低菜品种类和火候精度；门口备菜则保留了厨房的灵活性。PNM 之所以更受欢迎，是因为它在“省搬运”和“可落地”之间找到了平衡。

\displaystyle E_{\text{搬运}} \propto N \times d

搬运能耗正比于搬运的数据量乘以搬运距离。距离从 10 厘米降到 1 厘米，能耗就能下降一个量级。

$N$ 数据量需要移动的比特数，单位常用 bit 或 Byte。
$N = \text{总数据量}$
$d$ 搬运距离数据在导线或封装连线上走过的物理长度。
$d = \text{存储到计算单元的互连长度}$
$E \propto N \times d$单位比特的搬运能耗随距离线性增长，距离越短越省电。
$E_{\text{搬运}} = k \times N \times d$

HBM堆叠方案：多层仓库与垂直电梯

HBM 就像一座多层食材仓库，每一层都是 DRAM 存储，楼层之间用垂直电梯连接。这座电梯就是 TSV 硅通孔，它穿透每一层存储芯片，把数据从顶楼直接送到一楼大厅。大厅里的逻辑控制基底，正好可以安放 PNM 的备菜台。

HBM 把多个 DRAM die 垂直堆叠，层间用 TSV 和微凸块互连，底部是逻辑控制 die。越来越多的设计把部分计算单元放到这个逻辑基底上，让 AI 算子在离存储最近的地方完成预计算、数据聚合或 Cache 管理，从而减轻主处理器收到的数据洪流。

电梯修得越多，备菜台生意越好。HBM 堆叠把“仓库楼层”变高，TSV 电梯让“取菜”变快，PNM 再在电梯口接一手，AI 推理的带宽瓶颈就被大大缓解。

\displaystyle B_{\text{HBM}} = B_{\text{TSV}} \times N_{\text{TSV}} \times f_{\text{IO}}

HBM 总带宽约等于每个 TSV 每次传输的比特数、TSV 数量和 IO 频率三者的乘积。通路越多，带宽越宽。

$B_{\text{TSV}}$ 单通道宽度每个 TSV 单次能传的比特数。
$B_{\text{TSV}} = \text{每个TSV的位宽}$
$N_{\text{TSV}}$ 通道数量堆叠结构中硅通孔的个数，数量越大并行度越高。
$N_{\text{TSV}} = \text{有效TSV总数}$
$f_{\text{IO}}$ 传输频率数据在 TSV 上翻转的速度，单位 Hz。
$f_{\text{IO}} = \frac{\text{每秒传输次数}}{N_{\text{TSV}}}$
$B_{\text{HBM}}$ 总带宽三者相乘得到存储堆叠的聚合吞吐能力。
$B_{\text{HBM}} = B_{\text{TSV}} \times N_{\text{TSV}} \times f_{\text{IO}}$

大模型推理优化：给千人宴席高效备菜

大模型推理像一场千人宴席，每上一道菜都要反复取用同几味核心调料。尤其是自回归生成时，新生成的每个 token 都要读取全部模型权重，还要把之前所有对话的 KV Cache 重新读一遍。这些数据经常待在 HBM 里，反复被访问，成为典型的访存密集场景。

PNM 把注意力计算、KV Cache 聚合、中间结果规约等操作放到 HBM 逻辑基底附近执行，减少主 GPU 与存储之间的往返流量。结果就是单 token 生成延迟降低，每秒处理的请求数提升，同时单位请求的能耗下降。

备菜台把最容易堵车的环节提前消化掉，千人宴席才能一桌接一桌上菜。这就是 PNM 在大模型推理中带来吞吐和能效双重提升的原因。

\displaystyle T_{\text{单层}} \geq \max\left(T_{\text{计算}}, \frac{S_{\text{权重}} + S_{\text{KV}}}{B_{\text{有效}}}\right)

一层 Transformer 的实际耗时不可能小于计算时间和数据搬运时间中的较大者。PNM 重点压缩数据搬运那一项。

$T_{\text{计算}}$ 计算时间矩阵乘法和注意力等算子真正执行的时间。
$T_{\text{计算}} = \text{算子计算耗时}$
$S_{\text{权重}}$ 权重字节数当前层模型参数的大小，生成阶段通常要全部读取。
$S_{\text{权重}} = \text{该层参数量} \times \text{精度字节}$
$S_{\text{KV}}$ KV Cache 字节数历史 token 的键值缓存，会随序列长度增长。
$S_{\text{KV}} = 2 \times \text{层数} \times \text{头数} \times \text{头维度} \times \text{序列长度}$
$B_{\text{有效}}$ 有效带宽PNM 高带宽封装下，数据从 HBM 到计算逻辑的实际速率。
$B_{\text{有效}} = \frac{S_{\text{权重}} + S_{\text{KV}}}{T_{\text{搬运}}}$
$\max$ 取较大者总耗时不下于计算和搬运的短板，谁慢卡谁。
$T_{\text{单层}} \geq \max(T_{\text{计算}}, T_{\text{搬运}})$

工程挑战与趋势：让新后厨真正开起来

门口加备菜台听起来简单，真正落地却要面对许多现实问题：备菜台会占用仓库通道，产生更多热量；厨师和传菜员需要学习新流程；不同餐厅的菜单还得重新适配。PNM 同样面临散热、功耗、编程模型和生态工具链的考验。

把计算单元放进 HBM 逻辑基底，会让存储区域的功耗密度上升，散热设计必须同步跟上。软件侧也需要新的编程框架，把算子调度到近存单元上，而不是把所有任务都交给主处理器。未来，PNM 会与 Chiplet、3D 堆叠、统一内存架构结合，逐步形成“算力跟着数据走”的异构计算范式。

新后厨好不好，不能只看备菜台多近，还要看后厨会不会过热、厨师会不会用、菜单能否兼容。PNM 的终极方向不是一种芯片，而是一整套“数据就近计算”的软硬件生态。

\displaystyle U_{\text{有效}} = \frac{T_{\text{计算}}}{T_{\text{计算}} + T_{\text{搬运}} + T_{\text{等待}}}

系统有效利用率等于真正算数的时间占总时间的比例。搬运和等待越少，利用率越高。

$U$ 有效利用率计算单元真正干活的占比，越高说明硬件越不浪费。
$U_{\text{有效}} = \frac{T_{\text{计算}}}{T_{\text{总}}}$
$T_{\text{等待}}$ 等待时间任务排队、同步、存储刷新等不能计算也不能搬运的耗时。
$T_{\text{等待}} = T_{\text{总}} - T_{\text{计算}} - T_{\text{搬运}}$
分母合计总时间由计算、搬运、等待三部分构成。
$T_{\text{总}} = T_{\text{计算}} + T_{\text{搬运}} + T_{\text{等待}}$
比值最大化优化 PNM 的目标就是压低分母中的搬运和等待。
$U_{\text{有效}} = \frac{T_{\text{计算}}}{T_{\text{计算}} + T_{\text{搬运}} + T_{\text{等待}}}$

AI 应用场景

大模型推理加速：KV Cache 就近读取

阶段：模型推理

解决的问题：大模型自回归生成时，KV Cache 随上下文长度快速增长，反复访问 HBM 造成严重带宽瓶颈；传统方案把数据全部搬回 GPU 计算，延迟高且功耗大。

具体案例：某大模型推理服务把注意力计算下沉到 HBM 逻辑基底附近的 PNM 单元，KV Cache 直接就近读取并完成部分 attention 计算，单机吞吐提升约 30%，单 token 延迟明显下降。

云端异构封装：HBM-PNM 加速卡选型

阶段：AI 基础设施部署

解决的问题：数据中心追求单位功耗下的推理吞吐，传统 GPU 受限于 HBM 与计算核心之间的搬运开销；若存储在封装内集成近存逻辑，可降低请求排队时间。

具体案例：云厂商在算力选型时对比普通 HBM 加速卡与 HBM-PNM 加速卡，在长上下文场景下，后者因 KV Cache 访存优化而节省三成以上的数据搬运能耗。

端侧低功耗设备：边缘盒子里的省电备菜台

阶段：边缘部署

解决的问题：机器人、自动驾驶等端侧设备对功耗敏感，频繁搬运传感器中间数据会占用大量电池能量；PNM 让数据在存储旁完成预处理，减少主控芯片的搬运负担。

具体案例：某边缘 AI 盒子在内存旁边集成小型近存运算块，对视频帧做特征压缩后再交给主处理器，整机功耗下降约 20%，端到端时延更稳定。

Python 演示

python25 行

class MemorySystem:    def __init__(self, distance_cm, bandwidth_gbps, energy_pj_per_gb_cm):        self.distance_cm = distance_cm        self.bandwidth_gbps = bandwidth_gbps        self.energy_pj_per_gb_cm = energy_pj_per_gb_cm     def move_time_us(self, data_gb):        return data_gb / self.bandwidth_gbps * 1000.0     def move_energy_pj(self, data_gb):        return data_gb * self.distance_cm * self.energy_pj_per_gb_cm  def layer_data_bytes(param_b, kv_b):    return param_b + kv_b  far = MemorySystem(distance_cm=30, bandwidth_gbps=200, energy_pj_per_gb_cm=5)near = MemorySystem(distance_cm=2, bandwidth_gbps=1600, energy_pj_per_gb_cm=5)data_gb = layer_data_bytes(2e9, 0.5e9) / 1e9 print("远内存搬运用时(us):", round(far.move_time_us(data_gb), 2))print("近内存搬运用时(us):", round(near.move_time_us(data_gb), 2))print("远内存搬运能耗(相对):", far.move_energy_pj(data_gb))print("近内存搬运能耗(相对):", near.move_energy_pj(data_gb))

目的：用简单的搬运模型模拟一层 Transformer 推理时，远内存架构与近内存架构在搬运耗时和能耗上的差异。

class MemorySystem:定义一个包含距离、带宽、单位能耗的存储系统模型。
return data_gb / self.bandwidth_gbps * 1000.0把 GB 除以带宽得到秒，再乘 1000 换算成微秒。
data_gb = layer_data_bytes(2e9, 0.5e9) / 1e9模拟读取 2GB 权重和 0.5GB KV Cache 的总数据量。
near.move_time_us(data_gb)近内存高带宽通道下，同样数据搬得更快。
far.move_energy_pj(data_gb)远距离搬运时能耗更高，体现“短距离省电”的核心逻辑。

常见误区

误区我以为近内存计算和存内计算是一回事，都是在 DRAM cell 里做运算，直接把存储芯片变成计算芯片。

正解PNM 是把计算逻辑放在存储阵列旁边，比如 HBM 的逻辑基底上，数据仍然要从存储单元搬到计算单元，只是距离很短；PIM 才是在存储单元内部完成计算。区别类似于“仓库门口备菜”和“直接在货架上做饭”。

为何常见：两者都能减少数据搬运，名字又相近，初学者很容易把“近内存”理解成“在内存里”。

误区既然数据不用搬远了，PNM 应该能完全解决带宽不足的问题，再也不用担心内存墙。

正解PNM 只是把搬运距离缩短、互连变宽，但带宽仍受 TSV 数量、封装工艺、散热和功耗上限约束。计算速度继续提升后，新的瓶颈还会出现在近存单元与存储之间的传输接口上。

为何常见：人们容易夸大新技术的效果，看到“减少搬运”就以为“没有搬运”。

误区给 GPU 配上最高带宽的 HBM，大模型推理速度就一定成正比提升。

正解推理延迟取决于计算时间和数据搬运时间的较大者。若算子本身是计算密集的，带宽再高也只是“把路修宽但车很少”；只有访存密集的算子才能真正受益，例如长序列下 KV Cache 反复读写。

为何常见：大模型场景中带宽瓶颈非常突出，容易让大家忽略计算或调度同样可能成为短板。

误区既然都是靠近存储，PNM 和 PIM 的加速效果应该差不多，选哪个都行。

正解PNM 使用成熟数字逻辑，适合跑复杂控制和浮点运算，灵活性高；PIM 在存储阵列内计算，带宽潜力更大，但数字精度和算法复杂度受限。两者在实现成本、性能和灵活性上有明显取舍。

为何常见：只看到“减少数据搬家”的共同点，忽略了计算粒度和硬件改造深度的差异。

面试题

Q1. 近内存计算（PNM）首要解决的是什么问题？

单选题 · easy

A.CPU主频太低
B.数据搬运开销大← 正确答案
C.内存容量不足
D.编译器优化差

答案：B。PNM 把计算单元放到存储旁边，主要目的是缩短数据搬运距离、降低搬运耗时和能耗，而不是提升主频、容量或编译器能力。

Q2. “内存墙”的核心表现是什么？

单选题 · easy

A.内存颗粒太小
B.芯片面积太大
C.计算等待数据搬运← 正确答案
D.散热风扇太慢

答案：C。内存墙指计算速度远快于访存速度，处理器经常空转等待数据从存储送过来，就像大厨等服务员搬菜。

Q3. PNM 与存内计算（PIM）的关键区别是什么？

单选题 · mid

A.PNM把计算放在存储内部
B.PIM在存储阵列内计算← 正确答案
C.PIM把存储放在CPU内部
D.PNM完全不需要存储

答案：B。PIM 在存储单元内部直接做运算，PNM 在存储旁边放独立的计算逻辑。选项 A 把 PNM 说成了 PIM，C 和 D 都与两者定义不符。

Q4. 近内存计算中“近”指的是什么？

单选题 · mid

A.计算单元靠近存储阵列封装← 正确答案
B.操作系统靠近内存
C.内存靠近电源管理芯片
D.网络靠近服务器机柜

答案：A。PNM 的“近”是物理位置上的近，通过先进封装让计算逻辑紧贴 HBM 或 DRAM，从而缩短互连距离。

Q5. HBM 堆叠中哪些技术支撑近内存计算？

多选题 · mid

A.TSV硅通孔垂直互连← 正确答案
B.微凸块与先进封装← 正确答案
C.单纯提高动态内存频率
D.增加风扇加大散热

答案：AB。TSV 让各层存储垂直互通，先进封装把近存逻辑与存储集成在一起。单纯提高频率或加风扇不是 HBM 近存方案的核心支撑。

Q6. 大模型推理中，KV Cache 反复读写的瓶颈主要是？

单选题 · hard

A.网络传输延迟
B.磁盘随机读写
C.内存带宽压力← 正确答案
D.功耗墙上限

答案：C。KV Cache 存放在 HBM 中，自回归生成时每个 token 都要反复读取，访存数据量随序列长度增长，主要卡在内存带宽而非网络、磁盘或功耗。

Q7. 近内存计算工程化面临的主要挑战有哪些？

多选题 · hard

A.散热与功耗密度← 正确答案
B.编程与编译模型← 正确答案
C.存储介质完全替代
D.生态工具链适配← 正确答案

答案：ABD。近存逻辑会增加封装内功耗密度；软件需要新编程模型调度近存单元；生态工具链也要同步适配。PNM 并没有完全替代现有存储介质，C 错误。

Q8. 为什么缩短数据搬运距离能降低能耗？

单选题 · mid

A.互连导线电容随之减小← 正确答案
B.内存电压自动下降
C.计算单元不再发热
D.存储层数可以无限增加

答案：A。芯片间互连越长，导线电容越大，充放电耗能越多。PNM 缩短互连距离，本质上是减小了信号传输要驱动的电容负载。

Q9. 传统冯·诺依曼架构中计算与存储分离，导致？

单选题 · easy

A.数据和指令频繁搬运← 正确答案
B.内存不需要刷新
C.缓存完全没必要
D.指令集自动减少

答案：A。冯·诺依曼架构把计算和存储分开，所有数据和指令都要搬进搬出，形成所谓的“访存瓶颈”，这是 PNM 要改善的根本问题。

Q10. 关于 PNM 与大模型推理，下列说法正确的是？

多选题 · hard

A.访存密集算子更受益← 正确答案
B.所有层都能线性加速
C.权重加载更省带宽
D.KV Cache读取更高效← 正确答案

答案：AD。PNM 对 KV Cache 这类访存密集的重复读取更有利，但并非所有计算都能线性加速。权重加载只是等待变少，并不代表“更省带宽”，因此 C 不恰当。