Stable-Diffusion-v1-5-archiveWebUI高可用：双实例+负载均衡+健康检查部署

优质文章学习记录

— 10 min read

Stable-Diffusion-v1-5-archive WebUI 高可用：双实例+负载均衡+健康检查部署

你是不是也遇到过这种情况：正在用 Stable Diffusion 生成一张重要的设计图，突然页面卡住，刷新一下直接 502 错误，所有工作进度都丢了。或者团队里几个人同时用，服务器就慢得像蜗牛，一张图要等好几分钟。

对于需要稳定、高效生成图片的团队或个人来说，单点部署的 WebUI 服务就像走钢丝——一旦服务挂了，所有工作都得停摆。今天，我就来分享一个实战方案：为 Stable-Diffusion-v1-5-archive WebUI 搭建一套高可用架构。

这套方案的核心很简单：部署两个 WebUI 实例，前面加一个负载均衡器，再配上自动健康检查。这样一来，任何一个实例出问题，流量会自动切到另一个健康的实例上，服务几乎不会中断。同时，负载均衡还能把用户请求分摊开，提升整体的处理能力。

下面，我就手把手带你从零搭建这套系统。

1. 方案设计与核心思路

在开始敲命令之前，我们先搞清楚要做什么，以及为什么这么做。

1.1 我们要解决什么问题？

单实例部署的 Stable Diffusion WebUI 有几个明显的痛点：

  • 单点故障：服务进程崩溃、服务器重启、代码更新，都会导致服务不可用。
  • 资源瓶颈：GPU 算力有限，多个用户或复杂任务同时进行时，排队严重，体验差。
  • 维护困难：更新或调试服务时，必须停止服务，影响所有用户。

1.2 高可用方案的核心组件

我们的解决方案包含三个核心部分：

  1. 双实例：在两台服务器（或一台服务器的不同端口）上，分别部署完全相同的 Stable-Diffusion-v1-5-archive WebUI 服务。这是我们的“后备军”。
  2. 负载均衡器 (Nginx)：作为统一的入口，接收所有用户请求。它的职责是“调度”，根据策略（比如轮询）将请求分发给后端的两个 WebUI 实例。
  3. 健康检查：负载均衡器会定期（比如每5秒）去“探访”后端的每个 WebUI 实例，检查它是否还“活着”（能正常响应）。如果发现某个实例挂了，就立刻不再把新请求发给它，直到它恢复健康。

整个流程就像一家餐厅开了两个相同的厨房（实例），一个前台经理（Nginx）负责接待顾客（请求）并把点菜单分给两个厨房。经理会不断检查厨房是否着火（健康检查），如果A厨房着火了，就把所有新订单都交给B厨房，保证餐厅继续营业。

2. 环境准备与双实例部署

假设我们有两台服务器：server-A (192.168.1.10) 和 server-B (192.168.1.11)。我们将在这两台服务器上部署 WebUI。

2.1 基础环境与镜像部署

在两台服务器上，执行相同的部署操作。这里假设你已经通过类似 ZEEKLOG 星图镜像广场的平台，获取了 stable-diffusion-v1-5-archive 的部署镜像。

# 1. 登录服务器（以 server-A 为例） ssh [email protected] # 2. 假设镜像已提供一键部署脚本，运行它。如果没有，核心是启动WebUI服务。 # 通常启动命令类似这样（具体参数根据你的镜像调整）： cd /path/to/sd-webui python launch.py --listen --port 7860 --medvram # 3. 使用Supervisor守护进程（确保服务崩溃后能自动重启） # 安装supervisor (如果未安装) apt-get update && apt-get install -y supervisor # 创建Supervisor配置文件 cat > /etc/supervisor/conf.d/sd15-webui.conf << EOF [program:sd15-webui] command=python /path/to/sd-webui/launch.py --listen --port 7860 --medvram directory=/path/to/sd-webui autostart=true autorestart=true startretries=3 user=root redirect_stderr=true stdout_logfile=/var/log/sd15-webui.log stdout_logfile_maxbytes=10MB EOF # 更新Supervisor配置并启动服务 supervisorctl reread supervisorctl update supervisorctl start sd15-webui # 4. 验证服务是否启动 curl http://localhost:7860 # 或者查看进程 supervisorctl status sd15-webui

在 server-B (192.168.1.11) 上重复完全相同的步骤。确保两台服务器的 WebUI 都能通过各自的 IP 和端口 7860 独立访问。

关键点：确保两台服务器上的模型文件、依赖库版本完全一致，以避免生成效果出现差异。

3. 配置 Nginx 负载均衡与健康检查

现在，我们需要第三台服务器作为负载均衡器 (lb-server, 192.168.1.12)，或者你也可以选择在 server-A 或 server-B 其中一台上安装 Nginx。

