最近AI圈又冒出一个高频词近内存计算。很多朋友问我它到底是什么是不是厂商造出来唬人的新概念。我自己的第一反应是——这个词其实很老只是AI大模型把这股火彻底点着了。它的核心要解决的是算力增长飞快但数据搬运速度跟不上导致大量计算单元闲置。这篇文章我从内存墙讲起把它和存内计算的概念边界、主流的硬件落地形态、工程评估方法一次性说清楚。适合正在做大模型推理、推荐系统、向量数据库和相关基础设施的工程师参考。1. 内存墙近内存计算这门“黑话”出现的直接原因1.1 算力增长快带宽增长慢先说一个很多人在做项目时才真正体会到的现实GPU的算力每年都在大幅上涨但内存带宽的涨幅要温和得多。以NVIDIA A100为例FP16稠密算力大约是312 TFLOPSHBM2e的带宽在1.5~2 TB/s左右。拿312除以2得到155 FLOP/Byte左右的“算力带宽比”。这个数字意味着什么如果某个算法平均每读取1字节数据只做不足155次浮点运算它就会被带宽卡住GPU空有一身算力使不出来。训练大模型时之所以整体还算顺畅是因为矩阵乘法这类核心运算的算术强度很高一块数据读进来可以被反复重用可以做到几百甚至上千FLOP/Byte远高于155这个阈值。但推理阶段完全是另一番光景逐token生成时模型权重每个token都要被重新读取一遍。7B参数的fp16权重就约14GBbatch size等于1时每生成一个token都相当于把14GB数据从头搬一遍。这种场景下带宽决定延迟算力只是陪跑。掉进过这个坑的人应该都有同感你以为瓶颈在显卡不够快升级到更高算力卡后单token延迟几乎没变。问题不在算力在数据搬运。1.2 Transformer推理暴露的不只是算力问题大模型推理里还有一批运算的算术强度低得离谱比如自注意力中的QK相似度计算、Softmax、KV cache的读取、以及对注意力权重的聚合操作。这些操作往往被笼统归入“访存密集”型负载。实际用profiler看GPU的DRAM占用率经常打到90%以上而CUDA Core利用率只有百分之二三十。此时机器的状态像是几十个厨师在厨房里等着但食材都在三公里外的仓库来回搬货的小车成了瓶颈。QK^T和Softmax需要读取整个注意力矩阵和相关向量但每个元素的计算量非常小。KV cache读取长上下文对话时每个生成步骤都要把此前所有token的Key和Value重新读一遍这个数据量随上下文长度线性增长。多轮交互中的状态切换AI Agent、多模型协作这类场景本身就喜欢保持大上下文导致KV cache巨大带宽压力进一步叠加。也正是从这些真实需求出发近内存计算才被推到台前。它试图回答一个很直接的问题如果瓶颈是数据搬运那我们把计算放进内存旁边不让数据跑那么远行不行1.3 一个简单的算术题决定你是否需要近内存计算判断一套系统是不是带宽受限不需要很复杂的手段。先估算负载的算术强度也就是平均每字节数据搬运对应多少次浮点运算。然后对比设备的算力带宽比阈值。算术强度 阈值算力受限优先优化的应该是计算密度、算子实现、数据复用。算术强度 阈值带宽受限这时候花力气做数据压缩、算子融合、量化都是正路如果这些软件手段还不够硬件层面就要考虑近内存计算这类方案。我做过不少次这种粗略评估一张Excel表就够了。先把算子拆开统计每个算子的FLOPs和访存字节数再算总账。你往往会发现真正拖后腿的就是那么少数几个个位数的算子。把这些算子单独拎出来处理比全量迁移到新硬件快得多。2. “近内存计算”到底近在哪它和存内计算有什么边界2.1 按数据放的位置来定义近内存计算的英文是near-memory computing字面意思就是“在内存附近计算”。这里的关键不是“计算有多强”而是“计算离数据有多近”。传统冯·诺依曼结构里数据要经过内存总线、缓存层次、寄存器最后才进ALU。每一步都是延迟和功耗的开销。业界常引用的一组数据是一次DRAM访问消耗的能耗大约等于几十到几百次32位加法运算的能耗。具体的数值会随工艺节点变化但数量级的差距一直存在。换句话说搬运数据本身可能就是整个系统最贵的操作。近内存计算的思路是把计算单元放到存储阵列的边缘或附近。数据从存储单元读出后直接在旁边被处理不需要通过片外总线绕一大圈。和它经常被混为一谈的“存内计算”in-memory computing/computational memory则更激进逻辑直接嵌进存储单元内部甚至利用存储单元的物理特性直接完成乘加运算。2.2 近内存、存内计算与传统架构的关系为了方便对比我把三者的差异整理成了表格对比维度传统冯·诺依曼近内存计算存内计算计算单元位置远离存储阵列独立计算die存储die旁/片内边缘存储阵列内部数据搬运距离最远需要走片外总线短片上或封装内完成极短基本不出存储阵列代表产品/技术CPU、GPU计算核心HBM-PIM、PIM DIMM、2.5D封装的chipletReRAM/SRAM阵列的乘加阵列通用性最强中上可支持通用算子但受限较弱偏向特定AI算子工艺难度DRAM和逻辑工艺分离中逻辑少量嵌入存储die高需对存储单元做逻辑改造从这个表格能看出来近内存计算其实是“妥协后更可工程化的路线”。它不要求把存储单元的物理结构改得面目全非只需要在靠近存储的位置增加有限的计算资源。相比存内计算它的优势是更容易兼容现有存储工艺、更容易编程代价是数据还是要做一次较短的搬运。2.3 为什么不能把存储器和计算器“粘在一起”了事既然数据搬运这么贵为什么不直接做成一个巨大的芯片把存储和最强算力焊在一起这个问题几乎所有第一次接触近内存计算的人都会问我当时的反应也一样。答案有三层。第一层是工艺冲突DRAM工艺追求极高的电容密度和低成本逻辑工艺追求晶体管速度和能效二者在晶圆厂里是两套完全不同的流程。直接混在一起良率、密度、功耗都会付出代价。第二层是散热和供电存储芯片里塞入大规模计算单元后局部功耗密度猛增散热设计难做。第三层是成本即便技术可行大批量生产的良率和成本也会劝退大多数客户。做AI芯片的都清楚一个朴素道理好架构是“在物理约束下做取舍”不是在理想世界里做最优解。近内存计算的价值恰恰在于它能在不颠覆存储工艺的前提下把计算拉近到数据旁边属于一种可落地的次优解。这个“次优”在实践中往往已经足够优秀。3. 一张路线图看近内存计算的几种落地形态3.1 HBM-PIM把计算单元放进高带宽内存的堆栈里目前在AI服务器领域讨论最多的是HBM-PIM这种形态。HBM本身是多个DRAM die垂直堆叠通过硅通孔TSV实现高带宽连接。在这类内存die内部靠近bank的位置塞进可以完成一定浮点/整数计算的单元就是HBM-PIM的基本思路。三星公开资料里展示过HBM-PIM的方向官方给出的数据是在某些特定工作负载下能够实现约3倍的性能提升、约60%的功耗降低。注意这个数字是特定负载下的相对收益不是所有程序都能拿到的。它擅长的是那些“数据量大但操作规律”的任务比如向量加法、逐元素乘、大规模归约这类访存密集算子。如果你想在上面跑复杂的控制流逻辑基本没戏。实际应用中HBM-PIM的编程方式更接近“把算子下推到内存设备执行”和GPU的kernel launch有相似之处但生态还远没有CUDA成熟。3.2 带计算单元的DIMM把计算推进到内存条附近另一个已经商业化的方向是PIM DIMM代表是UPMEM推出的产品。它把可编程的DPU数据处理单元做进了标准DDR4 DIMM上服务器可以直接插这种内存条加装内存计算能力。它的优势在于兼容现有服务器基础设施不需要换主板、换CPU。这类产品的典型应用包括数据库扫描、图处理、压缩/解压、基因测序比对等数据密集型任务。它的编程模型和GPU差异很大通常需要通过厂商提供的SDK把任务映射到DPU上。优点是内存就近处理减少了主CPU的负载和互连压力缺点是需要接受厂商的工具链和数据分配方式。3.3 2.5D/3D封装与芯粒化让内存和计算芯粒做邻居还有一个容易被忽略的落地形态是芯片封装层面的把计算die和存储die放进同一个封装里通过interposer基板或TSV互联。这就是2.5D/3D封装技术。原本需要经过PCB走线、片外总线的数据通路现在可以在封装内部完成距离缩短一个数量级。近年来比较火的一个相关词汇是芯粒chiplet和UCIe互连标准。UCIe本来是为了解决不同芯粒之间互联的问题它也在把芯片系统的设计从“单颗大芯片”推向“封装内的小系统”。当计算芯粒和内存芯粒通过这种短距互连通信时工程上就是近内存计算的思路。我判断未来相当一部分AI芯片都会走这条路线不需要把所有逻辑都集成进存储die而是通过先进封装让计算与存储靠得更近。这种形态牺牲了极致的数据路径距离但换来了更好的可扩展性和成本灵活性。3.4 CXL它算不算近内存计算不少朋友会问CXL内存扩展是不是近内存计算严格来说不算。CXL解决的是内存容量池化和缓存一致性扩展问题它让远处的内存看起来离CPU/GPU更近但物理上数据还是在外部走着长距离互联。它和近内存计算的目标不完全一样一个是在解决“内存不够用”一个是在解决“数据搬不动”。不过二者有很强的互补关系。我在实际项目中见过混搭的做法用CXL扩展大容量内存池给冷数据用用贴近计算侧的持久内存或者HBM处理热数据。理解清楚这个边界能避免在技术选型时把不同层次的问题混在一起。4. 真正动手评估时我关注的三个工程问题4.1 数据局部性好算子一选就赢差算子救不回来近内存计算的硬件再先进如果数据访问模式不好收益也会被吃掉。带宽数字是理论峰值实际能拿到多少取决于访存局部性。比如向量加法这种操作每个元素读一次、写一次数据是线性流式访问非常适合近内存执行。而如果你的算法里每个数据要被反复从存储读到计算单元旁边但因为索引跳来跳去导致缓存命中率低那计算单元的利用率上不去最终还是会被访存延迟拖死。我在评估一个算子是否适合迁移到近内存设备时会先做一个简单步骤把算法按数据访问方式画一遍。只要我发现数据呈现出明显的“读一次算一次”或“小窗口内反复重用”的特征就会认真评估如果发现是稀疏随机访问、大量间接寻址我会直接放弃因为这类负载需要的是大规模片上缓存和复杂乱序处理能力而不是内存附近的简单计算单元。4.2 数据一致性算完的结果怎么回到主核近内存计算设备执行完计算后结果要回到主处理器的可见内存空间。这就牵出另一个经常被低估的问题一致性。主核怎么知道PIM设备已经算完了什么时候它读到的才是最终结果不同厂商的解决方案差别很大有的靠显式同步有的靠缓存刷新指令有的需要软件维护一个“设备状态标志”。这个同步开销在性能模型里很容易被漏掉。以前我看过一份近内存计算的评测报告单个kernel的加速比很漂亮但一旦把任务切碎成几千个小kernel每个kernel之间的同步次数一多整体收益就被互连延迟吃掉了。所以经验法则是尽量把数据划分成大块、把操作批量提交给近内存设备减少主核与设备之间的“握手”次数。4.3 编程模型和工具链别低估生态成本做实际工程的人都明白一个硬件方案再强编程体验跟不上就很难落地。近内存计算目前还没有一个像CUDA那样统一的编程标准。不同实现有各自的SDK有的让你用C语言扩展有的基于OpenCL风格有的直接给你封装好的算子库。我自己的建议是如果只是想验证近内存计算对某个负载有没有收益先别急着写custom算子。直接看供应商有没有现成的高性能算子库用库函数跑一遍实测。发现收益明显再考虑深挖自定义算子如果库函数都没有覆盖你的场景那大概率意味着很多隐藏的坑需要你自己踩。这时候要做的是重新评估ROI而不是硬着头皮上。5. 什么负载值得用近内存计算我的判据和实测心得5.1 Roofline模型一张图判断该不该做我一直觉得做性能工程的人应该把Roofline模型当常识。它的核心是一条斜面横轴是算术强度纵轴是可达性能。设备有一个“算力带宽比”阈值超过这个阈值后性能受算力限制低于这个阈值则受带宽限制。把你要做的负载放到Roofline图上一眼就能看出它在哪个区域。如果它落在带宽限制区且距离阈值还有很大距离意味着算力基本在睡觉近内存计算的收益就有理论依据。如果它早就落在算力限制区硬件已经接近跑满算力那再上近内存计算也没有意义因为瓶颈不在搬运。以7B参数大模型推理为例KV Cache读取和权重读取让整个推理流程的平均算术强度非常低完全落在带宽限制区。这也是我在实际项目里最推荐尝试近内存计算的场景之一。5.2 推荐做的负载与不建议碰的负载基于上面这套理论框架我把实践中的负载分成三类负载类型典型例子近内存计算的适用性流式数据扫描/聚合数据库扫描、embedding表聚合、批量向量范数计算非常合适数据线性访问计算简单低算术强度AI推理子任务注意力矩阵的QK^T、Softmax、KV Cache读取归约合适能明显改善延迟和带宽占用高逻辑复杂度/不规则访问图算法中大量随机邻居遍历、稀疏动态分支不合适计算单元弱同步开销高注意一个容易误判的点大模型训练里的GEMM并不适合近内存计算。虽然它访存量也很大但矩阵乘法可以通过分块实现极高的数据复用算术强度高于设备阈值GPU上的Tensor Core才是它的最佳归宿。只有把推理中那些“低算术强度、带宽瓶颈”的算子剥离出来后近内存计算才有明显的发挥空间。5.3 如果打算做第一版验证我的建议流程如果你对近内存计算产生了兴趣打算评估它是否适合你的业务我给一个自己反复使用过的操作顺序先做Roofline估算不急着碰硬件。用profiler比如NVIDIA的ncu或者系统perf工具采出你真实负载的DRAM吞吐量、计算利用率确认瓶颈确实是带宽。优化软件把能做的先做了算子融合、量化、缓存blocking、数据排布调整。很多人做到这一层就已经解决了大部分问题根本不需要换硬件。如果软件优化完成后带宽仍然是瓶颈并且负载满足“流式访问、低算术强度、可批量并行”的条件再去评估近内存计算设备。在评估设备时优先跑真实负载其次跑供应商benchmark。厂商的benchmark挑的都是最能发挥硬件特性的算子和你的真实数据分布之间可能差着十万八千里。最后对比总拥有成本近内存设备带来的性能和能效提升是否抵消了额外的开发、部署和运维复杂度。这套流程看起来朴素但能帮我砍掉至少一半“看起来很美好”的方案。工程选型最怕的是被单点数字打动忘了自己是在跟整个系统一起工作。6. 关于近内存计算我想说点UI设计之外的真话最后再聊几句个人经验。我在前面多次提到“别被宣传数字骗了”这不是客套话。近内存计算确实解决了真实问题但它不是万能药。它本质上适合的是“搬运量极大但每个数据操作非常简单”的场景比如推荐系统里的特征聚合、大模型推理里的attention和KV cache访问、数据库里的批量扫描。它不适合的场景也比比皆是强行迁移只会徒增复杂度。我的实操体会是真正从近内存计算吃到红利的团队都是先把系统拆得很清楚把带宽瓶颈算得很明白的人。他们不会因为“AI黑话”而追热点而是因为看清楚了计算模型和硬件物理限制的匹配关系才行动。如果你连自己负载的算术强度都说不清我建议先别急着研究近内存计算老老实实开一次profiler看看数据到底是怎么流进流出处理器的。另外一个非常有用的技巧在混合负载里把带宽受限的算子单独剥离出来评估不要试图把整个应用都迁到近内存设备上。一次只优化一个瓶颈收益会清晰得多。用真实业务数据测试别用均匀随机数据因为随机数据会高估缓存的作用低估内存带宽压力。关于近内存计算的讨论短期内肯定还会继续升温。我个人的判断是它不会替代GPU、CPU而是成为数据密集型场景里的一张新牌。牌得打对地方才能赢。