最近一次去线下交流会，有人问我：“你训练那个Demo模型的时候，显存爆了没有？”我说爆了，他又问：“那你怎么办？”我想了想，发现能聊的东西还真不少。从调整批量大小、切模型并行、换量化精度，到最后实在不行上CPU offload，几乎每一步都是在跟显存讨价还价。这种感觉不是一个两个人的个案，而是整个AI产业现在集体面对的状态——大家一边追着更大参数量的模型跑，一边被显存容量和内存带宽卡得死死的。说白了，AI产业已经进入了“内存焦虑”时代。

这篇文章想把这件事彻底讲透。我会从内存墙这个概念说起，算一笔模型运行的显存账，再聊聊产业端为什么会为HBM供应商挤破头，最后给你一份从工程角度缓解“内存焦虑”的实操清单。不管你是自己在本地跑模型的开发者，还是负责部署推理服务的人，看这篇应该都能找到几个能直接用的思路。

1. 内存焦虑到底在焦虑什么：算力上的巨人，存储上的矮子

1.1 “内存墙”不是新概念，只是AI把它推到了临界点

先说清楚一个背景。“内存墙”这个词在计算机体系结构里存在很多年了，指的就是处理器算力增长速度远远快于内存带宽和容量的增长速度，导致处理器经常处于“等数据”的状态。早年CPU时代，大家用多级缓存来缓解这个问题，效果还不错。到了GPU大规模并行计算的年代，问题开始显露：GPU的浮点运算能力每两三年翻好几倍，但显存的带宽和容量进步速度明显跟不上。

在AI训练和推理的场景里，这个矛盾被放大了。因为Transformer架构的模型，计算过程本质上就是反复做矩阵乘法和注意力计算，每一次操作都要把大量权重和中间结果从显存里搬进搬出。当一个7B量级的模型需要几十GB显存来放下参数、梯度和优化器状态时，算力再强也会被“喂不饱数据”拖住。我实测过，同样的推理任务，在显存带宽高的平台上跑，速度可能比带宽低的平台快一倍都不止，哪怕两者的算力规格看起来几乎一样。

1.2 从“算力焦虑”到“内存焦虑”的转变是怎么发生的

前几年大家聊AI基础设施，挂在嘴边的是“多少P算力”“多少张卡”。当时的主流判断是，算力是瓶颈，只要把显卡堆上去，大模型就能训练出来。但这两年风向变了。模型参数从十亿级别冲到千亿级别，单张显卡的显存还是停在几十GB的量级，于是很多人发现，卡再多，也可能被显存卡住。

具体到场景里，训练一个大模型，光是把参数和梯度塞进显存就够喝一壶的了。而推理侧也没有好到哪里去，长上下文、大批量并发请求，会让KV Cache大幅膨胀，把原本还算富裕的显存瞬间挤满。我见过太多人为了把模型装进显存，从FP16换到INT8再换到INT4，每一步都在牺牲精度换容量。这种“手头资源永远差一口气”的状态，就是内存焦虑最直观的体现。

1.3 内存焦虑的三个具体表现

如果你觉得“焦虑”这个词太抽象，我可以拆成三个现象，对照看看就知道说的是什么。

一是显存容量焦虑。模型放不下，或者放进去之后没有空间跑推理和训练，这是最直接的。二是带宽焦虑。就算显存够大，一次性把数据搬进显存的通道太窄，导致GPU核心大量时间在空转等数据，表现出来就是算力再高也跑不快。三是成本焦虑。高带宽显存的价格水涨船高，产能又有限，想要大容量高带宽的硬件，就得接受非常夸张的采购成本和排期。

这三个焦虑往往是叠加出现的。之前我在某公司帮他们评估一个70B级别模型的服务化部署方案，原计划用8卡并行推理，结果因为显存带宽和显存容量的限制，最后换成了更贵的方案。后来我发现，如果当时先做一遍量化再上，用4卡就能满足需求。这就是典型的“用资源换时间”和“用工程换资源”之间的权衡。

