清晨六点，面点铺的老王开始了一天的劳作。他的规矩几十年没变：食材存在后院冰窖（内存），操作台在铺子前厅（CPU），中间隔着一条长长的胡同（总线）。每做一屉包子，他就要穿过胡同去取一次面粉，再端着面粉跑回来揉面。一笼包子蒸下来，老王磨破了三双鞋，真正揉面的功夫却不到一半——大部分时间，都耗在了“路上”。 后来，儿子小王接手铺子，干了一件离经叛道的事：他直接在冰窖门口支了张案板，把面团、擀面杖、蒸笼全挪了过去。面粉不用再长途跋涉，老王（现在是顾问）笑称：“你这不是把厨房搬进冰箱了吗？”小王嘿嘿一笑：“爸，这叫近存储计算——哪儿的食材最多，我就在哪儿开火。” 这个故事，就是近数据计算家族中“近存储计算”（Near-Storage Computing）的全部秘密：与其让数据千里迢迢跑去问计算单元，不如让计算单元住到数据家门口。在AI模型动辄几十GB参数、训练数据以TB计量的今天，数据搬运的能耗和延迟早已超过计算本身——“存储墙”成了压在大模型头上的一座大山。近存储计算，正是绕开这座山的迂回隧道。

岗位关联

掌握近存储计算的核心思想与工程权衡，是AI系统优化工程师、芯片架构师理解下一代算力基础设施的必修课——当你的AI应用被内存带宽卡住时，你知道该往哪儿动刀。

目录
  1. 可视化演示
  2. 存储墙危机
  3. 3D堆叠架构
  4. 逻辑层设计
  5. 数据流调度
  6. 推理加速实测
  7. 能效提升解析
  8. 近存对比存内
  9. 部署效果验证
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示近存储计算核心：3D堆叠HBM中TSV垂直互连与逻辑层PE阵列、数据流调度与本地复用率提升、近存计算与传统架构及存内计算的能效对比。

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

3D堆叠HBM近存计算架构 HBM通过TSV将多层DRAM die与底部逻辑层垂直互连，逻辑层部署PE计算单元 TSV聚合带宽达数百GB/s，大幅缩短数据搬运路径 BW_TSV = N × bw_per_TSV, latency ∝ 1/distance 3D堆叠架构实现高带宽低延迟近存计算

存储墙危机

老王的铺子有个致命缺陷：冰窖离前厅太远。每次取面粉，老王都要穿过一条二十米的胡同，来回就是四十米。做一笼包子要取十次料，光走路就走了四百米。老王算了一笔账：他一天走了三十公里，其中二十五公里是纯走路，只有五公里是真在揉面。这就是“存储墙”——数据搬运的距离，已经远远超过了计算本身的工作量。

在计算机体系结构的世界里，这个“胡同”叫存储带宽。CPU的运算速度每年都在提升，但内存的访问速度却跟不上，两者的差距越拉越大。当CPU等待数据时，它只能空转——就像老王站在案板前，面粉还没送到，手再巧也只能干等着。更糟的是，搬运数据本身要消耗能量：走一趟胡同要喘三口气，取一次数据要烧掉比一次加法运算多几百倍的能耗。

这个问题的根源，是计算和存储在物理上的分离。传统计算机中，CPU和内存是两块独立的芯片，中间通过主板上的总线相连。总线既窄又慢，数据一次只能传一点点，还要排队。当AI模型需要处理海量参数时，这个“胡同”就成了整条流水线上最窄的瓶颈。摩尔定律还在生效时，计算速度可以靠堆晶体管来解决；但当晶体管密度逼近物理极限，“存算分离”这座墙就越来越不可逾越了。

存储墙危机，本质上是物理距离引发的效率灾难。就像老王终于意识到，与其每天来回跑胡同，不如直接把案板搬到冰窖门口——近存储计算的第一性原则，就是让计算追上数据，而不是让数据追赶计算。

存储墙占比=数据搬运时间计算时间+数据搬运时间≈80%∼90%\text{存储墙占比}=\frac{\text{数据搬运时间}}{\text{计算时间}+\text{数据搬运时间}} \approx 80\%\sim 90\%
这个公式告诉我们：在一次典型的大数据计算中，高达80%到90%的时间都花在了“走路”上，真正干活的“揉面”时间微乎其微。
  1. 数据搬运时间指数据从存储介质传输到计算单元所耗费的时钟周期，包含访存延迟与总线传输时间两部分。
    数据搬运时间=访存延迟+总线传输时间\text{数据搬运时间}=\text{访存延迟}+\text{总线传输时间}
  2. 计算时间指计算单元执行算术逻辑运算本身的耗时，在AI推理场景下通常仅为搬运时间的十分之一。
    计算时间=运算量计算吞吐率\text{计算时间}=\frac{\text{运算量}}{\text{计算吞吐率}}
  3. 占比公式将搬运时间除以总时间，得到存储墙的严重程度，数值越接近100%，说明系统越“闲不住脚”。
    存储墙占比=数据搬运时间总时间×100%\text{存储墙占比}=\frac{\text{数据搬运时间}}{\text{总时间}}\times 100\%

