6GB显存跑通Qwen-Image-2.1：量化、显存卸载与注意力切片实战指南

我折腾了两天，总算把 Qwen-Image-2.1 压到一块只有 6GB 显存的 GTX 1660Ti 上跑通了。说实话，这个目标一开始听起来有点离谱——现代图像生成大模型的权重动辄三四十 GB，哪怕量化后也要十几 GB，6GB 显存连模型本体都塞不下。但真做下来发现，只要把量化、显存卸载、注意力切片这几个手段组合好，老卡还是能发挥余热的。这篇文章就是我这次本地部署的完整实战记录，包括两套可复现的方案、所有关键参数的意义、以及我踩过的 OOM 和崩图的坑，给同样在低配显卡上折腾图像模型的朋友一个参考。

先说结论：这条路能走通，但 1660Ti 的角色是“能跑”，不是“跑得爽”。512×512 分辨率、20 步采样、NF4 量化的情况下，我实测单张图大约 90 秒，峰值显存 5.1GB 左右，基本贴着显存上限。如果你能接受这个速度，下面所有内容都可以直接抄作业。

1. 项目目标拆解：6GB 显存到底卡在哪

1.1 为什么 1660Ti 部署大模型这么难

GTX 1660Ti 是一张图灵架构的甜品卡，6GB GDDR6 显存、12nm 工艺，放在今天已经属于退休边缘。但真正麻烦的不是算力，显存才是硬门槛。

现代图像生成模型推理链路上有三个主要模块：文本编码器、DiT 主干（扩散 Transformer）、VAE 解码器。Qwen-Image-2.1 这种多模态模型，完整权重叠加起来超过 30GB，就算用 FP16 也要十几 GB。要在一个 6GB 的卡上跑，只有两条路同时走：量化压缩权重，以及把不参与当前计算的模块卸载到 CPU 内存。

这里需要先纠正一个误区：很多人以为“显存不够”就是报错时看到的CUDA out of memory，其实大多数情况是模型加载时一次性把所有权重都放进显存才爆的。只要能让权重按需进出显存，6GB 也是可以玩得转的。

我在规划时给自己定的标准很简单：能完成文本生成图像（文生图）、图像编辑（图生图）、局部重绘三件事，出图质量不崩、速度可以接受，就算部署成功。不追求高分辨率、不追求实时交互，先跑通，再谈优化。

1.2 Qwen-Image-2.1 的定位与预期效果

Qwen-Image-2.1 是开源社区推出的新一代统一图像生成模型，核心卖点是“文生图 + 图生图 + 多图参考 + 局部编辑”都在同一个模型里，而且对中文提示词的理解比前代强不少。对于本地部署来说，它最大的优势是生态里已经有人在折腾量化版本和图形化工作流，这大大降低了低配显卡玩家的门槛。

我在部署前给自己列了一份“成功标准”：

• 完成环境搭建后，能正常加载 4bit 量化权重；
• 文本生成图像流程完整走通，生成 512×512 图片；
• 显存峰值压在 5.5GB 以内，不触发 OOM；
• 单张出图时间控制在 2 分钟以内。

实际上跑完后，除了“局部重绘”需要稍微降低分辨率才能稳住外，其他目标都达成了。整个过程我会在下面完全复述出来。

1.3 方案选型逻辑：三条路我为什么只留了两条

在动手之前，我把可能的部署方案列了一下：

这次的核心诉求是“本地”，所以云端方案想都不想就排除了。而 Diffusers 和 ComfyUI 两条路线我最终都跑通了，因为两者的适用人群不同：愿意写代码、想弄清楚每个参数作用的，走 Diffusers；只想快速出图、不想碰脚本的，走 ComfyUI 更舒服。

2. 部署前的准备工作：环境与量化决策

2.1 核对驱动的兼容性顺序

看似简单的“装环境”其实有固定的检查顺序，我每次部署新模型都按这个顺序来，少走很多弯路：

1. 先查显卡驱动版本：命令行运行nvidia-smi，看右侧 Driver Version 和 CUDA Version；
2. 根据驱动版本决定能否安装新 CUDA 工具链，图灵架构对 CUDA 12.x 的支持没有问题；
3. 再查 Python 版本，建议 3.10 或 3.11，不要用太旧的版本，很多新库直接不兼容；
4. 最后检查系统内存，这一步最容易被忽略。

1660Ti 只有 6GB 显存，但 系统内存实际上是救命的。我机器上有 32GB 内存，这在 CPU offload 模式下是刚需——模型量化后大约 10~12GB，加载时需要同时在内存和显存之间反复交换。如果系统内存只有 8GB，基本可以直接放弃，必须先升级内存或增加交换分区。

