Stable Diffusion部署四路线：官方原版、整合包、Docker与ComfyUI选型指南

1. 为什么部署方式的选择比模型本身更影响体验

很多人第一次接触 Stable Diffusion，注意力全在模型上——哪个大模型画风好、哪个 LoRA 出图精致，却忽略了真正决定日常使用体验的其实是部署方式。我见过太多人下载了上百 G 的模型，结果卡在环境配置上三天没出一张图，最后热情耗尽直接弃坑。也见过有人用整合包跑通了，但想加个插件就各种报错，因为整合包的 Python 环境被锁死了。

部署方式的选择直接决定了三件事：上手速度、可扩展性、长期维护成本。官方原版最干净但门槛最高，整合包最快但容易变成黑盒，Docker 最规范但需要理解容器概念，ComfyUI 则是另一套完全不同的工作流逻辑。这四种路线没有绝对优劣，只有适不适合你当前阶段。

这篇文章我会把四条路线全部拆开讲透，包括每条路线适合什么人、核心原理是什么、具体怎么操作、踩坑了怎么排查。不管你是完全没碰过命令行的新手，还是想从整合包迁移到规范化部署的老玩家，都能找到对应的方案。核心关键词会自然融入各个章节，不堆砌，只讲能直接抄作业的实操内容。

2. 四条部署路线的整体设计与选型逻辑

2.1 先搞清楚这四条路线到底在解决什么问题

Stable Diffusion 本质上是一个需要 GPU 算力的深度学习推理程序，它的运行依赖 Python 环境、PyTorch 框架、CUDA 驱动、一系列图像处理库，以及一个前端界面。所谓"部署"，就是把这一整条依赖链在你的机器上跑通，并且提供一个能交互的入口。

官方原版（Automatic1111 WebUI 或 Forge）是最接近源码的形态。你手动安装 Python、手动装 PyTorch、手动克隆仓库、手动装依赖。好处是环境透明，任何插件、任何自定义节点都能装，出问题你知道去哪找。坏处是每一步都可能因为版本不匹配而失败，尤其是国内网络环境下，pip 装依赖经常卡在 installing requirement 那一步动不了。

整合包是社区玩家把上述所有步骤预先打包好的产物，典型代表就是秋叶系列。它内置了便携版 Python、预配置好的依赖、一键启动脚本，甚至帮你设好了国内镜像源。解压即用，双击启动，五分钟出图。代价是环境被封装成黑盒，你想升级某个库或者装一个依赖冲突的插件，可能会把整个环境搞崩。

Docker 部署是把整个运行环境封装进容器镜像。它的核心价值在于环境隔离和可复现——镜像里是什么版本就是什么版本，不会因为你宿主机装了什么而改变。适合有多台机器、需要团队协作、或者想在同一台机器上跑多个不同版本 SD 的场景。门槛在于你需要理解镜像、容器、端口映射、卷挂载这几个概念。

ComfyUI严格来说不是"另一种部署方式"，而是另一种前端。它和 WebUI 可以共用同一套模型文件，但工作流逻辑完全不同。WebUI 是表单式操作，填参数点生成；ComfyUI 是节点式编程，你把加载模型、编码提示词、采样、解码这些步骤用节点连起来。灵活度极高，适合做复杂工作流和批量自动化，但学习曲线陡峭。

2.2 选型决策：对号入座比盲目追新更重要

我整理了一张决策表，你直接对照自己的情况选：

这里有个很多人忽略的点：整合包和官方原版并不是对立的。你可以先用整合包快速跑通建立信心，等熟悉了再迁移到官方原版。我自己就是这么过来的——第一个月用整合包出了几百张图，摸清了采样器、CFG、步数这些参数的作用，然后才动手搭官方环境，这时候遇到报错也不会慌，因为我知道每个环节在干什么。

2.3 硬件门槛的真实情况

网上很多教程把硬件要求说得很吓人，实际体验下来：

• 显存 4G：能跑，但只能用 512x512 分辨率，出图慢，部分模型加载会爆显存
• 显存 6G：主流甜点，768x768 流畅，可以用大部分优化手段
• 显存 8G 以上：1024x1024 无压力，可以开高分辨率修复
• 显存 12G 以上：可以跑 SDXL 和视频模型

内存建议 16G 起步，32G 更稳。硬盘一定要 SSD，模型加载速度差距非常明显——机械硬盘加载一个 6G 的大模型可能要一两分钟，SSD 十几秒就搞定。另外预留至少 100G 空间，模型文件动辄几个 G，很快就能塞满。

