1. 先把“版本”这件事掰开：你到底在选什么

很多人第一次看到某开源图像生成模型 2.1 的发布页，会被一堆后缀砸晕：bf16、fp16、fp8、int8、w4a8、gguf、safetensors 分片……页面上一排下载按钮，旁边还挂着显存建议。我见过不少人凭直觉点了个带 int8 字样的文件，拉下来跑不通，或者跑通了出图发灰，最后得出“这个模型不行”的结论——其实问题从来不在模型，而在于没搞清楚这些后缀到底描述的是什么。

先把话说明白：所谓“用哪个版本”，本质上不是选模型能力，而是选数值精度。模型权重本身是一样的，训练出来的那套参数没变，变的只是这些参数在显存里用什么格式存、在计算时用什么格式算。bf16 是每个参数占 2 字节，int8 是 1 字节，w4a8 里的 w4 指权重压到 4 比特、也就是 0.5 字节，a8 指激活值仍然保持 8 比特。就这么点差别，落到一张 20B 量级的主干网络上，显存差出几十个 G，直接决定了你这张卡能不能跑、跑一张图要多久、出图会不会糊。

所以这篇东西想解决的问题很具体：给你一份能对着自己机器直接抄的选型清单，而不是再复述一遍“int8 更省显存”这种废话。适合谁看？手里有一张 16G 到 48G 显存的卡、想把这个 2.1 版本跑起来的人；想搭一套稳定出图工作流、不希望半夜 OOM 的人；以及打算基于它做二次开发、需要知道哪种格式在哪个推理栈上真的被支持的人。如果你只是想云上一键出图，那这部分内容对你价值不大，可以直接跳过。

我下面提到的模型统一用Q-Image 2.1代指，避免和市面上各种改包、微调分支混淆；涉及具体显卡也只说显存档位，不谈品牌型号，你自己对号入座即可。

1.1 你以为在选模型，其实在选数值格式

这里有个特别常见的误解：以为 int8 版本是“另一个模型”。不是。它和 bf16 版本是同一套权重，只是导出的时候做了一次量化——把原本每个参数 16 位的浮点，按某种映射规则压到 8 位整数，同时额外存一组缩放因子（scale），推理时再反量化回浮点参与计算。你看到的文件小了，是因为精度丢了，不是模型被裁了。

这个区别为什么重要？因为量化是有损的，而且损失分布极不均匀。有些层的权重数值范围很窄、分布很集中，压到 8 位几乎无损；有些层存在少量绝对值极大的离群值（outlier），一旦按整层统一缩放，正常值就被压成了一坨，精度全毁。这就是为什么同样叫 int8，有的实现出图几乎看不出差别，有的实现直接崩。差别往往不在位宽，而在量化粒度：是按整个张量共享一个 scale（per-tensor），还是每个通道一个（per-channel），还是每 128 个元素一组（per-group）。粒度越细，文件里额外存的 scale 越多，精度越好，但 kernel 实现也越复杂。

w4a8 更极端。4 比特只能表示 16 个离散值，单靠权重本身根本没法还原，必须配 group-wise 量化——常见做法是每 32 或 64 个权重共享一组 scale 和 zero-point。所以你会看到 w4a8 的文件体积大概是 bf16 的四分之一多一点，多出来的那点就是这些辅助参数。理解了这一点，后面所有关于“为什么 w4a8 有时候反而更慢”“为什么 w4a8 出图细节发糊”的问题，答案都能自己推出来。

提示：下载页面上如果只写 int8 没写量化粒度，基本可以默认是 per-channel 的 weight-only 量化，激活仍然是 bf16/fp16。这种方案兼容性最好，但省显存有限，因为激活没省。

1.2 显存账本：四个吃显存的大户

想把显存算明白，得先知道显存都被谁吃了。很多人只算权重，然后发现实际占用比算出来的多一大截，就开始怀疑人生。实际上一个完整的图像生成推理流程，显存消耗至少有四块：

第一块是权重，这是最容易算的，参数量乘以每参数字节数。Q-Image 2.1 这个体量，主干加上文本编码器，bf16 下是几十个 G 的量级，这也是为什么它一出场就把 24G 卡劝退了。

第二块是激活值，也就是前向计算过程中产生的中间张量。这部分和你出的图分辨率强相关，而且是平方级增长的——注意力的计算量随 token 数平方增长，中间缓存同理。1024×1024 的时候可能只占几个 G，拉到 2048×2048 就能翻好几倍。很多人栽在这里：权重明明塞得下，一出大图就 OOM。

