WAN2.2文生视频开源大模型部署教程：Kubernetes集群化编排与弹性扩缩容-洪萨配资

WAN2.2文生视频开源大模型部署教程：Kubernetes集群化编排与弹性扩缩容

1. 为什么需要在Kubernetes上部署WAN2.2？

很多人第一次听说WAN2.2，第一反应是：“这又是一个文生视频模型？和Sora、Pika有什么区别？”其实WAN2.2的特别之处不在于它多“大”，而在于它足够“实”——它基于ComfyUI工作流构建，轻量、可解释、模块清晰，更重要的是，它原生支持SDXL Prompt风格迁移，能用一句中文提示词，生成带电影感运镜、风格统一的5秒短视频。但问题来了：本地跑一个视频生成任务可能要占用8GB显存+3分钟等待时间；如果同时来5个用户请求呢？10个呢？卡死、OOM、排队超时就成了常态。

这时候，单机部署就撑不住了。你需要的不是“再加一张卡”，而是整套服务化能力：自动调度GPU资源、按需启停实例、故障自动恢复、流量高峰时快速扩容、低谷期自动缩容省成本。这些，正是Kubernetes（简称K8s）最擅长的事。本文不讲抽象概念，不堆yaml参数，只带你从零开始，在真实K8s集群中完成WAN2.2的容器化封装、服务暴露、工作流集成与弹性伸缩配置——所有步骤均可复制、可验证、可上线。

你不需要是K8s专家，只要会用kubectl、有至少一台装好NVIDIA驱动和containerd的Linux服务器（或云主机），就能跟着走完全流程。最后你会得到一个真正可用的AI视频生成服务：输入中文提示词，选风格，点运行，30秒内返回MP4链接，背后是自动伸缩的GPU节点池。

2. 环境准备与基础依赖安装

2.1 集群前提条件检查

在开始前，请确认你的Kubernetes集群已满足以下最低要求：

Kubernetes版本 ≥ v1.24（推荐v1.26+）
已安装并配置好NVIDIA Device Plugin（用于GPU资源发现）
容器运行时为containerd（Docker已不被K8s官方推荐）
至少1台GPU节点（A10/A100/V100均可，显存≥24GB更稳妥）
集群内已部署CoreDNS，且能正常解析Service域名

你可以用以下命令快速验证GPU是否就绪：

kubectl get nodes -o wide # 查看输出中是否有"nvidia.com/gpu: X"字段（X为可用GPU数量） kubectl describe node <gpu-node-name> | grep -A 10 "Allocatable" # 应看到类似：nvidia.com/gpu: 2

若未显示GPU资源，请先部署NVIDIA Device Plugin并重启kubelet。

2.2 构建WAN2.2专用镜像

WAN2.2本身不提供Docker镜像，我们需要基于其ComfyUI工作流定制一个生产级镜像。核心思路是：复用ComfyUI官方基础镜像 + 注入WAN2.2工作流 + 预加载SDXL风格模型 + 暴露标准API端口。

创建Dockerfile如下：

FROM comfyanonymous/ComfyUI:latest # 切换到ComfyUI根目录 WORKDIR /app/ComfyUI # 复制WAN2.2工作流文件（需提前下载wan2.2_文生视频.json） COPY ./workflows/wan2.2_文生视频.json /app/ComfyUI/custom_nodes/wan2.2/workflow.json # 下载并解压SDXL风格模型（约4.2GB，建议使用国内镜像源） RUN mkdir -p /app/ComfyUI/models/checkpoints && \ curl -L https://hf-mirror.com/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors \ -o /app/ComfyUI/models/checkpoints/sd_xl_base_1.0.safetensors # 启用中文分词支持（关键！否则中文提示词无法正确解析） RUN pip install --no-cache-dir jieba # 暴露ComfyUI默认端口 EXPOSE 8188 # 启动脚本：确保GPU可见 + 启动WebUI CMD ["bash", "-c", "export CUDA_VISIBLE_DEVICES=0 && python main.py --listen --port 8188 --enable-cors-header"]

构建并推送镜像（以阿里云ACR为例）：

docker build -t registry.cn-hangzhou.aliyuncs.com/your-namespace/wan2.2-comfyui:v1.0 . docker push registry.cn-hangzhou.aliyuncs.com/your-namespace/wan2.2-comfyui:v1.0

