12GB显存跑SDXL图像生成：FP16与CPU卸载实测对比

显存不够这件事，几乎是每个跑本地图像生成模型的人都会撞上的墙。我手头这张卡只有12GB显存，平时跑常规分辨率的图还算从容，可一旦把分辨率拉到接近2K、又叠加高步数和复杂采样器，显存曲线就跟坐了火箭一样往上窜，动不动就给你来个内存溢出中断。最近我在折腾一个基于SDXL架构的通用图像生成模型，社区里习惯叫它“万象熔炉”或者Anything XL，这类模型参数体量大、文本编码器也重，对显存的胃口比早期模型大得多。为了让它在我这张卡上稳定跑起来，我把目光投向了两个最常被提及的优化手段：FP16半精度推理和CPU卸载。这篇内容就是我把这两套方案前后显存占用实测数据摊开对比的完整记录，顺带把参数怎么调、坑在哪里、什么场景该用哪种方案讲透。不管你是刚入门想搞清楚显存到底被谁吃掉了，还是已经跑过几轮但总在爆显存边缘反复横跳，应该都能从下面的实测数据里找到对你有用的部分。

1. 先搞清楚显存到底被谁吃掉了

在动手做对比之前，得先弄明白一件事：跑一次图像生成，显存里到底装了什么。很多人以为显存占用就是模型文件大小，其实远不止。我见过不少新手拿着一个6GB多的模型文件，纳闷为什么12GB的卡还会爆，问题就出在对显存构成的理解上。

1.1 模型权重的常驻占用

模型权重是最直观的一块。一个完整的SDXL类模型，包含UNet主干、两个文本编码器（一个负责主提示词、一个负责补充语义），以及VAE解码器。这些组件在加载后都会以某种精度常驻在显存里。以FP32全精度加载时，一个参数量在25亿到30亿级别的UNet，光权重就要吃掉10GB上下，再加上文本编码器，总量轻松突破12GB。这就是为什么很多人默认配置下第一步加载就失败——还没开始生成，显存已经见底了。

换成FP16半精度，每个参数从4字节压到2字节，权重占用直接砍半。这是最立竿见影的一刀，也是我后面实测里第一个要验证的变量。需要说明的是，半精度并不是简单粗暴地截断，而是把浮点数的表示范围做了取舍，对图像生成这种对数值精度要求没那么苛刻的任务来说，画质损失在肉眼层面基本可以忽略，但显存收益是实打实的。

1.2 激活值与中间张量的动态占用

权重只是静态部分，真正让显存曲线剧烈波动的是推理过程中的中间张量。扩散模型是迭代去噪的，每一步都要在UNet里做大量的卷积和注意力计算，这些计算会产生大量中间激活值。分辨率越高、批次数越大，这部分占用越夸张。我实测过，同样一个模型，512×512出图和1024×1024出图，峰值显存能差出3到4GB，差距主要就来自这里。

注意力机制是中间张量的大户。自注意力和交叉注意力在计算时需要存储查询、键、值的矩阵，序列长度跟图像的分辨率平方相关。分辨率翻倍，注意力矩阵的元素数量翻四倍，这就是高分辨率出图显存暴涨的数学根源。理解这一点很关键，因为它决定了后面优化手段的适用边界——CPU卸载能缓解权重占用，但对单步计算内部的峰值激活帮助有限。

1.3 VAE解码阶段的瞬时峰值

还有一个容易被忽略的环节是VAE解码。扩散过程在潜空间里完成，最后一步要把潜变量解码成像素图像，这个解码过程本身也会产生不小的显存峰值。尤其是解码高分辨率图像时，VAE的上采样层会瞬间拉高占用。有些人前面采样都顺利，偏偏在最后解码阶段爆显存，就是栽在这里。这部分占用是瞬时的，但峰值往往比采样阶段还高，做显存规划时必须把它算进去。

把这三块拆开看，优化的思路就清晰了：FP16主要压权重，CPU卸载主要把权重挪走腾地方，而激活值和VAE峰值则要靠分辨率控制、分块解码等手段来对付。下面两套方案的实测，就是围绕这几块占用此消彼长的关系展开的。

2. FP16半精度方案：最划算的第一刀

如果只能选一个优化手段，我会毫不犹豫选FP16。它改动最小、收益最大、对画质影响最小，几乎是所有显存优化的起点。这一节我把实测数据和参数细节都摆出来。

2.1 为什么FP16是默认首选

从FP32切到FP16，权重占用理论上直接减半，实测下来也基本吻合。我用同一个模型分别以两种精度加载，在完全相同的出图参数下记录加载完成后的静态显存占用，FP32版本加载完就逼近11GB，而FP16版本稳定在6GB出头。这中间省出来的近5GB，足够把分辨率往上提一档，或者把批次数从1加到2。