2. 算一笔显存账：模型跑起来到底吃掉了多少内存

2.1 训练时的显存分配：参数、梯度、优化器状态三座大山

很多人以为训练模型只是把参数放进显存就行了，实际远不止。一次完整的训练，显存里有四大块占用：模型参数、梯度、优化器状态、中间激活值。前三个加起来才是真正的“硬占用”。

以某开源7B FP16模型为例，单是参数就是14GB显存，梯度同样要14GB，优化器状态按AdamW来算，需要复制的动量参数和方差参数，至少是28GB。也就是说，光是这三项就已经56GB，还没算数据和激活值。这就解释了为什么很多人微调7B模型，一张24GB的卡基本转不开，往往得上多卡或做梯度累积、混合精度。

我建议任何人拿到一个模型之后，先做一道乘法题：参数量乘以2字节（FP16），再乘以1到3倍，就是训练时跑起来最基础的显存占用。如果算出来超过手头显卡的显存，后面的各种优化技巧都只是补救，本质上你还是“放不下”。

2.2 推理时最容易被忽略的显存刺客：KV Cache

推理阶段和训练不同，不需要梯度，也不需要优化器状态，显存压力主要集中在参数和KV Cache上。KV Cache是什么呢？在生成式模型推理时，每处理一个新token，都需要拿它的查询向量Q去和历史所有token的键向量K、值向量V做对比。为了避免每次都重算历史token的K和V，推理框架会把这些结果缓存下来。

问题在于，这个缓存的大小和序列长度、层数、头数、隐藏维度全部挂钩。我算过一组数：一个8B模型，上下文长度从2K扩展到32K，KV Cache的占用可能从不到1GB暴增到十几GB，直接超过模型自身参数。这就是为什么长上下文应用是显存消耗的大户，也是为什么处理长文档时大家总在调KV Cache相关参数。

所以部署推理服务时，模型参数只能算“基础负债”，KV Cache才是那个“浮动负债”。你真正要预留的显存不是把参数放进去就够，而是“模型参数 + 最大并发数 × 每请求KV Cache容量 + 推理框架的运行时开销”这个总和。

2.3 一张表看清不同规模模型的实际显存需求

为了方便参考，我把常见模型规模在训练和推理场景下的显存需求整理成了一张表。注意这只是近似值，实际会因子模型实现、框架、量化方式不同而浮动，但用来做前期规划足够：

每次看到这张表，我都会想起一个观点：“推理时的显存需求不是线性的，它会随着并发和上下文长度跳跃式上涨。”所以，不要只根据模型参数大小决定部署方案，一定要把你的实际业务特征，特别是上下文长度和并发数，代入算一遍。

2.4 激活值：训练时那个被忽视的“隐形杀手”

很多人算训练显存时只算了参数、梯度、优化器状态，却忽略了中间激活值。实际上激活值在某些模型结构下能占到训练总显存的30%到50%。因为前向传播过程每一层的输出都要先存下来，反向传播时才拿去做梯度计算。层数越多、序列越长、batch越大，激活值越大。

后来有个很实用的经验：用激活值重计算技术，也就是把中间结果丢弃一部分，等反向传播时再重新算一遍，用少量计算换大量显存。这在显存吃紧时非常管用，我经常把它放在优化方案的前三选择里。虽然训练时间会变长，但至少能让大模型在有限显存里“转得起来”。

3. 产业端的内存博弈：HBM、硬件路线与部署格局

3.1 高带宽显存为什么变成“硬通货”

既然显存容量和带宽都重要，那产业界最关注的当然就是高带宽内存芯片了。这类产品把多个DRAM芯片堆叠在一起，通过硅通孔实现超高带宽和超大容量。现在主流的AI加速卡几乎都搭载了这类高带宽显存，容量越大、带宽越高，卡的售价就越夸张。

