企业官网建设流程全解析

1. 先把部署路线选清楚：四条路各自的适用人群

Stable Diffusion 的部署方式，说到底是四种：官方原版、社区整合包、Docker 容器、ComfyUI 节点流。很多人一上来就问“哪个最好”，这个问题本身就不成立，因为四条路服务的是完全不同的人。我自己从 2023 年开始折腾，前后在五台机器上装过十几遍，踩过的坑足够写一本小册子。这篇就把四条路线拆开讲透，包括每一步为什么这么做、参数怎么算、出问题怎么查。

先给一个结论性的对照表，方便你对号入座：

为什么官方原版反而最难？因为它只给你一个 Python 环境和一份 requirements.txt，剩下的 CUDA 版本、torch 编译、xformers 匹配全靠自己。整合包把这些全部打包好了，双击 run.bat 就能跑，代价是环境被锁死，你想升级某个库可能直接崩。Docker 的价值在于“一次构建，到处运行”，特别适合你有多个项目、多个 Python 版本互相打架的场景。ComfyUI 则是另一条赛道，它不追求开箱即用，而是追求工作流的可复用和可版本化。

我个人的建议是：如果你只是想出图，直接上整合包；如果你想长期做项目、要复现、要迁移，Docker 是正解；如果你要做复杂的多模型串联、批量处理，ComfyUI 值得投入时间学。下面逐条展开。

2. 官方原版部署：从零理解依赖链的每一步

2.1 为什么官方部署总是卡在 installing requirements

热词里有个高频问题：“stable diffusion webui forge run.bat 卡在 installing requirement”。这个现象几乎每个用官方方式部署的人都遇到过。根本原因有三个：一是 pip 默认走国外源，下载 torch 这种几百 MB 的包经常超时；二是 requirements 里某些包的版本和你的 CUDA 驱动不匹配，pip 会反复尝试解析依赖；三是 Windows 下长路径和权限问题导致写入失败。

解决思路很直接：先换国内源，再手动锁定 torch 版本，最后分步安装而不是一把梭。具体操作：

# 第一步：升级 pip 并换源 python -m pip install --upgrade pip pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple # 第二步：先单独装 torch，指定 CUDA 版本 # CUDA 11.8 对应 cu118，CUDA 12.1 对应 cu121 pip install torch==2.1.2 torchvision==0.16.2 --index-url https://download.pytorch.org/whl/cu118 # 第三步：再装其余依赖 pip install -r requirements.txt

为什么要先装 torch？因为 requirements.txt 里通常写的是torch不带版本号，pip 会去解析最新版，而最新版可能要求更高的 CUDA。你先手动钉死版本，pip 在装其他包时就会以这个为基准，冲突概率大幅下降。

2.2 CUDA、驱动、torch 三者的版本对应关系

这是官方部署最容易翻车的地方。很多人显卡驱动是 535，却去装 cu121 的 torch，结果torch.cuda.is_available()返回 False。记住一个原则：驱动版本决定你能用的最高 CUDA 运行时版本，torch 的 cuXXX 必须小于等于这个上限。

查驱动支持的最高 CUDA 版本：

nvidia-smi # 右上角会显示 CUDA Version: 12.2 之类

然后对照：

实测下来，如果你不确定，就选比上限低一档的版本，稳定性最好。比如驱动支持 12.2，你就装 cu118，几乎不会出问题。

2.3 启动参数怎么调：显存不够的救命配置

官方 WebUI 的启动参数直接决定你能不能跑起来。低显存用户（8G 以下）必须加这几个：

# 在 webui-user.bat 里设置 set COMMANDLINE_ARGS=--medvram --xformers --opt-split-attention

• --medvram：把模型分阶段加载，显存占用降 30% 左右，代价是速度慢一点。
• --lowvram：更激进，适合 4G 显存，但速度会明显下降。
• --xformers：用 xformers 库优化注意力计算，速度快 20%-30%，显存也省。
• --opt-split-attention：不装 xformers 时的替代方案。