更关键的是速度。半精度运算在现代显卡上的吞吐能力远高于全精度，我实测同一张图、同样步数，FP16比FP32快了将近40%。这个提升不是线性的，因为还涉及到显存带宽和计算单元的调度，但方向很明确：精度降一半，速度反而涨。对本地部署来说，这几乎是白捡的性能。

画质方面我做了仔细的对比。同一组提示词、同一个随机种子，FP32和FP16各出一张，放大到200%逐像素看，差异集中在极少数高频细节区域，比如细密的毛发纹理或者极细的线条边缘，FP16会略微平滑一点点。但这种差异在正常观看距离下完全看不出来，而且可以通过稍微提高步数或者换更精细的采样器来弥补。我的判断是：除非你在做需要严格可复现的科研对比，否则FP16没有任何犹豫的必要。

2.2 实测数据：加载与出图两阶段对比

我把实测数据整理成表格，方便你直接对照自己的硬件做参考。测试环境是一张12GB显存的显卡，模型为同一份权重文件，出图分辨率1024×1024，采样步数30，批次1，使用相同的采样器和调度器。

从数据能看出几个规律。第一，节省量在三个阶段基本一致，都在4.8GB左右，说明FP16对权重和由权重衍生的中间计算都有均匀的压缩效果。第二，FP32配置下峰值已经顶到11.9GB，离12GB上限只差一点点，任何一点额外开销都会导致失败，这就是“边缘触发”的含义——有时候能跑通，有时候就崩，非常不稳定。第三，速度提升接近四成，这个收益在批量出图时会被放大得非常可观。

提示：不同显卡的显存带宽和计算单元配置不同，绝对数值会有出入，但FP16相对FP32的节省比例和提速比例大体稳定。你可以用自己硬件跑一遍对照，重点看峰值是否留出了至少1GB的安全余量。

2.3 开启FP16的实操要点与常见坑

开启FP16本身不复杂，主流推理框架基本都支持一个精度参数或者加载选项。但有几个细节不注意就会踩坑。

第一个坑是混合精度不等于全半精度。有些框架提供的是自动混合精度，也就是大部分算子用FP16、少数对数值敏感的算子（比如某些归一化层）保留FP32。这种模式显存收益略小于纯FP16，但数值稳定性更好。我建议优先用混合精度，除非你确认纯FP16在你的模型上不产生溢出或黑图。

第二个坑是VAE精度要单独设置。很多人把UNet设成FP16就以为万事大吉，结果VAE还是FP32，解码阶段照样爆。VAE对精度相对敏感一些，但大多数情况下FP16也能正常工作，如果出现解码后图像发灰或者色彩异常，再把VAE单独切回FP32，用分块解码来压峰值。

第三个坑是文本编码器的精度。SDXL类模型有两个文本编码器，其中一个对精度比较敏感，强行半精度可能导致提示词理解偏差，表现为某些概念生成不出来或者语义漂移。稳妥的做法是文本编码器保持FP32或混合精度，只把UNet压到FP16，这样显存收益略减但稳定性最好。我实测这个组合下静态占用约7GB，仍然比全FP32省了近4GB。

# 伪代码示意：分组件设置精度 pipe = load_pipeline(model_path) pipe.unet.to(dtype=torch.float16) # UNet 半精度，收益最大 pipe.vae.to(dtype=torch.float16) # VAE 半精度，注意观察解码质量 pipe.text_encoder.to(dtype=torch.float32) # 文本编码器保精度，稳定优先

这段配置是我反复试下来平衡性最好的组合。如果你显存特别紧张，可以把VAE也压到FP16并开启分块解码；如果显存宽裕，文本编码器保持FP32能换来更准确的提示词响应。

3. CPU卸载方案：把权重请出显存

FP16解决的是“每个参数占多少地方”，CPU卸载解决的是“参数该待在哪里”。思路很直接：显存不够，那就把暂时用不到的模型组件挪到内存里，等真正需要计算时再搬回显存。这套方案在显存极度紧张时几乎是救命稻草，但代价也很明显。

3.1 CPU卸载的工作原理拆解

扩散模型的推理是有明确阶段性的：先由文本编码器把提示词编码成条件向量，然后UNet反复迭代去噪，最后VAE解码出图。这三个阶段是串行的，同一时刻只有一个组件在满负荷工作。CPU卸载正是利用了这个特性——文本编码完成后，把文本编码器挪到内存；UNet采样时只留UNet在显存；采样结束再把UNet挪走，换VAE进来解码。

