很多人第一次把 ComfyUI 塞进 Docker，都会经历同一个瞬间：容器起来了，浏览器也能打开界面，节点连好、提示词填完，一点“Queue Prompt”，进度条却卡在 0%，日志里翻来覆去只有一句 Torch not compiled with CUDA enabled 或者干脆提示找不到 GPU。问题不在 ComfyUI 本身，而在于容器的 GPU 透传、CUDA 运行时和模型挂载这三条链路里，有一条没接上。下面按“先跑起来，再逐项排错”的顺序，把 Stable Diffusion + ComfyUI 的 Docker 部署走一遍。
先理清容器里到底跑着什么
ComfyUI 是一个基于节点的工作流界面，Stable Diffusion 是它调用的扩散模型，两者都依赖 PyTorch 来调用 NVIDIA 显卡。Docker 的价值在于把这套依赖（Python、PyTorch、CUDA 运行时、各种自定义节点）封进镜像，避免和宿主机环境互相污染。
但这里有个关键分工需要先记住：宿主机提供显卡驱动，容器提供 CUDA 运行时和 PyTorch。也就是说，显卡驱动装在宿主机上，镜像里装的是和驱动匹配的 CUDA 版本。二者版本对不上，容器就会“看得到驱动、用不了显卡”。所以排查时永远先确认宿主机驱动，再怀疑镜像。
部署前的最小准备
在拉镜像之前，先确认三件事，能省掉后面一大半的折腾。
宿主机侧
- NVIDIA 驱动：用
nvidia-smi能正常输出显卡型号、驱动版本和 CUDA 版本。如果这条命令本身报错，先修驱动，别往下走。 - NVIDIA Container Toolkit：这是让 Docker 能访问 GPU 的关键组件。安装后需要重启 Docker 服务，否则
--gpus参数不会生效。 - Docker 与 Docker Compose：建议用较新版本，旧版对
--gpus的支持不完整。
验证 GPU 透传是否真的通了
这是最容易翻车的一步。先跑一条官方测试命令：
docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果这条命令能打印出和宿主机一致的显卡信息，说明 Docker 到 GPU 的链路是通的，问题就只可能在镜像或模型上。如果报 could not select device driver "" with capabilities: [[gpu]]，说明 NVIDIA Container Toolkit 没装好或 Docker 没重启。
启动 ComfyUI 容器
社区里有几个可用的 ComfyUI 镜像方案，比如 GitHub 上的 mosesyyoung/comfyui-docker（MIT 许可证，主打自动 GPU 配置），以及 Docker Hub 上一些面向 NVIDIA GPU 的镜像。选择时注意两点：镜像最近是否还在维护、CUDA 与 PyTorch 版本是否匹配你的驱动。版本和许可证信息请以你实际拉取时的页面为准，镜像更新较快，这里不写死具体 tag。
一个典型的 docker-compose.yml 大致长这样：
services:
comfyui:
image: <你选用的镜像>:<tag>
ports:
- "8188:8188"
volumes:
- ./models:/app/models
- ./output:/app/output
- ./custom_nodes:/app/custom_nodes
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
restart: unless-stopped几个字段值得解释：
ports：ComfyUI 默认监听 8188，映射到宿主机后浏览器访问http://localhost:8188。volumes：把模型、输出、自定义节点挂到宿主机，容器重建时数据不丢，这是长期使用的关键。deploy.resources：声明 GPU 资源。用docker compose时走这段；如果用docker run，等价写法是--gpus all。
启动后看日志：
docker compose logs -f日志里如果出现 Total VRAM 和显卡型号，说明 GPU 已经被识别；如果只有 CPU 字样，直接跳到下一节的排查。
模型目录怎么挂才不出错
“模型加载失败”是第二类高频问题，绝大多数是路径没对上。ComfyUI 期望模型放在固定子目录下：
| 模型类型 | 容器内路径 | 说明 |
|---|---|---|
| 主模型（Checkpoint） | /app/models/checkpoints | SD1.5、SDXL 等 |
| VAE | /app/models/vae | 单独 VAE 放这里 |
| LoRA | /app/models/loras | 微调权重 |
| ControlNet | /app/models/controlnet | 控制网络模型 |
挂载时注意两点：一是宿主机目录的读写权限，容器内进程通常不是 root，权限不对会写入失败；二是挂载点必须覆盖容器内的模型目录，如果你把宿主机目录挂到了 /app/models 之外的路径，界面里自然看不到模型。挂好后刷新 ComfyUI 页面，在节点里点刷新按钮，模型列表才会更新。
常见故障逐项排查
容器启动了，但日志显示用的是 CPU
按顺序查这几处：
- 宿主机驱动：
nvidia-smi是否正常。 - Container Toolkit：用前面那条
nvidia/cuda测试命令验证。 - compose 配置：
deploy.resources或--gpus all是否漏写。 - 镜像本身：有些镜像的 CPU 版本和 GPU 版本 tag 不同，确认你拉的是 GPU 版。
如果前三条都通过，唯独容器内 torch.cuda.is_available() 返回 False，多半是镜像里的 PyTorch 是 CPU 版，或者 CUDA 版本和驱动不兼容。可以在容器里执行：
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"输出里 torch.version.cuda 为 None，说明装的是 CPU 版 PyTorch；有版本号但 is_available() 为 False，通常是驱动版本低于该 CUDA 运行时要求。
出图时报显存不足（OOM）
显存不足和部署无关，但常被误判成部署问题。6GB 显存可以跑 SD1.5 的低分辨率出图，SDXL 则比较吃力；分辨率、批次数、是否同时加载多个模型都会影响占用。遇到 OOM 先降分辨率和 batch size，再考虑换更小的模型。ComfyUI 相比传统 WebUI 在显存调度上更细，节点式工作流可以做到按需加载，合理拆分工作流能缓解一部分压力。
浏览器打不开 8188
先确认容器是否在运行（docker ps），再看端口映射是否被占用。如果宿主机 8188 已被其他服务占用，改成 "8189:8188" 即可，容器内端口不用动。远程服务器部署时，注意防火墙或安全组是否放行了对应端口。
自定义节点装了却不生效
自定义节点通过 custom_nodes 目录挂载进来后，通常需要重启容器才会被加载。部分节点还有自己的 Python 依赖，需要在容器内安装。这也是把 custom_nodes 挂到宿主机的意义：节点和依赖的改动不会随容器销毁而丢失。
适合长期使用的维护清单
跑通一次只是开始，想稳定用下去，建议固定几个习惯：
- 锁定镜像 tag：不要用
latest，写死具体版本，避免某次pull后环境突变。 - 模型与输出分离挂载：模型目录只读挂载也可以，输出目录单独挂，方便备份和清理。
- 记录版本组合：把宿主机驱动版本、镜像 tag、CUDA 版本记在项目 README 里，出问题时能快速定位。
- 定期核验：镜像的维护状态、许可证和依赖更新变化较快，升级前先看发布说明。
验证与下一步
判断部署是否真正成功，看三个信号：容器日志里出现显卡型号和显存总量；ComfyUI 界面能加载出 checkpoint 模型；用默认工作流出图时进度条正常推进并生成图片。三者齐了，说明 GPU 透传、模型挂载和服务访问这条链路都通了。
接下来可以按需调整：想提升出图质量就换模型和加 LoRA，想批量处理就研究 ComfyUI 的 API 模式，想省显存就精简工作流里的常驻节点。部署本身只是把地基打好，真正决定效果的是工作流设计。
评论列表 (5条)：
加载更多评论 Loading...