Stable Diffusion in Docker：把官方模型装进容器，一行命令出图

凌晨三点的创作冲动，和一块被"环境配置"劝退的显卡

你有没有过这种感觉：半夜突然来了一个绝妙的创作灵感，想要用 AI 画一张图，结果打开电脑一看——PyTorch 版本不对、CUDA 驱动不匹配、transformers 库装不上……折腾了两个小时，显卡还在闲着，灵感早就凉了。

这大概是每一位想要本地部署 Stable Diffusion 的用户都经历过的"门槛之痛"。而 fboulnois/stable-diffusion-docker 这个项目，正是来解决这个问题的：不需要懂深度学习环境配置，只需要会 Docker，一条命令就能跑起官方 Stable Diffusion。

一条提示词生成的金刚鹦鹉画作，图片由 AI 模型生成

它是什么：Docker 化的 Stable Diffusion CLI 工具

stable-diffusion-docker 是一个将 Stability AI 官方 Stable Diffusion 模型（存放在 HuggingFace）封装进 Docker 容器的开源项目。核心思路非常清晰：环境即代码，依赖全部打包进镜像，用户只需要提供 GPU 和一条命令。

这个项目不同于其他"WebUI"类的 Stable Diffusion 部署方案（如 Automatic1111 WebUI），它采用的是纯命令行界面。没有花哨的网页，没有复杂的参数面板，一切通过 ./build.sh run 传入参数来控制。这让它特别适合：

• 有明确出图需求的用户：知道要什么 prompt，不需要反复调整参数
• 有自动化 pipeline 需求的用户：可以嵌入到脚本和工作流中批量出图
• 有服务器部署需求的用户：没有 Web 界面，反而更适合纯后台运行

项目支持切换多个官方模型，默认使用 CompVis/stable-diffusion-v1-4，也可以轻松指定 SD 1.5、SD 2.0、SD XL、OpenJourney、Dreamlike Diffusion 等流行模型。

通过 img2img 模式将输入图片风格转化为玫瑰花束风格

核心功能：七种出图模式，覆盖主流创作场景

项目将 Stable Diffusion 的能力拆解为七个独立的功能模块，每种对应一个 --model 参数或特定输入模式：

Text-to-Image（文字生图）：最基础的功能，用一段文字提示词生成图片。默认 512×512 分辨率，50 步采样。对着命令行输入 ./build.sh run '星空下的海边小镇'，等上几十秒，一张图就出现在 output 目录里。

Image-to-Image（图生图）：给模型提供一张参考图和一段提示词，让模型在参考图的基础上进行创作。非常适合"这个风格不错，但主体换一下"的需求。

Depth-to-Image（深度引导）：使用 stabilityai/stable-diffusion-2-depth 模型，根据输入图片的深度图和提示词生成新图。适合需要保持原图结构但完全改变内容的场景。

Instruct Pix2Pix（指令修图）：通过 timbrooks/instruct-pix2pix 模型，可以对图片进行"在保持整体风格的同时做某件事"的指令式修改，比如"把晴天换成雨天"。

UnCLIP 变体：基于 Stable Diffusion 2.1 的 unCLIP 架构，从已有图片生成变体版本，适合产品设计、Logo 演变等需求。

4倍放大（Upscale）：使用 stabilityai/stable-diffusion-x4-upscaler 对低分辨率图片进行超分辨率放大，搭配 img2img 使用效果更佳。

Inpainting（局部重绘）：上传一张图和一张 mask（蒙版），让模型只重绘白色区域，黑色区域保持不变。非常适合给图片中的某个物体换色、换材质，或者去除不需要的元素。

同一提示词生成的多张不同结果，AI 生图具有随机性

技术内幕：代码怎么组织的

从代码结构来看，这是一个极简主义的项目。核心代码只有两个 Python 文件：docker-entrypoint.py（约 300 行，入口脚本）和 requirements.txt（依赖清单），配合一个 build.sh 脚本管理 Docker 构建和运行。