这种“按需搬运”的机制，让显存里同时只需要容纳一个组件，理论上峰值占用能降到单个最大组件的水平。听起来很美，但搬运本身是有成本的：权重在内存和显存之间传输要走总线，这个带宽远低于显存内部带宽，所以每次搬运都会带来明显的延迟。这就是为什么开了CPU卸载之后，出图时间会肉眼可见地变长。

还有一个变种叫顺序卸载，它做得更细，连UNet内部的层都可以逐层搬运，显存占用能压到极低，但速度损失也更大。我一般不建议普通用户开到这个粒度，除非你的显存真的小到离谱，比如8GB以下还想跑高分辨率。

3.2 实测数据：卸载前后的显存与耗时对比

我在FP16的基础上叠加CPU卸载，做了第二组实测。测试条件与上一组保持一致，重点观察显存峰值和耗时的变化。

数据很能说明问题。显存峰值从接近7GB压到了3.6GB左右，这个水平意味着8GB甚至6GB的卡都能比较从容地跑1024×1024出图了。但代价是耗时从23秒涨到41秒，慢了将近八成。这个交换是否划算，完全取决于你的硬件处境：显存够用的人绝不会开它，显存不够的人不开它就跑不起来，没得选。

我特别想强调一个观察：卸载后的显存占用并不是简单地等于最大组件的大小，而是略高于它。原因是搬运过程中存在短暂的“新旧共存”窗口——新组件搬进来、旧组件还没完全释放，这个重叠期会推高瞬时峰值。所以做显存规划时，不能只按单个组件的理论大小来算，要留出这部分重叠余量，我一般按最大组件大小的1.2倍来预估比较稳妥。

3.3 卸载策略的选择：全量还是分层

CPU卸载不是只有开和关两个选项，不同框架提供了不同粒度的策略，选错了要么收益不够要么慢得离谱。

组件级卸载是最常用的，也就是前面说的文本编码器、UNet、VAE之间互相搬运。它的显存收益中等，速度损失可接受，适合显存缺口在2到4GB的场景。我实测这个模式下，显存能压到3.5GB上下，速度损失在七八成，是大多数人的默认选择。

层级卸载把粒度细化到UNet内部的每一个残差块，显存能压到2GB以下，但速度损失可能翻倍甚至更多。这种模式我只在一种情况下推荐：显存实在太小，比如6GB卡想跑1024分辨率，不开层级卸载根本进不去，那就只能忍受慢。

智能卸载是近几年一些框架引入的策略，它会根据当前显存余量动态决定搬哪些、留哪些，试图在速度和显存之间找平衡点。实测下来它的表现介于组件级和层级之间，但行为不够可预测，调试时不太好定位问题。我个人的偏好是手动指定组件级卸载，行为明确、容易排查。

注意：开启CPU卸载后，内存占用会显著上升，因为权重都堆在内存里。如果你的内存本身就不宽裕（比如只有16GB），同时开卸载又加载大模型，可能从显存不足变成内存不足。做优化时要两头都看一眼，别顾此失彼。

4. 两套方案怎么选：场景化决策

数据摆完了，真正的问题是：我到底该用哪套？答案不是二选一，而是看你的显存水位和出图需求。这一节我把常见场景列出来，给出对应的配置建议。

4.1 按显存容量对号入座

显存容量是最直接的决策依据。我把常见容量和推荐配置整理成对照表，你可以直接对号入座。

这张表的核心逻辑是：先用FP16把权重压到最低，再看剩余显存够不够容纳峰值激活，不够再上卸载。顺序不能反，因为FP16的性价比远高于卸载，先上卸载等于白白牺牲速度。

12GB这个档位特别值得说。从数据看，FP16不卸载的峰值约7GB，12GB卡有充足余量，完全没必要开卸载。我见过有人12GB卡也开着卸载，结果出图慢了一倍还浑然不觉，这就是没做实测、凭感觉优化的典型。显存优化要基于数据，不能基于焦虑。

4.2 按出图需求反向选择

显存不是唯一变量，出图需求也会反过来影响配置选择。如果你追求的是批量出图、快速迭代，那速度就是第一优先级，只要显存不爆，坚决不开卸载。我批量跑图时会把FP16拉满、卸载全关，哪怕峰值顶到显存上限的九成也认了，因为省下来的时间远比那点显存余量值钱。

如果你追求的是极限分辨率，比如1536×1536甚至更高，那显存峰值会成倍上涨，这时候卸载就成了必需品。我的做法是分辨率超过1280时默认开启组件级卸载，把省下的显存留给激活值。高分辨率下激活值的增长是非线性的，前面算过注意力矩阵跟分辨率平方相关，所以分辨率越高，卸载的收益越明显。