这里有个坑：xformers 的版本必须和 torch 严格对应，装错了会直接报undefined symbol。如果你不想折腾，就用--opt-split-attention，效果差一点但不会崩。

3. 整合包部署：快是真快，坑也是真坑

3.1 秋叶整合包为什么能一键跑起来

秋叶整合包（包括 WebUI 版和 ComfyUI 版）的核心价值在于：它把 Python 运行时、CUDA 库、torch、所有依赖、常用模型、常用插件全部打包在一个目录里，用嵌入式 Python 解释器，不污染系统环境。你解压完双击启动器，它自动检测显卡、自动配置参数、自动开浏览器。

它的启动器做了几件事：检测显卡型号和显存、根据显存自动选择优化参数、检查模型目录、启动一个本地 HTTP 服务。这些逻辑写在启动器的 exe 里，你看不到但确实在跑。

3.2 整合包的三个典型故障与修复

故障一：启动后浏览器打不开，命令行报端口占用。原因是 7860 端口被其他程序占了。解决办法是改启动参数--port 7861，或者在启动器设置里改端口。

故障二：生成图片时报RuntimeError: CUDA out of memory。整合包默认参数偏保守，但如果你的显存特别小（比如 6G），还是不够。进启动器的高级选项，把“显存优化”从“平衡”改成“低显存”，它会自动加--lowvram。

故障三：装了新插件后启动崩溃。整合包的环境是锁定的，新插件可能要求更高版本的某个库。这时候不要直接 pip install 升级，而是去插件的 GitHub 页面看它的 requirements，手动装兼容版本。实在不行就把插件目录删掉，重启即可恢复。

提示：整合包不要放在中文路径或带空格的路径下，这是最常见的“莫名其妙启动失败”原因。路径改成D:\SD这种最稳。

3.3 整合包能不能升级、能不能迁移

能，但要讲方法。升级模型和插件是安全的，直接替换文件即可。升级核心程序（比如 WebUI 本体）要谨慎，因为整合包的 Python 环境是定制的，新版 WebUI 可能要求新的依赖。我的做法是：保留旧版本目录不动，下载新版整合包解压到新目录，把models和extensions目录整个拷过去，这样既升级了又保留了资产。

迁移到另一台机器更简单，整个目录拷贝过去，但要注意目标机器的显卡驱动版本不能低于原机器，否则 CUDA 会不兼容。

4. Docker 部署：环境隔离的正解与网络配置的坑

4.1 Docker Desktop 装不上：virtualization support not detected 的排查链

热词里“virtualization support not detected docker desktop failed to start”是高频问题。这个报错的意思是 Docker Desktop 需要 WSL2 或 Hyper-V，而你的 CPU 虚拟化没开。排查链路是这样的：

第一步，进 BIOS 开虚拟化。Intel 叫 VT-x，AMD 叫 SVM，通常在 Advanced 或 CPU Configuration 里。开完保存重启。

第二步，确认 Windows 功能里开启了“虚拟机平台”和“适用于 Linux 的 Windows 子系统”。用管理员 PowerShell：

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

第三步，装 WSL2 内核更新包，然后wsl --set-default-version 2。

第四步，如果还报错，检查是不是装了其他虚拟化软件（比如某些安卓模拟器）占用了 Hyper-V。关掉它们再试。

4.2 用 Docker 跑 Stable Diffusion 的镜像选择

Docker 跑 SD 有两种思路：一是用现成的镜像（比如siutin/stable-diffusion-webui-docker），二是自己写 Dockerfile。现成镜像省事但版本可能旧，自己写灵活但要处理 GPU 透传。

自己写 Dockerfile 的核心是基础镜像要带 CUDA：

FROM nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04 RUN apt-get update && apt-get install -y python3 python3-pip git wget RUN pip3 install torch==2.1.2 torchvision==0.16.2 --index-url https://download.pytorch.org/whl/cu118 WORKDIR /app RUN git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git WORKDIR /app/stable-diffusion-webui RUN pip3 install -r requirements.txt EXPOSE 7860 CMD ["python3", "launch.py", "--listen", "--port", "7860"]