问题在于，高带宽显存的制造工艺复杂，良率爬升慢，供应量远远跟不上AI加速卡的需求。我就亲眼看到某AI公司为了拿到足够的高带宽显存配额，提前大半年跟供应商签协议，而且还在高峰期溢价采购。这种供需失衡带来的结果就是：好卡难抢、贵卡更贵，整个产业的扩张节奏都得跟着内存供应链走。

3.2 GPU厂商的应对：更大显存、更复杂的存储层次

面对“内存焦虑”，硬件端也在改变。一个很明显的趋势是，新一代加速卡开始把显存做得越来越大，甚至出现了“超大显存版”的产品线，目的就是让客户能把更大模型放到单卡上，减少跨卡通信的开销。

另一个趋势是存储层次越来越复杂。过去大家只关心显存和CPU内存，现在在AI场景里，还有CPU内存、SSD近存、远端存储等多种层次。算得慢没关系，关键是容量要够、层次要能串联起来。这种设计思路其实借鉴了传统计算机体系结构里的“金字塔存储体系”，把最热的数据放显存，冷一点的数据放CPU内存，最不常用的甚至可以放硬盘。

3.3 软件生态的补位：算子库和推理框架在想办法“抠内存”

硬件不够，软件来凑。算子库方面，各家都在优化内存分配策略，减少碎片化，提高显存复用率。推理框架则在模型加载、量化、批处理调度上下了很多功夫。比如有些框架支持动态批处理，把不同请求打包在一起，共享KV Cache空间，这样同样的显存能服务更多并发请求。

我个人的感受是，软件生态的优化空间一直存在，而且很多时候比单纯加硬件性价比高得多。之前有一个推理服务，高峰期并发一直起不来，后来调整了批处理策略和KV Cache的显存复用方式，并发能力直接提升了30%，而硬件一台没加。所以说，内存焦虑虽然严重，但别只盯着买卡，软件层的优化潜力真的值得先榨干净。

3.4 为什么“内存焦虑”短期不会消失

就算硬件和软件都在努力，内存焦虑还是很难在短期内消失。原因很简单：模型的增长速度和上下文长度增长速度，依然比内存技术的演进速度快。面世的大模型动不动就是几百GB的权重，而单卡显存容量才几十GB到一百多GB，靠单卡放模型这件事，在超大模型上已经行不通了。

所以可以预见到的是，未来一段时间里，大家还是会一边追新模型，一边在各种并行方案、量化方案、offload方案里腾挪。内存依然是AI产业最稀缺的资源之一，谁能在有限内存里跑更大的模型，谁就能省下实实在在的基础设施成本。

4. 实战缓解“内存焦虑”的七种方案

4.1 量化优先：FP16到INT8再到INT4的取舍之道

量化是目前性价比最高的显存优化手段。原理很简单，就是用更低比特数来表示模型权重，从而减少显存占用。把一个FP16模型转成INT8，权重显存直接减半；转成INT4，能再减一半。对于70B级别的模型，从FP16到INT8能省下70GB左右，这是非常可观的数字。

但量化不是无代价的。精度下降是最大的担忧，尤其是在低比特量化下，模型输出质量可能明显退化。我的经验是，先做校准集量化，观察业务核心指标有没有退化，如果退化在可接受范围内就采用；激进一点可以试试混合精度量化，把敏感层保留高精度，非敏感层用低比特。实际项目中，很多服务模型现在都跑INT8甚至INT4，效果依然能打。

4.2 Offload策略：把东西放到“稍慢但更大”的存储里

显存不够的时候，可以考虑把一部分数据挪到CPU内存甚至NVMe硬盘里，这就是offload。它的核心思想是，不是所有数据都需要放在最快的存储里，把那些访问频率低的数据放到慢一点的存储，能大幅释放显存空间。

我记得网上有种说法挺形象的：“别把所有鸡蛋放在一个篮子里，CPU内存那么大，不用白不用。”确实，很多时候模型权重、优化器状态这种低频访问的数据，完全可以offload到CPU内存；只在计算时才把当前需要的部分搬到GPU显存。代价是增加了数据传输时间，如果offload策略没调好，训练速度可能腰斩。但它总比直接OOM，什么都干不了要强得多。

