一台服务器上跑数据库扫描，CPU 利用率 28%，内存带宽却占到 95%——这是典型的访存瓶颈。这种情况下加核毫无意义，只会让更多核一起等内存。要解决它，得把计算搬到数据旁边，这就是近存计算要解决的问题。
内存墙到底卡在哪？
卡在带宽和延迟的剪刀差。过去二十年，处理器算力增长远快于内存带宽增长，两者差距逐年拉大。结果是：只要任务的数据量大到无法全部放进缓存，性能就由内存带宽决定，而不是由算力决定。
学术上把这叫”内存墙”。工程上的表现很直观：CPU 大量时间处于等待状态（stall），利用率上不去，但带宽已经打满。这时候优化指令、增加核心、换更快的 CPU 都无效。
近存、存内、缓存，三者有什么区别？
常被混为一谈，实际差异很大。
| 方案 | 计算位置 | 改造成本 | 适用场景 |
|---|---|---|---|
| 缓存优化 | CPU 缓存内 | 低，只需改代码 | 数据可切块、有复用 |
| 近存计算 | 内存控制器旁 | 中，需专用硬件 | 扫描、过滤、聚合类负载 |
| 存内计算 | 存储单元内部 | 高，需新器件 | 矩阵运算、神经网络推理 |
三者的共同目标都是减少数据搬运。区别在于搬多远：缓存优化让数据少搬几次，近存计算让计算靠近数据，存内计算让计算就在数据所在的位置发生。
实测效果有多大？
我们在一台数据库扫描任务上做了对比：常规架构下 CPU 大量时间在等内存，加核只是让更多核一起等。把过滤算子下沉到近存单元后，只有满足条件的行才回传，数据搬运量降到原来的 1/20，整体耗时下降 63%。
需要注意：这个收益来自”减少搬运”，不是来自”算得更快”。如果任务本身是计算密集型（如复杂函数计算），近存带来的收益会小得多。选型的第一步是判断负载类型。
代价是什么？
编程模型变了。传统代码可以随意访问任意内存地址，近存架构下算子必须按数据块写，不能跨块随机访问。这意味着现有的复杂查询、递归算法、指针密集的代码都要重写。
另一个代价是可移植性差。近存单元通常与特定硬件绑定，换平台就要重写。所以实践中的策略是：只把最热点、最规则的算子下沉，其余部分留在通用 CPU 上，做混合架构而不是全盘替换。
什么负载值得做近存改造？
- 值得：大表扫描与过滤、列式聚合、日志检索、基因序列比对——共同点是数据量大、每字节的计算少、访问模式规则。
- 不值得：小数据集（能放进缓存）、图遍历这类随机访问密集的负载、需要频繁跨块交互的算法。
现在就该上吗？
取决于数据规模。如果单表数据量在千万行以内、能通过索引和分区把扫描量压下来，传统架构配合缓存优化通常够用。当扫描量达到数十 GB 且无法再压缩时，近存才开始显出价值。先测量，再决定，别为了架构先进性付溢价。
发表回复