3D堆叠架构

小王改造铺子的第一步，不是买新案板，而是重新设计厨房的“楼层结构”。他把原本平铺的冰窖改造成了一栋三层小楼：一楼是操作间（放案板和厨具），二楼三楼是冷藏室（放食材）。楼道里装了电梯（垂直通道），面粉从三楼到一楼，只需几秒钟，而不是走胡同的几分钟。这就是3D堆叠存储的核心思路——把水平的“胡同”结构，改造成垂直的“电梯”结构。

在芯片制造中，这种“小楼”就是3D堆叠架构：多层DRAM存储晶圆垂直堆叠在一起，每一层存储之间用硅通孔（Through-Silicon Via，简称TSV）连接。硅通孔是穿过硅片的垂直导线，相当于小楼里的电梯井——它让信号不再需要水平绕过整块芯片，而是垂直向上穿透几十微米的距离，就能到达目的地。

3D堆叠最巧妙的设计，是把逻辑层（也就是“操作间”）放在整个堆叠的底层。为什么是底层？因为底层离外部接口（比如主板上的控制器）最近，信号进出最方便；同时底层也是散热条件最好的位置，计算单元产生的热量可以更快传导出去。上层的存储层则像仓库，安静地码放着数据，等待底层的“厨师”随时取用。每一层存储之间以及存储层与逻辑层之间，通过密密麻麻的硅通孔相连——一根根细如发丝的铜柱，构成了上万条并行数据通道。

有了垂直架构，小王的“小楼”落成了。但仅仅把案板搬到楼下还不够——他还需要设计一套适合在这个小楼里工作的“厨房动线”。3D堆叠只是骨架，逻辑层的设计才是灵魂。

B3D=NTSV×fTSV×WbitTcycleB_{\text{3D}}=\frac{N_{\text{TSV}}\times f_{\text{TSV}}\times W_{\text{bit}}}{T_{\text{cycle}}}
3D堆叠的带宽等于硅通孔数量、单孔频率、位宽的乘积除以时钟周期。由于硅通孔可以做得非常密集，总带宽往往比传统平面总线高出数倍乃至一个数量级。
  1. 硅通孔数量3D芯片中贯穿硅片的垂直导线总数，决定并行通道的数量，通常以万为单位计数。
    NTSV=垂直导线总数N_{\text{TSV}}=\text{垂直导线总数}
  2. 单孔频率每个硅通孔每秒能够传输信号的次数，受材料电阻和寄生电容影响。
    fTSV=1RC寄生f_{\text{TSV}}=\frac{1}{RC_{\text{寄生}}}
  3. 位宽每个硅通孔单次传输的比特数，典型值为1比特，但聚合后可形成宽总线。
    Wbit=单孔位宽W_{\text{bit}}=\text{单孔位宽}
  4. 总带宽三者的乘积除以时钟周期，得到每秒可传输的总比特数，即3D架构的有效带宽。
    B3D=NTSV×fTSV×WbitTcycleB_{\text{3D}}=\frac{N_{\text{TSV}}\times f_{\text{TSV}}\times W_{\text{bit}}}{T_{\text{cycle}}}

逻辑层设计

小王的“小楼”盖好了，但他很快发现一个新问题：楼下操作间太小，放不下前厅那套复杂的大型厨具（传统CPU核心）。于是他换了一批小巧的专用工具——不求样样精通，只求把“揉面”“擀皮”“包馅”这三招练到极致。逻辑层的设计哲学，就是用大量小而专的处理单元，替代少量大而全的通用核心。

传统CPU设计讲究“通用”，什么活都能干，但代价是电路复杂、体积庞大。近存储计算的逻辑层反其道而行之：只放那些最常用、最耗时的操作——比如矩阵乘法、向量加法、数据过滤——将这些操作用专用的硬件加速器实现。这些加速器不执行复杂的控制逻辑，而是像流水线上的工人一样，只负责一个动作，把动作做到极致快。

逻辑层的设计还体现在数据通路的“短”和“宽”上。在传统架构中，数据从内存到CPU要经过内存控制器、系统总线、缓存层级，路径长且窄。而在3D堆叠的近存架构中，逻辑层直接通过硅通孔连接存储层，数据通路是垂直的、短的、并行的——成千上万条数据通道同时工作，一次可以搬走一整层的数据，不再需要“挤牙膏式”地排队传输。为了让软件开发者方便使用这些加速器，逻辑层还会提供一套“近存算子库”——就像给小工们写的标准操作手册，把“怎么揉面”“怎么擀皮”的细节封装好，上层应用只要调用接口就行。

逻辑层的设计，让近存储计算真正“活”了起来。但有了好工具还不够，还要有聪明的调度——就像小王不仅要给小工配好工具，还要决定“先揉哪团面，后蒸哪笼包子”。数据流调度，就是近存储系统的大脑。