注意：实际生产中，模型文件不应硬编码进镜像。推荐使用K8sPersistentVolume挂载NAS或对象存储（如OSS/S3），实现模型热更新与多实例共享。

3. Kubernetes核心资源编排

3.1 创建命名空间与资源配置

我们为WAN2.2服务创建独立命名空间，便于权限隔离与资源统计：

# namespace.yaml apiVersion: v1 kind: Namespace metadata: name: wan22-video labels: name: wan22-video

接着定义GPU资源请求策略。WAN2.2单次推理需约12GB显存，我们按16GB预留，并设置CPU/MEM保障：

# resources.yaml apiVersion: v1 kind: ResourceQuota metadata: name: gpu-quota namespace: wan22-video spec: hard: requests.nvidia.com/gpu: "4" requests.cpu: "8" requests.memory: "32Gi"

应用配置：

kubectl apply -f namespace.yaml kubectl apply -f resources.yaml -n wan22-video

3.2 部署StatefulSet：稳定、可追踪、可伸缩

WAN2.2作为无状态服务，用Deployment即可，但为了后续日志追踪、Pod名可读性及GPU绑定稳定性，我们选用StatefulSet（配合Headless Service）：

# wan22-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: wan22-comfyui namespace: wan22-video spec: serviceName: wan22-headless replicas: 1 selector: matchLabels: app: wan22-comfyui template: metadata: labels: app: wan22-comfyui spec: containers: - name: comfyui image: registry.cn-hangzhou.aliyuncs.com/your-namespace/wan2.2-comfyui:v1.0 ports: - containerPort: 8188 name: http resources: limits: nvidia.com/gpu: 1 memory: "24Gi" cpu: "6" requests: nvidia.com/gpu: 1 memory: "16Gi" cpu: "4" env: - name: COMFYUI_MODEL_PATH value: "/app/ComfyUI/models" volumeMounts: - name: models-pv mountPath: /app/ComfyUI/models volumes: - name: models-pv persistentVolumeClaim: claimName: models-pvc tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu.present operator: Exists

配套创建Headless Service（用于内部Pod间通信）和ClusterIP Service（供外部调用）：

# service.yaml apiVersion: v1 kind: Service metadata: name: wan22-headless namespace: wan22-video spec: clusterIP: None selector: app: wan22-comfyui --- apiVersion: v1 kind: Service metadata: name: wan22-api namespace: wan22-video spec: type: ClusterIP selector: app: wan22-comfyui ports: - port: 8188 targetPort: 8188

关键点说明：
tolerations和affinity确保Pod只调度到有GPU的节点；
volumeMounts挂载模型PVC，避免每次拉镜像都重复下载；
replicas: 1是初始值，后续将通过HPA动态调整。

应用全部资源：

kubectl apply -f wan22-statefulset.yaml -n wan22-video kubectl apply -f service.yaml -n wan22-video

3.3 验证基础服务连通性

等待Pod就绪后，执行端口转发测试：

kubectl port-forward svc/wan22-api 8188:8188 -n wan22-video

打开浏览器访问http://localhost:8188，应看到ComfyUI界面。点击左侧工作流列表，确认wan2.2_文生视频已加载。此时你已成功将WAN2.2跑在K8s上——但还只是单实例，没有弹性。

4. 实现弹性扩缩容：从1到N的智能调度

4.1 为什么不能只靠ReplicaSet手动扩缩？

手动kubectl scale可以改副本数，但无法应对真实业务场景：

用户请求突增时，你不可能24小时盯屏；
GPU空闲时，多开的Pod白白烧钱；
单个Pod崩溃，需人工介入恢复。

真正的弹性，是让系统自己“看用量、做决策、执行动作”。

Kubernetes提供了Horizontal Pod Autoscaler（HPA），它能基于CPU、内存或自定义指标（如QPS、队列长度）自动调整Pod数量。但WAN2.2是GPU密集型任务，CPU利用率常低于30%，而GPU显存却早已打满——所以必须使用自定义指标。

4.2 基于GPU显存使用率的HPA配置

我们采用NVIDIA DCGM Exporter采集GPU指标，并通过Prometheus暴露给K8s。

首先部署DCGM Exporter（已在GPU节点运行）：

