大模型推理“内存战”：带宽与容量决定性能上限

最近圈子里聊大模型推理，绕不开一个现象：新一代加速卡算力提升其实有限，但大家宁可加价也要抢。核心原因出在显存上——H100到H200，单看FLOPS变化不大，但显存带宽从3.35TB/s拉到了4.8TB/s、容量从80GB翻到141GB，跑70B级别模型的推理吞吐直接上了一个台阶。这就是今天想聊的“推理芯片内存战”：AI算力竞争已经进入下半场，不再单纯拼峰值算力，而是拼内存怎么摆、搬得快不快、装得够不够。

这篇文章适合正在做大模型部署、推理性能优化、或者准备采购加速卡的工程师，以及想理解芯片选型逻辑的产品和技术管理者。我会从内存墙的原理、主流芯片的内存规格、软件层面的省内存策略，一路聊到集群层面的内存调度和未来趋势，最后附上我实际调优时踩过的坑。看完之后，你对“为什么70B模型用四卡比单卡反而快”“为什么同一块卡跑不同模型速度差好几倍”这类问题，会有一个很清晰的答案。

1. 内存墙：推理芯片真正的“命门”

1.1 算力和带宽的剪刀差

先讲一个容易被忽视的事实：GPU的FLOPS（每秒浮点运算次数）这些年涨得飞快，但内存带宽的增速远远跟不上。业内管这个叫“内存墙”——你芯片算得再快，数据从内存搬到计算单元的速度有限，计算单元就只能空转等数据。

大模型推理正好是访存密集型负载。自回归生成每一个token的时候，都需要把整个模型的权重从HBM（高带宽内存）里读出来，才算得动下一步。举个例子：一个70B参数模型，用INT8量化后权重大约70GB，如果你手里的卡带宽是4.8TB/s，那理论极限就是每秒读取完一遍权重70GB，大约能生成68个token。FP16精度的70GB模型更惨，权重翻倍成140GB，每秒只能生成约34个token。再算上注意力计算、KV Cache读写和调度开销，实际值只会更低。

所以你就明白了：在单卡推理场景下，token生成速度的上限，不是算力决定的，而是“每生成一个token要搬多少数据”除以“内存带宽”决定的。买卡的时候与其盯着PFLOPS数字，不如先看带宽和容量。

1.2 容量不够，一切白搭

带宽是“搬得快不快”，容量是“装不装得下”。大模型推理要占内存的不只是权重，还有KV Cache——这是Transformer解码时为了不去重复计算历史注意力而缓存下来的Key和Value矩阵。上下文越长、并发请求越多，KV Cache膨胀得越离谱。

以Llama-3-8B为例，FP16精度下每生成一个token大约需要新增128KB的KV Cache。听起来不多？那把它乘上128K上下文：128KB × 131072 token ≈ 16GB。也就是说，光KV Cache就要吃掉16GB显存，一个请求就能把一整张80GB的卡撑掉五分之一。如果是并发了32路请求，显存直接爆炸。

生活里可以这么理解：带宽决定“上菜速度”，容量决定“桌子大小”。桌子不够大，菜再多也摆不下；上菜太慢，客人等着急。大模型推理这两个都得兼顾。

1.3 为什么过去没人在意内存，现在成了主战场

很多人会问：训练大模型的时候不也要内存吗？怎么以前都拼FLOPS，现在忽然开始拼内存了？

因为训练和推理的访存模式完全不同。训练时可以用大batch size把一批数据同时喂进去，权重在多个样本间复用，计算重、访存相对被摊薄；而且训练更关心整体吞吐，等几百毫秒访存不是什么大问题。推理不一样，它是低延迟的串行生成，一次生成一个token，每一步都要把全部权重读一遍，数据复用率很低。用户要的是“首字延迟越低越好、每秒生成的token越多越好”，访存就成了绕不过去的短板。

高并发和长上下文进一步放大了这个矛盾。用户多一个，KV Cache就要多备一份；上下文拉长一倍，KV Cache也线性增长。训练时代还能将就的内存配置，到了推理场景直接成为瓶颈。这也就是我理解的“内存战”含义：AI算力竞争进入下半场，下半场拼的不再是“能不能把模型训出来”，而是“能不能在有限的成本内把模型跑得又快又稳”。

2. 主流推理芯片的“内存军备竞赛”

2.1 各家芯片内存规格对比

既然内存成了胜负手，芯片厂商自然开始在内存容量和带宽上疯狂加码。我整理了当前几款代表性推理芯片的公开规格，仅供参考：

从这个表能看出两条路线。NVIDIA和AMD都在堆HBM，容量从80GB往192GB走，带宽从3.35TB/s往8TB/s冲。苹果那套则走了不同的路——统一内存，CPU和GPU共用同一片LPDDR内存，带宽虽然远低于HBM，但胜在容量大、成本相对可控，个人电脑上跑7B、13B模型很舒服，但跑70B大模型做高并发推理就不太够用。