T近存=T计算+T传输近存≈T计算+DWTSV×NT_{\text{近存}}=T_{\text{计算}}+T_{\text{传输近存}}\approx T_{\text{计算}}+\frac{D}{W_{\text{TSV}}\times N}
近存计算的总耗时约等于计算时间加上极短的垂直传输时间。因为硅通孔的并行宽度N很大，传输时间D除以总带宽后被压缩到极小的数值。
  1. 计算时间专用加速器执行特定运算所需的时间，由于硬件针对算子优化，通常远小于通用核心。
    T计算=运算量加速器吞吐T_{\text{计算}}=\frac{\text{运算量}}{\text{加速器吞吐}}
  2. 近存传输距离数据从存储单元到逻辑层加速器的物理距离，在3D堆叠中仅为一层硅片的厚度。
    D≈50μm∼100μmD\approx 50\mu m\sim 100\mu m
  3. 并行传输宽度硅通孔阵列同时传输数据的通道数量，决定了近存传输的实际带宽。
    WTSV×N=总并行位宽W_{\text{TSV}}\times N=\text{总并行位宽}
  4. 总耗时计算时间加上极短的传输时间，两者近乎相等，意味着数据搬运的延迟几乎可以被忽略。
    T近存=T计算+DWTSV×NT_{\text{近存}}=T_{\text{计算}}+\frac{D}{W_{\text{TSV}}\times N}

数据流调度

周末早晨，铺子迎来早高峰，点单像雪片一样飞来。小王站在小楼中央，手里攥着一叠订单，开始排兵布阵：猪肉馅的面团放在二楼，就让二楼的小工就地处理；豆沙馅的在一楼，就让一楼的小工先开工。整个上午，没有一个面粉袋子需要跨楼层搬运，所有小工都在“原地开火”。数据流调度的核心思想，就是让每个计算任务尽量在数据所在的存储层附近完成。

在一个近存储计算系统中，数据分布在不同的存储层中。如果调度器把需要读取某层数据的任务分配给远离该层的计算单元，数据就不得不跨层传输——这是最消耗能量的操作。优秀的调度器会像小王一样“智能感知”：它首先要分析任务的数据访问模式，判断哪些数据是热点、哪些是冷数据；然后为每个任务匹配最近的计算单元；最后还要考虑负载均衡，避免某一个计算单元忙死、其他单元闲死。

调度器的目标是实现数据传输的最小化。这个过程可以形式化为一个优化问题：给定一组计算任务和它们的数据依赖关系，找到一种任务到计算单元的映射方式，使得总数据传输量最小。调度算法需要考虑存储堆叠的层级结构、硅通孔的带宽限制、计算单元的利用率等因素。一个精心设计的数据流调度器，能够让数据在最近的地方被消费，让整个系统像一支训练有素的厨房团队——每个人都在处理手边的食材，没有人需要在楼道里跑来跑去。

调度讲究“就地取材”，但当任务真的跑到数据家门口去算，实际效果到底怎么样？小王决定做个对比实验：同一批订单，一天用老办法（前厅操作），一天用新办法（冰窖门口操作），看看到底能快多少。推理加速的实测数据，马上见分晓。

min⁡∑i=1Ntask∑j=1Nlayerxij×dij×Vi\min \sum_{i=1}^{N_{\text{task}}} \sum_{j=1}^{N_{\text{layer}}} x_{ij}\times d_{ij}\times V_i
这个公式是调度器的目标函数：找到一种分配方案x，让所有任务的数据搬运总量（任务数据量V乘以搬运距离d）最小化。
  1. 任务分配变量x_ij取值为1表示任务i被分配到存储层j的计算单元执行，为0则不分配。
    xij∈{0,1}x_{ij}\in\{0,1\}
  2. 搬运距离d_ij表示任务i所需数据位于存储层j时，数据到该层计算单元的物理距离，在3D架构中通常极小。
    dij=数据与计算单元的层间距离d_{ij}=\text{数据与计算单元的层间距离}
  3. 任务数据量V_i表示任务i需要读取的数据总量，数据量越大，搬运成本越高。
    Vi=任务i的数据量V_i=\text{任务i的数据量}
  4. 最小化目标对所有任务的搬运量加权求和并取最小值，即调度器要寻找的最优解。
    min⁡∑i=1Ntask∑j=1Nlayerxij×dij×Vi\min \sum_{i=1}^{N_{\text{task}}}\sum_{j=1}^{N_{\text{layer}}}x_{ij}\times d_{ij}\times V_i

推理加速实测

小王在铺子里贴了一张告示：“新老工艺对比，欢迎围观。”他准备了两百个一模一样的订单，每单要做二十笼包子。第一天，他请老王用传统方式在前厅做；第二天，他用自己的近存储方案在小楼里做。两天下来，结果让老王目瞪口呆：同样的订单，新方案只用了一半时间——不是因为小工手更快，而是因为面粉再也不用“走胡同”了。在AI推理场景中，近存储计算的提速逻辑与此完全一致。

AI模型推理的典型特征是“权重主导”：模型参数（权重）占据了绝大部分数据量。以一个大语言模型为例，参数量动辄数十亿甚至数千亿，模型文件大小达数GB。在每次推理中，模型权重都需要从存储中读出，与输入数据做矩阵乘法。在传统架构中，这些权重数据必须全部从内存搬到计算核心——一次推理就要搬几GB数据，而推理一次往往只需要几毫秒的计算。数据搬运的时间，成了推理延迟的绝对主力。