注意：nvidia-smi显示的 “CUDA Version” 是当前驱动支持的最高版本，不等于 Python 环境里实际使用的 CUDA 运行时版本。两者可能不同，但一般驱动支持的版本高于等于 PyTorch 要求的版本就能正常跑。

我这次的环境清单如下：

• 系统：Windows 11，避免使用 Linux 双系统，方便切换日常使用；
• 显卡驱动：保持厂商最新稳定版，这是减少玄学问题的第一步；
• Python：3.10，用虚拟环境隔离，绝不污染全局环境；
• 系统内存：32GB DDR4 3200。

实测数据表明，这套环境跑 Diffusers 和 ComfyUI 都没有出现驱动层面的报错，问题反而都出在显存策略上。

2.2 量化格式怎么选：NF4 还是 GGUF

部署大模型绕不开量化。常见的选择有两个方向：Diffusers 生态里常见的是bitsandbytes 的 NF4 4bit 量化；ComfyUI 生态里常配合GGUF 格式的 Q4_K_M / Q5_K_M 量化。

我个人的建议是：如果你走 Python 脚本，用 NF4 最省事，因为在加载模型时直接加load_in_4bit=True就能完成量化，不需要额外转换文件；如果你走 ComfyUI，优先下载别人转换好的 GGUF 文件，加载快、占用低。

这里有个很重要的体力活：1660Ti 显存太小，所以我不建议加载 FP16 或 FP8 版本，直接上 4bit。量化后模型体积大约压缩到 12GB 左右，还是大于显存，但配合 offload 就能跑了。

关于量化质量，我的实际观感是：生成纯文本渲染、风景类图片，4bit 和 FP16 的差别不仔细看不太出来；但生成人脸、文字细节时，4bit 会明显丢一点纹理质感。在 6GB 卡的条件下，这是必须接受的妥协。不要执着于画质，先跑通再说。

2.3 下载模型文件的避坑经验

模型文件的完整结构一般包含三个子目录：transformer（主干）、text_encoder（文本编码器）、vae（变分自编码器）。下载时要注意：

• 不要只下载某一个文件，仓库里的model_index.json和配置文件缺一不可；
• 优先选择“已经量化好的版本”，能省去不少事；
• 如果下载中断，建议用断点续传工具，模型文件体积大，浏览器下载很容易断。

由于下载平台存在限速问题，我最后是把整套权重放在了本地磁盘一个独立目录下，路径不要带中文和空格，省得后续 Python 路径解析出幺蛾子。

3. 实战操作：两套方案完整跑通

3.1 方案一：Diffusers 脚本部署（代码可直接复现）

我先把核心代码放在前面，再解释每一行是干什么的。这段代码基于我实际调试通过的版本稍作精简，适用于低显存场景：

import torch from diffusers import QwenImagePipeline model_path = "./models/Qwen-Image-2.1" # 使用 4bit 量化加载文本编码器和主干 from transformers import BitsAndBytesConfig quantization_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16, bnb_4bit_use_double_quant=True, bnb_4bit_quant_type="nf4", ) pipe = QwenImagePipeline.from_pretrained( model_path, torch_dtype=torch.float16, quantization_config=quantization_config, device_map="auto", ) # 修改为单卡 CPU 顺序卸载模式，显存友好 pipe.enable_sequential_cpu_offload() pipe.enable_attention_slicing() prompt = "一个坐在窗边的少女，阳光洒在书桌上，电影感灯光，细节丰富" image = pipe( prompt=prompt, height=512, width=512, num_inference_steps=20, guidance_scale=3.5, ).images[0] image.save("output_512.png")

这段代码里有三个关键点，缺一个都会炸显存：

第一个，BitsAndBytesConfig配置了 NF4 4bit 量化。这里我没有把三个模块全部量化，实践中发现文本编码器也量化的话，中文理解能力会明显下降，所以建议只让主干和 VAE 吃 4bit，文本编码器保持 FP16。不过受限于代码简洁性，上面的写法是全量化，效果会差一点，如果你追求更好中文提示词理解，可以把文本编码器单独用 FP16 加载。

第二个，enable_sequential_cpu_offload()。这个方法的原理是：把模型按层拆开，计算完一层立刻从显存卸载回内存，再加载下一层。代价是速度较慢，但显存峰值只有正常模式的 1/4 左右。对 1660Ti 来说，这是唯一能跑通 1024×1024 附近分辨率的方式。

