1. 项目概述
最近在测试vLLM-Omni框架与Wan2.1-T2V-1.3B模型的性能表现,这是一个基于Ascend NPU的文本到视频生成任务。测试环境使用了8张910B3 NPU卡,主要考察了单卡单实例、双卡单实例两种部署方式,并对模型并行策略进行了优化探索。
文本到视频生成是当前生成式AI领域的前沿方向,相比静态图像生成,视频生成需要处理时间维度上的连续性,计算复杂度呈指数级增长。Wan2.1-T2V-1.3B是一个基于扩散模型的文本到视频生成模型,参数规模达到13亿,能够根据文本提示生成高质量的视频内容。
2. 测试环境配置
2.1 硬件环境
测试使用了8张Ascend 910B3 NPU卡,通过npu-smi工具可以查看各卡的运行状态:
bash复制npu-smi info
输出显示了每张卡的运行状态、功耗、温度以及内存使用情况。从输出可以看到:
- 所有NPU卡健康状态均为OK
- 功耗在90-100W之间
- 温度维持在42-47℃的合理范围
- HBM显存使用情况各不相同,部分卡使用率较高
2.2 软件环境
测试前需要配置以下环境变量:
bash复制export ASCEND_RT_VISIBLE_DEVICES=2 # 指定使用的NPU设备
export VLLM_WORKER_MULTIPROC_METHOD=spawn # 设置多进程方法
source /usr/local/Ascend/ascend-toolkit/set_env.sh # 加载Ascend工具链
source /usr/local/Ascend/nnal/atb/set_env.sh # 加载ATB库
注意:环境变量的设置顺序很重要,必须先设置设备可见性,再加载工具链。
3. 单卡单实例测试
3.1 服务启动
使用以下命令启动单卡服务:
bash复制vllm-omni serve /data/models/Wan2.1-T2V-1.3B-Diffusers \
--omni --port 8023 --boundary-ratio 0.875 \
--flow-shift 5.0 --cfg-parallel-size 2 --dtype float16
参数说明:
--omni: 启用Omni模式--port 8023: 指定服务端口--boundary-ratio 0.875: 边界比率参数--flow-shift 5.0: 光流偏移量--cfg-parallel-size 2: CFG并行大小--dtype float16: 使用FP16精度
3.2 请求测试
使用curl发送生成请求:
bash复制curl -X POST http://localhost:8023/v1/videos/sync \
-F "prompt=A futuristic city at sunset" \
-F "width=832" \
-F "height=480" \
-F "num_frames=81" \
-F "fps=16" \
-F "num_inference_steps=50" \
-F "guidance_scale=4.0" \
-F "seed=42" \
-o /data/cjh/omini/server_test3.mp4
请求参数解析:
prompt: 生成视频的文本描述width/height: 视频分辨率num_frames: 总帧数fps: 帧率num_inference_steps: 扩散模型推理步数guidance_scale: CFG引导系数seed: 随机种子
单卡测试耗时约6分钟,生成了一段81帧、832x480分辨率的视频。
4. 双卡单实例测试
4.1 服务启动
使用两张NPU卡启动服务:
bash复制export ASCEND_RT_VISIBLE_DEVICES=2,3 # 指定使用两张卡
export CFG_PARALLEL_SIZE=2 # 设置CFG并行大小
vllm-omni serve /data/models/Wan2.1-T2V-1.3B-Diffusers \
--omni --port 8023 --boundary-ratio 0.875 \
--flow-shift 5.0 --cfg-parallel-size 2 --dtype float16
4.2 性能对比
使用相同的curl请求测试,双卡配置下耗时约3分钟,相比单卡性能提升约2倍。这是因为:
- CFG-Parallel策略将guidance分支和无guidance分支分配到不同GPU上并行计算
- 扩散模型每步需要跑两次计算(有引导和无引导)
- 并行计算使得50步推理的时间减半
实测心得:CFG-Parallel对扩散模型特别有效,因为这类模型天然就有并行计算的机会。但要注意不是所有模型都支持这种并行方式。
5. 模型并行策略分析
5.1 支持的并行策略
根据官方文档测试,Wan2.1模型支持以下并行策略:
-
CFG-Parallel:
- 固定需要2张卡
- 速度提升约2倍
- 生成质量保持不变
- 原理:将CFG引导的两个分支并行计算
-
不支持的并行策略:
- Ring/USP并行:适用于长序列场景,可减少单卡显存占用
5.2 并行策略选择建议
选择并行策略时需要考虑:
- 硬件资源:CFG-Parallel需要偶数张卡
- 序列长度:长视频更适合Ring/USP并行(但当前模型不支持)
- 质量要求:CFG-Parallel不会影响生成质量
- 部署复杂度:CFG-Parallel配置简单,只需设置环境变量
6. 并发处理与扩展方案
6.1 并发限制
测试发现vLLM-Omni有以下并发限制:
- 单实例batch_size固定为1
- 架构设计上Diffusion Worker不支持同时处理多个请求
- 这不是配置问题,而是框架的设计选择
6.2 扩展方案
要提高并发处理能力,可以采用:
-
多实例部署:
- 在不同端口启动多个服务实例
- 每个实例使用不同的NPU设备
-
负载均衡:
- 使用Nginx作为反向代理
- 将请求分发到多个服务实例
- 配置示例:
nginx复制upstream video_servers { server localhost:8023; server localhost:8024; server localhost:8025; } server { listen 80; location / { proxy_pass http://video_servers; } }
-
资源隔离:
- 每个实例绑定到特定的NPU设备
- 避免资源争用
7. 性能优化建议
基于测试结果,提出以下优化建议:
-
硬件选择:
- 对于生产环境,建议至少使用2张NPU卡
- 内存带宽高的设备性能更好
-
参数调优:
boundary-ratio和flow-shift影响视频质量- 需要针对具体场景调整这些参数
- 建议进行网格搜索找到最优参数组合
-
预热策略:
- 服务启动后先发送几个预热请求
- 让模型完成初始化并达到稳定状态
- 避免第一个请求响应时间过长
-
监控指标:
- 实时监控NPU利用率
- 跟踪内存使用情况
- 记录每个请求的耗时分布
8. 常见问题与解决方案
8.1 服务启动失败
问题现象:
- 报错提示NPU不可用
- 服务无法绑定到指定端口
解决方案:
- 检查NPU设备状态:
npu-smi info - 确认设备号正确:
export ASCEND_RT_VISIBLE_DEVICES=2,3 - 检查端口是否被占用:
netstat -tulnp | grep 8023 - 确保有足够的权限访问NPU设备
8.2 生成视频质量差
问题现象:
- 视频中出现 artifacts
- 运动不连贯
- 与文本描述不符
调优建议:
- 增加
num_inference_steps(但会增加耗时) - 调整
guidance_scale(通常在4-8之间) - 尝试不同的
seed值 - 检查模型文件是否完整
8.3 性能不如预期
可能原因:
- NPU未充分利用
- 内存带宽成为瓶颈
- 框架开销过大
排查步骤:
- 使用
npu-smi监控NPU利用率 - 检查HBM内存使用情况
- 尝试减少
cfg-parallel-size - 考虑使用更轻量级的模型
9. 实际应用建议
根据测试经验,给出以下应用建议:
-
生产部署:
- 使用Docker容器化部署
- 配置资源限制和健康检查
- 实现自动扩缩容
-
用户体验优化:
- 对于交互式应用,先返回低分辨率预览
- 后台继续生成高分辨率版本
- 提供进度反馈机制
-
成本控制:
- 根据负载动态启停实例
- 使用混合精度训练(FP16/FP32)
- 考虑模型量化方案
-
持续改进:
- 建立自动化测试流水线
- 定期评估新模型版本
- 收集用户反馈优化prompt模板