requirements.txt 中的依赖非常清晰：diffusers[torch] 是核心，封装了 Stable Diffusion 的推理管道；transformers 提供模型加载和预处理；torch 和 xformers 负责 GPU 加速；safetensors 提供安全的模型权重加载；onnxruntime 支持可选的 ONNX 推理路径。

docker-entrypoint.py 的设计值得玩味。作者用 argparse 定义了完整的命令行参数体系，通过 DiffusionPipeline 的动态加载机制支持多种模型和 pipeline 类型。代码中通过 inspect.signature 动态提取各 pipeline 支持的参数，然后根据用户输入进行过滤和传递——这种设计避免了为每种 pipeline 写独立处理逻辑，让整个脚本保持简洁。

Dockerfile 使用 python:3.11-slim-bullseye 作为基础镜像，先安装 PyTorch（带 CUDA 11.8 支持），再创建非 root 用户 huggingface 来运行推理——这是一个安全实践，避免容器内以 root 身份运行。

build.sh 脚本则是用户体验的核心。它封装了 docker build、docker run 的完整流程，自动处理 GPU 参数（--gpus=all）、数据卷挂载（huggingface 缓存目录、input 目录、output 目录），用户甚至不需要知道这些底层细节。

部署体验：真的只要一条命令吗？

按照 README 的流程走一遍：安装 Docker Desktop、确保有 NVIDIA 显卡和 nvidia-container-toolkit、去 HuggingFace 申请一个访问令牌（token.txt 文件）、执行 ./build.sh build 构建镜像、执行 ./build.sh run '提示词' 出图。

整个过程对有 Docker 经验的用户来说确实非常顺滑。但有几个坑值得提前说明：

第一个坑：GPU 内存要求。默认配置下（float32，512×512），至少需要 8GB 显存。如果只有 6GB 显存（比如部分笔记本显卡），需要加 --half --height 256 --width 256 --attention-slicing 这些参数来降低内存占用，而且生成质量会有所下降。

第二个坑：HuggingFace Token。这是项目的"准入门槛"。没有 HF 账号和用户令牌，根本跑不起来。项目作者这样做是因为官方模型的许可证要求必须接受协议、有使用追踪。对于不想注册 HF 账号的用户，这是一个明显的障碍。

第三个坑：没有 Web 界面。这是这个项目和其他方案（如 Automatic1111 WebUI）最大的区别。如果你习惯在网页上拖拖滑块看实时预览，这个纯 CLI 工具会让你很不适应。但如果你是开发者或者有批量处理需求，CLI 的可编程性反而是优势。

局限与争议

这个项目最大的争议点在于它的定位。作为一个"官方 Stable Diffusion CLI Docker 封装"，它本质上并没有对模型做任何修改或优化——它只是给官方管道加了一层 Docker 外壳。

在 GitHub Issue 区，有人提出希望添加 WebUI 支持，作者明确拒绝了，理由是"这不是这个项目的目标"。这意味着如果你想要 ControlNet、Lora 训练、插件系统等进阶功能，还是得用 Automatic1111 或 ComfyUI。

另外，由于默认使用 HuggingFace 官方模型，下载模型权重需要时间（SD 1.4/1.5 大约 4GB，SD XL 大约 6GB），第一次运行前需要等待模型下载完成。通过 huggingface 数据卷可以避免重复下载，但如果切换模型，新模型仍需下载。

行业意义：让 AI 生图"平民化"的新思路

stable-diffusion-docker 体现了一种重要的工程哲学：将复杂的环境依赖封装为不可变基础设施（Immutable Infrastructure）。在 AI 工具领域，环境配置往往是最大的使用障碍。一张图能不能画出来，往往不取决于用户的创意，而是取决于用户的"炼丹"水平。

这个项目通过 Docker 将这个障碍降到了最低。开发者不需要理解 PyTorch 的版本兼容性，不需要知道 CUDA 和 cuDNN 的关系，不需要配置环境变量——只要 Docker 能跑，AI 就能跑。

745 个 star 说明这个方向有真实的需求。对于有一定技术背景、想要在本地或服务器上稳定运行 Stable Diffusion 的用户来说，这是一个值得收藏的工具。