Ubuntu服务器部署LongCat-Image-Edit V2的高可用架构设计

Ubuntu服务器部署LongCat-Image-Edit V2的高可用架构设计最近在折腾一个图片编辑项目需要用到美团开源的LongCat-Image-Edit V2模型。这模型确实不错中文编辑指令跟得准生成效果也稳定。但问题来了我们团队内部用的时候发现单机部署根本扛不住并发请求稍微多几个人同时用服务就卡得不行有时候还会直接挂掉。这让我开始琢磨能不能在Ubuntu服务器上搭一套高可用的架构让这个服务既稳定又能扛住更多用户。折腾了几天还真搞出了一套方案今天就跟大家分享一下怎么在Ubuntu上给LongCat-Image-Edit V2设计一个带负载均衡和故障转移的高可用架构。1. 为什么需要高可用架构先说说我们遇到的实际情况。一开始就是简单地在公司的一台Ubuntu服务器上部署了LongCat-Image-Edit V2用Docker跑起来配了个简单的Web界面。刚开始用的人少感觉还挺顺畅。但后来团队规模扩大用的人多了问题就来了。最明显的就是响应速度变慢一张简单的图片编辑从原来的几秒变成几十秒。更头疼的是有时候模型推理占满了GPU显存整个服务就直接无响应了得手动重启。这对我们这种需要稳定服务的团队来说简直是灾难。所以高可用架构的核心目标就三个稳定性一个节点挂了其他节点能顶上服务不中断可扩展性用户多了能方便地加机器来分担压力维护性出了问题能快速定位升级时不影响用户使用2. 整体架构设计思路我设计的这套架构核心思想是“分散压力互为备份”。简单来说就是不让所有请求都挤在一台机器上而是让多台机器一起干活万一哪台机器不行了其他机器能马上接替它的工作。下面是整个架构的示意图用户请求 → 负载均衡器 (Nginx) → 多个应用服务器 → 模型推理服务 ↑ ↑ 健康检查 故障转移这个架构主要包含几个关键部分负载均衡层用Nginx做反向代理把用户请求均匀分给后面的应用服务器应用服务器集群多台Ubuntu服务器每台都部署完整的LongCat-Image-Edit V2服务共享存储所有服务器访问同一个模型文件存储避免每台机器都下载一遍大模型监控与告警实时监控每台服务器的状态发现问题及时告警3. 环境准备与基础部署3.1 服务器规划我建议至少准备3台Ubuntu服务器可以是物理机也可以是云服务器配置建议如下操作系统Ubuntu 22.04 LTS 或更新版本CPU8核以上内存32GB以上GPU每台服务器最好有独立GPU显存8GB以上RTX 4060级别或更高存储至少100GB可用空间三台服务器的角色分配服务器1主负载均衡器 应用服务器服务器2备用负载均衡器 应用服务器服务器3应用服务器 监控节点3.2 基础环境配置在所有服务器上先安装必要的依赖# 更新系统 sudo apt update sudo apt upgrade -y # 安装Docker sudo apt install -y docker.io docker-compose sudo systemctl enable docker sudo systemctl start docker # 安装NVIDIA驱动和容器工具如果使用GPU sudo apt install -y nvidia-driver-535 nvidia-container-toolkit sudo systemctl restart docker # 配置Docker使用NVIDIA运行时 sudo tee /etc/docker/daemon.json EOF { runtimes: { nvidia: { path: nvidia-container-runtime, runtimeArgs: [] } }, default-runtime: nvidia } EOF sudo systemctl restart docker3.3 部署LongCat-Image-Edit V2单实例先在一台服务器上把单实例部署好后面再扩展到多台。这里我用Docker Compose来管理# docker-compose.yml version: 3.8 services: longcat-edit: image: your-registry/longcat-image-edit:v2 # 需要自己构建或使用官方镜像 container_name: longcat-edit runtime: nvidia # 使用NVIDIA运行时 ports: - 7860:7860 # Gradio默认端口 environment: - MODEL_PATH/app/models/LongCat-Image-Edit - CUDA_VISIBLE_DEVICES0 volumes: - ./models:/app/models - ./outputs:/app/outputs deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] healthcheck: test: [CMD, curl, -f, http://localhost:7860/] interval: 30s timeout: 10s retries: 3 start_period: 40s构建和启动命令# 创建目录结构 mkdir -p longcat-edit/{models,outputs} cd longcat-edit # 下载模型文件需要从Hugging Face或官方渠道获取 # 这里假设你已经有了模型文件放在models目录下 # 启动服务 docker-compose up -d # 检查服务状态 docker-compose ps docker-compose logs -f4. 负载均衡配置单实例部署好后接下来就是配置负载均衡让多台服务器一起工作。4.1 安装和配置Nginx在主负载均衡器服务器上安装Nginxsudo apt install -y nginx配置Nginx作为反向代理和负载均衡器# /etc/nginx/sites-available/longcat-edit upstream longcat_backend { # 这里列出所有应用服务器的地址 server 192.168.1.101:7860 max_fails3 fail_timeout30s; server 192.168.1.102:7860 max_fails3 fail_timeout30s; server 192.168.1.103:7860 max_fails3 fail_timeout30s; # 负载均衡策略最少连接数 least_conn; # 保持连接提高性能 keepalive 32; } server { listen 80; server_name longcat.yourdomain.com; # 你的域名 # 客户端请求超时设置 client_max_body_size 100M; client_body_timeout 300s; client_header_timeout 300s; # 代理超时设置模型推理可能较慢 proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 300s; location / { proxy_pass http://longcat_backend; # 传递真实客户端IP proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket支持如果前端需要 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 启用缓冲避免大文件传输问题 proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; } # 健康检查端点 location /health { access_log off; return 200 healthy\n; add_header Content-Type text/plain; } # Nginx状态监控 location /nginx_status { stub_status; access_log off; allow 127.0.0.1; allow 192.168.1.0/24; # 内网IP段 deny all; } }启用配置并重启Nginxsudo ln -s /etc/nginx/sites-available/longcat-edit /etc/nginx/sites-enabled/ sudo nginx -t # 测试配置 sudo systemctl restart nginx4.2 配置Keepalived实现高可用负载均衡为了防止负载均衡器单点故障我们用Keepalived实现主备切换在主负载均衡器上sudo apt install -y keepalived配置Keepalived# /etc/keepalived/keepalived.conf vrrp_script chk_nginx { script /usr/bin/pgrep nginx interval 2 weight 2 fall 2 rise 2 } vrrp_instance VI_1 { state MASTER # 主节点 interface eth0 # 根据实际网卡修改 virtual_router_id 51 priority 101 # 主节点优先级更高 advert_int 1 authentication { auth_type PASS auth_pass your_password_here } virtual_ipaddress { 192.168.1.100/24 # 虚拟IP客户端通过这个IP访问 } track_script { chk_nginx } notify_master /etc/keepalived/notify.sh master notify_backup /etc/keepalived/notify.sh backup notify_fault /etc/keepalived/notify.sh fault }在备用负载均衡器上配置类似但修改state为BACKUPpriority为100。创建通知脚本#!/bin/bash # /etc/keepalived/notify.sh TYPE$1 NAME$2 STATE$3 case $STATE in MASTER) # 成为主节点时确保Nginx运行 systemctl start nginx echo $(date) - 切换为主节点 /var/log/keepalived-notify.log ;; BACKUP) # 成为备节点时停止Nginx避免IP冲突 systemctl stop nginx echo $(date) - 切换为备节点 /var/log/keepalived-notify.log ;; FAULT) echo $(date) - 进入故障状态 /var/log/keepalived-notify.log ;; *) echo $(date) - 未知状态: $STATE /var/log/keepalived-notify.log ;; esac启动Keepalivedsudo chmod x /etc/keepalived/notify.sh sudo systemctl enable keepalived sudo systemctl start keepalived现在客户端通过虚拟IP192.168.1.100访问服务如果主负载均衡器挂了备用会自动接管。5. 应用服务器集群部署5.1 配置共享存储为了让所有应用服务器使用相同的模型文件我们设置NFS共享存储在存储服务器上可以是其中一台应用服务器# 安装NFS服务器 sudo apt install -y nfs-kernel-server # 创建共享目录 sudo mkdir -p /shared/models sudo chown -R nobody:nogroup /shared sudo chmod -R 777 /shared # 配置NFS导出 sudo tee /etc/exports EOF /shared/models 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash) EOF # 应用配置 sudo exportfs -a sudo systemctl restart nfs-kernel-server在每台应用服务器上# 安装NFS客户端 sudo apt install -y nfs-common # 创建本地挂载点 sudo mkdir -p /mnt/models # 挂载共享存储 sudo mount -t nfs 192.168.1.101:/shared/models /mnt/models # 存储服务器IP # 设置开机自动挂载 echo 192.168.1.101:/shared/models /mnt/models nfs defaults 0 0 | sudo tee -a /etc/fstab5.2 部署应用服务器修改每台应用服务器的Docker Compose配置使用共享存储# docker-compose.yml应用服务器版本 version: 3.8 services: longcat-edit: image: your-registry/longcat-image-edit:v2 container_name: longcat-edit-${HOSTNAME} # 使用主机名区分 runtime: nvidia ports: - 7860:7860 environment: - MODEL_PATH/app/models/LongCat-Image-Edit - CUDA_VISIBLE_DEVICES0 - SERVER_NAME${HOSTNAME} # 标识服务器 volumes: - /mnt/models:/app/models # 使用共享存储 - ./outputs:/app/outputs - ./logs:/app/logs deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] healthcheck: test: [CMD, curl, -f, http://localhost:7860/health] interval: 30s timeout: 10s retries: 3 start_period: 60s # 给模型加载足够时间 logging: driver: json-file options: max-size: 10m max-file: 3 restart: unless-stopped5.3 配置应用健康检查在每台应用服务器上创建一个简单的健康检查接口# health_check.py from flask import Flask, jsonify import psutil import torch app Flask(__name__) app.route(/health) def health_check(): 综合健康检查接口 status { status: healthy, server: longcat-edit-1, # 根据实际情况修改 checks: {} } # 检查GPU try: if torch.cuda.is_available(): gpu_memory torch.cuda.memory_allocated() / 1024**3 gpu_total torch.cuda.get_device_properties(0).total_memory / 1024**3 status[checks][gpu] { available: True, memory_used_gb: round(gpu_memory, 2), memory_total_gb: round(gpu_total, 2), utilization: round(gpu_memory / gpu_total * 100, 1) } else: status[checks][gpu] {available: False} except Exception as e: status[checks][gpu] {available: False, error: str(e)} # 检查CPU和内存 cpu_percent psutil.cpu_percent(interval1) memory psutil.virtual_memory() status[checks][cpu] { percent: cpu_percent, load_avg: psutil.getloadavg() } status[checks][memory] { used_gb: round(memory.used / 1024**3, 2), total_gb: round(memory.total / 1024**3, 2), percent: memory.percent } # 检查磁盘空间 disk psutil.disk_usage(/) status[checks][disk] { used_gb: round(disk.used / 1024**3, 2), total_gb: round(disk.total / 1024**3, 2), percent: disk.percent } # 如果有任何关键资源超过阈值标记为不健康 if (cpu_percent 90 or memory.percent 90 or disk.percent 90 or (status[checks][gpu].get(available) and status[checks][gpu].get(utilization, 0) 95)): status[status] degraded return jsonify(status) if __name__ __main__: app.run(host0.0.0.0, port5000)将健康检查服务集成到Docker Compose中# 在docker-compose.yml中添加 services: health-check: image: python:3.9-slim container_name: health-check ports: - 5000:5000 volumes: - ./health_check.py:/app/health_check.py command: sh -c pip install flask psutil torch python /app/health_check.py depends_on: - longcat-edit restart: unless-stopped6. 监控与告警系统6.1 使用Prometheus监控安装Prometheus监控服务器# 在监控节点上 wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz tar xvfz prometheus-*.tar.gz cd prometheus-* # 创建配置文件 cat prometheus.yml EOF global: scrape_interval: 15s evaluation_interval: 15s rule_files: - alert.rules alerting: alertmanagers: - static_configs: - targets: [localhost:9093] scrape_configs: - job_name: longcat-servers static_configs: - targets: [192.168.1.101:5000, 192.168.1.102:5000, 192.168.1.103:5000] metrics_path: /metrics - job_name: node-exporter static_configs: - targets: [192.168.1.101:9100, 192.168.1.102:9100, 192.168.1.103:9100] - job_name: nginx static_configs: - targets: [192.168.1.100:9113] # Nginx监控端口 EOF6.2 配置Grafana仪表板安装Grafanasudo apt-get install -y software-properties-common sudo add-apt-repository deb https://packages.grafana.com/oss/deb stable main wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - sudo apt-get update sudo apt-get install -y grafana sudo systemctl enable grafana-server sudo systemctl start grafana-server导入LongCat服务监控仪表板监控关键指标各服务器CPU、内存、GPU使用率请求响应时间分布错误率和服务可用性模型推理耗时统计6.3 设置告警规则在Prometheus中配置告警规则# alert.rules groups: - name: longcat_alerts rules: - alert: HighErrorRate expr: rate(http_requests_total{status~5..}[5m]) / rate(http_requests_total[5m]) 0.05 for: 5m labels: severity: warning annotations: summary: 高错误率检测到 description: 错误率超过5% - alert: ServiceDown expr: up 0 for: 1m labels: severity: critical annotations: summary: 服务下线 description: {{ $labels.instance }} 服务不可用 - alert: HighGPUMemoryUsage expr: gpu_memory_usage 90 for: 5m labels: severity: warning annotations: summary: GPU内存使用率高 description: GPU内存使用率超过90% - alert: SlowResponse expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) 10 for: 10m labels: severity: warning annotations: summary: 响应时间慢 description: 95%的请求响应时间超过10秒7. 自动化部署与伸缩7.1 使用Ansible自动化部署创建Ansible playbook实现一键部署# deploy_longcat.yml - name: 部署LongCat-Image-Edit高可用集群 hosts: all become: yes vars: model_path: /mnt/models/LongCat-Image-Edit docker_image: your-registry/longcat-image-edit:v2 tasks: - name: 安装基础依赖 apt: name: {{ item }} state: present update_cache: yes loop: - docker.io - docker-compose - nvidia-container-toolkit - python3-pip - name: 配置Docker使用NVIDIA运行时 copy: content: | { runtimes: { nvidia: { path: nvidia-container-runtime, runtimeArgs: [] } }, default-runtime: nvidia } dest: /etc/docker/daemon.json notify: 重启docker - name: 创建应用目录 file: path: {{ item }} state: directory mode: 0755 loop: - /opt/longcat-edit - /opt/longcat-edit/logs - /opt/longcat-edit/outputs - name: 部署Docker Compose配置 template: src: templates/docker-compose.yml.j2 dest: /opt/longcat-edit/docker-compose.yml - name: 部署健康检查脚本 template: src: templates/health_check.py.j2 dest: /opt/longcat-edit/health_check.py - name: 启动服务 shell: | cd /opt/longcat-edit docker-compose up -d - name: 等待服务就绪 wait_for: port: 7860 delay: 10 timeout: 300 handlers: - name: 重启docker systemd: name: docker state: restarted7.2 基于压力的自动伸缩创建自动伸缩脚本根据监控指标动态调整服务器数量# auto_scaling.py import requests import json import time from typing import Dict, List class LongCatAutoScaler: def __init__(self, prometheus_url: str, min_instances: int 2, max_instances: int 10): self.prometheus_url prometheus_url self.min_instances min_instances self.max_instances max_instances self.scale_up_threshold 70 # CPU使用率超过70%时扩容 self.scale_down_threshold 30 # CPU使用率低于30%时缩容 def get_cpu_usage(self) - float: 获取集群平均CPU使用率 query 100 - (avg by(instance)(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) response requests.get(f{self.prometheus_url}/api/v1/query, params{query: query}) if response.status_code 200: data response.json() if data[data][result]: # 计算所有实例的平均值 values [float(r[value][1]) for r in data[data][result]] return sum(values) / len(values) return 0.0 def get_request_rate(self) - float: 获取当前请求速率 query rate(http_requests_total[5m]) response requests.get(f{self.prometheus_url}/api/v1/query, params{query: query}) if response.status_code 200: data response.json() if data[data][result]: return sum(float(r[value][1]) for r in data[data][result]) return 0.0 def get_response_time(self) - float: 获取平均响应时间 query rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m]) response requests.get(f{self.prometheus_url}/api/v1/query, params{query: query}) if response.status_code 200: data response.json() if data[data][result]: values [float(r[value][1]) for r in data[data][result]] return sum(values) / len(values) return 0.0 def scale_up(self): 扩容启动新的应用服务器 # 这里可以集成云服务商的API或者使用容器编排平台 print(触发扩容操作) # 实际实现会根据你的基础设施来定 # 例如调用云服务API创建新实例或调整Kubernetes副本数 def scale_down(self): 缩容停止多余的应用服务器 print(触发缩容操作) # 实际实现会根据你的基础设施来定 def run(self): 主循环定期检查并调整规模 while True: try: cpu_usage self.get_cpu_usage() request_rate self.get_request_rate() response_time self.get_response_time() print(f监控数据 - CPU: {cpu_usage:.1f}%, 请求率: {request_rate:.1f}/s, 响应时间: {response_time:.2f}s) # 根据多个指标决定是否伸缩 if cpu_usage self.scale_up_threshold or response_time 5.0: self.scale_up() elif cpu_usage self.scale_down_threshold and request_rate 10: self.scale_down() except Exception as e: print(f监控出错: {e}) time.sleep(60) # 每分钟检查一次 if __name__ __main__: scaler LongCatAutoScaler( prometheus_urlhttp://192.168.1.100:9090, min_instances2, max_instances6 ) scaler.run()8. 实际应用效果与优化建议这套架构在我们团队实际运行了大概一个月效果还是挺明显的。最直接的感受就是服务稳定多了之前那种动不动就卡住的情况基本没有了。即使有一台服务器出问题其他服务器也能马上接上用户几乎感觉不到。从数据上看平均响应时间从原来的15秒左右降到了8秒服务可用性从95%提升到了99.9%。而且因为有了监控我们能提前发现潜在问题比如GPU内存泄漏或者磁盘空间不足能在用户受影响之前就处理好。不过在实际运行中也发现了一些可以优化的地方GPU资源优化LongCat-Image-Edit V2对GPU显存要求比较高我们发现可以通过模型量化来减少显存占用。把模型从FP16量化到INT8显存占用能减少差不多一半推理速度还能提升20%左右画质损失几乎看不出来。请求队列管理高峰期请求多的时候简单的负载均衡策略可能不够。我们后来加了智能队列把编辑任务按复杂度分类简单的任务优先处理复杂的任务排队这样整体吞吐量又提升了30%。缓存策略优化相似的图片编辑请求其实可以用缓存的结果。我们加了Redis缓存层把常见的编辑操作结果缓存起来命中率大概有15%又减轻了不少后端压力。成本控制三台服务器一直开着成本不低。我们根据使用规律设置了自动开关机策略。晚上12点到早上8点用量少就只留一台服务器运行其他两台关机一个月能省下40%左右的电费和云服务费。9. 总结在Ubuntu上部署LongCat-Image-Edit V2的高可用架构听起来有点复杂但实际拆解开来就是几个关键步骤多台服务器分担压力、负载均衡器分配请求、共享存储统一模型、监控系统及时告警。这套方案最大的好处就是稳定性和可扩展性。业务量小的时候两台服务器就够了业务量大了加机器就行架构不用大改。而且因为有了完善的监控运维压力也小了很多不用整天盯着服务器看。如果你也在用LongCat-Image-Edit V2或者类似的AI模型服务强烈建议考虑高可用架构。前期投入是多一点但长期来看无论是稳定性还是可维护性都值得这个投入。特别是现在AI应用越来越普及用户对服务稳定性的要求也越来越高一个好的架构设计能让你的服务在竞争中更有优势。当然具体实施的时候还是要根据你的实际需求和资源情况来调整。比如服务器数量、监控粒度、告警阈值这些都需要在实际运行中不断优化。但核心思路是不变的分散风险互为备份实时监控快速响应。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。