第三块是文本编码器。这部分经常被忽略，因为它只在开始阶段跑一次，跑完就不需要了。但如果你不做卸载，它就那么一直占着显存。一个 7B 级别的文本编码器在 bf16 下就是十几个 G，白白占着太浪费。这是个非常值得优化的点，后面会专门讲。

第四块是框架和缓存的固定开销，包括推理框架自身的上下文、显存池的碎片、VAE 解码时的临时缓冲。这部分看着零碎，实际能吃掉 2 到 4 个 G，而且碎片化严重的时候，明明总空闲够，就是分配不出来，报的还是 OOM。

注意：任务管理器或者监控工具显示的“已用显存”往往包含了缓存池，看起来占用很高，实际可用余量可能还有。判断能不能跑，别看已用，看峰值和 OOM 日志。

1.3 为什么 2.1 这个版本对精度特别敏感

量化对模型的影响不是均质的。像图像生成这类任务，对数值扰动的敏感度远高于文本分类。原因在于扩散/流匹配的采样过程是迭代的：几十步去噪，每一步的输入都依赖上一步的输出，误差会累积放大。分类任务里某一层有 1% 的噪声，最后 softmax 一压，结论还是对的；但生成任务里 1% 的噪声经过五十步迭代，可能就变成画面上一片诡异的纹理。

2.1 这个版本又有它的特殊性。它的主干规模大、层数深，中间还带文本渲染这类对细节极其敏感的能力——你让它画一块招牌，上面几个字，量化噪声稍微大一点，字就糊成一团或者笔画错乱。另外它用了较大的文本编码器来理解复杂提示词，这部分如果被粗暴量化，语义理解会退化，表现为“提示词里明明写了三个物体，出来只有两个”。

所以我的基本判断是：主干的量化可以激进一点，文本编码器和 VAE 尽量别动。这个思路在后面的混合策略里会展开。很多一体化量化包把所有模块一起压了，省事但牺牲大，如果你在意出图质量，值得自己拆开处理。

2. 三种格式的底细：bf16、int8、w4a8 到底差在哪

聊具体数字之前，先把这三种格式的脾气摸清楚。我不是要给你讲浮点数的 IEEE 标准，而是讲它们在实际推理中的表现差异，哪些场景安全、哪些场景翻车。

2.1 bf16：基准线，也是“最不容易翻车”的那个

bf16 全称 brain float 16，它和常规 fp16 的区别在于指数位更多、尾数位更少。fp16 有 10 位尾数、5 位指数，动态范围窄，遇到极大极小的数值容易溢出；bf16 把尾数砍到 7 位，指数留 8 位，动态范围和 fp32 一样。对生成模型来说这个取舍非常划算：我们不怕精度粗，怕的是溢出变成 NaN。

bf16 就是所有对比的基准线。它不省任何显存，权重该多大就多大，但它有三个实打实的好处：一是所有推理框架都原生支持，不管你是用主流的扩散推理库、节点式工作流工具，还是自己写脚本，bf16 永远是最先跑通的那条路；二是画质天花板就是它，任何量化版本的上限都不会超过 bf16；三是调试友好，出问题了你至少能确定不是精度惹的祸，排查范围一下子小了一半。

什么时候必须用 bf16？我的经验是：做效果评估、对比不同提示词的表现、给客户出终稿、或者要基于它做微调。这几种场景对画质或数值稳定性有硬要求，省那点显存不值当。至于日常大批量试提示词、调构图，用低精度版本完全够。

2.2 int8：省一半显存，但要分清是“权重int8”还是“权重+激活int8”

int8 这个词被用得很乱，市面上至少有两种完全不同的东西都叫 int8。

第一种是weight-only int8，权重压到 8 位，激活和计算仍然是 bf16。加载时反量化，或者用融合 kernel 边算边反量化。这种方案的好处是兼容性极好，几乎所有框架都能吃，缺点是显存只省了权重那一半，激活没动。对于我们这种激活占比不低的生成任务，总体显存大概能降四成左右。

第二种是W8A8，权重和激活都是 8 位，矩阵乘法直接用整数指令跑。这种才是真正意义上的“全 int8 推理”，速度快、显存省得多，但对硬件和 kernel 支持要求高，不是所有卡、所有框架都吃得上。而且激活量化需要校准数据，做不好精度掉得很厉害。

实际操作中你拿到的 int8 包，九成是第一种。判断方法很简单：看文件大小。如果只比 bf16 小一半左右，那就是 weight-only；如果小了一大截并且附带了校准配置文件，那可能是 W8A8。