3.1 安装与配置 Nginx

在负载均衡器服务器上操作：

# 1. 安装 Nginx apt-get update && apt-get install -y nginx # 2. 创建负载均衡配置文件 # 我们将其放在 /etc/nginx/conf.d/ 下 cat > /etc/nginx/conf.d/sd15-loadbalancer.conf << EOF upstream sd15_backend { # 定义后端服务器组，并配置健康检查 server 192.168.1.10:7860 max_fails=3 fail_timeout=30s; server 192.168.1.11:7860 max_fails=3 fail_timeout=30s; # 负载均衡策略：轮询 (round-robin) # 其他策略：least_conn (最少连接), ip_hash (会话保持) } server { listen 80; # 如果你有域名，可以在这里配置 # server_name sd.yourdomain.com; location / { # 将请求代理到后端服务器组 proxy_pass http://sd15_backend; # 以下是一些重要的代理设置，确保WebUI正常工作 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket 支持 (如果WebUI有相关功能) proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # 超时设置 proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 300s; } # 可选：添加一个状态检查页面（需要nginx status模块） location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; # 只允许本机访问，安全考虑 deny all; } } EOF # 3. 测试Nginx配置语法是否正确 nginx -t # 4. 重新加载Nginx配置，使其生效 systemctl reload nginx

3.2 核心配置解析

  • upstream sd15_backend: 定义了一个名为 sd15_backend 的后端服务器池。
  • max_fails=3 fail_timeout=30s: 这是被动健康检查。如果 Nginx 连续 3 次向后端服务器发送请求失败，就会认为该服务器“不健康”，并在接下来的 30 秒内不再向其分发请求。30秒后会再次尝试。
  • proxy_pass http://sd15_backend: 将所有到达 location / 的请求转发到后端服务器池。
  • 超时设置：Stable Diffusion 生成图片可能耗时较长，因此将 proxy_read_timeout 等参数调大，避免任务被意外中断。

3.3 验证负载均衡

配置完成后，你的用户将不再直接访问 192.168.1.10:7860 或 192.168.1.11:7860，而是访问负载均衡器的 IP 或域名（例如 http://192.168.1.12）。

  1. 打开浏览器，访问 http://负载均衡器IP。
  2. 你应该能看到熟悉的 Stable Diffusion WebUI 界面。
  3. 为了验证负载均衡是否生效，你可以快速、连续地提交几次生成请求，然后分别去两个后端服务器的应用日志 (/var/log/sd15-webui.log) 查看。你会看到请求被交替分配到了 server-A 和 server-B。

4. 模拟故障与高可用验证