3. 官方原版部署：从零搭建透明可控的环境

3.1 环境准备的核心逻辑

官方原版部署最容易出问题的地方就是环境。我把它拆成四个必须对齐的组件：显卡驱动、CUDA、Python、PyTorch。这四个东西版本必须互相兼容，错一个就报错。

先说显卡驱动。N 卡用户去官网下最新驱动就行，装完在命令行敲nvidia-smi，能看到显卡信息和 CUDA Version 就说明驱动没问题。注意这里显示的 CUDA Version 是驱动支持的最高版本，不是你实际装的版本。

Python 版本选择很关键。目前 WebUI 和 Forge 主流支持 Python 3.10.x，强烈建议用 3.10.6 或 3.10.11，不要用 3.11 或 3.12，很多依赖包还没适配。安装时务必勾选"Add Python to PATH"，否则后面命令行找不到 python。

PyTorch 的安装是重头戏。你需要根据显卡驱动支持的 CUDA 版本去 PyTorch 官网找对应的安装命令。比如驱动支持 CUDA 12.1，就装torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121。装完验证一下：

import torch print(torch.__version__) print(torch.cuda.is_available())

第二行输出 True 才算成功。如果是 False，说明 PyTorch 没识别到显卡，八成是 CUDA 版本不匹配。

3.2 拉取仓库与安装依赖

环境搞定后，克隆仓库。WebUI 和 Forge 二选一：

git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git # 或者 Forge 版本 git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git

然后进入目录运行启动脚本。Windows 下双击webui-user.bat，Linux 下运行webui.sh。第一次启动会自动创建虚拟环境并安装依赖，这一步就是很多人卡住的"installing requirement"。

卡住的核心原因通常是网络。pip 默认从国外源下载，速度极慢甚至超时。解决办法是配置国内镜像源。在 webui 目录下找到或创建pip.ini（Windows）或pip.conf（Linux），写入：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple timeout = 120

如果已经卡住了，先 Ctrl+C 中断，配好镜像源再重新启动。有时候是某个特定包下载失败，可以看日志里最后一行是哪个包，单独用pip install 包名 -i 镜像源装一下再继续。

3.3 模型放置与首次出图

依赖装完后，把下载的模型文件（.safetensors 或 .ckpt）放进models/Stable-diffusion/目录。VAE 放models/VAE/，LoRA 放models/Lora/。刷新一下界面就能在模型下拉框里看到。

首次出图建议用最简单的参数：采样器选 Euler a，步数 20，CFG 7，分辨率 512x512，提示词写个简单的英文描述。点生成，如果几秒到几十秒后出图，恭喜你环境搭好了。

注意：第一次生成会加载模型到显存，比较慢，之后会快很多。如果报 CUDA out of memory，降低分辨率或加--medvram启动参数。

3.4 启动参数优化实战

官方原版的启动参数直接决定性能和功能。在webui-user.bat里找到set COMMANDLINE_ARGS=这一行，按需添加：

• --xformers：启用 xformers 加速注意力计算，能显著降低显存占用并提速，强烈推荐
• --medvram：显存 6G 左右用，牺牲一点速度换显存
• --lowvram：显存 4G 用，速度更慢但能跑
• --api：开启 API 接口，方便其他程序调用
• --listen：允许局域网访问，手机也能连
• --port 7861：改端口，避免冲突

我实测下来，--xformers在 3060 上能把出图速度提升 30% 左右，显存占用降低约 1G，属于必开项。如果你的显卡比较新（40 系），可能 xformers 兼容性有问题，可以改用--opt-sdp-attention。

4. 整合包部署：最快出图路线与它的边界

4.1 整合包到底整合了什么

秋叶整合包之所以能做到解压即用，是因为它把一整套运行环境都打包进去了。具体包括：便携版 Python 解释器、预装好的 PyTorch 和 CUDA 运行时、所有依赖库、预配置的国内镜像源、一键启动脚本、常用插件和模型。

它的工作原理是：启动脚本调用包内的便携 Python，而不是你系统里的 Python，所以不会和你系统环境冲突。所有依赖都装在包内的python目录下，模型放在models目录。整个包就是一个自包含的沙盒。

这种设计的好处是零污染、零配置。你系统里装没装 Python、装了几个版本，都不影响它运行。坏处是升级困难——你想升级 PyTorch 版本，得手动替换包内文件，很容易搞坏。而且整合包通常锁定在某个版本，新出的插件如果依赖更新的库，可能装不上。