还有一种情况是多任务并行。有些人一边跑图一边还开着别的吃显存的应用，这时候显存预算要打折扣，即便总容量够，实际可用也可能不够。这种场景下我建议保守配置，宁可开卸载慢一点，也别在关键时刻爆掉中断。

4.3 组合拳：FP16加卸载加分辨率控制

实际优化往往不是单一手段，而是几套组合拳。我总结了一个优先级顺序，按这个顺序调，基本能覆盖绝大多数场景。

第一步永远是开FP16，这是性价比最高的一刀，没有理由不做。第二步是控制分辨率，在画质可接受的前提下，优先用模型的原生训练分辨率，避免无谓的超采样。第三步才是开CPU卸载，作为显存不足时的兜底。第四步是分块VAE解码，专门对付解码阶段的瞬时峰值，它不影响采样速度，只在最后一步生效，属于低成本的保险措施。

这个顺序背后的逻辑是：越靠前的手段，对速度的伤害越小、对显存的收益越大。把低成本高收益的手段用尽，再动用高成本的手段，才是合理的优化路径。很多人一上来就开卸载，结果速度慢得没法用，其实是把顺序搞反了。

5. 实操中踩过的坑与排查清单

数据和方案讲完了，最后这部分是我在实际操作中攒下来的经验，都是文档里不会写、但真遇到时能救命的东西。

5.1 那些让人抓狂的典型问题

问题一：开了FP16之后出图发黑或者全灰。这个我遇到过两次，一次是VAE精度问题，一次是某个归一化层在半精度下数值溢出。排查思路是先单独把VAE切回FP32看是否恢复，如果恢复了就是VAE的锅，用分块解码配合FP32 VAE解决；如果没恢复，就检查是不是用了纯FP16而非混合精度，换成混合精度通常能解决。

问题二：卸载开着，显存还是爆。这种情况多半是卸载策略没覆盖到峰值来源。组件级卸载只搬权重，但高分辨率下的激活值峰值它管不了。解决办法是降分辨率或者开分块解码，把激活峰值压下去。还有一种可能是卸载的重叠窗口推高了瞬时占用，把批次降到1、步数适当减少能缓解。

问题三：速度慢得离谱，怀疑没生效。先确认卸载是不是真的在搬运，有些框架的配置项名字很相似，开错了等于没开。再确认是不是不小心开了层级卸载，那个粒度下慢是正常的。最后看内存是不是吃紧了，内存不足会导致频繁换页，速度会断崖式下跌。

问题四：同一套配置，有时成功有时失败。这是最折磨人的。根源通常是峰值贴着显存上限，系统其他进程的微小波动就会导致结果不同。解决办法不是反复重试，而是主动留出安全余量，把峰值压到上限的八成以下，稳定性会好很多。

5.2 一份可以直接照着查的速查表

这张表我建议存下来，遇到问题按行对照，能省下大量瞎试的时间。排查的核心思路是分段定位：把加载、采样、解码三个阶段分开观察，看峰值到底出现在哪一段，再针对那一段下手。一上来就全局调参，往往越调越乱。

5.3 几个容易被忽视的细节

第一个细节是显存监控要实时。很多人只在出图结束后看一个总数，这没用，因为峰值是瞬时的。要用能记录峰值的监控工具，或者干脆在关键节点手动打点，才能抓到真正的峰值出现在哪一步。我习惯在加载后、采样中、解码前各记一次，三次数据一对比，瓶颈一目了然。

第二个细节是随机种子的影响被低估了。不同种子生成的图像复杂度不同，激活值的峰值也会有波动。做显存测试时要用固定种子，否则数据没有可比性。我早期做对比时就吃过这个亏，同一套配置两次测试差了0.5GB，查了半天才发现是种子不同导致的。

第三个细节是驱动和框架版本。半精度的算子支持、卸载的调度效率，都跟框架版本强相关。升级框架有时能白捡性能，有时反而引入回归。我的做法是优化前先固定一个已知稳定的版本，把基线数据测出来，再考虑要不要升级，升级后重测对比，避免盲目追新。

第四个细节是别忽略系统层面的占用。桌面环境、浏览器、其他后台程序都会占显存，做测试时尽量关掉无关应用，否则测出来的数据会偏乐观，实际部署时又不够用。我一般测试前会清一遍后台，确保基线干净。

这套实测做下来，我最大的体会是：显存优化没有银弹，只有对场景的准确判断。FP16是几乎无脑该开的，CPU卸载是显存告急时的救命绳，两者叠加能把一张小卡的潜力榨到极限，但代价是时间。真正重要的是先测出自己的基线数据，搞清楚峰值出现在哪、离上限差多少，再决定动不动刀、动哪一刀。凭感觉优化，要么优化不足反复爆显存，要么过度优化白白浪费时间，两头都不讨好。