第三个，enable_attention_slicing()。注意力切片会把大的注意力计算拆成小块，逐块计算，避免单个矩阵乘法占用过多显存。开启后速度会稍微下降，但显存占用能再低一截，属于低显存玩家的默认标配。

首次运行会非常慢，因为要加载十几 GB 的权重到内存再转显存。我在机械硬盘上试过一次，光加载就等了 8 分钟，换到 NVMe SSD 之后只要 2 分钟左右。所以如果你的模型盘还是机械硬盘，强烈建议先换固态。

3.2 方案二：ComfyUI + GGUF 工作流

对于不想写代码的朋友，ComfyUI 是更好的选择。核心步骤大概四步：

1. 从官方仓库下载 ComfyUI 的整合包，解压后双击启动脚本；
2. 在 ComfyUI 的models/diffusion_models目录下放置量化后的 GGUF 文件（文件名类似qwen-image-2.1-q4_k_m.gguf）；
3. 安装支持 GGUF 的节点插件，在 ComfyUI 管理器中搜索“GGUF”关键词，找到后一键安装，重启进程；
4. 加载社区分享的工作流 JSON 文件，把采样器里的模型节点指向你的 GGUF 文件，分辨率改为 512×512，步数改为 20。

ComfyUI 的好处是节点可视化，你可以直观看到每个模块的显存占用。我在调试时发现，1660Ti 在 ComfyUI 里跑 Qwen-Image-2.1 的 GGUF 版本，显存峰值比 Diffusers 方案低一些，大约 4.8GB 就能稳住，可能是因为 GGUF 已经做了 4bit 权重打包。

但 ComfyUI 也有让我头疼的地方：首先是插件版本和主程序版本之间经常出现兼容性问题，升级主程序后插件没跟上就会报节点缺失；其次图形化界面里如果某个节点画错了连线，排查起来比看 Python 报错更费劲。我的建议是：出问题先看红色节点提示，大多数情况是模型文件路径没配对，而不是真有什么深层错误。

3.3 低显存参数背后的原理，不只是“抄作业”

很多人喜欢直接复制参数，但我要强调一下为什么这些参数这么设，因为环境稍微一变，你可能就需要自己调整。

num_inference_steps我设成 20，理论上扩散模型采样步数越多细节越丰富，但 1660Ti 的算力有限，25 步和 20 步在肉眼观感上差别很小，时间却能省下 20%。这不是偷懒，而是低算力环境下的时间成本平衡。

guidance_scale设成 3.5，没有用默认的 7 或更高。CFG 越大，模型对提示词的遵循越强，但代价是需要“正向 + 负向”两遍推理，显存和耗时都会涨。在 6GB 显存环境下，过大的 CFG 很容易让显存吃紧。我在调试时从 7 降到 5、再降到 3.5，才在显存和提示词遵循度之间找到一个可接受的点。

height和width设为 512，这是 1660Ti 能稳定跑通的上限附近。我把分辨率拉到 768 试过，即使开着 offload，出图时间直接翻到 4 分钟以上，中途还经常触发 OOM。如果你一定要高分辨率图，我建议先以 512 出图，再用常规放大工具做后处理，而不是直接让模型硬顶高分辨率。

3.4 实测数据：贴着显存上限跑完

我把实际跑出来的数据整理了一下。这是我的环境实测结果，不同机器会有差异，但相对比例有参考价值：

第二行的 768×512 差点崩掉，是我反复调参记录下来的极限值。老实说，跑到这个分辨率时风扇已经拉满，我一度担心长期这样会不会伤硬件。后来我就把日常出图锁定在 512×512，只有做局部重绘或临时看图时才降到更小分辨率。

耗时上，ComfyUI 确实比 Python 脚本快一些，主要原因是 GGUF 量化在加载阶段做了更紧凑的算子融合，显存交换次数更少。但差距不算大，不至于为了十几秒的速度放弃脚本的灵活性。

4. 常见问题与排查技巧：我踩过的坑

4.1 高频问题：CUDA out of memory

这是低显存用户遇到最多的报错，没有之一。我的排查顺序是这样的：

第一步，先看是不是batch_size大于 1。单卡 6GB 显存，任何 batch size 大于 1 的场景都是自找麻烦，直接改成 1。

第二步，确认是否开启了enable_sequential_cpu_offload()。有人只开了enable_model_cpu_offload()——这俩是不一样的。model offload把整个模块整体卸载，而sequential offload按层卸载，后者更激进，显存占用更低。所以遇到 OOM，先把model offload换成sequential offload。