近存储计算把聚合运算（如矩阵乘法）下推到存储层执行。模型权重存储在哪个存储层，矩阵乘法的累加器就放在哪个层的逻辑单元中。输入数据只需要传输一次（从主机进入），权重则始终“留在原地”参与计算。实测数据显示，在推荐系统、图像识别、自然语言处理等典型AI推理任务中，近存储计算可以将端到端推理时间减少40%到71%，访存延迟降低约一个数量级。特别是对于直接受益于内存带宽的“内存受限型”模型——参数大、计算密度低——提升幅度更为显著。

实测证明了“在数据家门口算”的威力。但老王还有最后一个质疑：“快是快了，电费是不是也翻倍了？”小王笑而不语，递给他一张电费单——能效提升的秘密，藏在那份账单里。

S加速=T传统T近存=T搬运+T计算T搬运近存+T计算S_{\text{加速}}=\frac{T_{\text{传统}}}{T_{\text{近存}}}=\frac{T_{\text{搬运}}+T_{\text{计算}}}{T_{\text{搬运近存}}+T_{\text{计算}}}
S代表加速比：传统架构总耗时除以近存架构总耗时。当近存架构中的搬运时间T_搬运近存趋于零时，加速比趋近于一个大于1的数值。
  1. 传统总耗时数据从内存搬到CPU的时间加上CPU计算的时间，搬运占据大头。
    T传统=T搬运+T计算T_{\text{传统}}=T_{\text{搬运}}+T_{\text{计算}}
  2. 近存总耗时数据只走极小垂直距离的搬运时间加上计算时间，搬运可忽略。
    T近存=T搬运近存+T计算T_{\text{近存}}=T_{\text{搬运近存}}+T_{\text{计算}}
  3. 加速比两者的比值，由于近存搬运时间小得多，比值大于1，即为加速效果。
    S加速=T搬运+T计算T搬运近存+T计算>1S_{\text{加速}}=\frac{T_{\text{搬运}}+T_{\text{计算}}}{T_{\text{搬运近存}}+T_{\text{计算}}}>1

能效提升解析

老王盯着电费单，反复确认了好几次：从每月三千降到一千五，居然还省了一半！他问小王：“你那些小工，工具更多、干活更快，怎么电费反而少了？”小王指着自己的脚说：“爸，以前你是整个铺子走得最远的人——电费的大头，全烧在你的鞋底上了。”在计算机系统中，数据搬运的能耗，就是那双被磨破的鞋。

芯片领域有一个经验法则：一次从DRAM读取32位数据的能耗，是执行一次32位加法运算能耗的约200倍。这意味着，当你的算法在做“低强度计算”（比如简单的累加）时，能耗几乎全部消耗在数据往返的路上，而不是计算本身。近存储计算之所以省电，就是因为它把那条能耗最高的路给“拆”了——数据不再一路奔波到CPU，而是原地等待附近的计算单元处理，搬运的物理距离缩短了几个数量级。

科学界用“能耗-距离乘积”来描述这个现象：传输能耗与传输距离成正比。在3D堆叠的近存架构中，数据从存储到逻辑层的垂直距离只有几十微米，而传统架构中从内存芯片到CPU的水平距离则达到数厘米。这两个距离差了三个数量级，能耗自然也随之锐减。实测数据显示，近存储计算在典型AI推理任务上的能效比（每瓦特每秒可执行的运算次数）可以提升2到5倍。与此同时，由于高能耗的数据搬运减少了，整个系统的发热也大大缓解——散热压力减轻，风扇可以慢下来，数据中心的PUE（能源利用效率）也随之改善。

电费单上的数字，让老王彻底服气了。但他又想到一个问题：“你这种'把厨房搬进冰箱'的思路，跟隔壁镇流行的'存内计算'是不是一回事？”小王摇摇头，开始给父亲讲起两种“就近原则”的微妙区别。

E总=E搬运+E计算=α×D×V+E计算E_{\text{总}}=E_{\text{搬运}}+E_{\text{计算}}=\alpha\times D\times V+E_{\text{计算}}
总能耗等于搬运能耗加计算能耗。搬运能耗等于单位距离单位数据的能耗系数α，乘以搬运距离D和搬运数据量V。近存储计算的关键，就是把D从厘米级降到微米级。
  1. 搬运能耗系数α是每单位数据移动单位距离所消耗的能量，与材料、线宽、频率相关。
    α=单位距离单位数据能耗\alpha=\text{单位距离单位数据能耗}
  2. 搬运距离D是数据从存储到计算单元的物理距离，传统架构为几厘米，近存架构为几十微米。
    D传统≫D近存D_{\text{传统}}\gg D_{\text{近存}}
  3. 搬运数据量V是一次任务中需要搬运的数据总量，模型权重越大，V越大。
    V=数据量V=\text{数据量}
  4. 总能耗构成计算能耗相对固定，搬运能耗随距离缩短而大幅压缩，总能耗随之下降。
    E总=α×D×V+E计算E_{\text{总}}=\alpha\times D\times V+E_{\text{计算}}

近存对比存内

