stable-diffusion-webui-distributed

当一张图需要等10分钟：让多卡并行生成成为可能

清晨8点，设计师小林接到一个紧急需求——客户要一组4K超清产品图，必须在两小时内交付。往常她会启动SD WebUI，设置batch_size=4，然后盯着进度条等待生成结果。然而512×512的图还好，一旦切换到1024×1024甚至更高分辨率，显存告急、生成时间飙升。"这张图要8分钟，那张12分钟……"她忍不住焦虑起来。

如果小林的工位上有两块GPU呢？或者她有一台闲置的游戏主机和一台工作站？stable-diffusion-webui-distributed 这个插件正是来解决这个问题的——它可以将多台机器的算力聚合起来，让一张超高分辨率的图片在多卡之间并行生成，大幅缩短等待时间。

从单机到集群：SD WebUI的分布式扩展思路

这个插件的开发者 papuSpartan 遇到的实际痛点很明确：单台机器跑大分辨率图片时，batch_size 越大，每张图的等待时间就越长。背后的原因是SD的生成过程必须串行——显存不够放下一整批图，就必须一张一张地生成，无法真正并行。

他的解决方案是将单机的串行压力分散到多台机器。插件采用主从架构（Master/Slave）：主节点接收用户的生成请求，然后将任务拆分成多个子批次，分发给局域网内的多个"从节点"并行处理，每个从节点独立完成一部分图片的生成，最后主节点将结果汇总返回。

图1：Master/Slave 分布式架构示意。主节点负责任务调度和结果聚合，从节点各自独立执行生成任务。

这种设计有几个精妙之处：首先，从节点不需要图形界面，只要开启 API 模式就能被主节点调用；其次，插件内置了性能基准测试（benchmark），会自动测量每台机器的生成速度（ipm: images per minute），并据此智能分配任务量——更快的机器多干活，而不是机械地均分。

核心功能：透明的并行生成体验

安装插件后，用户在 SD WebUI 的脚本（Scripts）标签页中就能看到 "Distribute" 选项。与正常使用相比，操作几乎没有额外学习成本——只需在下拉菜单中选择参与分布式的各台机器，然后正常填写 prompt、尺寸、batch_size 等参数即可。

插件会在生成过程中实时显示每台从节点的工作状态、剩余任务量、生成速率等信息。如果某台机器"拖后腿"，用户可以在 UI 的 Util 标签页手动中断任务，或调整超时时间。当 benchmark 数据不准时（比如某台机器新换了模型导致速度变化），也可以一键重新跑基准测试。

在 txt2img 和 img2img 两种生成模式上，插件都提供了支持。甚至对 ControlNet 这样的扩展也做了兼容——scripts/spartan/control_net.py 中专门处理了 ControlNet 的 mask 和预处理器在分布式场景下的传递问题，确保复杂工作流不会被分布式架构破坏。

部署门槛：需要一点动手能力

这个插件的部署并不复杂，但有明确的前提条件：

必须先有一台正常运行 SD WebUI 的主机器。这个插件是 WebUI 的扩展，不能脱离 WebUI 独立运行。主节点通过 WebUI 扩展界面搜索"Distributed"一键安装，从节点只需要开启 WebUI 的 --api 和 --listen 参数即可接受任务分发。

各台机器之间需要处于同一局域网，并且每台机器上的模型、脚本、扩展等资源最好保持同步——如果主节点用的是 SD 1.5 模型，从节点也应该有同样的模型，否则系统会 fallback 到从节点上已有的模型，可能导致风格不一致。作者在 README 中推荐用 rclone 工具来同步多台机器的模型目录。

从节点对硬件没有特殊要求，但显存仍然决定生成速度。插件配置文件中会记录每台机器的 pixel_cap（像素上限），这也是 benchmark 的核心指标——在分配任务时，系统会确保单次分发到某台机器的图片总像素数不超过它的 pixel_cap。

技术细节：分布式调度核心实现

从代码结构看，项目的核心逻辑集中在 scripts/spartan/ 目录下：

• world.py：定义了 World（集群管理器）、Worker（单个节点）、Job（分配给节点的任务）三个核心类。World 在初始化时通过 ping sweep 探测所有可达节点，然后加载配置文件恢复之前的 worker 列表。每个 Worker 维护自己的状态机（UNAVAILABLE → IDLE → WORKING → DONE）和性能统计。
• worker.py：每个 Worker 通过 HTTP API 与主节点通信，接收任务、返回生成的图片 base64 数据。Worker 会解析 SD WebUI 的处理结果格式，将从节点返回的 info JSON 和图片数据转换为主节点能理解的格式。
• ui.py：基于 Gradio 构建了完整的配置界面，包括 worker 管理、benchmark 控制、实时日志查看等功能。使用 InputAccordion 等组件将复杂的分布式参数封装成交互友好的控件。
• pmodels.py：定义了 Benchmark_Payload 等 Pydantic 模型，用于验证配置数据的合法性，避免运行时错误。

插件还内置了完整的日志系统——同时输出到控制台（Rich 美化格式）和文件（distributed.log），并提供了 GUI 实时日志查看器，方便用户在 WebUI 界面上直接观察分布式生成的全过程。

局限与争议

目前来看，这个插件最大的局限在于它只适用于 AUTOMATIC1111 WebUI 生态。用户如果使用的是 ComfyUI、Forge WebUI 或其他 SD 前端，这个插件完全无法使用。从 topics 可以看到，项目明确标注为 stable-diffusion-webui-plugin，定位就是针对 A1111 的扩展。

另外，插件依赖 HTTP API 在节点间通信，对网络环境有一定要求——节点之间需要低延迟的局域网连接，公网分布式虽然技术上可行，但实际体验会大打折扣。

许可证方面，项目当前没有任何开源许可证（license: null），这意味着代码的复用和二次分发存在法律灰色地带，对于企业用户来说可能是个顾虑。

行业意义：让AI绘画从单卡走向集群

stable-diffusion-webui-distributed 的出现，反映了一个更广泛的趋势：AI 生成工具正在从单卡本地走向多卡/多机协同。随着图像生成质量要求的提升（更高分辨率、更大 batch、更复杂的工作流），单卡瓶颈越来越明显。

对于有闲置硬件资源的团队（比如有多台游戏主机的工作室、有旧显卡的研究组），这个插件提供了一种几乎零成本提升出图吞吐量的方案。它的价值不在于技术突破，而在于将分布式计算的思想以插件形式落地到最广泛使用的 SD 前端里，让非 DevOps 背景的创作者也能享受集群的效率提升。