架构好不好，得经过故障测试。我们来模拟一下后端实例崩溃的情况。

  1. 观察效果：此时，你继续通过负载均衡器 (http://192.168.1.12) 使用 WebUI 生成图片。
    • 第一次请求：Nginx 可能还会把请求发给已挂掉的 server-A，导致页面错误或长时间等待。
    • 后续请求：Nginx 检测到 server-A 连续失败（达到 max_fails=3），会将其标记为“不可用”。之后的所有新请求都会自动发给健康的 server-B。服务整体没有中断！

恢复服务：在 server-A 上重启服务。

supervisorctl start sd15-webui

等待片刻（fail_timeout=30s 之后），Nginx 会再次尝试将请求发给 server-A，如果成功，则自动将其加回健康池，恢复负载均衡。

制造故障：在 server-A 上，手动停止 WebUI 服务。

# 在 server-A 上执行 supervisorctl stop sd15-webui

5. 进阶优化与生产建议

上面的方案已经能提供基础的高可用。要用于生产环境，还可以考虑以下几点：

5.1 使用域名与 HTTPS

为负载均衡器配置域名并申请 SSL 证书，启用 HTTPS，保证通信安全。

# 在Nginx配置中，将监听80端口的server块改为监听443，并配置SSL证书路径 server { listen 443 ssl http2; server_name sd.yourdomain.com; ssl_certificate /path/to/your/cert.pem; ssl_certificate_key /path/to/your/key.pem; ... # 其他配置不变 }

5.2 更精细的健康检查

Nginx 商业版或开源版搭配 nginx_upstream_check_module 模块，可以配置主动健康检查，定期请求一个特定的健康检查接口（比如 /health），更早地发现后端故障。

5.3 会话保持 (Session Persistence)

如果 WebUI 有用户登录状态等会话信息，默认的轮询策略会导致用户下次请求被发到不同后端，会话丢失。可以使用 ip_hash 策略，让同一客户端的请求总是发往同一后端。

upstream sd15_backend { ip_hash; # 添加此行 server 192.168.1.10:7860; server 192.168.1.11:7860; }

5.4 监控与告警

为 Nginx 和后端服务器设置监控（如 Prometheus + Grafana），监控关键指标：

  • Nginx：请求率、响应时间、后端健康状态。
  • 服务器：CPU、GPU、内存使用率。
  • WebUI：生成队列长度、平均生成时间。 配置告警规则，当服务异常时及时通知运维人员。

6. 总结

通过 双实例部署 + Nginx 负载均衡 + 健康检查 这套组合拳，我们成功为 Stable-Diffusion-v1-5-archive WebUI 构建了一个简单而有效的高可用架构。

这个方案带来的核心价值是：

  • 可靠性提升：单点故障不再导致服务完全中断，保障了业务连续性。
  • 性能扩展：通过水平扩展实例，提高了系统整体的并发处理能力。
  • 维护便利：可以在不影响用户的情况下，对单个后端实例进行滚动更新或维护。

部署过程其实并不复杂，核心在于理解各个组件的作用和协作方式。你可以根据实际资源情况，将这个模式扩展到更多实例，或者结合 Docker 容器化技术，让部署和管理变得更加灵活高效。希望这篇实战指南能帮助你搭建出更稳定的 AI 图像生成服务。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 ZEEKLOG星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。

Read more

Copilot使用体验

本篇是去年使用Copilot的记录，不代表目前水平，仅做个人记录同步，谨慎参考。 GitHub Copilot的订阅计划 https://docs.github.com/en/copilot/about-github-copilot/subscription-plans-for-github-copilot 个人版提供30天的免费试用。个人版每月10 美元或每年 100 美元。 Copilot操作文档 https://docs.github.com/en/copilot/quickstart 目前支持JetBrains IDEs，Vim/Neovim，Visual Studio，Visual Studio Code，Xcode。安装插件，登录Github账号就可以使用了，需要开代理。 基本操作 * 获取代码建议，输入代码时会自动触发，使用“Tab”键采纳。 * 切换建议，macOS使用“Option+]”或“

从 LLaMA-Factory 微调到高通 NPU 部署: Qwen-0.6B 全链路移植指南

前言 在大模型端侧化部署的趋势下，如何将微调后的 LLM 跑在手机 NPU 上是很多开发者的痛点。本文将手把手教你如何将使用 LLaMA-Factory 微调后的 Qwen-0.6B 模型，一步步移植到高通（Qualcomm）骁龙平台的 NPU 上，实现低功耗、高速度的本地化推理。 一、 导出微调模型 首先，在 LLaMA-Factory 界面中选择好微调后的检查点（Checkpoint），填写导出路径，点击 “开始导出” 。 导出成功后，你会在目录下看到如下文件： * model.safetensors（模型权重） * config.json（模型配置） * tokenizer.json 等（分词器相关） 要将微调后的 Qwen-0.6B 模型移植到高通 NPU，第一步就是格式转换。safetensors 是目前
拆解 Llama 4 Scout：Meta 新一代 MoE 模型到底强在哪

拆解 Llama 4 Scout：Meta 新一代 MoE 模型到底强在哪

摘要 Meta 于 2025 年 4 月发布的 Llama 4 Scout，是其首次将混合专家（MoE）架构引入 Llama 系列的轻量化先锋模型。作为 Llama 4 家族的入门级 MoE 型号，该模型在参数规模与部署效率间实现了精准平衡：总参数达 109B，但单 token 仅激活 17B 参数，结合原生多模态能力与行业领先的 10M token 上下文窗口，既具备处理复杂任务的潜力，又支持在单张 NVIDIA H100 GPU 上完成高效部署。 官方数据显示，Llama 4 Scout 在 MMLU、ChartQA 等主流基准测试中，显著优于 Gemma 3、
主流大模型介绍(GPT、Llama、ChatGLM、Qwen、deepseek)

主流大模型介绍(GPT、Llama、ChatGLM、Qwen、deepseek)

GPT系列模型 一、ChatGPT 的本质 * 发布者：OpenAI（2022年11月30日） * 类型：聊天机器人模型，基于自然语言处理技术 * 核心能力：理解语言、生成对话、撰写邮件/文案/代码、翻译等 * 增长数据：2个月用户破1亿，日活约1300万 二、GPT 系列模型演进对比 模型发布时间参数量核心创新主要局限GPT-12018.061.17亿引入生成式预训练 + Transformer Decoder语言模型单向；需微调才能泛化GPT-22019.0215亿多任务学习 + Zero-shot 能力无监督能力仍有限GPT-32020.051750亿Few-shot 学习 + Sparse Attention成本高、长文本不稳定、内容不可控ChatGPT2022.11基于GPT-3引入 RLHF（人类反馈强化学习）服务不稳定、可能生成错误信息 三、核心技术点回顾 1. GPT-1 * 使用单向 Transformer Decoder（