2.2 HBM为什么成了兵家必争之地

HBM（High Bandwidth Memory）不是普通内存，它是把多层DRAM芯片垂直堆叠起来、通过硅通孔（TSV）连通的立体结构，再和计算芯片封装在很近的距离上。它的优势就是“宽”——数据通道比传统DDR内存宽很多倍，所以带宽能飙到几TB/s，同时每bit的能耗比GDDR低不少。

但HBM的代价也很大。工艺复杂、良率有挑战、产量有限，一颗加速卡上用的HBM堆叠高度直接决定成本和产能。所以你会发现，新一代芯片更迭，很大一部分精力就是在干一件事：让HBM堆得更高、跑得更快。H200从HBM3换到HBM3e，带宽从3.35TB/s涨到4.8TB/s；B200进一步做到8TB/s，一口气翻了快一倍半。

可以说，芯片厂商之间打的“内存战”，本质上是HBM供应链和封装能力的战争。谁能拿到更多HBM产能、谁能把堆叠和封装良率做上去，谁就能在这轮推理芯片竞争里占据先手。

2.3 没有HBM的路线：大容量统一内存

不过，不是所有场景都非HBM不可。我实测过不少中等尺寸模型的本地部署，统一内存架构反而是更务实的解法。苹果M系列就是典型代表：带宽只有800GB/s上下，但192GB的容量可以无压力加载70B量化模型做本地推理。数据不用在CPU和GPU之间倒腾，减少了很多工程复杂度。

工业界也有人在探索这种思路，比如部分推理加速卡把LPDDR/GDDR做大容量。这类方案的取舍很明确：牺牲带宽、压成本，换更多内存空间。如果业务模型不大、并发不高，完全够用；但如果要跑大规模服务，带宽的短板会很快暴露。

我个人建议：选型时先算清楚自己模型在目标并发和上下文长度下，需要的容量和带宽分别是多少，再决定要不要追逐HBM顶配。很多场景，容量优先的路线会比“无脑上HBM”更省钱、更实用。

3. 软件层的“省内存”与“减搬运”策略

3.1 KV Cache管理：从浪费到按需分配

硬件内存再多，也经不住软件乱用。过去部署推理服务，KV Cache的内存分配非常粗糙：预先划一块连续的大显存空间，按最大长度给每个请求预留。请求多了、长度不一，内存碎片和浪费极其严重，经常出现“显存还有几十GB，新请求却OOM”的尴尬局面。

vLLM提出的PagedAttention把这个问题解决了大半，思路其实借鉴了操作系统虚拟内存分页：把KV Cache切成一页一页的小块，按需分配和释放，不再要求一整块连续空间。效果非常直观——同样的显存容量，并发能力能提升好几倍，长尾请求占用的资源也大幅度下降。

做部署优化的朋友可以把这个当第一优先级：优先换用带PagedAttention的推理框架（比如vLLM、SGLang），或者开启类似的内存池化调度，比单纯换一张大显存的卡性价比高得多。

3.2 量化：把权重和KV Cache“瘦身”

省内存最粗暴的办法就是把数据变小。FP16转INT8，模型权重直接减半；再激进一点转INT4，70B模型的权重能从140GB左右压到35GB，一张80GB的卡就能跑起来。KV Cache也一样，从FP16压到INT8甚至INT4，长上下文的内存压力立刻缓解。

量化不是没有代价。低比特会带来精度损失，尤其对复杂推理任务或者对输出质量要求高的场景，影响可能很微妙。我实际做推理部署的时候，通常会先跑一轮量化后模型的评估集，对比关键指标，再决定用哪个位宽。AWQ、GPTQ这些主流量化方案在质量和加速比上各有所长，建议以自己模型的实测结果为准。

3.3 稀疏激活与MoE：少读一点就是胜利

从降低访存量的角度看，MoE（混合专家）模型是另一个典型的“内存战”打法。虽然这类模型的参数量巨大，但每次推理只激活一小部分专家。比如DeepSeek-V3这类架构，表面上有几百B参数，实际生成一个token时读取的专家权重远小于总权重量，相当于用“稀疏激活”换来了更低的访存压力。

这种思路启发挺大：与其提高总带宽，不如减少必须搬运的数据量。很多推理优化都在往这个方向走——包括把一些不常用的权重放慢速存储，用的时候再换进显存；或者把注意力计算里耗时最长的部分放到SRAM里做分块计算，减少对HBM的读写次数。软件层“省内存”的空间，其实不比硬件堆料小。

4. 从单卡到集群：推理算力集群的“内存协同”

4.1 集群里内存的分布与角色

单卡的内存战只是第一步，真正上规模之后，推理集群的内存问题会更加复杂。当前主流推理集群的构成大致是：每台AI服务器内部插多张加速卡，每张卡带自己的HBM显存；服务器有CPU侧的系统DRAM；再往上有NVMe SSD和分布式存储；卡与卡之间通过NVLink、UB等高速互联，服务器之间由RDMA网络连通。