启动容器时必须加--gpus all：

docker run --gpus all -p 7860:7860 -v /host/models:/app/stable-diffusion-webui/models -d sd-webui

-v挂载模型目录是关键，否则每次重建容器模型都没了。

4.3 Docker 网络与国内源加速

Docker 拉镜像慢是常态，配置国内镜像加速器：

{ "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com" ] }

写在 Docker Desktop 的 Settings → Docker Engine 里，重启生效。容器内部 pip 也要换源，在 Dockerfile 里加pip config set global.index-url。

还有一个坑：容器内访问宿主机的服务（比如你想让容器里的 SD 调用宿主机的某个 API），不能用localhost，要用host.docker.internal（Windows/Mac）或宿主机的实际 IP（Linux）。

5. ComfyUI 部署：节点流的核心逻辑与插件管理

5.1 ComfyUI 和 WebUI 的本质区别

WebUI 是“表单式”的，你填参数、点生成。ComfyUI 是“节点式”的，你把加载模型、编码提示词、采样、解码、保存这些步骤用连线串起来。这个区别决定了 ComfyUI 的学习曲线更陡，但一旦学会，工作流可以保存成 JSON 文件，别人导入就能复现你的完整流程，包括用了哪个模型、什么采样器、多少步、什么 CFG。

为什么 ComfyUI 显存占用更低？因为它按需加载，只有工作流里用到的节点才会实例化模型，不像 WebUI 一次性把所有东西加载进显存。实测同样的 8G 显存，WebUI 跑 512x512 勉强，ComfyUI 能跑 768x768。

5.2 秋叶 ComfyUI 整合包的目录结构与插件安装

秋叶 ComfyUI 整合包的目录结构大致是：

ComfyUI/ ├── ComfyUI/ # 主程序 │ ├── custom_nodes/ # 插件目录 │ ├── models/ # 模型目录 │ └── output/ # 输出目录 ├── python/ # 嵌入式 Python └── 启动器.exe

装插件有两种方式：一是用 ComfyUI Manager（如果整合包预装了），在界面里搜索安装；二是手动 git clone 到custom_nodes目录，然后进插件目录pip install -r requirements.txt。注意要用整合包自带的 python，不是系统的：

..\..\python\python.exe -m pip install -r requirements.txt

5.3 ComfyUI 切换国内源与依赖冲突处理

ComfyUI 的插件生态很活跃，但插件之间的依赖冲突也常见。典型症状是启动时报ImportError: cannot import name 'xxx'。原因是插件 A 要求numpy==1.24，插件 B 要求numpy==1.26，装了一个另一个就崩。

处理原则：优先保证主程序能跑，冲突插件二选一。如果两个都要，就建虚拟环境隔离，但整合包不支持多环境，这时候就体现出 Docker 的优势了。

切换国内源在 ComfyUI 里同样重要，因为 Manager 装插件时会调 pip：

# 在 ComfyUI 根目录建 pip.ini（Windows） [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

6. 模型管理与显存优化的实战经验

6.1 模型目录怎么组织才不乱

不管你用哪种部署方式，模型目录迟早会乱。我的组织方式是按类型分目录，再按来源分子目录：

models/ ├── Stable-diffusion/ # 主模型 │ ├── SD1.5/ │ ├── SDXL/ │ └── Flux/ ├── Lora/ ├── VAE/ ├── ControlNet/ └── Embeddings/

WebUI 和 ComfyUI 都支持通过配置文件指定额外的模型路径，这样你可以让两个程序共享同一份模型，省硬盘。WebUI 在webui-user.bat里加--ckpt-dir，ComfyUI 在extra_model_paths.yaml里配。

6.2 显存不够时的参数调整顺序

显存不够时，按这个顺序调，从影响最小的开始：