隔壁镇也有一家面点铺，老板走的是另一条路：他不把案板搬到冰窖门口，而是直接在面粉袋里嵌入微型面团搅拌器——面粉在袋子里就能发酵，根本不用倒出来。这听起来更彻底，但问题也随之而来：每袋面粉都要特制，工艺复杂，而且一旦面粉升级换代，搅拌器可能就报废了。这就是存内计算（Computing-in-Memory）与近存储计算的本质差异：一个把计算融入存储介质内部，一个把计算放在存储旁边。

两个方案都遵循“数据不远行”的原则，但实现力度与取舍各不相同。存内计算将计算单元直接嵌入存储阵列中，利用存储单元的物理特性（如模拟电流累加）直接完成计算。它的优势是数据搬运距离几乎为零（零距离），理论上能达到最高的能效比和带宽——但代价是：存储单元必须为计算重新设计，难以复用成熟的DRAM/NAND工艺，良率和可靠性面临挑战，且只能实现有限的算子类型（如乘加操作），通用性不足。

近存储计算则保守得多：它保持存储介质不变（仍用成熟的DRAM或NAND），只是在存储芯片的同一个封装或堆叠中，额外集成独立的逻辑层。这样既获得了大部分“数据就近处理”的收益，又避免了对存储工艺的伤筋动骨。两者的适用场景也因此分工明确：存内计算适合那些算子固定、追求极致能效的场景（如边缘端的神经网络推理芯片）；近存储计算则适合数据规模巨大、需要灵活编程的系统（如数据库分析、大规模推荐系统、AI大模型推理）。

思路理清了，方案也论证得头头是道。但老王知道，纸上的道理再漂亮，端上桌的包子才算数。小王的“近存储厨房”到底能不能在真实营业中扛住客流高峰？下一步，是验证部署效果的时刻。

C总成本=C存储工艺+C逻辑工艺+C集成C_{\text{总成本}}=C_{\text{存储工艺}}+C_{\text{逻辑工艺}}+C_{\text{集成}}
存内计算的总成本主要在存储工艺改造，近存储计算的总成本在逻辑与存储的异质集成。两者孰优孰劣，取决于应用场景更看重计算效率还是研发投入。
  1. 存储工艺成本制造存储单元本身的成本，近存储计算使用成熟工艺，存内计算需要定制存储阵列。
    C存储工艺=存储晶圆制造成本C_{\text{存储工艺}}=\text{存储晶圆制造成本}
  2. 逻辑工艺成本制造计算单元的成本，近存储计算需要额外制造逻辑层，存内计算则将计算融入存储。
    C逻辑工艺=逻辑晶圆制造成本C_{\text{逻辑工艺}}=\text{逻辑晶圆制造成本}
  3. 集成成本将存储与逻辑封装的成本，3D堆叠需要硅通孔工艺，存内计算则是一体化制造。
    C集成=封装与互联成本C_{\text{集成}}=\text{封装与互联成本}
  4. 总成本三者的和，近存储与存内在成本构成上各有侧重，应用选型需综合考虑。
    C总成本=C存储工艺+C逻辑工艺+C集成C_{\text{总成本}}=C_{\text{存储工艺}}+C_{\text{逻辑工艺}}+C_{\text{集成}}

部署效果验证

小王没有急着全面改造，而是先在铺子里做了一周的“试营业”：小楼厨房开足马力，但前台系统仍然保留老设备作为备份。第一天中午，客流高峰涌进来，小楼厨房面前排起长队，但每一单的出餐时间都稳定达标；晚间统计时，有一笼包子火候稍欠——查明原因，是小工对一种新馅料的处理不熟练，需要微调算子库的参数。工程化的路上，没有一次到位的完美，只有反复迭代的打磨。

近存储计算从学术概念走到实际部署，同样经历了这样的“试营业”阶段。在实验室中，研究人员搭建了搭载近存储计算引擎的原型系统：一块3D堆叠存储芯片，底层集成逻辑层，配套定制驱动和算子库。测试负载选用了真实业务场景——点击率预估、图像分类、大规模向量检索——而不是理想化的微基准测试。真实的负载带来了真实的约束：数据的访问模式不规则、多个任务并发执行、数据类型多样。在这些条件下，原型系统交出了令人信服的答卷：延迟降低、吞吐提升、能耗下降，与前文的实测数据吻合。

但部署也暴露出了工程化挑战：第一，软件生态不成熟——要让现有AI框架（如PyTorch、TensorFlow）自动把算子卸载到近存储引擎，需要开发编译器插件和运行时调度器；第二，热管理问题——逻辑层密集计算时，局部温度升高会影响存储单元的刷新特性；第三，成本控制——3D堆叠硅通孔工艺的良率仍低于成熟的平面芯片。这些挑战决定了近存储计算在短期内更可能率先落地于高端数据中心和专用加速场景，然后随着工艺成熟逐步向更多领域渗透。

小王的“试营业”交出了亮眼的成绩单，铺子的生意也蒸蒸日上。父亲老王坐在店里，看着小楼里忙碌的小工们，感慨万千：“我走了一辈子的胡同，你倒好，直接让厨房住进了食材的家。”近存储计算的故事，正是这样一场关于“距离”的产业革命——当数据不能走向计算，就让计算走向数据。

