动手写这篇文章之前我先说说为什么选这个时机。做AI绘画工具安装类的内容我已经写了三年多从最早期只有AUTOMATIC1111那一套WebUI脚本到后来节点式ComfyUI异军突起再到如今Docker容器化部署成了团队协作和多机迁移的标准答案。现在搜“Stable Diffusion安装”结果五花八门有让你直接下整合包的有让你跟着敲源码安装的还有一上来就让你上K8s的。很多朋友不是不想学是根本不知道该从哪条路线切入。这篇内容我会把Stable Diffusion WebUI和ComfyUI的完整安装路径一次讲明白官方源码部署、一键整合包、Docker容器化三种方案我都实际跑过。文章会覆盖每条路径的完整步骤、适用场景、隐藏坑点以及我在三种方案之间切换时总结出的经验。无论你是刚接触AI绘画、想给自己电脑装一套本地出图环境的新手还是要批量交付项目、需要在不同机器上复制环境的开发者这篇内容都能给你一份直接抄作业的参考答案。1. 先回答核心问题三种安装方式我是该选官方的、整合包还是 Docker1.1 三种方式的底层差异其实是“Python环境、依赖管理和GPU接口”很多人一上来就陷入一个误区以为WebUI和ComfyUI是两个完全独立的软件。实际上它们共享同一套底层技术栈。两者都是运行在Python环境下的AI推理前端核心依赖都包含PyTorch、CUDA运行时、扩散模型加载器。区别在于WebUI把生成功能组织成了“选项卡”式的功能面板而ComfyUI用工作流节点把整个采样过程可视化、模块化。正因为底层同源三种安装方案的核心差异就不在“软件本身”了而在于环境交付方式。官方源码部署本质上是你自己从零配一套Python虚拟环境克隆代码仓库手动用pip安装所有依赖。这是最“透明”的方案你能看到每一个依赖包的版本出问题时的排查路径也最清晰但代价是初学时很容易在依赖冲突上卡住。整合包方案相当于把“Python解释器虚拟环境预装依赖模型管理界面启动器”整个打包压缩。我通常会推荐初学者从这入手因为省掉了几乎所有环境层面的问题却完全保留了出图功能。缺点是它像一个黑盒出问题之后你能做的操作非常有限而且更新时容易把自定义配置覆盖掉。Docker容器化是把整个运行环境连同系统依赖、Python依赖、启动命令一起固化到一个镜像里。镜像内部的环境永远一致无论在Windows、Linux服务器还是云主机上一条docker run就能把环境完整拉起来。这是目前团队协作和服务器部署最常用、最可靠的方案但学习门槛相对最高。1.2 一张表格看懂适用人群安装方式上手难度环境可控性适合场景主要劣势官方源码部署中高想深入学习需要精确控制依赖版本首次配置耗时长一键整合包低低新手入门本地自用出图黑盒大版本更新麻烦Docker容器化较高极高多机部署团队协作服务器环境需要理解容器基础概念我在实际帮人解决问题时有一套推荐逻辑如果你只是想在本地电脑上跑图没打算研究代码那就用整合包这是性价比最高的选择。如果你想长期研究这个领域学习模型精调、ControlNet、自定义脚本那官方源码部署是必修课因为整合包很难让你接触到底层。如果你有项目交付、多台机器部署、远程服务器出图的需求我建议直接学Docker别在整合包上花时间——因为整合包在服务器上的表现往往不理想。2. 官方部署路线从源码把两大主程序跑起来2.1 环境准备Python、Git和老老实实的CUDA确认很多人第一次部署官方版本时最容易犯的错误是忽略环境前置检查Python装完直接克隆仓库、装依赖结果跑的CPU推理速度只有GPU的二三十分之一。先做三件事。第一安装Python。WebUI官方推荐Python 3.10.6版本ComfyUI的兼容范围更宽一些3.10到3.12都可以。但为了保险我建议Windows用户使用Python 3.10.6或者3.10.11不要去追最新的3.12因为不少图像处理库尚未完全适配。安装时务必勾选“Add Python to PATH”这是新手遇到“python不是内部或外部命令”的首要原因。第二安装Git。这个没有什么特别的门道去Git官网下载Windows版本一路默认安装即可。装完之后打开终端验证一下git --version能输出版本号就算成功。第三确认显卡驱动和CUDA。这里有个常见误区你以为需要自己安装完整版CUDA Toolkit其实对运行Stable Diffusion来说只需要保证NVIDIA显卡驱动足够新。因为PyTorch会在安装时一起带上它需要的CUDA运行时文件。我的经验是NVIDIA驱动版本不低于545系列基本就够用驱动越新越好。驱动装好后在终端输入nvidia-smi看到类似下表的信息就说明识别正常----------------------------------------------------------------------------- | NVIDIA-SMI 545.84 Driver Version: 545.84 CUDA Version: 12.3 | -----------------------------------------------------------------------------注意右上角显示的CUDA Version是驱动支持的最高CUDA版本不代表实际安装的CUDA Toolkit版本。你只需要确认驱动能识别GPU型号和显存大小即可。2.2 WebUI源码安装与首次启动参数确认好环境之后打开终端Windows下建议用PowerShell执行git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui.git cd stable-diffusion-webui接下来是WebUI的依赖安装过程。在Windows下直接双击运行webui-user.bat即可它会自动创建虚拟环境并安装依赖。第一次安装的时间取决于网络状况通常需要15到40分钟这是正常的不需要反复重启。这里我强调几个安装过程中的核心机制方便你后续排查这个脚本会先创建一个venv虚拟环境然后读取requirements_versions.txt中锁定的依赖版本逐条pip安装。其中最关键的是PyTorchWebUI默认会安装CPU版本的PyTorch吗不会脚本里其实没有直接指定PyTorch版本它依赖一个额外的torch2.x.xcu121这样的预编译轮子。如果你在安装日志里看到torch后面没有cu后缀说明装错成CPU版了那就算显卡驱动再新也没有用。首轮安装完成之后程序会启动一个本地服务默认地址是http://127.0.0.1:7860。浏览器打开就能看到WebUI界面。启动参数方面提几个我实际用下来比较常用的参数作用--xformers使用xFormers加速注意力计算显存占用更小速度更快--medvram中等显存优化适合8GB以下显卡--lowvram低显存优化适合6GB以下显卡--precision full --no-half关闭半精度推理解决某些显卡的黑图问题--listen允许局域网内其他设备访问在Windows上修改这些参数直接编辑webui-user.bat中的COMMANDLINE_ARGS一行即可。例如6GB显存的GTX 2060我一般写成set COMMANDLINE_ARGS--xformers --medvram2.3 ComfyUI源码安装更轻的入口更深的折腾空间ComfyUI的官方部署更加轻量。克隆仓库之后它的安装只做两件关键事情安装PyTorch相关依赖然后启动主程序。没有WebUI那么多前期校验。git clone https://github.com/comfyanonymous/ComfyUI.git cd ComfyUI python -m venv venv venv\Scripts\activate pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu121 pip install -r requirements.txt python main.py首次启动后终端会输出当前地址默认是http://127.0.0.1:8188。打开之后就是ComfyUI的节点界面了。这里要特别说明ComfyUI的核心优势体现在工作流上初次打开是一片空白画布需要从左侧的节点列表把“加载模型”“正向提示词”“采样器”“解码”等节点拖到画布上连接起来。如果你觉得从零搭建工作流太费劲官方和社区提供了大量可直接拖拽的workflow文件。你只要下载一个别人分享的xxx_workflow.json文件拖到ComfyUI界面上就能自动生成整套节点。这是ComfyUI组织形式与WebUI差别最大的一点WebUI是打开即用、无需配置ComfyUI允许你精确定义每一步的采样流程。2.4 模型目录结构这是最容易出错的一条无论WebUI还是ComfyUI装好之后第一件事都是放模型。很多人以为把模型放在哪里都一样结果下载的模型不显示从而反复怀疑自己安装出了故障。WebUI的模型目录在models/Stable-diffusion/下大模型文件以.safetensors或.ckpt结尾放这里。其他资源对应关系资源类型存放目录大模型Checkpointmodels/Stable-diffusion/LoRAmodels/Lora/VAEmodels/VAE/Embeddingmodels/embeddings/ControlNet模型models/ControlNet/ComfyUI的目录结构几乎一致大模型在models/checkpoints/LoRA在models/loras/ControlNet在models/controlnet/。放错位置最典型的症状是界面里看不到对应模型或者加载时报错“File not found”。模型下载方面官方生态中最常见的确定性来源是HuggingFace和Civitai。下载时注意看模型说明里的发布日期以及是否兼容当前WebUI/ComfyUI版本。我习惯把下载好的模型文件名改成易识别的名称比如sd_xl_base_1.0.safetensors这样后面选模型时不会一头雾水。注意不要一边启动WebUI一边往目录里复制模型程序启动时只扫描一次模型列表。启动后再放入的文件需要点击界面上的“刷新”按钮或者重启服务才能被识别到。3. 整合包到底帮你干了什么以及它的边界3.1 整合包通过一个自带的Python环境规避了绝大多数版本问题社区里流传最广的“秋叶整合包”这类方案本质是作者构建了一个预先配置好的完整运行目录。这个目录里除了WebUI或ComfyUI的代码外还包含一个完整的Python嵌入式环境、预装好的PyTorch、常用扩展、模型管理工具以及一个图形化启动器。我用整合包最大的感受是你不需要理解“虚拟环境”这个概念不需要手动去pip安装任何一个包也不需要担心Python版本和PyTorch版本是否匹配。启动器界面上直接提供了版本切换、更新回滚、模型管理这些常用操作的图形化入口。对于纯出图用户整合包的体验在80%的场景下都是最优的。这里我建议下载时认准作者官方渠道秋叶整合包通常在B站有官方发布页。文件很大解压之后大概10到20GB这是正常的因为里面除了程序还预置了一些基础模型和常用插件。3.2 整合包的自定义空间与更新陷阱整合包的边界在哪里我举两个实际遇到的场景。第一个场景你想装一个新的扩展插件。WebUI插件本质上是一段放进extensions/目录的代码整合包通常会在启动器里提供一个“扩展安装”入口但部分整合包版本因为内置了较老的插件管理器无法适配新插件依赖的API。这种情况的解决办法是手动从Git克隆插件到extensions/目录然后在启动器里重启服务。第二个场景更新问题。整合包的作者会定期发布新版本但你不能直接在里面执行git pull因为整合包对原版代码做过定制化修改。我见过太多朋友点了一键更新结果整个包直接无法启动了。正确做法是更新前先备份models/目录和outputs/目录然后全新下载新版整合包再把备份的模型和出图文件覆盖回去。自定义的启动参数、插件配置也建议先在文本文件里留底。总结来说整合包适合“用工具”而不是“研究工具”的人。如果你发现自己越来越频繁地需要给ComfyUI安装自定义节点或者开始阅读报错日志里的Python堆栈信息那说明你已经过了整合包的阶段可以切换到官方部署或Docker了。4. Docker容器化让环境变成一段可复用的配置4.1 Windows上Docker最容易卡在启动阶段先把虚拟化搞清楚Docker容器化的核心价值在于“一次构建、处处运行”。在AI图像生成场景里这意味着你不再需要在一台新机器上重复装Python、CUDA依赖、各种插件只需要推一个镜像过去跑起来就能直接用。在Windows环境下Docker Desktop的安装其实不难真正容易卡住的是启动阶段。最常见的一个报错是Docker Desktop failed to start because virtualization support was not detected或者Virtualization support not detected这个问题的原因99%是Windows的虚拟化功能没打开或者WSL2没有启用。确认顺序如下第一打开“任务管理器”→“性能”页面查看“虚拟化”项是否显示“已启用”。如果显示“未启用”需要重启电脑进入BIOS/UEFI设置找到Intel VT-x或AMD SVM相关的选项并打开。第二在PowerShell管理员权限中执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完毕后重启系统。第三安装WSL2内核。在终端中运行wsl --update随后设置默认版本wsl --set-default-version 2完成以上三步之后Docker Desktop基本能正常启动了。这个排查过程我已经做过不下十次每次都是其中一环缺失。4.2 用Compose搭建ComfyUI容器顺便把数据卷和端口一次说清容器化部署AI绘图服务我的推荐是用docker-compose.yml文件定义整套服务这样后续启动、停止、重新构建都只需要一条命令。下面是我实际用来部署ComfyUI的docker-compose.yml示例services: comfyui: image: comfyanonymous/comfyui:latest container_name: comfyui ports: - 8188:8188 volumes: - ./models:/app/ComfyUI/models - ./output:/app/ComfyUI/output - ./custom_nodes:/app/ComfyUI/custom_nodes environment: - NVIDIA_VISIBLE_DEVICESall restart: unless-stopped在项目目录执行docker compose up -d等待镜像拉取完成之后浏览器打开http://localhost:8188就能看到ComfyUI界面了。这里把三个关键配置项的原理说清楚。端口映射“8188:8188”冒号左边是宿主机端口右边是容器内端口。如果你本机8188端口被占用改成8288:8188访问地址也随之变成http://localhost:8288。注意改的是左边不是右边。数据卷挂载这是Docker方案最核心的优势。./models:/app/ComfyUI/models表示把宿主机当前目录下的models文件夹映射到容器内的模型目录。这样模型文件始终在宿主机上容器删掉重建模型也不会丢。很多新手第一次部署时不挂载数据卷容器一旦重建模型和出图文件就全没了。NVIDIA_VISIBLE_DEVICES环境变量这个告诉容器允许使用宿主机的哪一块GPUall表示所有GPU都可见。4.3 GPU怎么透进容器NVIDIA Container Toolkit 的配置与验证Docker容器默认只能使用CPU。要让容器内的PyTorch调用宿主机GPU必须在宿主机上安装NVIDIA Container Toolkit。Linux服务器上的安装流程distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | tee /etc/apt/sources.list.d/nvidia-docker.list apt update apt-get install -y nvidia-container-toolkit安装完成之后重新启动Docker服务systemctl restart docker验证是否把GPU成功透传进容器docker run --rm --gpus all nvidia/cuda:12.1.1-base-ubuntu22.04 nvidia-smi如果看到显卡信息说明GPU透传成功。接下来你再启动ComfyUI容器时加上--gpus all参数即可。上面docker-compose.yml里的NVIDIA_VISIBLE_DEVICES正是干这个的。Windows下使用Docker跑GPU路径不太一样。Docker Desktop在Windows下依赖WSL2后端GPU透传是通过WSL2 CUDA支持的。你需要确保Windows侧已安装相应显卡驱动同时在WSL2内再安装一份支持CUDA的PyTorch环境。这也意味着Windows下用Docker跑AI绘图性能损耗比Linux下要高一些。所以我自己的经验是Windows上自用直接官方部署或整合包服务器或云主机上才用Docker。4.4 还是搞不定先手动构建一次最小镜像如果官方镜像的默认配置不满足需求比如需要预装某些自定义节点我建议自己写一个Dockerfile。这种方式最可控依赖也更清晰。FROM python:3.10-slim WORKDIR /app RUN apt-get update apt-get install -y git RUN git clone https://github.com/comfyanonymous/ComfyUI.git WORKDIR /app/ComfyUI RUN pip install --no-cache-dir torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu121 RUN pip install --no-cache-dir -r requirements.txt EXPOSE 8188 CMD [python, main.py, --listen, 0.0.0.0]在Dockerfile所在目录执行docker build -t my-comfyui . docker run -d --gpus all -p 8188:8188 -v ./models:/app/ComfyUI/models my-comfyui使用python:3.10-slim作为基础镜像比我前面提到的nvidia/cuda镜像更轻量同时因为PyTorch自带了CUDA运行时并不需要完整的CUDA开发环境。5. 高频坑排查我在这三种方案之间切换时的真实记录5.1 CUDA明明装了程序却说找不到显卡这个坑我踩得最多也是社区提问频率最高的问题。典型症状是nvidia-smi一切正常但无论是WebUI还是ComfyUI启动日志里都显示CUDA not available或CPU only。排查路径其实很清晰。第一步在Python环境中验证PyTorch能否识别CUDApython -c import torch;print(torch.cuda.is_available());print(torch.__version__)如果输出False说明PyTorch版本是CPU版。这时需要重新安装CUDA版的PyTorch卸载后再从PyTorch官网获取对应CUDA版本的安装命令。第二步确认PyTorch的CUDA版本是否兼容。PyTorch在代码中编译了特定版本的CUDA运行时驱动支持的CUDA版本必须大于等于PyTorch需要的版本。驱动别太老就行。第三步检查环境变量CUDA_HOME。有些人的Python环境是从Anaconda继承的CUDA_HOME指向了错误的路径这会导致PyTorch找不到cudart共享库。我的建议是直接删除或忽略CUDA_HOME环境变量让PyTorch从自身包内加载依赖。5.2 显存不足之后三层降载方案显存溢出报错在低显存显卡上非常常见。无论是WebUI还是ComfyUI出图失败时终端里通常会有CUDA out of memory提示。我的处理策略是分三层逐步降低资源占用。第一层降低分辨率。默认的512x512在6GB显存显卡上基本都能跑直接上1024x1024就会爆显存。先把出图尺寸控制在显卡能力范围内比如8GB显卡用640x640或768x768是安全线。第二层使用显存优化推理参数。WebUI用--medvram或--lowvram参数启动可以让模型分片加载、需要时再调入显存。ComfyUI则比较智能一般会自动控制显存占用但如果你手动添加了多个加载模型节点还是会爆。第三层开关xFormers和半精度。xFormers能降低显存占用同时提升速度但部分老显卡不兼容需要关闭。半精度推理fp16默认开启如果出现黑色图像或偏色可以尝试--precision full --no-half牺牲速度换稳定性。5.3 Docker Desktop启动失败与端口被人占用的解决过程Docker Desktop在Windows上的启动失败多数是第一节提到的虚拟化问题。如果你确认虚拟化已开启仍然启动失败我有两个额外建议。第一个在“设置”→“Resources”→“Advanced”中确认分配给Docker的内存和CPU是否充足。内存低于2GB时镜像构建很容易失败。第二个遇到端口冲突时启动容器会报错Error starting userland proxy: listen tcp4 127.0.0.1:8188: bind: address already in use说明8188端口被占用了。排查占用进程netstat -ano | findstr 8188 taskkill /PID PID /F或者修改docker-compose.yml里的端口映射这是更稳妥的方式。如果是在服务器上用Docker还有一类常见问题是容器启动后无法访问。这时候先检查docker ps确认容器状态然后看日志docker logs -f comfyui日志里能看到实际的启动错误80%的情况是依赖安装不完整或者模型目录没有正确挂载。5.4 三种方案的日常更新与回滚姿势版本更新是AI绘图工具的日常但更新方式因安装方案而异误操作会引发连锁问题。官方源码部署的更新最简单。进入项目目录git pull拉取新代码然后重新运行启动脚本脚本会自动检测依赖变更并安装新依赖。但我在升级WebUI时经常遇到的问题是某个插件与新版WebUI不兼容表现为界面加载完成后页面空白或者按钮无响应。我的习惯是升级前先禁用所有插件让新版WebUI以纯原生状态启动确认无误后再逐个启用插件。ComfyUI的官方部署更新建议使用ComfyUI Manager这个原生插件。它提供了一键升级、节点安装和版本回滚功能。对于整合包用户我不建议在包内直接执行git pull因为整合包对原版做的定制化修改会被覆盖。正确做法前文说过了备份关键目录、全新下载新版整合包、然后把备份放回去。Docker方案的更新很优雅修改docker-compose.yml中的镜像标签然后执行docker compose pull docker compose up -d如果升级后出问题回滚同样简单把镜像标签改回旧版本重新执行上面的命令即可。这就是容器化的最大好处你的环境配置是声明式的、可回溯的。6. 折腾完三套方案之后我的一些心里话经常有人问我官方部署、整合包、Docker到底哪一种才算“最好的方案”我的回答是这取决于你未来半年内想怎么使用这套工具。如果你只是想把AI绘画当做一个高效率的图像生成工具想尽快开始出图不想碰任何代码那没必要自虐直接去用整合包就好。拿到手放上模型就能跑剩下的时间应该花在提示词和出图审美上。如果你想在AI绘画领域长期深入那官方部署是必须经历的一关。不是因为整合包跑出来的图不好而是研究CLIP、Vae、采样器这些概念时命令行日志、依赖报错、源码阅读都是最好的老师。整合包把这一切都藏起来了你会少很多学习机会。如果你是团队协作或者需要在服务器上部署服务给其他人用那就从Docker开始。千万不要先在一台机器上手动装好环境再想办法“复制”到另一台。就算你能把整个目录打包驱动差异、路径差异、系统依赖差异也会让你崩溃。把环境声明成docker-compose.yml一个文件到哪都能一键拉起这才叫可复用的部署。我个人的使用习惯是本地日常出图走整合包因为省心、启动快插件生态也经过大量用户验证涉及新功能测试和节点工作流调试用官方部署的ComfyUI因为能直接改代码、输出完整日志所有需要交付给团队或者部署到服务器的项目一律Docker化模型和数据卷独立管理。三套方案并存各自负责自己的场景这是我最舒服的状态。最后再分享一个小技巧无论你选择哪种安装方案都养成把模型文件单独备份的习惯。模型是下载成本最高的资产。我会把常用大模型、LoRA、VAE统一放在一个独立的目录里通过符号链接或数据卷挂载的方式让WebUI和ComfyUI共用同一份模型文件既省磁盘空间又避免了重复下载。这个习惯帮我省下的时间远超了当初折腾环境时的所有成本。