最佳实践是把offload和计算流水线结合起来：在GPU计算当前batch时，后台线程预取下一batch需要的数据，让显存和CPU内存之间的数据传输和计算重叠起来，这样能最大程度减少等待时间。

4.3 并行切分：把一个模型拆到多张卡上

当单卡显存实在放不下整个模型时，用多卡并行是绕不开的路。模型并行、流水线并行、张量并行、数据并行，这些词汇听起来复杂，但本质上就是“把模型按不同维度切开，分布到不同卡上”。

在我做多卡推理的经验里，张量并行是最直接见效的。把一个大的矩阵乘法拆成多份，分别在不同卡上算，最后做一次结果合并。模型越大，可切分的空间越大，多卡并行带来的增益越明显。不过通信开销是绕不开的成本，卡与卡之间需要频繁同步中间结果，需要高速互联来支撑。

一个实用的建议是：并行度和显存节省之间不是线性关系，但通信开销会随之上涨。所以在选择并行方案前，先估算一下你的模型到底卡在显存容量还是通信瓶颈，两边的权重不一样，方案会差很多。

4.4 微调阶段的显存拯救：LoRA和梯度检查点

对于要不要全量微调模型这件事，我的态度一直是：能不上全量就不上。某开源7B模型全量微调动辄需要数十GB显存，而对绝大多数业务来说，低秩适配这种参数高效微调方法完全够用。它本质上是冻结原模型权重，在旁边加一个小型可训练分支，训练时只有这部分参数的梯度和优化器状态需要保存。

用这种方式，显存占用能降低一个数量级。我当时在24GB显存平台上微调7B模型，用全量方式基本跑不动，切到低秩适配之后不仅跑起来了，还能把上下文长度往上调。

梯度检查点也值得一试，它牺牲一部分计算量，来换取前向激活值不用全部存储。这招对训练显存优化非常有效，原本因为激活值OOM的任务，开了梯度检查点之后往往就能跑通了。

4.5 推理阶段的动态优化：批处理与KV Cache复用

推理服务的显存压力主要来自并发请求带来的KV Cache膨胀。动态批处理的核心思路是，不同请求生成的token数量不一样，与其等到所有请求都结束再统一返回，不如提前结束的请求立刻释放显存，把空间让给新请求。这样同样的显存能承载更高的并发。

KV Cache复用则是把相同前缀请求的KV Cache直接共享。比如多轮对话场景中，前面的对话历史是完全一样的，那就不需要重复计算和存储，直接复用已有缓存。很多推理框架都已经内置了这些能力，关键是业务方要去开启和调参。我遇到过不少团队，模型部署了但功能没开全，白瞎了硬件。

4.6 流式加载：让模型从硬盘“边跑边读”

如果连量化加多卡并行都无法把模型完全塞进显存，还可以考虑流式加载。这个方法不要求模型全部常驻显存，而是按需把当前计算需要的权重部分动态加载到显存中计算，算完再释放，继续加载下一部分。

听起来很美好，但它的瓶颈直接落在存储带宽上。如果用的是普通SSD，读取速度可能只有几GB/s到十几GB/s，远低于显存带宽。所以流式加载一般是“能跑但跑不快”的状态，EDGE场景或者对延迟不敏感的任务可以试试，生产环境的高并发服务就别指望它了。

4.7 换模型：焦虑的终极解药可能是“够用就好”

最后一条建议可能很多人不爱听，但它是真实有效的：如果某个模型的显存需求远超你的硬件能力，可以考虑换一个参数量更小但能力相近的模型。现在的模型领域越来越卷，小模型通过更好的训练数据和知识蒸馏，在很多任务上的表现已经追平早期的大模型。

