AI 芯片为什么越来越像内存生意？从 HBM 成本看 LLM 推理的真正瓶颈

Mon, 25 May 2026 10:03:25 +0800

如果你还在用“这张卡有多少 TFLOPS”来判断一套 LLM 推理系统值不值得买，我建议先停一下。

这不是说算力不重要。训练大模型、跑高吞吐推理，当然离不开矩阵乘法能力。但最近 Hacker News 上一篇 Epoch AI 的芯片成本拆解很值得看：他们估算，在 Nvidia、AMD、Google、Amazon 等 AI 芯片的组件成本里，高带宽内存 HBM 的占比已经从 2024 年一季度的 52% 上升到 2025 年四季度的 63%。

也就是说，今天一颗 AI 加速器越来越不像“纯算力商品”，反而更像一块被昂贵内存包围的计算核心。

这个变化对做应用的人也有直接影响。你在云上选 H100/H200，或者在本地纠结 4090、Mac Studio、工作站多卡，并不是在买一个抽象的“AI 能力”。你买的是：模型权重能不能放下，KV cache 能不能撑住上下文，batch size 能不能拉起来，以及 token 流水线会不会被内存带宽卡死。

说白了，LLM 推理的很多瓶颈，最后都会变成内存问题。

HBM 成本占比上升，说明了什么？

Epoch AI 这篇文章的核心数字很简单：HBM 在 AI 芯片组件成本中的占比，从 52% 增长到 63%；同时 logic dies 大约维持在 13%，先进封装和其他辅助组件占比下降。这个结论不是单一芯片报价，而是按生产量加权估算出来的行业平均值。

我不建议把这个数字理解成“GPU 厂商利润被内存厂吃掉了”这么简单。更有用的读法是：产业链正在用真金白银投票，承认 AI 工作负载对内存系统的饥渴程度越来越高。

为什么？因为 LLM 不是只做一次矩阵乘法就结束。

模型推理至少有两类阶段：prefill 和 decode。prefill 阶段要把提示词一次性喂进去，计算密度相对高；decode 阶段则是一个 token 一个 token 往外吐，每一步都要读模型权重，还要读写不断增长的 KV cache。上下文越长、并发越高，显存容量和带宽压力越明显。

这也是为什么 NVIDIA 在介绍 H200 时，重点强调的不是又多了多少理论算力，而是 141GB HBM3e、4.8TB/s 内存带宽，以及相比 H100 更大的容量和更高带宽。Micron 的 HBM3E 页面也把“高容量、高带宽、低功耗”直接绑定到生成式 AI 和超算场景。

厂商宣传当然有营销成分，但方向没错：大模型时代，内存系统正在从配角变成主角。

“Memory Wall”不是论文里的抽象词

如果你想找一个更学术的背景，可以看 2024 年 arXiv 上的 AI and Memory Wall。论文里有个很直观的判断：过去二十年，服务器峰值 FLOPS 的增长速度明显快过 DRAM 和互连带宽，结果就是很多 AI 应用，尤其是 serving，瓶颈越来越偏向内存而不是计算。

人话翻译：芯片算得越来越快，但数据喂不进去。

在传统后端系统里，我们很熟悉这种问题。数据库查询慢，不一定是 CPU 不够，可能是随机 IO、缓存命中率、网络往返。LLM 推理其实也类似，只是“数据库”换成了模型权重和 KV cache，“索引命中”换成了批处理、attention 优化和显存布局。

这也是我不太喜欢只用 tokens/s 讨论推理引擎的原因。tokens/s 是结果，不是原因。你要追问它是在什么上下文长度、什么 batch size、什么量化精度、什么显存占用、什么并发模型下测出来的。否则两个数字放在一起，很容易变成跑分游戏。

Hypho Blog 之前写过 Gemma 4 多 token 预测，里面提到 speculative decoding 和多 token 预测的价值，本质上就是减少昂贵大模型调用次数，让一部分 token 由更便宜的草稿路径先猜。它看起来是“算法加速”，但落到系统层面，仍然是在缓解 decode 阶段对内存访问和调度的压力。

同样，本地 LLM 推理引擎之争里讨论 llama.cpp、Ollama 这些工具时，真正该看的也不是谁的命令行更漂亮，而是谁能更稳定地利用硬件内存层级：量化格式、KV cache 策略、Metal/CUDA 后端、batch 调度，都会直接影响可用性。

对工程选型的第一个影响：显存容量不是“越大越好”，而是决定边界

很多团队买 GPU 时会问：“这张卡能不能跑 70B？”

这个问题不够精确。更好的问法是：

用什么精度跑？FP16、INT8、4-bit，还是更激进的 2-bit/3-bit？
目标上下文长度是多少？8K、32K、128K，还是 1M？
是单用户交互，还是几十路并发？
是否需要工具调用、RAG、长文档、多轮对话保留上下文？
失败时是慢一点可以接受，还是延迟抖动会直接影响业务？

因为显存容量决定的是系统边界。模型权重放不下，谈不上推理；KV cache 放不下，长上下文和并发就会突然崩；中间 buffer 和框架开销没算进去，部署时就会出现“理论可跑，线上 OOM”的尴尬。