int8 的精度表现在我实测里是相当能打的。在同一组提示词、同一个随机种子下，weight-only int8 和 bf16 出图放一起，肉眼几乎分不出来，像素级比对的结构相似度也在 0.98 以上。差异要到放大到局部、看高频纹理的时候才勉强能察觉——比如头发丝的走向、织物纹理的细密程度，会有一点点“被抹平”的感觉。对绝大多数用途来说，这个代价完全可以接受。

2.3 w4a8：最诱人也最容易踩坑的一档

w4a8 是这三者里最刺激的。权重压到 4 比特，显存占用直接干到 bf16 的四分之一左右，这意味着原本 40 多 G 的权重变成 10 G 出头，一张 24G 的消费卡突然就有了跑起来的可能。诱惑力不用我多说。

但它的坑也是最多的，我按严重程度排一下：

坑一，kernel 支持不齐。4 比特权重的反量化不是普通矩阵乘法能高效处理的，必须有专门的融合 kernel。这类 kernel 通常只对特定显卡架构、特定计算库版本做了优化。你在一张新卡上可能跑得飞快，换一张老卡直接报“不支持的算子”或者悄悄回退到慢速路径。我遇到过最离谱的情况是：同一个 w4a8 包，在两张不同代的卡上，一张 3 秒出一张图，另一张要 20 多秒，因为后者走了 fallback。

坑二，出图质量有肉眼可见的损失。这个得实话实说。4 比特的信息密度太低了，纹理细节、细小文字、复杂光影过渡这几个方面退化明显。具体表现是：远景还看不出问题，一旦放大看局部，皮肤质感会有点“塑料”，织物纹理糊成一片，招牌上的字容易缺笔画。如果你的用途是快速出草稿、批量试构图、给内部看方向，这个质量完全够；但要交付成品，我不建议。

坑三，稳定性问题。部分 w4a8 实现在长提示词、复杂 CFG 参数下会出现数值异常，表现为纯黑图、纯灰图或者满屏噪点。这类问题不是每次都有，大概几十张里冒一张，排查起来极其难受，因为随机种子固定也不一定复现。

坑四，生态割裂。不同人导出的 w4a8 包格式不统一，有的是 safetensors 加自定义配置，有的是打包成专门格式。换一个推理框架可能就不认了，得重新找对应的版本。

提示：如果你决定上 w4a8，先别急着铺开用。跑 20 张不同提示词、不同种子的图，逐张看有没有异常，确认稳定了再进工作流。这一步花十分钟，能省掉后面几小时的排查。

2.4 一张表看清三者的取舍

把上面的内容压缩成一张表，方便你对着自己的需求快速定位。注意这里说的是典型情况，具体实现会因为导出方不同而有波动。

看懂这张表，其实答案已经出来大半了。真正需要纠结的只有一种情况：显存刚好卡在中间，int8 差一点跑不动，w4a8 能跑但质量不放心。这种时候就该考虑混合策略，而不是硬选一个。

3. 显存占用实测：把数字算给你看

这一节我把账算细一点，让你能自己推算自己机器上的情况，而不是死记一组数字。因为每个人的分辨率、批量、框架版本都不一样，给死的数字意义有限，给算法才有用。

3.1 先算理论值：参数量乘以字节数

权重的算法极其简单：

权重显存(GB) ≈ 参数量(B) × 每参数字节数

以 Q-Image 2.1 这个量级为例，主干网络在 20B 参数附近，文本编码器在 7B 附近，VAE 只有零点几个 B。分开算：

• bf16：主干 20 × 2 = 40 GB，文本编码器 7 × 2 = 14 GB，VAE 约 0.6 GB，合计约54.6 GB
• int8：主干 20 × 1 = 20 GB，文本编码器 7 × 1 = 7 GB，VAE 保持 bf16 约 0.6 GB，加上 scale 开销约28 GB
• w4a8：主干 20 × 0.5 = 10 GB，文本编码器 7 × 0.5 = 3.5 GB，加上 group scale 大约再多 8% 到 12%，VAE 不动，合计约14.5 GB

这三个数字一摆出来，很多东西就清楚了。bf16 光是权重就 54 G，没有 80G 级别的卡根本别想，实际上还得留出激活的空间，稳妥要 80G 起步。int8 的 28 G 意味着 40G 卡能舒服跑，48G 卡毫无压力，32G 卡勉强但要小心激活。w4a8 的 14.5 G 让 24G 卡看到了希望——但也仅仅是希望，因为激活还没算。

3.2 实测环境与口径说明