我自己就做过一个项目，原本计划用某70B级别模型，后来业务实测发现某7B级别的量化版完全能打，推理速度还快了好几倍，显存占用从几百GB直接降到十几GB。内存焦虑有时候不是“不够多”，而是“选择不对”。用尽可能小的模型满足业务需求，才是性价比最高的解法。

5. 常见问题与排查技巧实录

5.1 遇到CUDA Out of Memory错误，怎么一步步排查

CUDA OOM是所有做AI的人都遇到过的经典报错。第一次遇到时可能很慌，但排查顺序其实很固定。先看是不是别的进程占用了显存，用显存查询命令确认；然后看自己的代码有没有显存泄漏，比如循环里反复创建显存张量没有释放；再下来看模型本身的大小和输入数据的大小，是不是真的超出了硬件能力。

我遇到过一个印象很深的案例：某同学跑同一个模型，换一台机器就OOM，查了很久才发现是机器上后台还跑着其他占用显存的服务。这种案例提醒我们，很多时候问题不在模型本身，而在环境。

5.2 推理速度很慢，怎么判断是算力瓶颈还是带宽瓶颈

这是一个很容易误判的问题。算力瓶颈的典型特征是GPU计算单元利用率很高，但是整体吞吐上不去；带宽瓶颈的典型特征则是计算单元大量空闲，在等数据从显存里搬过来。工具上看，可以用性能分析工具把GPU的算力利用率和显存带宽利用率打开，一眼就能看出是哪一边的问题。

针对两种瓶颈的解法不同。算力瓶颈可以考虑换更高算力的卡，或者优化计算逻辑减少无效计算；带宽瓶颈则更适合做量化、减少数据搬运量、优化数据布局。我见过有人明明是带宽瓶颈，却砸钱换了算力更高的卡，结果速度没有任何提升，这就是典型的没找准病根。

5.3 量化之后模型效果变差，该怎么定位

量化后效果变差，先别急着否定量化。看看是不是校准数据集选得不够有代表性，或者是不是某些层对量化特别敏感。定位方法很简单：逐层对比原模型和量化模型在验证集上的输出差异，找到差异最大的层，把这些层单独设置成高精度，其他层继续低比特量化。

我自己调试过一个大模型，量化后回答质量明显下降，逐层排查发现是某一层对激活值分布特别敏感，单层改成FP16之后整体效果立刻恢复了大半，而显存只增加了一点点。这种精细化调优，是内存焦虑时代每个人都要掌握的技能。

5.4 多卡并行效率上不去，先检查通信和负载均衡

多卡并行时发现加速比达不到预期，优先查两件事：一是卡间通信带宽利用率是不是被打满了，二是各卡的负载是不是均衡。如果某张卡明显比其他卡慢，整个并行任务都会被它拖住。

负载不均衡的常见原因是模型切分没有做好，各卡拿到的计算量差异很大。通信开销占比过高则往往是因为并行策略不适合当前模型结构。这时可能需要把张量并行调整成流水线并行，或者反过来，具体要看模型的计算特性和通信拓扑来决定。

6. 我在内存焦虑时代的一些个人体会

做AI工程这些年，我最大的感受是：资源永远是稀缺的，如何在稀缺资源下把效果做到最好，才是真正的核心能力。内存焦虑不完全是坏事，它在逼着整个行业去优化、去思考，而不是无脑堆硬件。

有几个小技巧我一直用到现在，分享给各位：

第一，任何模型部署前，先花五分钟算一下显存账。模型参数量、KV Cache、框架开销都算进去，再预留一定余量，别等到OOM才后悔。第二，优先考虑量化，这是性价比最高的优化手段，而且用对方法之后效果损失常常可以忽略。第三，多学一点推理框架的高级功能，很多显存优化能力框架内已经内置，只是默认没开，翻一下配置文件可能就有惊喜。

内存焦虑时代，拼的就是谁能用更少的资源跑更大的模型、扛更多的并发。希望这篇东西能帮你在面对显存不足时少走一些弯路。