1. 降低分辨率。512x512 是 SD1.5 的甜点，768x768 显存翻倍。
2. 减少 batch size。从 4 降到 1，显存降 75%。
3. 加--medvram。降 30% 显存，速度降 10%。
4. 加--lowvram。降 50% 显存，速度降 40%。
5. 换更小的模型。SD1.5 比 SDXL 省一半显存。
6. 用 ComfyUI 替代 WebUI。

实测数据（RTX 3060 12G，512x512，20 步）：

6.3 模型格式 safetensors 与 ckpt 的选择

优先用 safetensors。ckpt 是 pickle 格式，理论上可以执行任意代码，来源不明的 ckpt 有安全风险。safetensors 只存张量数据，加载更快也更安全。现在主流模型都提供 safetensors 版本，如果只有 ckpt，用工具转换一下再用。

7. 常见报错速查与排查思路

7.1 启动类报错

7.2 生成类报错

生成时报NaN或全黑图，通常是 VAE 不匹配或 CFG 太高。先换 VAE，再把 CFG 从 7 降到 5 试试。报RuntimeError: expected scalar type Half but found Float，是半精度问题，加--no-half启动参数，但速度会慢。

7.3 插件类报错

插件报错先看它的 GitHub Issues，90% 的问题别人已经遇到过了。如果 Issues 里没有，就把报错信息完整复制去搜。注意看报错栈的最后一行，那才是真正的错误点，前面的都是调用链。

8. 我踩过的几个印象深刻的坑

第一个坑：曾经为了省事，把整合包放在C:\Users\我的文档\AI\Stable Diffusion这种路径下，结果启动一直失败，报的错还特别模糊。后来改成D:\SD就好了。中文路径和空格是隐形杀手。

第二个坑：Docker 里跑 SD，模型挂载用相对路径，结果容器启动后找不到模型。Docker 的-v必须用绝对路径，Windows 下还要注意盘符写法，D:\models要写成/d/models或者用//d/models。

第三个坑：ComfyUI 装了一个插件后，另一个插件失效了。查了半天发现是 numpy 版本冲突。最后用pip install numpy==1.24.4钉死版本才解决。这件事让我意识到，整合包的“方便”是有代价的，环境不隔离，冲突迟早会来。

第四个坑：以为显存越大越好，买了 24G 的卡，结果发现瓶颈在 CPU 和内存。加载大模型时，如果内存只有 16G，模型从硬盘读到内存再到显存这个过程会非常慢。后来加到 64G 内存，加载速度提升明显。所以配机器要均衡，不能只看显卡。

第五个坑：用--xformers加速，结果生成的图出现奇怪的网格状伪影。查了才知道是 xformers 版本和 torch 不匹配导致的数值精度问题。换回--opt-split-attention后伪影消失。加速是有代价的，出图质量优先时不要盲目开优化。

9. 给不同阶段的人的具体建议

如果你是纯新手，今天就想出图：下载秋叶整合包，解压到英文路径，双击启动器，等它自动打开浏览器，选一个模型，输入提示词，点生成。不要碰任何命令行。

如果你已经会用整合包，想深入：装一个 ComfyUI，从官方示例工作流开始，逐个节点理解它的作用。先跑通最简单的“加载模型→编码提示词→采样→解码→保存”，再逐步加 ControlNet、Lora、放大。

如果你要做团队协作或长期项目：上 Docker。把环境、模型、工作流全部容器化，用 docker-compose 管理。这样换机器、换同事、换服务器，一条命令就能复现。

如果你要部署到服务器给别人用：Docker + Nginx 反向代理 + 鉴权。注意 WebUI 默认没有鉴权，直接暴露公网很危险，必须加--gradio-auth username:password。

最后说一句，部署这件事没有“一劳永逸”的方案。模型在更新，插件在更新，CUDA 在更新，你今天配好的环境，三个月后可能就要调整。所以与其追求一次配好，不如把排查思路练熟。知道报错去哪查、版本怎么对应、参数怎么调，比记住某个具体命令有用得多。