AI推理内存战：HBM带宽与KV Cache如何成为性能瓶颈
最近和几个搞推理部署的朋友聊天，发现大家的关注点正在发生一个明显的变化：以前凑在一起聊的是“你这卡算力多少TFLOPs、能塞下多大的模型”，现在聊着聊着全都绕回到同一个词——内存。推理芯片的“内存战”确实已经打响了，AI算力竞争正在进入一个以带宽和容量为核心的下半场。
这篇文章我想把这件事从头到尾捋一遍：为什么推理会突然把内存推到聚光灯下，内存墙到底是什么墙，HBM为什么成了各家芯片的必争之地，以及落到我们这些真正做部署、做推理优化的人身上，要怎么理解和应对这场变化。无论你是做芯片架构的、搞算法优化的，还是单纯在维护推理集群的，这篇文章应该都能给你一些可以用的判断框架。
1. 风向变了：为什么推理芯片的竞争焦点从“算力”滑向了“内存”
1.1 训练烧算力，推理吃带宽
先说一个基本判断：训练和推理，对硬件资源的需求逻辑是完全不同的。
训练大模型的时候，数据是成批（batch）往里灌的。你拿着一个包含几千个样本的batch，在GPU上做一堆矩阵乘法，每一个权重参数在一个batch里会被反复读取和更新。这个过程中，计算量（FLOPs）的增长速度远远超过数据搬运量（Bytes）的增长速度，所以训练场景是典型的算力密集型负载，谁的矩阵算力猛，谁就能更快地把模型训出来。过去几年各家拼的FLOPS、拼的Tensor Core规模，本质都是在拼这个。
推理就不一样了。尤其是大模型那种自回归式的文本生成，每次只出一个token。每生成一个token，都相当于要把整个模型的权重从头到尾读一遍。模型越大，读一遍权重需要的访存量就越大。以现在主流的7B、8B模型为例，FP16精度下光权重就是14GB到16GB，你每蹦出一个字，硬件就得从内存里搬十几GB的数据出来。这时候你会发现，计算的活儿反而不重，重的是数据搬运。
这就是为什么开头我说“风向变了”——推理负载的核心瓶颈已经从“算得动算不动”变成了“喂得饱喂不饱”。一家推理芯片公司，如果只看它的TOPS（每秒万亿次操作）数字，不看内存带宽，那基本等于只看车的发动机功率不看油箱和油路，很容易被实际表现打脸。
1.2 内存墙：芯片算得动，数据喂不饱
“内存墙”这个词在芯片圈聊了几十年了，但从来没像今天这么扎眼。它的本质很简单：处理器的计算能力每年在涨，但内存的访问速度增长要慢得多，两者之间越拉越大的差距，就像一堵墙一样挡在系统性能面前。
放到AI推理里，这堵墙的感受会非常直接。假设你有一颗算力很强的芯片，理论上每秒能算几百TFLOPs，但它的内存带宽只有几百GB/s，那会发生什么？模型权重搬运的时间会远远超过真正计算的时间，芯片大部分时间都在“等数据”，算力再高也是空转。这就是典型的“吃不饱”，行业里叫memory bound。
举个具体数字大家感受一下：如果一颗芯片的内存带宽是1TB/s，跑一个14GB权重的中型模型，生成一个token最少也要14毫秒去读权重。你心里估算的“每秒能出多少token”其实不是算出来的，是被内存带宽卡死的。
所以现在的推理芯片，内存带宽就是生命线。这也是为什么高端AI芯片上HBM（高带宽内存）几乎成了标配——普通DDR或者GDDR那种带宽，喂不饱大模型推理这张嘴。
注意：这里说的“内存”不是电脑里那种DDR内存条，而是指芯片的片上存储和显存这一整条存储体系。推理芯片的内存战，主要打的是HBM这类高带宽内存的容量和带宽。
2. 内存战的三条主线：容量、带宽、能效
2.1 HBM：为什么高带宽内存成了“硬通货”
既然推理吃带宽，那自然谁的内存带宽更高，谁就有优势。现阶段能提供超高带宽的内存方案，就是HBM。
HBM和传统GDDR最大的区别在于它的架构：HBM把多个DRAM die堆叠在一起，通过硅中介层和底下的计算芯片互联，每一层die之间有大量的数据通道。这种立体堆叠的方式，让HBM的数据位宽可以做得很宽（1024位甚至更宽），配合高频，带宽就能做到TB/s级别。
我举个例子：几年前的A100上用的是HBM2e，带宽大概2TB/s出头；到了H100，用上HBM3，带宽轻松跑到3.35TB/s；最新的H200和B200方案，带宽更高。这个增长曲线，基本就是在给“内存战”做注脚——大家已经不是在挤牙膏了，是在拼了命往上加带宽。
这背后的逻辑就是前面说的，带宽直接决定了推理的token生成速度。同一颗芯片核心，配上两代不同的HBM，推理吞吐能差接近一倍，这是很多不看内存的人容易忽略的。
2.2 各家芯片的内存配比思路
从各家芯片的内存策略，也能看出不同玩家对这场“内存战”的理解差异。
英伟达的思路比较直接：靠HBM的迭代升级来维持带宽优势，同时不断提高显存容量。从80GB到141GB再到192GB，容量越给越大。容量之所以重要，是因为模型参数和KV Cache都住在显存里——放不下的数据只能往内存甚至硬盘搬，一搬性能就血崩。
AMD这边的做法是走chiplet路线，把计算die和IO die分开，然后外挂HBM。比如MI300系列，主打超大显存容量，某些配置甚至到了192GB以上。AMD的思路很直白：你模型多大我都能塞下，塞下就是胜利。
国内做推理芯片的厂商，绝大多数也是围绕HBM来设计。不过HBM的产能和成本都是问题，所以也有不少团队在尝试用LPDDR方案搭配大容量、低带宽来做。这个方向不是不能做，但适用的场景需要仔细挑——比如一些对延迟不敏感、但对成本极度敏感的云端批量推理场景，LPDDR的低成本反而是优势。
2.3 被低估的能效：内存也“烧电”
内存战还有一个容易被忽略的维度——功耗。
HBM带宽很高，但它不是免费的。带宽越高，数据在片内片外跑的功耗越高。一个HBM堆栈本身的功耗可以到十几瓦甚至更高，如果一颗芯片挂四个六个HBM堆栈，光内存部分的功耗就快赶上一个小型CPU了。而且这还不算完，搬运数据的时候，SRAM缓存、片上网络、I/O接口都在耗电。
这对推理部署的影响特别现实：很多推理场景是要7x24小时跑的，功耗直接折算成电费、散热、机柜密度。同样一次推理，如果芯片内存架构设计得好，能把数据搬动量压低，整机能耗就能差出一大截。这已经从单纯的技术问题变成了运营成本问题。
所以“内存战”打的其实不是一个维度，而是容量、带宽、能效三条线一起拉。谁能在这三者之间找到最优平衡，谁才能真正赢得推理市场的下半场。
3. 推理场景下的内存消耗大户：KV Cache与显存规划
3.1 KV Cache到底占了多大空间
从硬件层面看完，落回实际部署，最让搞推理优化的朋友头疼的其实是一个叫KV Cache的东西。
大模型生成文本时，每处理一个新的token，都要参考之前所有token的信息。为了避免重复计算，推理框架会把之前算出来的Key和Value矩阵缓存下来，这个缓存就是KV Cache。它的特点是：随着上下文变长，KV Cache会线性增长。
别小看这个线性增长，它涨起来非常猛。拿一个8B参数量的模型举例，假设它32层、32个注意力头、每个头维度128，那么每缓存一个token的KV数据大约是0.5MB。如果用户输入了一大段长文档，上下文到了10万token，光KV Cache就要吃掉将近50GB显存——这已经比模型本身的14GB权重还大三倍多。
KV Cache一涨，最直接的后果就是显存爆掉。你在部署推理服务时，往往不是模型塞不下，而是并发一上来、上下文一拉长，显存就告急。很多团队遇到“OOM报错”都是这个原因。
3.2 PagedAttention与内存碎片问题
KV Cache还有一个特别烦人的特性：它的大小是动态变化的，没法像模型权重那样一次性分配固定空间。如果KV Cache不断增长，显存里就会出现大量碎片，原有的显存管理方式效率会很差。
这里必须提一下vLLM项目里的PagedAttention——它可能是过去两年对推理内存管理影响最大的一个创新。PagedAttention的思路借鉴了操作系统里的虚拟内存分页机制：把KV Cache切成固定大小的块，按需分配，不要求物理上连续。这个方案能显著降低显存碎片，让可用显存暴涨。我实际测试过，同样的模型和并发配置，用上PagedAttention之后，可以服务的并发请求数量能提升好几倍。
不过要注意，PagedAttention这类方案解决的是“KV Cache怎么放”的问题，并没有解决“KV Cache总容量太大”的问题。真正要从根上缓解，还是得靠模型层面的优化，比如分组查询注意力（GQA）这种架构改动，把KV头数压缩，从源头把KV Cache的体积降下来。这也是为什么新出的模型普遍都在用GQA——不只是为了加速，更是为了省内存。
3.3 量化、投机解码对内存的“曲线救国”
既然带宽和容量都紧张，大家自然想办法给内存“减负”。
最直接的手段是量化。把模型权重从FP16压到INT8、INT4，模型体积直接缩一半甚至四分之一。权重变小，单token生成需要搬运的数据量也变小，带宽压力大幅缓解。这也是为什么现在4-bit量化推理这么流行——你看着是在省显存，其实也在变相提高有效带宽利用率。
投机解码（speculative decoding）的路径不太一样。它的思路是先用一个小模型快速草拟多个token，再用大模型一次性验证。这看起来是计算层面的优化，但仔细想一下，因为草拟的小模型权重小、访存量低，投机解码真正省下来的恰恰是内存搬运的量——用“更多但更便宜”的读取替代“少而昂贵”的读取。
所以说，目前主流推理优化手段，表面五花八门，底层逻辑全是围绕内存做文章。理解了这一点，你在做推理优化的时候思路会清晰很多：任何能减少访存量、降低KV Cache体积、提升数据复用率的优化，效果都不会差。
4. 部署推理集群与单卡时的内存估算
4.1 单卡推理显存怎么粗算
很多刚接触大模型推理的朋友，第一个问题就是：我的卡能不能跑这个模型？这里给一个简单的估算公式，实战中很好用。
单卡推理所需显存，主要由三块构成：
- 模型权重：参数量 × 每个参数的字节数。比如7B模型，FP16就是14GB，INT4量化后大约3.5GB。
- KV Cache：取决于并发数和上下文长度。并发越高、上下文越长，占得越多。
- 运行时开销：框架的中间激活值、CUDA context、推理引擎本身也要占一部分，通常预留个几GB比较稳。
经验上的粗算是：一个7B模型FP16权重大约14GB，如果想跑起来不憋屈，至少要有24GB显存的卡；想跑比较长的上下文和不错的并发，那就得往40GB甚至80GB走了。
我之前用一张A10（24GB显存）跑7B模型的FP16版本，模型权重就占了14GB，KV Cache稍微拉长一点就直接OOM。后来换了量化到INT8的版本，权重降到7GB，才勉强能同时处理十几个并发的短会话。这个例子很典型：内存不够，优化来凑，但优化也解决不了全部问题。
4.2 实际部署中常见的“爆显存”场景
在实际部署中，我踩过最多的坑基本集中在三类：
第一类是用户上下文特别长。很多人测试时只发一句话，显存看着挺宽裕，但线上用户一粘贴大段文档，KV Cache直接起飞，服务瞬间OOM。这个问题的通用解法是限制最大上下文长度，或者在路由层做长度预估，把超长请求分给显存更大的实例。
第二类是并发估算失误。推理框架的并发数不是你想设多少就设多少，每个并发请求都对应一块独立的KV Cache空间。之前我就吃过亏，凭感觉把并发调到32，结果服务刚起来没多久就OOM重启。后来学乖了：先用单请求压测估算每个请求的平均显存占用，再倒推最大并发。
第三类是显存碎片化。长期运行的推理服务，随着请求不断创建和释放KV Cache，显存碎片会越积越多。这也是为什么内存池、显存复用这些技术在推理框架里这么重要。如果框架本身支持类似PagedAttention的机制还好，不支持的话就得定期重启或者用框架自带的内存清理接口。
4.3 内存优化手段的优先级排序
如果你正在做一个推理服务的部署优化，我的建议是按这个优先级来：
- 先做权重量化。这是性价比最高的一步，成本低、收益直接，7B模型从FP16换成INT4之后，显存占用和带宽压力同步下降，推理速度往往反而更快。
- 再用KV Cache优化方案。选一个有PagedAttention或类似机制的推理框架，比如vLLM、SGLang，本身就能帮你在并发场景下省大量显存。
- 然后卡上下文长度。通过服务端配置把单请求的上下文控制在合理范围，避免极端长文本打爆显存。
- 最后才是硬件升级。如果以上都做完了还是不够，那就考虑换更大显存的卡，或者上多机多卡方案。
这套顺序我验证过很多次，基本上能把现有硬件吃干榨净，再谈扩机器的事。
5. 推理芯片内存竞赛的下一步：近存与存内计算
5.1 近存计算：把内存搬到芯片边上
内存带宽的物理极限摆在那里，单纯靠堆HBM堆栈和拉高频，边际收益会越来越低。下一步的竞争方向，正在转向“近存计算”。
近存计算的核心思路很简单：数据搬运的功耗和延迟与距离强相关，那把内存搬得离计算单元更近一点，不就能省下搬运成本吗？现在的HBM已经算是近存的一种初级形态——它通过硅中介层和计算die封装在一起，离得足够近。再往前走一步，就是把SRAM甚至DRAM直接和计算核心做进同一个die或者更为紧密的2.5D/3D封装里。
这个方向对推理芯片尤其有价值。如果能把一部分模型权重或者高频访问的数据直接塞进片上存储，推理时的数据搬运量就能大幅下降。不少新的AI芯片设计里，都把片上SRAM容量作为主打指标，就是这个道理。
5.2 存内计算：真正把“墙”拆掉
比近存更激进的，是存内计算。这个概念通俗说就是：让内存单元本身也具备计算能力，直接在存储的位置做运算，数据根本不用搬出来，那内存墙自然就不存在了。
存内计算在模拟电路层面做矩阵乘法已经有不少实验室成果，但在数字电路、商业化的成熟度上还有很大距离。原因也很现实：通用性差、精度控制难、编程模型不成熟。现在的AI模型结构变化很快，存内计算的硬件一旦固化，很容易被算法迭代甩在后面。
我自己对这个方向的判断是：存内计算短期内不会成为主流，但它会是内存战的终极形态之一。那些现在就在布局存内计算的公司，等的是未来某一天AI负载足够稳定、规模足够大时的那波技术红利。
5.3 给做应用的人的建议
聊了这么多硬件层面的东西，最后落到实际应用的建议。
如果你是一个做推理应用、或者负责AI基础设施的人，这波内存战的直接影响就是：选芯片的时候，别只盯着算力数字看，把内存带宽、容量、能效放到同等重要的位置来评估。我见过不少团队买了算力很强的卡，结果跑推理负载时发现带宽跟不上，实际吞吐远低于预期，钱花得冤枉。
另外，要多关注推理框架层面的创新。现在像vLLM、SGLang、TensorRT-LLM这些框架，几乎每次大版本更新都在内存管理上下功夫。作为使用者，跟着框架的更新走，往往不需要换硬件就能获得明显收益。
还有一点：做容量规划的时候，给KV Cache留的余量一定要够。宁可前期多配一些显存，也不要让服务跑到一半因为内存不足而重启。线上的稳定性，很多时候就是靠这点余量兜底的。
我个人在实际操作中的体会是，搞推理优化这行，核心能力其实就一条：算清楚数据要搬多少、往哪搬、怎么搬得最快最省。理解了这条，无论硬件怎么变、框架怎么迭代，你都能快速找到优化方向。内存战的本质，说到底就是一场围绕“数据搬运效率”的竞赛，而这场竞赛，现在才刚刚进入下半场。
