部署前先理解整体架构

Krita AI Diffusion 是面向 Krita 的 AI绘画插件，常见用法是在 Krita 内绘制草图、蒙版或局部区域，再把生成任务交给后端推理服务处理。使用 Docker部署的核心价值，是把运行环境、依赖库和插件节点封装在容器里，减少 Python 版本、显卡驱动组件、依赖冲突带来的安装失败。对需要多台设备复用同一套模型、希望快速迁移环境，或不想把大量依赖装进系统环境的用户来说，容器方式更稳妥。

常见方案是 Docker 容器运行 ComfyUI 或兼容后端，Krita AI Diffusion 在插件设置中填写服务地址，例如 http://127.0.0.1:8188。Krita 负责交互与工作流控制，Docker 容器负责加载模型并完成生成。部署时最重要的三件事是：镜像是否包含所需节点，端口是否能被 Krita 访问，模型与输出目录是否正确挂载。

准备环境与硬件检查

建议使用 Windows 11、主流 Linux 发行版或支持容器桌面环境的 macOS。显卡方面，NVIDIA 显卡体验通常更好，显存建议 8GB 起步，生成高分辨率图像或使用较大模型时建议 12GB 以上。仅 CPU 也能运行，但速度较慢，更适合测试连接是否正常。

部署前先确认 Docker 已安装并能正常执行。终端输入 docker --version，能看到版本号即可。NVIDIA 用户还需确认容器能调用显卡，可执行 nvidia-smi 查看驱动状态；若在 Linux 上运行，还需要安装 NVIDIA Container Toolkit，并确保 docker run --gpus all 能识别设备。若显卡不可见，后续即使容器启动成功，也可能只能使用 CPU。

镜像选择与拉取

镜像建议选择维护活跃、说明清楚、标明支持 ComfyUI 与 Krita AI Diffusion 相关节点的版本。不要随意使用来源不明的镜像，尤其是要求额外输入账号凭据或带有可疑启动脚本的镜像。对于个人用户，可以优先选择社区常用的 ComfyUI 镜像，再根据插件要求补齐节点；对于团队环境，则建议自行基于官方基础镜像构建，便于审计依赖。

拉取镜像的通用命令为：docker pull 镜像地址:标签。示例写法可以是 docker pull ghcr.io/your-repo/comfyui-krita:latest。实际使用时请替换为你确认可信的镜像名称。生产环境不建议长期使用 latest 标签，因为镜像更新后可能导致节点版本变化。更稳妥的做法是固定版本号，例如 :2025-01 或 :cuda12，方便回滚。

规划数据目录

容器重建后内部文件可能丢失，因此模型、输出图、工作流配置必须放在宿主机目录中。建议建立一个独立目录，例如 D:AIkrita-diffusion 或 /data/krita-diffusion，并在下面划分 models、output、input、custom_nodes、workflows、cache 等子目录。这样升级镜像时只替换容器，不会影响已有模型和作品。

模型目录通常需要包含 checkpoints、loras、vae、controlnet、upscale_models 等分类。不同镜像的目录结构可能略有差异，关键是宿主机目录要挂载到容器内后端实际读取的位置。例如将本机 ./models 挂载到 /app/ComfyUI/models，将 ./output 挂载到 /app/ComfyUI/output。若路径不一致，容器能启动，但界面中会看不到模型。

使用 docker run 快速启动

适合首次验证的命令可按以下思路配置：docker run -d --name krita-ai-backend --gpus all -p 127.0.0.1:8188:8188 -v /data/krita-diffusion/models:/app/ComfyUI/models -v /data/krita-diffusion/output:/app/ComfyUI/output -v /data/krita-diffusion/custom_nodes:/app/ComfyUI/custom_nodes --restart unless-stopped 镜像地址:标签。

这里的 -p 127.0.0.1:8188:8188 表示只允许本机访问，安全性更高。如果需要同一局域网内其他电脑连接，可改为 -p 8188:8188，并在系统防火墙中只允许可信设备访问。-v 参数是数据目录挂载，冒号左边是本机路径，右边是容器内路径。--restart unless-stopped 能让容器在系统重启后自动恢复，适合长期使用。