4.2 下载与启动的正确姿势

下载整合包要注意两点：来源可靠和解压路径不含中文。路径含中文是新手最常见的坑，会导致各种莫名其妙的编码错误。建议解压到D:\SD这种纯英文短路径。

解压后目录结构大致是：

SD/ ├── launch.bat # 启动脚本 ├── python/ # 便携 Python 环境 ├── models/ # 模型目录 ├── extensions/ # 插件目录 ├── webui/ # 主程序 └── output/ # 出图目录

双击launch.bat，会弹出一个命令行窗口开始加载。第一次启动会检查依赖，可能需要几分钟。看到Running on local URL: http://127.0.0.1:7860就说明成功了，浏览器会自动打开界面。

4.3 整合包的扩展与迁移

整合包用久了想装新插件，直接在 WebUI 的"扩展"标签页里从 URL 安装即可，大部分插件能正常装。如果装完启动报错，通常是依赖冲突，可以在整合包的 Python 环境里手动装依赖：

# 进入整合包目录 cd D:\SD # 用包内 Python 装依赖 python\python.exe -m pip install 包名 -i https://pypi.tuna.tsinghua.edu.cn/simple

如果整合包彻底玩坏了，最省事的办法是重新解压一份，把models和output目录拷过去，几分钟就恢复。这也是整合包的一个隐性优势——容错成本低。

实操心得：整合包建议保留一份纯净备份，玩坏了直接覆盖，比排查问题快得多。模型目录可以单独放，用软链接或者启动参数指向，这样换整合包不用重新下模型。

4.4 什么时候该从整合包毕业

整合包不是终点。当你出现以下需求时，就该考虑迁移到官方原版或 Docker 了：

• 想用最新的 PyTorch 或 CUDA 特性
• 需要装依赖冲突严重的插件
• 想同时跑多个不同配置的实例
• 需要精细控制启动参数和性能调优
• 想理解每一步到底发生了什么

迁移的时候，模型文件直接拷过去就行，插件列表可以导出，剩下的就是重新搭一遍环境。有了整合包的使用经验，你对整个流程已经有直觉了，迁移不会太难。

5. Docker 部署：环境隔离与可复现的终极方案

5.1 Docker 部署 SD 的核心价值

Docker 解决的是"在我机器上能跑"这个经典问题。它把 SD 运行所需的一切——操作系统层、Python、CUDA、依赖库、程序代码——全部封装进一个镜像。你在任何装了 Docker 的机器上运行这个镜像，得到的环境完全一致。

对 SD 来说，Docker 的价值体现在几个具体场景：多版本共存（一个容器跑 WebUI，一个跑 ComfyUI，互不干扰）、快速迁移（换机器只需拉镜像）、团队协作（大家用同一个镜像，不会出现"你的能跑我的不能跑"）、干净卸载（删容器就完事，不留垃圾）。

代价是GPU 直通配置有一定门槛。Docker 默认不能访问宿主机 GPU，需要装 NVIDIA Container Toolkit 并配置。这一步配好了后面就一劳永逸。

5.2 环境准备与 GPU 直通配置

先装 Docker Desktop（Windows/Mac）或 Docker Engine（Linux）。Windows 用户注意，Docker Desktop 需要开启 WSL2 或 Hyper-V。如果启动时报 "virtualization support not detected"，说明 BIOS 里没开虚拟化，重启进 BIOS 打开 VT-x/AMD-V 即可。

装完 Docker 后，配置 GPU 支持。Linux 下：

# 添加 NVIDIA 容器工具包源 distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list # 安装并重启 Docker sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker

验证 GPU 直通是否成功：

docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

能看到显卡信息就说明配置好了。Windows 下 Docker Desktop 较新版本已经内置 GPU 支持，勾选设置里的"Use the WSL 2 based engine"即可。

5.3 运行 SD 容器实战

社区有现成的 SD 镜像可以直接用。以 WebUI 为例：

docker run -d \ --name sd-webui \ --gpus all \ -p 7860:7860 \ -v /path/to/models:/app/models \ -v /path/to/output:/app/output \ --restart unless-stopped \ sd-webui-image

参数逐个解释：--gpus all让容器用所有 GPU；-p 7860:7860把容器端口映射到宿主机；-v把模型和输出目录挂载出来，这样容器删了数据还在；--restart unless-stopped让容器开机自启。