在这个体系里，HBM是最贵的“快内存”，主要放权重、KV Cache和激活值；CPU内存是“慢一点但是大得多”的中间层，KV Cache溢出的场景可以换到这边（offload）；NVMe则负责做模型权重和检查点的落盘加载。我在实际部署中发现，很多人低估了CPU内存和NVMe在推理链路里的作用——当显存不足时，合理的整体换出策略能救活很多原本OOM的请求。

4.2 并行策略对内存占用和带宽的影响

多卡推理并不是卡越多越好，关键看并行切的是“哪一维”。TP（张量并行）把模型权重按层内切到多张卡上，每张卡只存一部分参数，推理时每张卡只读自己的那一份，多卡的总带宽可以叠加。这就是为什么同样跑70B FP16模型，四卡H100比单卡H100要快得多——单卡受限于单卡带宽，四卡的总带宽是四倍。

PP（流水线并行）更多用于训练，在推理场景会因为卡间通信延迟拖慢整条链路。EP（专家并行）是MoE模型下比较常用的切法，把不同专家放在不同卡上，按需组合。对推理集群来说，我的经验是：优先TP，带宽叠加收益最直接；MoE模型再搭配EP，效果更好。

4.3 长上下文与并发场景下的内存压力调优

长上下文和高并发是所有推理服务的内存噩梦，也是“内存战”真正落地的地方。调试时我会重点看这几个参数：停止条件里的最大序列长度、并发请求数（max-num-seqs）、KV Cache大小、以及是否启用了PagedAttention和换出策略。

实际排查“爆内存”问题，通常是这样一套动作：先用nvidia-smi看GPU显存占用；接着看推理框架日志里KV Cache pool的利用率；再确认并发参数和模型量化位宽；如果显存不够，就考虑开CPU offload、降低并发上限、对KV Cache做量化。顺序很重要，不要一上来就换卡，先把软件层的参数调明白，很多时候省下来的显存等于省下真金白银。

5. 下一步：近存计算、CXL与统一内存架构

5.1 近存计算与存内计算

既然瓶颈在“搬数据”，最彻底的办法就是不搬。HBM本身就是一种近存计算思路，已经把DRAM和计算芯片封装到了一起。再往前走一步，是存内计算（IMC）：把乘加运算直接做进存储单元里，权重不往外面拿，在“内存里”就把部分计算结果算完。

这个方向目前在学术界和个别商业产品里能看到一些苗头，但离大规模落地还有距离。比较务实的是继续优化HBM堆叠结构、扩大芯片上的SRAM缓存。FlashAttention这种算法能在SRAM里分块做注意力计算，避免来回读写HBM，本质上也是在“物理空间和算法层面一起把数据搬运量降下来”。

5.2 CXL内存池化：把内存变成可共享的资源

CXL（Compute Express Link）是另一个值得关注的方向。它让设备之间可以通过标准化协议共享内存，物理上分散的内存可以“池化”成一个大的资源池，需要扩容时动态分配，而不用给每台服务器单独插满内存。

这对推理集群的意义在于：当你开了很多低并发服务，每张卡只用了少量显存，池化内存能让这些碎片化的资源被其他高负载服务用起来。不过要注意，CXL内存的延迟和带宽目前还是低于本地HBM，更适合“容量型”需求，不适合“带宽饥渴”的每token全权重读取场景。

5.3 未来的推理芯片在内存上会有哪些取舍

往后看，推理芯片的内存竞争大概会沿着三条线同时走：第一是把HBM带宽和容量继续往上顶，满足超大模型和超高并发；第二是开发更聪明的缓存和调度策略，让每bit内存都物尽其用；第三是探索统一内存、CXL、近存计算这类结构性创新，把“内存不是一张卡的事”变成现实。

对我来说，这个趋势意味着做推理优化不能再只盯着PFLOPS和模型结构了，得学会站在内存的角度想问题——你的数据在哪里、在哪个层级、搬一次要花多少时间和功耗、能不能少搬几次。这些问题想明白了，选卡、选框架、调参数，心里都会更踏实。

最后分享一个我在实际部署中悟出来的体会：前阵子为了把一个33B模型做成高并发的长上下文服务，最开始想直接上两张大容量卡，结果预算翻倍不说，性能还没有明显提升。后来冷静下来，先把模型做了INT8量化，KV Cache量化到FP8，再换到vLLM开PagedAttention，把并发数压到合理区间——结果同样的单卡就把服务稳稳跑住了，吞吐还比以前翻了一倍。所谓“内存战”，不光是芯片厂商的仗，也是每个部署工程师每天要打的仗。多从内存角度重新审视自己的系统，你会省下很多预算，也少踩很多坑。