helm repo add gpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helm install dcgm-exporter gpu-helm-charts/dcgm-exporter -n wan22-video

然后创建Prometheus Rule，将DCGM_FI_DEV_MEM_COPY_UTIL（显存拷贝利用率）转化为K8s可读指标：

# gpu-metrics-rule.yaml apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: gpu-utilization-rule namespace: wan22-video spec: groups: - name: gpu.rules rules: - record: gpu_utilization_percent expr: 100 * (dcgm_gpu_memory_used_bytes{job="dcgm-exporter"} / dcgm_gpu_memory_total_bytes{job="dcgm-exporter"})

最后配置HPA，目标显存使用率设为70%（留30%缓冲防抖动）：

# hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: wan22-hpa namespace: wan22-video spec: scaleTargetRef: apiVersion: apps/v1 kind: StatefulSet name: wan22-comfyui minReplicas: 1 maxReplicas: 8 metrics: - type: Pods pods: metric: name: gpu_utilization_percent target: type: AverageValue averageValue: 70

应用HPA：

kubectl apply -f hpa.yaml -n wan22-video

现在，当GPU显存平均使用率持续5分钟超过70%，HPA会自动增加Pod副本；低于40%持续10分钟，则缩减。整个过程无需人工干预。

4.3 实测弹性响应：模拟高并发请求

我们用简单脚本模拟10个并发请求（每个生成1个5秒视频）：

# test-load.sh for i in {1..10}; do curl -X POST http://$(kubectl get svc wan22-api -n wan22-video -o jsonpath='{.spec.clusterIP}'):8188/prompt \ -H "Content-Type: application/json" \ -d '{ "prompt": "一只橘猫坐在窗台看雨，水墨风格，镜头缓慢推进", "workflow": "wan2.2_文生视频", "style": "水墨" }' & done wait

执行前观察HPA状态：

kubectl get hpa -n wan22-video # NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE # wan22-hpa StatefulSet/wan22-comfyui <unknown>/70% 1 8 1 2m

运行脚本后30秒内，REPLICAS将升至3；1分钟后升至5；峰值时达6。待请求结束，2分钟内自动缩回1。全程日志可查：

kubectl logs -l app=wan22-comfyui -n wan22-video --since=5m

你看到的不是“理论可行”，而是真实发生的弹性伸缩。

5. 生产就绪增强：日志、监控与安全加固

5.1 统一日志收集：对接ELK或Loki

WAN2.2日志分散在各Pod中，需集中管理。推荐使用Loki+Promtail（轻量、专为日志设计）：

# promtail-config.yaml（片段） clients: - url: http://loki:3100/loki/api/v1/push scrape_configs: - job_name: kubernetes-pods static_configs: - targets: - localhost labels: job: kubernetes-pods __path__: /var/log/pods/*wan22-comfyui*/*.log

部署后，所有WAN2.2 Pod日志自动发送至Loki，可通过Grafana查询关键词如"video generated"、"OOMKilled"，快速定位失败请求。

5.2 关键监控大盘：不只是“GPU在不在”

除了基础GPU使用率，还需关注：

请求成功率：HTTP 2xx vs 5xx比例（反映服务健康度）
平均生成耗时：从提交到返回MP4的P95延迟（影响用户体验）
队列积压数：ComfyUI内部等待队列长度（预示过载风险）

我们在Prometheus中添加如下Recording Rule：

# recording-rules.yaml groups: - name: wan22.rules rules: - record: wan22:video_generation_duration_seconds:mean5m expr: histogram_quantile(0.95, sum(rate(comfyui_video_generation_duration_seconds_bucket[5m])) by (le)) - record: wan22:queue_length expr: count by (pod) (comfyui_queue_pending_tasks)

搭配Grafana模板，即可获得实时大盘，一眼掌握服务水位。

5.3 最小权限安全实践

禁止root运行：在Dockerfile中添加USER 1001；
Secret管理API Key：若需对接第三方存储，用K8s Secret注入，而非硬编码；
NetworkPolicy隔离：限制仅ingress-controller和监控组件可访问wan22-api服务：

# network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: wan22-isolate namespace: wan22-video spec: podSelector: matchLabels: app: wan22-comfyui policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: nginx-ingress - podSelector: matchLabels: app: prometheus ports: - protocol: TCP port: 8188