我下面的实测数据基于这么一套配置，你对照着看差异：单卡推理，操作系统为常见 Linux 发行版，推理框架用主流的扩散推理库，开启了注意力加速后端，VAE 使用分块解码（tiling）以降低峰值，文本编码器在编码完成后立即卸载到内存。分辨率从 1024 起，批量固定为 1。种子固定，提示词用同一组包含主体、风格、文字渲染的复合描述。

特别说明一下文本编码器卸载这件事，因为它对结果影响巨大。如果不做卸载，bf16 下那 14 G 会一直挂着，int8 下 7 G 也一直挂着。做了卸载之后，这部分显存在采样阶段是完全释放的，只在最开始编码提示词时短暂占用。所以下面的实测峰值里，文本编码器的占用只体现在“预编码阶段峰值”，不体现在“采样阶段峰值”。这两个峰值要分开看，取大的那个才是你实际需要的显存。

3.3 实测数据表：分辨率与格式的交叉对比

下面这组数字是我在同一台机器上反复跑出来的采样阶段峰值显存，单位 GB，批量 1，文本编码器已卸载。数据有±1G 的波动，取决于框架版本和显存碎片情况，看趋势别看绝对值。

这张表里最值得看的一行是 1536×1536 的 w4a8：22.6 G。这个数字非常微妙，因为它意味着在 24G 卡上跑 1536 分辨率是贴着上限的，任何一点额外开销——比如你同时开着浏览器、开着预览窗口、框架缓存没清干净——都会导致 OOM。而 1328×1328 的 19.4 G 就舒服得多，留出了 4 G 出头余量。

再看批量那一行。批量从 1 提到 4，显存只涨了 20% 多，但吞吐量是 4 倍。这就是所谓的“批量摊薄固定开销”：权重只加载一次，多出来的主要是激活，而激活的增长比线性要慢一些，因为部分中间结果可以复用。如果你要批量出图，尽量把批量开大一点，反而比一张一张跑更省总显存。

3.4 除了权重，还有哪些隐形吃显存的角落

表里的峰值减去理论权重，就是激活加框架开销。1024 分辨率下，bf16 的 47.2 减掉纯主干权重 40，多出来 7.2 G，这里面激活大概占 4 到 5 G，框架和碎片占 2 到 3 G。这个比例不算小，值得单独处理。

激活的大头在注意力。分辨率翻倍，token 数翻四倍，注意力矩阵的元素数是 token 数的平方，也就是十六倍。虽然实际实现用了分块和流式注意力，不会真的分配完整的平方矩阵，但增长趋势仍然明显。这也是为什么从 1536 到 2048，显存涨了 14 G 而不是线性的 7 G。

碎片是怎么来的？推理过程中会反复分配、释放不同大小的张量，长时间跑下来显存池里会留下一堆大小不一的空洞。明明总空闲还有 3 G，但你要一个连续的 2.5 G 就是分配不出来。缓解办法有两个：一是设置环境变量让显存分配策略更激进（不同框架变量名不同，通常是类似PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True这种），二是定期重启进程，别让一个进程连续跑几千张。

VAE 解码是个隐藏峰值。采样阶段结束，潜空间特征要过 VAE 解码成像素图，这一步的临时显存可能比采样阶段还高，尤其是在大分辨率下。所以一定要开分块解码，它会牺牲一点速度，但把峰值压下来一大截。这是我认为最值得开的一个选项，没有之一。

注意：判断显存够不够，要取“采样峰值”和“VAE 解码峰值”里的较大值，不是只看采样。很多人采样跑完了，卡在最后解码那一步 OOM，特别憋屈。

3.5 速度与画质的代价，值不值

光看显存不够，还得看速度和质量的代价。我做了三组对照，每组同样是 30 步采样、同一提示词、同一随机种子，记录单图耗时和主观画质。

速度方面，int8 大概是 bf16 的 0.85 倍耗时，也就是快 15% 左右。这个提升比很多人预期的要小，因为生成任务的瓶颈不全在矩阵乘法，还有大量归一化、激活函数、注意力 softmax 这些没被量化的算子。w4a8 就分化严重了：kernel 匹配的时候能到 0.7 倍耗时，不匹配的时候因为要走反量化 fallback，反而比 bf16 慢一半。所以“w4a8 一定更快”是个错觉，它只是更省显存，速度要看运气。

画质方面，int8 和 bf16 的差距，我把图放大到 200% 逐块对比，主要差异在极高频纹理上——细密的织物、树叶、发丝尖端，int8 会有一点点“过度平滑”的倾向，像是做了轻微的降噪。文字渲染基本无差别，复杂提示词的语义遵循度也一致。这个代价我觉得完全可以接受。