挂载卷这一步非常关键。千万不要把模型放在容器内部，否则容器一删模型全没。所有需要持久化的数据——模型、输出、配置——都要挂载到宿主机。

5.4 Docker Compose 管理多实例

当你需要同时跑多个服务时，用 Docker Compose 管理更清晰。创建一个docker-compose.yml：

version: '3.8' services: sd-webui: image: sd-webui-image ports: - "7860:7860" volumes: - ./models:/app/models - ./output-webui:/app/output deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] restart: unless-stopped comfyui: image: comfyui-image ports: - "8188:8188" volumes: - ./models:/app/models - ./output-comfy:/app/output deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] restart: unless-stopped

这样两个服务共用同一份模型目录，节省硬盘空间，各自输出到不同目录。docker compose up -d一键启动，docker compose logs -f看日志，docker compose down停止。

注意：两个容器同时跑会争抢显存，如果显存不够，建议用CUDA_VISIBLE_DEVICES环境变量给它们分配不同显卡，或者错峰使用。

5.5 Docker 部署的常见坑

坑一：镜像拉取慢。配置国内镜像加速器，在 Docker Desktop 设置里添加 registry-mirrors。

坑二：容器内路径和宿主机路径混淆。记住-v左边是宿主机，右边是容器。你在容器里看到的/app/models实际对应宿主机的/path/to/models。

坑三：权限问题。Linux 下容器内用户可能没权限写挂载目录，加--user $(id -u):$(id -g)或者调整目录权限。

坑四：显存不释放。容器停止后显存有时不会立即释放，nvidia-smi看到残留进程可以手动 kill，或者重启 Docker 服务。

6. ComfyUI 实战：节点式工作流的威力与门槛

6.1 ComfyUI 和 WebUI 的本质区别

WebUI 是"填表式"的——你在一堆输入框里填提示词、选模型、调参数，点生成。ComfyUI 是"连线式"的——界面上是一堆节点，每个节点做一件事，你用线把它们连起来定义数据流向。

这个区别带来的影响是根本性的。WebUI 里你想换个采样流程，只能用它预设好的那套；ComfyUI 里你可以把采样器拆开，中间插入任何处理节点。比如你想在采样过程中间做一次图像缩放再继续采样，WebUI 做不到，ComfyUI 连几根线就行。

代价是学习曲线。第一次打开 ComfyUI，满屏节点和连线会让人懵。但理解几个核心节点后，你会发现它其实很直观——无非是"加载模型→编码提示词→采样→解码→保存"这条主线。

6.2 核心节点与最小工作流

一个能出图的最小工作流包含这些节点：

• Load Checkpoint：加载大模型
• CLIP Text Encode（两个）：分别编码正向和负向提示词
• Empty Latent Image：定义生成图像的尺寸
• KSampler：采样器，核心中的核心
• VAE Decode：把潜空间数据解码成图像
• Save Image：保存结果

把它们按数据流连起来：Checkpoint 的 MODEL 输出接 KSampler 的 model 输入，CLIP 输出接两个 Text Encode，Text Encode 输出接 KSampler 的 positive 和 negative，Empty Latent 接 KSampler 的 latent_image，KSampler 输出接 VAE Decode，最后接 Save Image。

KSampler 的参数和 WebUI 一一对应：steps 是步数，cfg 是提示词引导强度，sampler_name 是采样器，scheduler 是调度器，denoise 是重绘幅度。理解这些参数在 WebUI 里的作用，迁移到 ComfyUI 就很快。

6.3 秋叶 ComfyUI 整合包的使用

和 WebUI 整合包一样，秋叶也出了 ComfyUI 整合包，解压即用。启动后浏览器打开http://127.0.0.1:8188。它预装了常用节点和 ComfyUI Manager，后者是管理插件的利器。

ComfyUI Manager 可以一键安装、更新、卸载插件，还能检查缺失节点。当你加载别人分享的工作流时，如果提示缺少节点，打开 Manager 点"Install Missing Custom Nodes"就能自动补齐。这个功能极大降低了使用门槛。

模型目录结构和 WebUI 类似，models/checkpoints放大模型，models/loras放 LoRA，models/vae放 VAE。如果你已经装了 WebUI，可以在 ComfyUI 的配置文件里把模型路径指向 WebUI 的目录，省一份硬盘空间。

6.4 工作流分享与复用