R部署=实际性能提升理论性能提升×总拥有成本降低预期成本降低R_{\text{部署}}=\frac{\text{实际性能提升}}{\text{理论性能提升}}\times \frac{\text{总拥有成本降低}}{\text{预期成本降低}}
部署效果不是单一指标，而是性能提升与成本降低的综合比。当这个比值大于1时，说明方案在真实环境中不仅达标，还超出了预期。
  1. 实际性能提升原型系统在真实负载下测得的延迟/吞吐改善幅度，通常略低于理想值。
    实际性能提升=T传统T近存，真实负载\text{实际性能提升}=\frac{T_{\text{传统}}}{T_{\text{近存，真实负载}}}
  2. 理论性能提升在理想条件（无调度开销、无热损失）下的最大性能增益，作为基准参照。
    理论性能提升=T传统T近存，理想\text{理论性能提升}=\frac{T_{\text{传统}}}{T_{\text{近存，理想}}}
  3. 成本降低比总拥有成本（硬件+软件+维护）的实际降低幅度与预期值的比值。
    成本降低比=实际TCO缩减预期TCO缩减\text{成本降低比}=\frac{\text{实际TCO缩减}}{\text{预期TCO缩减}}
  4. 部署效果指数性能比乘以成本比的乘积，综合衡量方案在真实部署中的成色。
    R部署=性能比×成本比R_{\text{部署}}=\text{性能比}\times\text{成本比}

AI 应用场景

大模型推理服务加速

阶段：推理部署与性能优化

解决的问题：大语言模型每次推理需要读取数GB的权重参数，传统架构中这些参数在内存与GPU之间不断搬运，导致推理延迟高、吞吐受限、GPU利用率低。近存储计算在存储旁放置矩阵运算单元，权重数据不再反复搬运。

具体案例：某云服务商在推荐系统推理集群中采用3D堆叠近存储方案后，实测端到端推理延迟降低50%，单机吞吐提升2.2倍，单位请求能耗下降60%。关键的embedding查询和注意力计算被卸载到近存引擎，CPU/GPU得以腾出算力处理更复杂的逻辑。

数据库分析引擎加速

阶段：数据预处理与查询执行

解决的问题：数据分析查询需要扫描海量的行/列数据（如表扫描、聚合、过滤），传统架构中数据从存储到CPU的传输远超计算时间。近存储计算将谓词下推（filter pushdown）和聚合操作下推到存储层，只向上层返回精简结果。

具体案例：某金融风控系统引入近存储计算卸载方案后，大规模客户信用评估的批量查询耗时从小时级降至分钟级，因为90%的无效数据在存储侧就被过滤掉了，无需上传。数据分析师提交即席查询的平均等待时间减少了85%。

边缘AI视觉推理

阶段：模型压缩与边缘部署

解决的问题：边缘设备（摄像头、自动驾驶终端）对功耗和响应时间极为敏感，传统方案要么把数据上传云端（延迟高），要么在端侧部署大算力芯片（功耗高）。近存储计算以极低的功耗实现数据原位处理。

具体案例：某智慧城市项目在道路监控摄像头中采用近存储视觉推理方案，在5W功耗预算内实现了实时车辆识别，图像数据在传感器邻近的存储层完成预处理与初步分类，只有关键的异常事件才上传云端，带宽成本降低90%。

Python 演示