w4a8 的差距就明显了。同样是放大对比，纹理区有块状感，皮肤的高光过渡会出现轻微的色阶，文字部分在笔画交叉处容易黏连。用客观指标算，int8 相对 bf16 的结构相似度在 0.98 以上，w4a8 大概在 0.93 到 0.96 之间浮动，取决于提示词复杂度。这个区间意味着：整体观感还行，细看有瑕疵。

所以我的结论是，int8 是性价比拐点。它省了四成多显存，换来几乎无损的画质和一点速度提升。w4a8 则是不得已而为之的选项，只有当你的显存真的卡在 24G 以下、又非要跑这个模型的时候，才值得接受那个质量损失。

4. 怎么选：一份能直接抄的选型清单

前面铺垫了这么多，这一节直接给结论。我按显存档位和使用场景两条线来分，你对号入座就行。

4.1 按显存档位分档的直接结论

16G 及以下：说实话，完整跑 Q-Image 2.1 是吃力的。w4a8 在 1024 分辨率下峰值 17.1 G，已经超了。可行的路子有两条，一是降到 768 或 896 分辨率出图再放大，二是用主干 w4a8 加文本编码器 CPU 卸载的组合，把文本编码器的 3.5 G 彻底挪出去，能挤出一点空间。但即便如此，余量极小，我不推荐把这个配置当主力，容易心态崩溃。

24G：这是 w4a8 的主场。1024 和 1328 分辨率都能跑，1328 留 4 G 余量，比较舒服。如果你对画质有要求，可以试试 int8 加主干分块加载（如果框架支持），但速度会掉不少。我的建议是 24G 卡就用 w4a8 做草稿和批量试构图，重要的图另找机器出。

32G：这是个尴尬档位。int8 的 1024 峰值 29.8 G 刚好卡住，1328 的 33.5 G 就超了。所以 32G 卡跑 int8 只能锁在 1024 以内，想上大图还得 w4a8。这个档位我的建议是：日常用 int8 出 1024，需要大图的时候切 w4a8。

40G 到 48G：int8 的舒适区。1024 到 1536 全都能跑，2048 的 49.3 G 差一点点，开个分块或者稍微降点分辨率就行。这个档位我强烈建议就用 int8，别碰 w4a8 了，画质和省那点显存不值当。

80G 及以上：直接 bf16，不用想。这个档位谈量化就是浪费时间，把完整的数值精度用上，出图和评估都以它为基准。

4.2 按使用场景分：出图工作流、批量生产与二次开发

显存只是约束之一，用途才是决定性的。我按三种典型场景再捋一遍。

场景一：个人出图工作流，边调提示词边看效果。这种场景的特点是交互频繁、单张为主、对画质有一定要求但不至于到交付级。我的推荐是 int8，前提是显存够。因为你要反复看细节、判断提示词改动带来的微小变化，w4a8 的纹理损失会干扰你的判断——你以为提示词写得不到位，其实是量化把细节吃了。这个坑我踩过，调了半天提示词，换成 bf16 一跑，发现原提示词本来就是对的，只是 w4a8 没渲染出来。

场景二：批量生产，比如给一批商品出场景图。这种场景吞吐优先，画质只要达标就行。推荐 int8 配大批量。批量开到 4 到 8，显存增长有限但吞吐翻几倍。如果你的显存只够 w4a8，那就 w4a8 配批量，先把量做上去，抽检合格率，把不合格的重跑。批量场景下单张的质量波动可以靠抽检和重跑消化掉，这是 w4a8 最能发挥价值的地方。

场景三：二次开发，比如做提示词优化、做后处理管线、做效果评估。这种场景必须 bf16。原因是你要拿它当基准去对比别的东西，基准本身带量化噪声，后面所有对比结论都不可信。我见过有人用 w4a8 做 A/B 测试，得出“某个提示词模板更好”的结论，换成 bf16 一验证，差距根本不存在，纯粹是量化噪声造成的偶然差异。

4.3 部署栈与格式的兼容性对照

同一个格式，在不同推理栈上的支持程度差别很大。这张表帮你提前避坑，免得下载完了发现加载不了。

这里有一条通用经验：先用官方参考实现把 bf16 跑通，再去折腾量化版本。因为官方实现是所有其他实现的事实标准，你在这里建立的“正常出图长什么样”的认知，是后面判断量化版本有没有问题的基础。跳过这一步直接上第三方量化包，出了问题你连对照都没有。