ComfyUI 最强大的地方是工作流可以导出成 JSON 文件分享。别人拿到你的 JSON，拖进界面就能复现你的完整流程，包括所有参数和节点连接。这比 WebUI 分享一张图的参数要完整得多。

社区有大量现成工作流可以下载，比如图生图、局部重绘、ControlNet 组合、批量处理等。我的建议是先从别人的工作流开始用，跑通了再逐个节点研究它在干什么，最后自己改。这比从零搭工作流效率高得多。

实操心得：工作流里如果用了自定义节点，分享给别人时对方可能没装。导出前用 Manager 的"Save"功能，它会提示哪些节点是自定义的。或者干脆截图加文字说明，比 JSON 更通用。

6.5 ComfyUI 的性能调优

ComfyUI 在显存管理上比 WebUI 更激进，默认就会把不用的模型从显存卸载。启动参数里可以加：

• --lowvram：低显存模式
• --normalvram：正常模式
• --highvram：高显存模式，模型常驻显存，速度快但占显存
• --fp8_e4m3fn-unet：用 fp8 精度跑 UNet，显存减半，画质损失很小

实测在 8G 显存上，用 fp8 精度可以跑 SDXL 模型，这在 WebUI 上比较吃力。ComfyUI 的显存优化确实做得更好，这也是它在低配机器上受欢迎的原因。

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

7.1 启动阶段问题速查

7.2 出图阶段问题排查

出图全黑或全灰：通常是 VAE 问题。检查是否加载了正确的 VAE，有些模型需要配套 VAE。也可能是提示词太短或 CFG 太低。

出图人物扭曲：分辨率太低或模型不适合该题材。SD 1.5 在 512x512 下人物容易崩，可以开高分辨率修复，或者换 SDXL 模型。

出图速度突然变慢：检查是否有其他程序占用 GPU，或者显存快满了在频繁交换。用nvidia-smi看显存占用。

插件装了但界面不显示：重启 WebUI，或者检查插件是否兼容当前版本。有些插件需要特定版本的依赖。

7.3 我踩过的几个真实坑

坑一：整合包和官方版共用模型目录导致冲突。我一开始把两个环境的模型目录设成同一个，结果两边同时启动时互相锁文件。后来改成各自独立目录，用软链接共享，问题解决。

坑二：Docker 容器时区不对导致输出文件时间戳混乱。加-e TZ=Asia/Shanghai环境变量解决。

坑三：ComfyUI 工作流加载后节点全红。这是缺少自定义节点，用 Manager 装缺失节点即可。如果 Manager 也装不上，可能是网络问题，手动 git clone 到 custom_nodes 目录。

坑四：xformers 和某些插件冲突导致出图花屏。关掉 xformers 改用 sdp attention 就正常了。这种兼容性问题没有通用解，只能一个个试。

7.4 性能优化的几个实用技巧

模型格式选择：优先用 safetensors 格式，加载快且安全。ckpt 格式有安全风险且加载慢。

精度选择：fp16 比 fp32 快一倍且显存减半，画质几乎无差别。除非模型明确要求 fp32，否则都用 fp16。

批处理：一次生成多张比多次生成单张效率高，因为模型只加载一次。但显存占用会成倍增加，量力而行。

缓存利用：ComfyUI 会缓存已加载的模型，连续用同一个模型出图会越来越快。频繁切换模型反而慢。

系统层面：关掉不必要的后台程序，尤其是浏览器多标签页，它们会占用显存。Windows 下可以在显卡设置里把 Python 设为高性能模式。

8. 四条路线的协同与进阶思路

部署不是一次性的选择，而是可以组合使用的。我现在的配置是：Docker 跑一个 WebUI 做日常出图，本地装一个 ComfyUI 做复杂工作流，模型目录通过挂载共享。这样既有 Docker 的稳定性，又有 ComfyUI 的灵活性。

如果你还在纠结选哪条路线，我的建议是：先用整合包跑通，建立对 SD 的直觉；然后花一个周末搭官方原版，理解每个环节；最后按需上 Docker 或 ComfyUI。这个过程走下来，你对 SD 的理解会超过 90% 的用户，遇到任何问题都能自己定位。

部署这件事，本质上是在"省事"和"可控"之间找平衡。整合包省事但可控性差，官方原版可控但费事，Docker 和 ComfyUI 在各自维度上提供了新的平衡点。没有最好的方案，只有最适合你当前阶段的方案。等你把四条路线都摸过一遍，自然就知道自己该长期用哪套了。