第三步，设置环境变量让 PyTorch 的小块显存分配更细：

export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128

这样做的好处是减少显存碎片化。我实测这个变量对 1660Ti 非常有效，有些场景设置后峰值直降 0.4GB 左右。

第四步还是不行，就降分辨率。从 768 降到 640，再降到 512，总能找到一个稳住的点。显存问题本质上就是“模型放不下”，要么压缩模型，要么缩小输入，没有第三条路。

4.2 模型加载卡住与系统内存耗尽

Diffusers 首次加载时很大概率出现“看起来像假死”的现象，其实是在加载权重到内存。如果系统内存只有 16GB 或以下，这一步很容易直接卡死。

我的处理办法：

• 打开任务管理器确认 Python 进程的内存占用；
• 如果内存耗尽，先加一个系统交换文件。Windows 下我手动设置了 16GB 的虚拟内存，Mac 或 Linux 也用同样的思路；
• 如果内存明明足够但加载极慢，检查模型文件放在机械硬盘还是固态硬盘。机械硬盘的随机读取速度在这种场景下是个大瓶颈，13GB 的权重文件在机械盘上加载需要好几分钟，期间看起来像死机。

注意：加载 Qwen-Image-2.1 这种体量的模型时，CPU 内存建议至少 24GB。内存不够，再快的显卡也白搭。

4.3 出图全黑、噪点多、颜色发灰的排查思路

模型跑起来了，结果出来一张黑图或者充满噪点的图，这种问题比 OOM 更让人抓狂。我的排查经验是：

先看 VAE 是否用了 FP16。很多图像模型在 FP16 下 VAE 解码会数值溢出，导致生成结果出现黑块或噪点。常见的解决办法是在 pipeline 里单独给 VAE 指定torch_dtype=torch.float32。

代码片段：

pipe.vae = pipe.vae.to(torch.float32)

改完之后再跑一张，大部分黑图问题会立刻消失。

其次看负面提示词。如果只是一味强调“质量高”，但没有提供负面词，模型会倾向于生成模糊或灰蒙蒙的画面。1660Ti 算力有限，我不会用复杂的负面词库，一般固定这一句负面词就够用：“lowres, bad anatomy, worst quality, blurry”。

最后看采样器和步数设置。有的采样器在低步数时收敛不稳定，建议用 DPM++ 2M Karras 或 Euler a，并在 20 步左右测试。不要乱换采样器，低配显卡玩不起反复实验。

4.4 出图提速的几个实用技巧

在跑通之后，我花了不少时间优化速度，总结出四个立竿见影的技巧：

第一，开启torch.compile。图灵架构虽然老，但编译优化还是能带来 15%~25% 的提升，开启方法很简单：

pipe.transformer = torch.compile(pipe.transformer, mode="reduce-overhead", backend="inductor")

代价是首次运行需要额外几分钟做编译预热，之后就好用了。

第二，缓存文本编码器的输出。如果多次生成都用同一组提示词，或者用同一张参考图做图生图，文本编码结果其实可以复用。Diffusers 里的做法是先单独调用文本编码器，保存 embedding，再传给采样器。这样能省下每次最耗时的编码阶段。

第三，采样步数控制在 16~20 之间，CFG 控制在 3~5。你不会想为了多 5% 的画质多等 60 秒的。

第四，关闭不需要的额外模块。比如图生图时如果不需要原图细节注入，就不要开启额外的图像分析模块。每个额外模块都意味着显存占用和计算时间。

5. 一些个人体会与后续可扩展方向

这次在 1660Ti 上跑通 Qwen-Image-2.1，给我最大的体会是：低显存只是门槛，不是死路。只要你能接受速度和画质的取舍，6GB 显存的老卡依然能玩最新的开源图像模型。整个过程里，最花时间的不是写代码，而是慢慢试探哪个参数组合能让显存峰值落在安全线内。

最后分享一个小技巧：不要在低配机器上做“一次跑完整流程”的美梦。我的习惯是先跑一步测试，比如只调用文本编码器确认权重加载正常，再单独跑 VAE 解码确认没有数值溢出，最后再走完整采样链路。每一步都确认稳定了再合起来，能省下大量排查时间。

这个部署完成之后，我还打算继续折腾两件事：一是尝试把低显存的优化策略迁移到其他图像模型上，二是研究一下 8GB 显存显卡能不能通过更多层的 offload 策略跑通 1024×1024 分辨率。到时候如果跑通了，再回来跟大家分享新的实测数据。