4.4 混合策略：不同模块用不同精度

这是我个人最推荐的方案，也是很多人没想到的一层。既然量化的损失主要来自主干和文本编码器，而这两者的敏感度不一样，那为什么不分开处理？

具体做法：主干用低精度，文本编码器和 VAE 保持 bf16。理由很实在。文本编码器只跑一次，跑完就卸载，它的显存占用是瞬时的，不构成持续压力；而它对语义理解的影响是全局的，一旦量化过头，整个提示词的理解都会偏。VAE 参数量小，占不了多少显存，但它负责最终像素重建，对细节保真度影响直接，压它纯属得不偿失。

按这个策略，24G 卡的配置可以是：主干 w4a8（10 G）+ 文本编码器 bf16 预编码后立即卸载（峰值时 14 G 但瞬时）+ VAE bf16（0.6 G）。采样阶段峰值大约 16 到 17 G，比全 w4a8 多一点点，但语义遵循度和色彩还原会明显好一截。这个组合我在实际项目里用了挺久，稳定性和效果的平衡让我满意。

还有一种更激进的混合：分层量化。主干里靠近输入的层和靠近输出的层保持高精度，中间层压狠一点。理由是首尾层对最终结果的影响更直接，中间层更多是做特征变换，容错空间大。这个方案需要自己改量化脚本，门槛高一些，适合有量化经验的人折腾。效果上大概能在同等显存下多换回一点画质，但提升幅度不至于惊艳，投入产出比看个人。

5. 跑通实操：从下载到出第一张图

理论讲完，来点能直接执行的。这一节我按顺序给出完整流程，中间穿插几个关键参数的解释，让你知道每个选项为什么这么设。

5.1 环境准备与依赖

先把地基打好。Python 版本用 3.10 或 3.11，这两个版本生态兼容性最好，太新的版本有些算子库还没跟上。显卡驱动和计算库版本要匹配，这一点特别容易出错——计算库版本太低，w4a8 的融合 kernel 根本调不起来，会静默回退到慢速路径，你只会觉得“怎么这么慢”，很难想到是版本问题。

依赖清单大致是：深度学习框架本体、扩散推理库、加速库、图像处理库。安装顺序建议先装框架再装其余，避免版本互相覆盖。安装完跑一行验证：

import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(f"显存: {torch.cuda.get_device_properties(0).total_memory / 1024**3:.1f} GB")

这四行输出能确认三件事：框架装对了、显卡认到了、显存看清楚了。第三步很多人跳过，结果后面按错的显存档位选格式，白忙一场。

磁盘空间也要提前规划。bf16 的完整权重接近 55 G，int8 约 28 G，w4a8 约 15 G。如果你要同时保留多个版本做对比，预留 120 G 比较稳妥。另外留一点给模型缓存目录，框架下载时会有临时文件。

5.2 bf16 基线跑通与关键参数

先跑基线。这段代码不追求性能，只求跑通、看清楚每个环节的显存占用。

import torch from diffusers import DiffusionPipeline pipe = DiffusionPipeline.from_pretrained( "本地模型路径", torch_dtype=torch.bfloat16, use_safetensors=True, ) pipe.to("cuda") pipe.enable_attention_slicing() # 注意力分块，降峰值 pipe.enable_vae_tiling() # VAE 分块解码，必开 prompt = "一间清晨的木质工作室，桌面上散落着工具，窗外有柔和侧光" image = pipe( prompt=prompt, num_inference_steps=30, guidance_scale=4.0, width=1024, height=1024, generator=torch.Generator("cuda").manual_seed(42), ).images[0] image.save("baseline_1024.png") print(f"峰值显存: {torch.cuda.max_memory_allocated() / 1024**3:.1f} GB")

几个参数值得单独解释。num_inference_steps=30是这个量级模型的常用值，低于 20 细节明显不足，高于 40 收益递减很快。guidance_scale=4.0是这类流匹配模型的典型区间，比早期扩散模型的 7 到 8 要低，设太高容易出现色彩过饱和和构图僵硬。这两个值不是死的，但对新手来说先按这个来，跑通了再微调。

enable_vae_tiling()我认为是必开项。它把解码过程切成小块逐块处理，峰值能降好几 G，代价是速度慢一点。在你显存不宽裕的时候，这个选项就是救命稻草。enable_attention_slicing()同理,牺牲速度换峰值,但注意它和数据并行的批量策略有点冲突,批量大的时候可以关掉。

跑完之后看输出那张图，记住它长什么样。这是你后面所有对比的参照物。

5.3 int8 与 w4a8 的加载方式