使用 Docker Compose 管理

长期使用更推荐 Compose，因为配置清晰，便于升级和迁移。compose 文件中应包含 image、container_name、ports、volumes、restart、environment 等字段。GPU 环境可增加显卡相关配置，具体写法会随 Docker 版本略有不同。完成后在配置文件所在目录执行 docker compose up -d，即可后台启动；查看日志使用 docker logs -f krita-ai-backend 或 docker compose logs -f。

升级镜像时先执行 docker compose pull，再执行 docker compose up -d。若升级后插件报错、节点缺失或模型不可见，可改回旧标签并重新启动。由于数据目录挂载在宿主机，回滚通常不会影响模型文件，但仍建议在升级前备份 custom_nodes、workflows 与关键配置。

Krita 插件连接设置

后端启动后，打开浏览器访问 http://127.0.0.1:8188，若能看到后端页面或接口响应，说明端口映射基本正常。接着打开 Krita，进入 Krita AI Diffusion 插件设置，选择连接外部服务，并填写 http://127.0.0.1:8188。保存后尝试刷新模型列表，再创建小尺寸测试任务，例如 512×512，确认生成链路没有问题。

如果 Krita 与 Docker 不在同一台设备上，需要填写后端设备的局域网地址，例如 http://192.168.x.x:8188。此时要确保后端端口已对局域网开放，并且路由器或系统防护规则没有拦截。不要把推理端口直接暴露到公网，除非你已经配置访问控制、反向袋里日志和资源限制，否则存在数据泄露与资源被滥用的风险。

常见问题与排查

问题一：Krita 提示无法连接。先检查容器是否运行，执行 docker ps 查看状态；再检查日志是否有报错；随后确认端口写法是否正确。若使用 127.0.0.1 绑定，只能本机访问，其他设备无法连接。

问题二：容器启动但没有使用显卡。检查 nvidia-smi 是否正常，确认启动命令包含 --gpus all，并查看日志中是否出现 CUDA 相关信息。若驱动版本过旧，可能需要升级显卡驱动或更换匹配的镜像标签。

问题三：模型列表为空。多半是目录挂载位置不对，或模型文件放错分类。进入容器执行 ls /app/ComfyUI/models，确认容器内能看到文件。还要注意模型格式是否被当前后端支持。

问题四：生成到一半报显存不足。可以降低画布尺寸、减少批量数量、关闭高消耗节点，或选择体积更小的模型。部分镜像支持低显存参数，可在环境变量或启动参数中启用，但速度会下降。

问题五：插件工作流报节点缺失。说明镜像未包含所需 custom nodes，或升级后节点版本不兼容。建议按插件说明安装对应节点，并固定版本。不要在不了解依赖关系的情况下批量更新所有节点。

安全边界与实用建议

AI绘画后端会读取输入图、草图、蒙版和输出结果，目录中可能包含未公开作品或客户素材。个人使用时建议端口只绑定 127.0.0.1；团队使用时也应限制访问范围，并定期清理 output 与临时目录。下载模型时要确认授权范围，商业项目尤其要保留来源记录和许可说明。

建议把模型文件与容器镜像分开管理，不要把几十 GB 的模型打进镜像中，否则升级和迁移成本会很高。常用模型可放在统一 models 目录，不同后端通过挂载共享。对于稳定工作环境，镜像标签、插件版本、Krita 版本和关键模型版本都应记录下来，出现问题时才能快速定位。

完成部署后，最好保存一份可复用清单：Docker 版本、镜像地址与标签、端口、宿主机目录、Krita 插件版本、显卡驱动版本、常用启动参数。这样无论是重装系统、迁移到新机器，还是给团队成员配置相同环境，都可以避免反复试错。Docker 不是让部署完全没有门槛，而是把复杂依赖固定下来；只要镜像可信、端口安全、数据目录清晰，Krita AI Diffusion 的日常使用会稳定很多。

《夸克》非常好用的免费AI浏览器

下载APP查看