vLLM-Ascend Qwen3-VL-235B-A22B 单batch性能优化案例
作者:昇腾实战派
1. 背景概述
在Atlas 800I A3 硬件平台上部署大模型推理服务时,面对超大规模多模态 MoE 模型(Qwen3-VL-235B-A22B)的低并发高时延敏感场景,如何实现单请求吞吐的显著提升成为关键挑战。
本文基于 vLLM-Ascend v0.13.0rc1 版本的性能瓶颈分析,系统性地探索了版本升级、并行策略重构、MoE 负载治理与缓存优化等多维度优化路径,为大规模多模态模型在生产环境中的高效部署提供了可复用的技术范式。
1.1 版本信息
- 设备:Atlas 800I A3
- 模型:Qwen3-VL-235B-A22B(VL + MoE 大模型)
- 引擎版本:vllm-ascend v0.13.0rc1
- 精度:BF16
- 测试场景:单请求、单 batch(典型低并发高时延敏感场景)
1.2 问题表现
Qwen3-VL-235B-A22B模型在 rc1 基线下能够正常运行,但单请求吞吐明显偏低。对于低并发但要求稳定响应的场景,该性能水平难以满足大部分要求。
2. 问题定位
针对性能不足问题,首先进行了 profiling 采集与链路拆解(prefill / decode / 通信 / MoE 路由与分发等),定位瓶颈来源。
2.1 Profiling 观察到的主要问题
结合 profiling 与 benchmark 数据,发现存在以下典型问题:
- MoE 路径存在明显固定开销与通信等待
- 单 batch 场景下,MoE 的 dispatch/combine 开销占比偏高;
- decode 阶段存在较多等待(如
EVENT_WAIT类时间占比偏高),说明通信与计算重叠不足。
- 专家负载存在不均衡迹象(尤其在高并发更明显)
- 从 MoE 相关算子统计/时间分布看,部分专家路径更热,导致局部热点与通信压力抬升;
- 单并发时该问题对 TPS 提升不一定非常明显,但在高并发场景会放大。
- rc1 版本在 Qwen3-VL 路径上的优化不充分
- 模型为 VL + MoE 结构,注意力/多模态路径和 MoE 路径均可能成为瓶颈;
- rc1 下针对 Qwen3-VL 的特定优化链路未充分生效(后续通过升级 rc2 得到验证)。
2.2 初步判断
综合判断,性能不足并非单一原因,而是以下因素叠加导致:
- Qwen3-VL 特定路径优化不足
- MoE 通信/计算重叠不足
- 并行策略(TP/DP 组合)与单并发场景不匹配
- 专家负载不均在高并发场景中潜在放大
3. 优化手段(定位后的动作与技术决策)
3.1 对比 rc1 / rc2 版本
在问题定位后,进一步对比 v0.13.0rc1 → v0.13.0rc2 的版本变更,重点关注 Qwen3-VL、MoE、通信优化相关 PR。
从 rc2 发布说明中可确认,存在多项直接或高度相关的性能优化,包括:
- PR #5848:Flashcomm1 feature now works with qwen3-vl
该项明确点名 Qwen3-VL,属于模型特定性能路径打通,极可能直接改善 Qwen3-VL 的注意力/通信相关性能。([docs.vllm.ai][1]https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html) - PR #5962:Support fine-grained shared expert overlap
提升共享专家的细粒度重叠能力,有利于 MoE 场景下通信-计算重叠,改善 decode 吞吐。([docs.vllm.ai][1]https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html) - rc2 引入/增强多项 custom ops 与 Triton kernels(包括 MoE 相关 custom op)
发布说明明确提到多项 custom ops / Triton kernels 的性能优化,这类改动通常会显著降低单 batch 固定开销。([docs.vllm.ai][1]https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html)
此外,rc2 对底层依赖栈也有升级:
- CANN:8.3.RC2 → 8.5.0
- torch_npu:2.8.0 → 2.8.0.post1
- triton-ascend:3.2.0(rc2 版本矩阵中明确)
这类 runtime/编译栈升级也可能带来额外性能收益。(docs.vllm.aihttps://docs.vllm.ai/projects/ascend/en/v0.13.0/community/versioning_policy.html)
3.2 升级版本验证(rc1 → rc2)
将版本升级至 v0.13.0rc2 后,在相同模型与相近测试条件下进行复测,单请求 TPS提升80%;
说明版本升级(含 PR 优化与底层依赖升级)已经显著改善了 Qwen3-VL-235B-A22B 的单请求性能。
3.3 优化并行策略(TP/DP 调整)
原基线并行策略为:
- TP4 × DP4
在单并发场景下,该配置未必最优(DP 资源在单请求场景利用率较低,反而增加同步与调度成本)。经调整为:
- TP8 × DP2
复测结果:
- 18 TPS → 24 TPS
这说明在单请求场景中,提高 TP、降低 DP 能更有效地提升单请求 decode 吞吐(前提是显存/通信拓扑允许)。
3.4 针对专家负载不均,尝试 EPLB(Expert Parallel Load Balancing)
在后续 profiling 中仍观察到专家负载不均衡问题,因此尝试引入 EPLB(专家负载均衡)方案,以改善高并发下的 MoE 热点专家问题。
技术路线
- 分析 Qwen3-VL-235B-A22B 的模型结构,确认其 MoE 模块与 Qwen3-235B-A22B 具有较高复用性
- 基于这一结构相似性,对现有 MoE/EPLB 代码进行模型适配开发,使其可作用于 Qwen3-VL-235B-A22B
结果
- 单并发场景:TPS 无明显变化(符合预期,单请求下专家热点问题不一定成为主瓶颈)
- 高并发场景:在启用 EPLB 并叠加缓存命中优化后,性能显著提升
3.5 高并发优化:Prefix Cache + MM Cache 命中优化
在高并发业务压测中,引入如下缓存策略:
- Prefix Cache 命中率 ~90%
- MM Cache(多模态缓存)命中率 ~90%
在上述缓存命中条件下,叠加 EPLB 后达到:
- 约 1500 TPS @ 90 并发
说明在高并发业务场景中,缓存命中 + MoE 负载均衡 是关键增益来源。
4. 优化方案 & 总结
4.1 优化方案总结(分层方案)
本案例最终采用的是“版本升级 + 并行策略重构 + MoE 负载治理 + 缓存优化”的组合方案:
方案一:版本升级(低成本高收益)
- 从 v0.13.0rc1 升级到 v0.13.0rc2
- 利用 rc2 中针对 Qwen3-VL / MoE / Flashcomm / custom ops 的优化
方案二:并行策略按场景调优(单并发优先)
- 基线:TP4DP4
- 调优:TP8DP2
- 原因:单请求场景下 DP 利用率低,TP 提升更有利于单请求 decode 性能
方案三:MoE 专家负载治理(面向高并发)
- 识别专家负载不均问题
- 复用 Qwen3-235B 的 MoE/EPLB 能力适配 Qwen3-VL-235B
- 单并发收益不明显,但为高并发稳定性和吞吐打基础
方案四:缓存命中优化(高并发核心增益)
- 提升 Prefix Cache 命中率
- 提升 MM Cache 命中率
- 在高并发场景叠加 EPLB,显著提升吞吐上限
4.3 经验总结(可复用方法论)
这次优化的经验不只是“换版本变快了”,而是一个比较完整的性能治理闭环:
经验 1:先分场景,再调参数
单并发和高并发的最优策略通常不同:
- 单并发:优先关注 decode 路径、TP/DP 配比、固定开销
- 高并发:优先关注缓存命中率、调度、MoE 热点与负载均衡
同一套配置不可能同时在所有场景最优
经验 2:版本升级要看“模型命中型 PR”,不是只看版本号
本次 rc2 收益大,不是因为“rc2 一定比 rc1 快”,而是因为 rc2 中存在:
- 直接命中 Qwen3-VL 的优化(#5848)
- 命中 MoE 重叠的优化(#5962)
这类“点名模型/路径”的 PR,优先级远高于泛化改动。([docs.vllm.ai][1]https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html)
经验 3:MoE 负载不均对单并发未必显著,但对高并发杀伤很大
单请求下看不出明显收益,不代表优化无效。MoE 负载均衡(EPLB)往往为高并发场景
[1]: https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html?utm_source=chatgpt.com
5. 关键词
- vllm-ascend
- Qwen3-VL-235B-A22B
- BF16
- 单请求性能优化
- 多模态推理优化
- MoE(Mixture of Experts)
- 专家负载不均
- EPLB(Expert Parallel Load Balancing)
- Flashcomm1
- shared expert overlap
- TP/DP 并行策略调优
- Prefix Cache
- MM Cache
- 昇腾 NPU
- profiling 性能分析
关键 PR / 版本关键词
- v0.13.0rc1 → v0.13.0rc2
- PR #5848(Flashcomm1 works with qwen3-vl)([docs.vllm.ai][1]https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html)
- PR #5962(fine-grained shared expert overlap)([docs.vllm.ai][1]https://docs.vllm.ai/projects/ascend/en/main/user_guide/release_notes.html)
- CANN 8.5.0 / torch_npu 2.8.0.post1 / Triton-Ascend 3.2.0(rc2 版本矩阵)(docs.vllm.aihttps://docs.vllm.ai/projects/ascend/en/v0.13.0/community/versioning_policy.html)
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐
所有评论(0)