int8 和 w4a8 的加载，取决于你拿到的包是什么形式。常见的有三种，我分别说。

形式一：已经量化好的完整权重目录。这种最省事，加载方式和 bf16 一样,只是不用指定 dtype，让它读配置里的量化信息。

pipe = DiffusionPipeline.from_pretrained( "本地int8模型路径", use_safetensors=True, ) pipe.to("cuda") pipe.enable_vae_tiling()

注意这里不要手动传torch_dtype。量化模型的配置文件里已经写好了计算精度，你手动指定反而可能覆盖掉，导致加载失败或者精度错乱。

形式二：bf16 权重加运行时量化。部分框架支持加载时动态量化，好处是不用额外下载，坏处是首次加载慢、占用内存高。

from diffusers import DiffusionPipeline import torch pipe = DiffusionPipeline.from_pretrained( "本地bf16模型路径", torch_dtype=torch.bfloat16, ) pipe.to("cuda") # 部分框架提供量化接口，具体名称依版本而定

这条路的实际收益有限，因为动态量化只是把权重转了一下，加载时的内存峰值反而更高。除非你磁盘紧张，否则我更推荐直接下量化好的包。

形式三：w4a8 专用格式。这种通常需要对应的推理引擎或插件，加载代码和上面完全不同。这时候别自己瞎试，去翻那个包附带的说明，或者对应的示例脚本。w4a8 的配置项很多——group size、是否启用激活量化、用哪个 kernel 后端——错一个就跑不起来或者跑得极慢。

加载完成后，第一件事是验证量化真的生效了：

for name, param in pipe.transformer.named_parameters(): print(name, param.dtype, param.shape) break print(f"加载后显存: {torch.cuda.memory_allocated() / 1024**3:.1f} GB")

如果打印出来的 dtype 还是 bfloat16，说明量化没生效，你加载的其实是原始权重——这种情况下显存当然不会降。这个问题很隐蔽，因为不报错，只是白忙。

5.4 显存监控与日志埋点

跑推理的时候必须盯着显存，不然出了问题只能靠猜。我自己习惯在每个关键节点打点：

import torch def report(tag): alloc = torch.cuda.memory_allocated() / 1024**3 peak = torch.cuda.max_memory_allocated() / 1024**3 print(f"[{tag}] 当前 {alloc:.1f} GB / 峰值 {peak:.1f} GB") report("加载完成") # ... 编码提示词 ... report("文本编码后") torch.cuda.reset_peak_memory_stats() # ... 采样 ... report("采样后") # ... VAE 解码 ... report("解码后")

注意中间那次reset_peak_memory_stats()。不加的话峰值会被前面的文本编码阶段污染，你看到的是历史最高，不是当前阶段的峰值，判断会失真。

还有个细节：memory_allocated只统计框架分配出去的部分，不含缓存池。想看真实占用要用memory_reserved。两者差异大的时候说明碎片严重，该重启进程了。

6. 踩坑实录：常见问题与排查表

这一段是我觉得全文最有价值的部分，因为下面每一条都是我或者身边的人真真切切踩过的，网上搜不到现成答案。

6.1 OOM 但显存看着还剩很多

这是最经典的问题。报错说显存不足，你打开监控一看，空闲还有 4 G，凭什么不足？

原因基本是碎片。推理过程中反复分配释放，显存池里全是大小不一的空洞,你要的那个张量需要连续空间，凑不齐。解决办法按有效性排序：

第一，开分块。VAE 分块解码、注意力分块，这两个能显著降低单次分配的最大块尺寸，碎片问题自然缓解。第二，设置显存分配策略环境变量，让分配器使用可扩展段。不同框架的变量名不一样，常见的写法是：

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

这一行在很多场景下能把“明明有空闲却分配失败”的问题直接消掉。第三，降低分辨率或批量，从源头减少峰值需求。第四，设一个显存占用上限，让分配器提前做规划：

import torch torch.cuda.set_per_process_memory_fraction(0.92, 0)

留 8% 余量给系统和框架自身，看起来是自缚手脚，实际能避免很多边界情况下的崩溃。

6.2 黑图、灰图、满屏噪点

这类问题的成因比较多，我按排查顺序列。

先查 dtype 和算子匹配。如果你在较老的显卡上跑 bf16，某些算子可能不被支持，框架会悄悄降级到 fp16 甚至 fp32，混用之后数值就乱了。检查方法是打印模块的 dtype 分布，看看是不是一致。

