这篇文章，我将记录下来折腾过程，希望能帮助到有相同需求，想要快速运行这个模型，找乐子的同学。
当然，也希望这篇文章，能够帮到将模型开源开放出来的 IDEA 研究院的开发团队的同学，改进当前开源项目中的不足之处，让中文开源项目越来越好。
如果你本地已经准备好了运行Docker的环境，并且有一张显存在 4G 到 8G 之间的显卡，可以尝试使用下面这个镜像，镜像尺寸为 8GB （ 如果你手头没有显卡，也不想使用云主机，那么可以等等后续不需要 GPU 的“模型把玩”文章，或者翻阅之前有关模型的文章 😀 ）
原始项目启用了git lfs，所以添加不添加–depth参数没有差别，耐心等待模型下载完毕之后，我们编写一个容器编排文件，来启动模型应用：
将上面的内容保存为docker-compose.yml之后，执行docker compose up -d，稍等片刻，在浏览器访问启动服务的 IP 地址和对应端口，比如：，就能够正常使用啦。
模型运行起来，当然是要玩一把了，我使用博客首页的古诗“醉里不知天在水，满船清梦压星河”为主题，尝试生成了一张图，看起来效果还不错：
如果你想了解如何从零开始配置 GPU 云服务器环境，或者想了解这个 Stable Diffusion 容器运行环境是如何构建的，可以继续阅读。
官方团队并未在仓库中添加容器镜像的编排文件，起初我认为是上线匆忙忘记了，但是随着我翻开 DockerHub 的提交记录时，发现原来这个镜像的构建方式是基于传统的docker commit构建的[6]，这样的镜像存在两个问题，首先是黑盒不透明，拿 Docker 当虚拟机用，不利于二次开发和维护；其次，这最后一次提交，单个提交的变动包含 5个GB ，里面是否无心夹带了不该存在的内容，对于想私有化部署的场景下，也着实是有些让人难以放心。
其次，用户如果想在干净完整复现，就只能参考镜像中的“历史操作记录”啦，然而，并不是所有的命令都是能被系统记录下来的，比如vim等交互式操作，或者非幂等的操作，用户实际上也无法再次复现。
然而，这些三个月前的操作，对于我们想正确运行太乙的模型和界面程序，非但没有正确指引，反而存在“误导”：
除了基础镜像的问题之外，官方fork改版的stable-diffusion-webuiWeb UI 项目[7]也隐藏了一些问题。虽然，其中不少问题都是从原版程序“继承”过来的。
首先，项目所需要的依赖，并不是完全都包含在项目的依赖声明文件中；并且，项目中存在俩requirements.txt文件，其中都包含了未指定明确版本的软件包。可能官方开发团队想缓解这个问题，于是编写了一个名为launch.py的启动文件，在执行程序之后，程序会自动调用prepare_enviroment()函数，包含了“近似”所有所需 Python 软件包依赖的安装，以及关联项目的下载。
在这个文件中，我们会发现目前版本的程序想正确运行起来，实际需要的基础运行环境是：torch==1.12.1+cu113 torchvision==0.13.1+cu113，好吧，如果你没有仔细阅读过这个launch.py，那么官方镜像提供的默认环境将浪费不少想让程序运行起来，花费的调试时间。
我们也能够在这个文件中发现大量直接调用subprocess.run执行的安装命令。因为项目中没有明确的版本声明，所以当程序下载完gfpgan、clip、xformers、deepdanbooru、pyngrok、Stable Diffusion、Taming Transformer、K-diffusion、CodeFormer、BLIP后，一通安装后，再进行安装web ui本身的依赖，很容易造成程序因为版本兼容性存在问题，而无法运行，或者运行出错的问题，对其他人提供公开代码，或者下载的软件，使用显式声明是好习惯。
在上面的依赖安装中，还存在两个问题。第一个是来自 Facebook Research 的 xformers，如果想要在 GPU 环境正确安装，安装指令需要调整。推测这里测试的同学，偷懒没有验证 GPU 环境从零到一的安装验证。
其二，pyngrok这个包，虽然目前还没有在项目中被公开使用，但是就伴随程序的“自动初始化”悄然无声的安装到用户电脑上，其实不见得是一件合适的事情。太乙团队的镜像里暂时并未发现ngrok的执行程序，但是如果其他人再分发的过程中，虽然不改动原始代码，但是在程序中夹带了ngrok，配合不严格的安全策略，对于用户而言，潜在的数据安全风险还是蛮高的。
如果你需要寻找其他版本的镜像，可以在DockerHub 的这个页面搜索[8]，另外，如果你需要判断 PyTorch 版本所需要的 CUDA 版本，可以在 PyTorch 官方发布页面中寻找线索：/previous-versions/。
然后，我们开始翻译launch.py程序中关于软件的依赖下载和安装命令，先处理基础软件依赖（不进行pyngrok的安装）：
接着，我们来处理程序运行所需要的三方开源仓库这类组件依赖，按照官方 Web UI 所需要的git hash版本将它们下载下来：
然后，我们来处理太乙专属的Web UI这部分的程序，为了让镜像能够稳定构建、稳定运行，我们对IDEA-CCNL/stable-diffusion-webui也进行“版本的显式定义”：
发现虽然比官方镜像解压缩后的 22.5GB 小，但是还是有些大，那么，接下来，我们来进行简单优化。
如果你想了解极限的“硬核优化”，可以参考《使用 Docker 和 HuggingFace 实现 NLP 文本情感分析应用》[9]或者往期大文章，在此就不赘述啦 😀
因为时间关系，我就先不折腾多阶段构建，以及定向的压缩实现啦，我们针对上面的镜像编排指令进行合并，再每个阶段去掉不必要的文件，很容易得到类似下面的，紧凑一些的Dockerfile：
将镜像推送到 DockerHub 上，经过平台的压缩，镜像传输尺比官方压缩后的镜像“轻” 2GB：
并且，镜像构建细节中，每一步做了什么，构建的层多大，都清清楚楚的展示在了 DockerHub 的镜像详情页中，“干净又卫生”。
我们在云环境默认创建的 GPU 服务器，可能环境有这样或者那样的小问题，为了避免时间浪费在琐碎问题上，我们可以考虑用 Docker 所提供的“固定 & 明确的运行环境”来节约时间。
想要运行 Docker 首先要完成 Docker 的安装，在《在笔记本上搭建高性价比的 Linux 学习环境：基础篇》[10]一文的“更简单的 Docker 安装”小节中，我提到过如何快速、正确的在 Ubuntu 环境完成 Docker 的安装，这里就不做展开了，有需要的同学可以自行翻阅。
如果，我们想在 Docker 中调用 Nvidia 显卡，光是完成 Docker 安装，还是不够的，还有一些事情要做。
在添加了软件源之后，我们执行下面的命令，完成nvidia-container-cli工具的安装：
完成工具安装之后，就可以使用下面的命令，来检查 Docker 需要的 Nvidia 显卡驱动是否完成完整安装了：
完成驱动安装，在 Ubuntu 22.04 中，将会自动加载内核驱动，如果你的操作系统没有自动完成驱动加载，那么可能需要执行重启。
完成 Docker 和 Nvidia 显卡的安装之后，此时 Docker 还不能调用显卡硬件，还需要做一些配置上的调整。
接着，为了万无一失，我们在/etc/docker/daemon.json中添加配置字段，如果需要的话，还可以在runtimeArgs中添加需要的参数：
执行完毕，除了执行上面的命令之外，也可以用命令来重启服务service docker restart。
太乙模型实际资源要求，感觉还不错，默认配置情况下一般也就占 4G 不到的显存，偶尔输出“sampling steps”比较大的图，会膨胀到 8GB 左右。
接下来，我会考虑聊聊 AIGC 话题里，绕不开的一些“关键词”，比如：大模型、Mac 、ARMv64 、低成本的 FineTune 等等。
在不发广告的情况下，我们在里面会一起聊聊软硬件、HomeLab、编程上的一些问题，也会在群里不定期的分享一些技术沙龙的资料。
如果你想更快的看到后续内容的更新，请戳“点赞”、“分享”、“喜欢”，这些免费的鼓励将会影响后续有关内容的更新速度。
