Ichibantitle
Back to Blog

内存墙已至：为什么内存占据了AI芯片三分之二的成本

May 25, 2026by Ichiban Team
aihardwarememorymachine learningperformance

Hero

作为软件工程师和 AI 从业者，我们往往将大量时间投入到对算力（Compute）的极致追求中。我们热衷于做 teraFLOPs 基准测试、优化 Kernel 启动开销，并尽可能地将操作并行化到硬件允许的所有 SM（Streaming Multiprocessors，流式多处理器）上。然而，承载这些模型运行的硬件底层物理现实，实际上已经发生了根本性的转变。

根据 Epoch AI 最新发布的数据，在现代 AI 芯片的总组件成本中，内存组件的占比已攀升至近三分之二。我们已经正式撞上了“内存墙”，而它正在重塑人工智能的经济学。

#发生了什么：Epoch AI 的核心发现

几十年来，半导体行业一直被摩尔定律所主导：逻辑单元不断缩小，晶体管越来越便宜，处理器速度越来越快。包含计算逻辑的硅片（Silicon Die）一直是物料清单（BOM）中无可争议的核心。

Epoch AI 的最新分析指出，这一范式在 AI 加速器领域已被彻底颠覆。如今，为了喂饱庞大的神经网络，必须要配备超高速的内存——尤其是 HBM（High Bandwidth Memory，高带宽内存），而它占据了旗舰 AI GPU 约 66% 的制造成本。

这很大程度上归因于 HBM 极度复杂的制造和封装工艺。与传统位于 PCB 板上、紧挨着处理器的 GDDR 内存不同，HBM 需要将内存芯片垂直堆叠，并使用微观的硅通孔（TSVs）进行连接。然后将这些堆叠好的内存放置在先进的硅中介层（例如台积电的 CoWoS）上，与计算芯片紧密相邻。这套工艺良率极难控制，且材料昂贵。算力不再是构建 AI 硬件的瓶颈所在；如何为这些算力输送数据才是。

#为什么这很重要：内存墙的经济学效应

为什么软件开发者或数据科学家需要关心硬件的 BOM 成本？因为硬件经济学决定了云服务的定价、API 的成本，并最终决定了哪些架构在商业部署上是切实可行的。

如果加速器三分之二的成本都花在了内存上，这意味着扩大模型规模（这需要线性增加的内存容量）将带来呈指数级上升的成本。当你在 AWS 或 GCP 上租用 AI 实例时，你不仅仅是在为矩阵乘法的能力买单；你很大程度上是在为芯片上挂载的物理 HBM3/HBM3e 支付高昂的溢价。

这种动态解释了为什么云服务商在内存分配上越来越“吝啬”。一款旗舰 GPU 可能标榜着惊人的 FLOPs，但如果它的显存上限只有 80GB 或 144GB，在进行大模型推理时就不得不将权重拆分到多个 GPU 上（张量并行，Tensor Parallelism）——这大幅推高了运营成本，并引入了网络延迟。

#技术启示：我们正受制于访存瓶颈（Memory-Bound）

从技术角度来看，内存成本的主导地位与现代深度学习的根本瓶颈完全吻合：大型语言模型（LLMs）严重受制于访存（Memory-bound），而非算力（Compute-bound）。

自回归生成（LLM 逐个 Token 输出文本的方式）要求在生成每一个 Token 时，都必须将整个模型权重矩阵从内存读取到计算单元中。此外，为了避免重复计算历史上下文，推理引擎会在 GPU 显存中维护一个“KV Cache”（键值缓存）。

为了说明内存消耗的速度有多快，我们可以看一段用于计算推理期间 KV Cache 大小的简单 Python 代码：

def calculate_kv_cache_gb(batch_size, seq_len, hidden_size, num_layers, precision_bytes=2):
    """
    Calculates the memory required to store the KV cache for a transformer model.
    precision_bytes: 2 for FP16/BF16
    """
    # 2 represents the Key and Value tensors
    bytes_per_token = 2 * hidden_size * num_layers * precision_bytes
    total_bytes = batch_size * seq_len * bytes_per_token
    
    return total_bytes / (1024 ** 3) # Convert to GB

# Example for a Llama-3-70B style model (80 layers, 8192 hidden size)
# with a batch size of 32 and a context window of 8,192 tokens:
cache_size = calculate_kv_cache_gb(batch_size=32, seq_len=8192, hidden_size=8192, num_layers=80)
print(f"KV Cache Size: {cache_size:.2f} GB") 
# Output: KV Cache Size: 6.25 GB (Just for the cache, not the model weights!)

当你把 140GB 的模型体积（以 FP16 精度下的 70B 参数模型为例），加上为了支持长上下文窗口和并发用户而产生的庞大 KV Cache 结合起来看，硬件厂商为何要拼命在硅中介层上塞进尽可能多且昂贵的 HBM 就不言而喻了。

#跨越内存墙：软件层面的应对策略

正因为内存已成为主要成本中心，当前 AI 领域最具影响力的软件工程突破都集中在内存优化上。业界正在通过以下这些每位现代开发者都应该了解的技术来积极应对：

  • 量化（Quantization，如 INT8, INT4, FP8）： 降低权重和激活值的精度。将精度从 FP16 降低到 INT4，可以将加载模型所需的内存带宽直接减半，从而使推理速度翻倍。
  • PagedAttention： 由 vLLM 推广的这项技术，将 KV Cache 当作操作系统的虚拟内存来管理，消除了内存碎片，并在相同的物理内存开销下允许更大的 Batch Size。
  • 分组查询注意力（Grouped-Query Attention, GQA）： 诸如 Llama-3 采用的模型架构层面的改进，通过减少 KV 头的数量，直接缩小 KV Cache 的内存占用。

#下一步发展：硬件与架构的未来

HBM 光罩尺寸的物理极限意味着我们无法无休止地在单芯片上不断堆叠内存。硬件厂商正在积极探索以下替代方案：

  1. 存算一体（Compute-In-Memory, CIM）： 直接在 SRAM 阵列中执行矩阵乘法的架构，彻底消除了内存与计算逻辑之间高昂的数据搬移开销。
  2. 光互连（Optical Interconnects）： 利用硅光子技术，允许极低延迟下将多个计算芯片各自的 HBM 堆叠池化在一起，相当于构建了一块巨大的逻辑 GPU。
  3. 新范式架构： 如 Mamba 或 RWKV 等状态空间模型（State Space Models, SSMs）。无论序列多长，它们的状态内存占用始终恒定，从根本上绕开了 KV Cache 爆炸的问题。

#总结

Epoch AI 的发现——内存占据 AI 芯片组件成本的三分之二——绝不仅仅是一个有趣的供应链统计数据；它已成为现代 AI 软件工程的决定性约束条件。

单纯依靠算力来暴力提升性能的时代已经结束了。在 AI 革命的下一阶段，真正的赢家将是那些把内存视为最宝贵资源的工程师和研究人员。无论你是在将模型部署到生产环境，还是在编写底层的 CUDA Kernel，你的首要目标都已经转移了：别再死磕算术逻辑了，开始死磕数据搬运吧。