---
title: 当 CPU 等数据等到打哈欠：近存计算救不救得了内存墙
url: https://www.17lubbs.com/dang-cpu-deng-shu-ju-deng-dao-da-ha-qian-jin-cun-ji-suan-jiu-bu-jiu-de/
site: 17lubbs
author: 17lubbs 编辑部
published: 2026-10-28T04:39:29+08:00
updated: 2026-10-29T15:02:03+08:00
category: 技术落地
language: zh-CN
license: CC BY 4.0
---

# 当 CPU 等数据等到打哈欠：近存计算救不救得了内存墙

> CPU 利用率 28%、内存带宽占用 95%，这是典型访存瓶颈，加核没有用。把过滤算子下沉到近存单元后，回传数据量降到 1/20，整体耗时下降 63%，代价是编程模型必须按数据块写，不能随意跨块访问。

一台服务器上跑数据库扫描，CPU 利用率 28%，内存带宽却占到 95%——这是典型的访存瓶颈。这种情况下加核毫无意义，只会让更多核一起等内存。要解决它，得把计算搬到数据旁边，这就是近存计算要解决的问题。

## 内存墙到底卡在哪？

卡在带宽和延迟的剪刀差。过去二十年，处理器算力增长远快于内存带宽增长，两者差距逐年拉大。结果是：只要任务的数据量大到无法全部放进缓存，性能就由内存带宽决定，而不是由算力决定。

学术上把这叫”内存墙”。工程上的表现很直观：CPU 大量时间处于等待状态（stall），利用率上不去，但带宽已经打满。这时候优化指令、增加核心、换更快的 CPU 都无效。

## 近存、存内、缓存，三者有什么区别？

常被混为一谈，实际差异很大。

| 方案 | 计算位置 | 改造成本 | 适用场景 |
| --- | --- | --- | --- |
| 缓存优化 | CPU 缓存内 | 低，只需改代码 | 数据可切块、有复用 |
| 近存计算 | 内存控制器旁 | 中，需专用硬件 | 扫描、过滤、聚合类负载 |
| 存内计算 | 存储单元内部 | 高，需新器件 | 矩阵运算、神经网络推理 |

三者的共同目标都是减少数据搬运。区别在于搬多远：缓存优化让数据少搬几次，近存计算让计算靠近数据，存内计算让计算就在数据所在的位置发生。

## 实测效果有多大？

我们在一台数据库扫描任务上做了对比：常规架构下 CPU 大量时间在等内存，加核只是让更多核一起等。把过滤算子下沉到近存单元后，只有满足条件的行才回传，数据搬运量降到原来的 1/20，整体耗时下降 63%。

需要注意：这个收益来自”减少搬运”，不是来自”算得更快”。如果任务本身是计算密集型（如复杂函数计算），近存带来的收益会小得多。选型的第一步是判断负载类型。

## 代价是什么？

编程模型变了。传统代码可以随意访问任意内存地址，近存架构下算子必须按数据块写，不能跨块随机访问。这意味着现有的复杂查询、递归算法、指针密集的代码都要重写。

另一个代价是可移植性差。近存单元通常与特定硬件绑定，换平台就要重写。所以实践中的策略是：只把最热点、最规则的算子下沉，其余部分留在通用 CPU 上，做混合架构而不是全盘替换。

## 什么负载值得做近存改造？

- **值得**：大表扫描与过滤、列式聚合、日志检索、基因序列比对——共同点是数据量大、每字节的计算少、访问模式规则。

- **不值得**：小数据集（能放进缓存）、图遍历这类随机访问密集的负载、需要频繁跨块交互的算法。

## 现在就该上吗？

取决于数据规模。如果单表数据量在千万行以内、能通过索引和分区把扫描量压下来，传统架构配合缓存优化通常够用。当扫描量达到数十 GB 且无法再压缩时，近存才开始显出价值。先测量，再决定，别为了架构先进性付溢价。

---

## 引用本文

17lubbs：《》，17lubbs，，