python101 行
import randomfrom dataclasses import dataclass, field @dataclassclass DataBlock:    data_id: int    size: int    layer: int  # 数据所在存储层编号 @dataclassclass ComputeUnit:    unit_id: int    layer: int  # 计算单元所在层编号    load: float = 0.0  # 当前负载 @dataclassclass Task:    task_id: int    need: int  # 需要处理的数据块编号    compute_cost: float = 1.0  # 计算时间 class NearStorageScheduler:    def __init__(self, num_layers=4, seed=42):        self.num_layers = num_layers        random.seed(seed)        self.blocks = []        self.units = []        self.tasks = []        self.total_transport = 0        self.total_energy = 0        self._init_hardware()        self._init_tasks()     def _init_hardware(self):        for i in range(20):            layer = random.randint(0, self.num_layers - 1)            size = random.randint(10, 100)            self.blocks.append(DataBlock(i, size, layer))        for j in range(8):            layer = random.randint(0, self.num_layers - 1)            self.units.append(ComputeUnit(j, layer))     def _init_tasks(self):        for k in range(30):            self.tasks.append(Task(k, random.randint(0, 19)))     def calc_dist(self, layer_a, layer_b):        return abs(layer_a - layer_b) * 10  # 每层间距折算为10单位距离     def naive_schedule(self):        # 最朴素策略：总是使用 0 号计算单元        for t in self.tasks:            b = self.blocks[t.need]            u = self.units[0]            dist = self.calc_dist(b.layer, u.layer)            energy = dist * b.size            self.total_transport += dist            self.total_energy += energy            u.load += 1     def near_schedule(self):        # 近存策略：选择与数据块同层或最近的计算单元        for t in self.tasks:            b = self.blocks[t.need]            best_u = None            best_dist = float('inf')            for u in self.units:                dist = self.calc_dist(b.layer, u.layer)                if dist < best_dist:                    best_dist = dist                    best_u = u            energy = best_dist * b.size            self.total_transport += best_dist            self.total_energy += energy            best_u.load += 1     def run(self, use_near=True):        if use_near:            self.near_schedule()        else:            self.naive_schedule()        return self.total_transport, self.total_energy     def report(self):        print("计算单元负载分布:")        for u in self.units:            print(f"  unit {u.unit_id} (layer {u.layer}): load={u.load}") if __name__ == "__main__":    print("=== 传统调度(全部用0号单元) ===")    s = NearStorageScheduler()    t, e = s.run(use_near=False)    print(f"总搬运距离={t}, 总能耗={e}")    s.report()     print("\n=== 近存调度(选最近单元) ===")    s2 = NearStorageScheduler()    t2, e2 = s2.run(use_near=True)    print(f"总搬运距离={t2}, 总能耗={e2}")    s2.report()    print(f"\n节能比例: {(1 - e2 / e) * 100:.1f}%")
目的：模拟了传统调度与近存储调度两种策略下的数据搬运动能耗，直观展示“就近计算”能省多少能量。
  1. calc_dist(b.layer, u.layer)计算数据块到计算单元的物理距离，每层间距折算10单位。
  2. naive_schedule()传统架构模拟：无论数据在哪层，永远送往0号计算单元。
  3. near_schedule()近存储架构模拟：遍历所有计算单元，选择与数据层距离最近的。
  4. energy = dist * b.size能耗与距离乘数据量成正比，这就是“走路费鞋”的数学模型。
  5. s2.report()打印计算单元的负载分布，可以看到近存策略下各单元负载更加均匀。

常见误区

误区近存储计算和存内计算都是“把计算放到存储那边”，两者是一回事，只是叫法不同。

正解它们的关键区别在于计算单元与存储介质的物理关系。近存储计算中，存储介质保持标准工艺（如普通DRAM/NAND），计算单元独立封装在同一模块或堆叠中，数据仍需经过短距离传输；存内计算则将计算直接融入存储阵列，在存储单元内部完成运算，传输距离几乎为零。类比来说，近存储是把小厨房“搬到”冰窖门口，存内则是直接在面粉袋里装搅拌器。前者兼容成熟工艺、灵活性高，后者能效极致但工艺挑战大。

为何常见：两个概念都主打“减少数据搬运”，且都出现在“存算一体”的大主题下，初学者容易把它们混为一谈。

误区既然计算单元已经住到存储旁边，数据就不用再传输了，系统里不存在数据移动。

正解近存储计算只是大幅缩短了数据搬运的物理距离（从厘米级降到微米级），但并没有消除搬运本身。数据仍然需要从存储阵列读出，经过硅通孔进入逻辑层。另外，并非所有数据都能本地化：模型参数和热数据可以常驻存储层，但输入数据、中间结果、控制信号仍需跨层传输。科学地说，近存储计算是“搬运距离的压缩”，而非“搬运行为的消灭”。

为何常见：直观上“搬到旁边”容易让人理解为“不用动了”，忽略了半导体中数据访问的物理必经过程。

误区近存储计算在架构上优于传统方案，换成近存储芯片后，任何程序都会自动加速。

正解近存储计算对“内存受限型”任务（如大权重推理、全表扫描）收益显著，但对“计算密集型”任务（如大量卷积、复杂分支逻辑）加速有限，甚至因为逻辑层算力不如主CPU而变慢。而且软件生态很关键：如果算子库不支持你的模型，调度器无法将计算卸载到近存引擎，硬件优势就发挥不出来。和所有架构优化一样，收益取决于工作负载与系统是否匹配。

为何常见：看到宣传数据中50%以上的延迟降低，容易以为这是普适的，忽略了特定条件和软硬件协同的前提。

误区近存储计算既然能完成AI推理，以后CPU/GPU就该被淘汰了，所有计算都在存储层做。

正解近存储计算的逻辑层只擅长有限类型的算子（矩阵乘加、过滤、聚合等），它处理不了复杂的控制流、动态分支、通用编程逻辑。在真实系统中，近存储引擎是CPU/GPU的“协处理器”：CPU负责整体调度和复杂逻辑，GPU负责大规模并行计算，近存储单元负责数据附近的特定算子。三者协同工作，而不是互相取代。就像小王并没有辞退老王，他只是把特定工作挪到更近的地方做。

为何常见：“计算下沉”的宣传容易让人联想到计算全面替代，忽略了异构系统中各司其职的设计原则。

面试题

Q1. 近存储计算的核心设计目标是（ ）

单选题 · easy

  • A.提高CPU主频
  • B.减少数据搬运距离← 正确答案
  • C.增大存储容量
  • D.简化编程模型

答案：B。近存储计算将计算单元搬到存储旁边，核心是缩短数据搬运的物理距离。提高CPU主频是传统性能路线，增大存储容量与计算架构无关，简化编程模型不是其出发点。正如小王把案板搬到冰窖门口，是为了让面粉少走路。