再查 w4a8 的稳定性。如果只有 w4a8 出问题、int8 和 bf16 都正常，那基本可以锁定是量化 kernel 的数值问题。缓解手段包括降低 CFG 值、缩短提示词、换一个量化包。这类问题很难彻底修，只能规避。

第三查 VAE 分块。分块解码在极少数情况下会在块的边界产生接缝或者伪影，表现为规则的网格状痕迹。如果伪影有规律，把分块关掉试试，能确认是不是它。

第四查种子和 Generator 设备。一个很容易忽略的点：Generator 创建在 CPU 还是 GPU 上，会导致同样的种子出不同的图。跨设备对比的时候必须固定这一点，否则你会以为是量化的问题，其实是种子环境变了。

6.3 w4a8 反而比 bf16 更慢

这个坑我印象很深。当时满心欢喜换上 w4a8，想着显存降了速度应该也快，结果一张图跑了快一分钟，比 bf16 还慢一倍。

排查下来是 kernel 回退。4 比特的反量化需要专门的融合算子，我的计算库版本偏旧，对应的算子没编译进去，框架就回退到了一个通用的慢速实现——它能算对，但效率极差。验证方法是看日志里有没有类似“fallback”“unsupported op”的警告，或者用 profiler 看算子耗时分布，如果时间集中在一堆零碎的小算子上，那就是没走上融合路径。

解决办法：升级计算库到支持该硬件的版本，确认推理引擎的版本匹配。这两步做完，速度从一分钟回到了三秒多。所以我的经验是，上 w4a8 之前先做一次速度基准测试，跑单图计时，和预期对不上就先查环境，别急着怀疑模型。

6.4 出图风格漂移与文字崩坏

这两个现象经常一起出现，很多人以为是提示词写得不好，其实是量化损失。

风格漂移的表现是：同样的提示词，量化版本出的图比 bf16 更“平”，光影层次少，色彩饱和度偏低，整体像是加了一层灰。原因是量化对数值分布的压缩，让模型对风格描述的响应变钝了。缓解办法是在提示词里加强风格词的权重，或者干脆换回 int8——这个现象在 int8 上不明显，在 w4a8 上比较突出。

文字崩坏是另一个典型。这个模型有文字渲染能力，但 4 比特精度下，笔画交叉、细小字符、复杂字体会出现黏连和缺笔。我的经验是，如果图里必须有清晰文字，就别用 w4a8，int8 是底线。而且即便是 int8，文字也要给足尺寸，图里占的面积太小，什么精度都救不回来。

6.5 常见问题速查表

把上面这些压缩成一张表，出问题的时候直接查。

这张表里我最想强调的是第一行和最后一行。OOM 有八成不是真的显存不够，而是碎片；而解码阶段崩溃，是因为多数人只监控采样不看解码，明明采样跑完了却功亏一篑。

提示：养成一个习惯，每次换配置之后跑三张不同分辨率的图，记录峰值。存成一个小表格，时间长了你就对自己机器的脾气了如指掌，不用每次都试错。

7. 最后一点个人经验

如果非要我给一句话结论：显存够就 int8，显存紧就 w4a8 配混合精度，要交付就 bf16。这三句话覆盖了我遇到的九成情况。

但有个心得比选型更重要：别把量化当成免费的午餐。它省下的显存，代价是画质的确定性和排查的复杂度。我现在的做法是，机器上常备两套权重——一套 int8 做日常，一套 bf16 做参照。任何时候觉得出图“哪里不对劲”，先切 bf16 跑同一提示词同一种子，两分钟就能判断是提示词的问题还是量化的问题。这个对照习惯帮我省下的时间，远超多占的那点磁盘。

另外提醒一句，量化包的质量差异非常大。同样标着 int8，不同人导出的结果可能天差地别，取决于量化时用了什么校准数据、什么粒度、有没有跳过敏感层。所以遇到一个表现好的量化包，记下来，别随便换。我吃过换包的亏——升级了一个“更新版本”，结果色彩全偏，回头找旧包发现已经被删了，只能重新调参适配。

最后说个容易被忽略的点：显存数字是死的，工作流是活的。你算出来 1328 分辨率要 19.4 G，在 24G 卡上好像很安全，但如果你同时开着预览窗口、开着浏览器几十个标签、后台还有个模型在跑，那 4 G 余量瞬间就没了。真正稳定的工作流，要按最坏情况留余量，而不是按理论值卡边。我现在的习惯是峰值不超过总显存的 80%，剩下的 20% 是给系统、给碎片、给自己的手滑留的缓冲。这个比例听起来保守，但它让我在过去大半年里没再因为 OOM 丢过一次任务。