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就是14GBINT4量化后大约3.5GB。KV Cache取决于并发数和上下文长度。并发越高、上下文越长占得越多。运行时开销框架的中间激活值、CUDA context、推理引擎本身也要占一部分通常预留个几GB比较稳。经验上的粗算是一个7B模型FP16权重大约14GB如果想跑起来不憋屈至少要有24GB显存的卡想跑比较长的上下文和不错的并发那就得往40GB甚至80GB走了。我之前用一张A1024GB显存跑7B模型的FP16版本模型权重就占了14GBKV 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留的余量一定要够。宁可前期多配一些显存也不要让服务跑到一半因为内存不足而重启。线上的稳定性很多时候就是靠这点余量兜底的。我个人在实际操作中的体会是搞推理优化这行核心能力其实就一条算清楚数据要搬多少、往哪搬、怎么搬得最快最省。理解了这条无论硬件怎么变、框架怎么迭代你都能快速找到优化方向。内存战的本质说到底就是一场围绕“数据搬运效率”的竞赛而这场竞赛现在才刚刚进入下半场。