Q2. 3D堆叠存储中，连接各存储层与逻辑层的垂直导线称为（ ）

单选题 · easy

  • A.数据总线
  • B.缓存行
  • C.硅通孔← 正确答案
  • D.存储栅格

答案：C。硅通孔（TSV）是穿透硅片的垂直金属导线，用于3D堆叠芯片的层间互联。数据总线是传统平面架构的概念，缓存行是CPU缓存与内存交换数据的单位，存储栅格不是标准术语。硅通孔就像小楼里的电梯井，让面粉垂直上下。

Q3. 在AI推理中，近存储计算加速效果最显著的场景是（ ）

单选题 · easy

  • A.计算密集型算子
  • B.内存受限型任务← 正确答案
  • C.整数运算任务
  • D.图像编解码任务

答案：B。近存储计算主要缓解访存瓶颈，因此对“权重数据量大、算力利用率低”的内存受限型任务（如大模型推理、全表扫描）收益最大。计算密集型任务瓶颈在计算本身，图像编解码已由专用硬件高效处理，整数运算不是区分维度。

Q4. 关于近存储计算与存内计算的区别，下列说法正确的是（ ）

单选题 · mid

  • A.两者没有任何区别
  • B.存内计算的计算单元独立于存储介质
  • C.近存储计算保留了标准存储工艺← 正确答案
  • D.近存储计算的数据搬运距离为零

答案：C。近存储计算保持存储介质不变，计算单元独立集成在存储附近；存内计算则将计算嵌入存储阵列。因此C正确。A显然错误，B是近存储的特征，D只在存内计算中近似成立。

Q5. 数据流调度器的核心优化目标是（ ）

单选题 · mid

  • A.最大化计算单元负载
  • B.最小化总数据搬运量← 正确答案
  • C.最小化存储容量
  • D.最大化数据传输距离

答案：B。调度器通过把任务分配到数据所在的最近计算单元，使总搬运距离与数据量的乘积最小化。最大化负载可能导致热点不均，存储容量与调度目标无关，最大化传输距离与近存储理念背道而驰。

Q6. 近存储计算能够降低系统能耗的原因包括（ ）

多选题 · mid

  • A.减少数据搬运的物理距离← 正确答案
  • B.消除所有数据访问操作
  • C.降低数据搬运能耗在总能耗中的占比← 正确答案
  • D.缩小了芯片面积

答案：AC。能耗与搬运距离成正比，近存储将距离从厘米级降到微米级，搬运能耗大幅压缩，C是这一效果的另一种表述。B错误，数据访问并未消除；D与能耗降低无直接因果，堆叠还增加了芯片面积复杂度。

Q7. 某近存系统将任务分配到计算单元时，采用“选择物理距离最近单元”的策略，在一组并发任务中，该策略可能带来的问题是（ ）

单选题 · hard

  • A.数据搬运量增大
  • B.计算单元间负载不均衡← 正确答案
  • C.存储容量不足
  • D.硅通孔带宽浪费

答案：B。纯“最近优先”策略容易让某些计算单元因数据热点而堆积任务，其他单元空闲，导致负载不均衡。优秀的调度器需在最小化距离和均衡负载之间权衡。A与策略目标相悖，C和D与调度策略无直接关联。

Q8. 近存储计算在工程化部署中面临的典型挑战包括（ ）

多选题 · hard

  • A.软件生态与编译器适配← 正确答案
  • B.局部散热与热管理← 正确答案
  • C.硅通孔工艺良率← 正确答案
  • D.存储介质重量

答案：ABC。部署挑战包括：AI框架需开发编译器插件以卸载算子到近存引擎、逻辑层密集计算导致局部高温、3D堆叠硅通孔工艺良率低于平面芯片。D“存储介质重量”是桌面级硬件的考量，与芯片部署无关。

Q9. 在能耗模型E = α×D×V + E_计算中，近存储计算主要改变的变量是（ ）

单选题 · hard

  • A.α（单位距离能耗系数）
  • B.D（搬运距离）← 正确答案
  • C.V（搬运数据量）
  • D.E_计算（计算能耗）

答案：B。近存储计算本质上是把存储和计算堆叠在一起，将搬运距离D从厘米级压缩到微米级。α由工艺决定，V由应用决定，E_计算由算法决定——这三个变量不是近存储架构的直接操控对象。就像把厨房搬到冰箱旁，省的是“路”而不是“锅”。

Q10. 请判断以下哪些说法符合近存储计算的真实特性（ ）

多选题 · extreme

  • A.逻辑层只需实现有限算子即可工作← 正确答案
  • B.它能完全替代CPU的通用计算能力
  • C.数据仍需经过硅通孔到达逻辑层← 正确答案
  • D.它适用于数据库全表扫描场景← 正确答案

答案：ACD。近存储逻辑层以专用加速器为主，只需覆盖常用算子（A正确）；数据从存储阵列读出经硅通孔传输到逻辑层，搬运行为仍在（C正确）；数据库扫描是典型的内存受限场景，适合近存卸载（D正确）。B错误——近存储无法替代CPU的通用控制与复杂逻辑，两者是协作关系。