我踩过的一个坑是，很多评估表只写“某模型 4-bit 需要 X GB 显存”，但实际系统还要留给 tokenizer、runtime、KV cache、embedding/rerank 模型、监控 sidecar、甚至同机其他服务。纸面上 24GB 能跑，生产上可能只能跑一个很憋屈的 demo。

这不是小题大做。RAG 系统尤其容易低估这件事。检索阶段可能很快，但一旦把多段文档塞进 prompt，prefill 成本和 KV cache 都会上来。如果你还要 rerank、引用溯源、工具调用，那显存压力不是线性增长那么简单。

第二个影响：带宽决定吞吐，容量决定能不能活

容量和带宽经常被混在一起讲，但工程含义不同。

容量回答“能不能放下”。带宽回答“放下以后能不能喂得动”。

对于 decode 阶段，模型每生成一个 token 都要访问大量权重和缓存。计算核心如果等数据，就会空转。你看到 GPU 利用率不高，不一定是 batch 太小，也可能是内存带宽成了瓶颈。增加 batch size 有时能提高利用率，但 batch size 又会吃更多 KV cache，最后又回到容量问题。

这就是为什么 HBM 贵但绕不开。它不是普通 DDR 的升级版，而是为了把更多内存堆到计算核心旁边，用更宽的总线提供更高带宽。代价也明显：封装复杂、供应链紧张、成本高。Epoch AI 的 63% 数字，本质上就是这个代价在账面上的体现。

对企业来说，这里有个反直觉结论：不是所有场景都应该追求最高端 HBM GPU。

如果你的场景是低并发内部知识库、固定短上下文、延迟要求不高，也许一套便宜得多的本地推理方案就够了。反过来，如果你做的是多租户 Agent 平台、长上下文代码分析、实时客服或者高并发 RAG，省 GPU 预算可能会在延迟、稳定性和工程复杂度上加倍还回来。

硬件便宜，不等于系统便宜。

第三个影响：优化路线会更偏“少搬数据”

既然内存越来越贵，推理优化就不会只围绕“算得更快”。我更看好几类减少数据搬运或提高有效利用率的方向：

第一是量化。它最直观，权重变小，显存占用下降，带宽压力也下降。但量化不是免费午餐，精度、模型兼容性、算子支持都会影响最终效果。尤其生产环境里，你不能只看一个 benchmark，要看业务数据上的退化。

第二是 KV cache 优化。长上下文和 Agent 场景会让 KV cache 变成吞显存的大户。分页 KV、压缩 KV、滑动窗口、prefix cache 都是在想办法让历史上下文不要无限制挤爆显存。

第三是 speculative decoding、多 token 预测和 draft model。它们的共同思路是：别让大模型每一步都全力出手。如果草稿路径猜得够准，就能减少主模型的昂贵 decode 次数。

第四是请求调度。很多推理系统的问题不是单请求慢，而是混合负载下互相拖累。短请求被长上下文请求堵住，交互请求被批处理吞吐策略牺牲，最后用户感知很差。好的调度不是把 GPU 塞满就完事，而是在吞吐、延迟和显存碎片之间做取舍。

这些方向看起来分散，其实都围绕同一件事：让有限的内存容量和带宽产生更多有效 token。

那么，企业应该怎么选？

我的建议比较朴素：先用工作负载画像倒推硬件，而不是先买卡再找场景。

如果你做的是企业内部 RAG，先统计真实 prompt 长度、文档片段数量、并发峰值、可接受延迟，再决定是用云上高端 GPU、托管 API，还是本地小模型加 rerank。不要为了“数据不出门”盲目自建，也不要为了“省运维”把所有请求都扔给外部 API。

如果你做 AI coding 或 Agent 平台，重点看长上下文和工具调用带来的 KV cache 压力。代码库分析、日志读取、多轮修复，这些都不是短 prompt。单次 demo 流畅，不代表持续任务稳定。

如果你做本地推理产品，要把“可运行模型列表”改成“在目标硬件上的稳定体验”。用户不关心你理论支持多少模型，他们关心 32GB 内存的机器跑 7B 会不会卡，64GB 统一内存的 Mac 跑长上下文会不会慢到不可用，消费级 GPU 上下文一长是不是直接爆显存。

最后，如果预算有限，不要只盯 GPU 型号。很多时候，模型选择、上下文裁剪、检索质量、rerank 策略、缓存设计，比硬件升级更划算。硬件能买来上限，但系统设计决定你能不能接近这个上限。

结语：AI 基础设施正在回到系统工程

HBM 占 AI 芯片成本 63% 这个数字，我觉得它最大的意义不是“内存涨价了”，而是提醒我们：LLM 规模化落地已经不再是单纯模型能力问题，而是系统工程问题。

模型参数、显存容量、内存带宽、KV cache、batch 调度、RAG prompt 长度、用户延迟预期，这些东西必须放在一起看。

也许几年后，新的架构会缓解今天的 memory wall；也许 HBM 供应会更充足，成本曲线会下去。这块我不敢下定论。但至少现在，如果一个 AI 基础设施方案只讲“我们有多少算力”，却不讲内存和调度，我会非常谨慎。

因为在 LLM 推理里，算力决定你能跑多快；内存往往决定你能不能真正跑起来。

GPU on Hypho