作者昇腾实战派一、背景介绍在构建高并发、低延迟的多模态AI分析系统时L1阶段的初筛环节对推理性能提出严苛要求。系统需在1分钟内完成音频与视频输入的联合理解输出初步判定结果。本文基于Atlas 800I A2部署Qwen3-Omni原生全模态大模型围绕关键算子瓶颈展开深度优化实现性能突破。版本环境vLLM-Ascend: v0.13.0CANN: 8.3.RC1模型Qwen3-Omni二、Qwen3-Omni模型架构与核心能力Qwen3-Omni于2025年9月发布是新一代原生全模态大模型支持文本、图像、音频、视频的统一处理并可实现端到端的流式响应。其核心能力包括原生全模态在多模态数据上联合预训练避免模态降智。卓越性能在36项音频与音视频基准测试中斩获32项开源SOTA22项总体SOTA超越Gemini-2.5-Pro、GPT-4o-Transcribe等闭源模型。多语言支持支持119种文本语言、19种语音理解语言与10种语音生成语言。低延迟响应纯模型端到端音频对话延迟低至211ms视频对话延迟低至507ms。长序列支持可处理长达30分钟的音频输入。个性化与工具调用支持system prompt定制、function call集成增强系统可扩展性。图1 Qwen3-Omni模型结构2.1 Audio TransformerAuTAudio TransformerAuT是一种注意力编码器‑解码器架构如图 2 所示在2000 万小时的有监督音频数据上从零训练。训练过程中音频的滤波器组特征在进入注意力层之前通过​Conv2D 模块进行 8 倍下采样​将token rate降至 ​12.5Hz​。为学习更强大、更通用的音频表征AuT 在大规模音频数据集上同时基于语音识别与音频理解任务进行联合训练。具体而言训练数据包含80% 中、英文伪标注 ASR 数据10% 其他语言 ASR 数据以及 10% 音频理解数据。在 Qwen3‑Omni 中AuT 编码器用作​音频编码器​其参数量约为 ​**0.6B6 亿**​。图2 Qwen3-Omni AuT结构2.2 Thinker模块多模态表征统一Thinker 模块将​文本​、​音频​、图像及​视频不含音频​转换为一系列表征用于输入。对于​文本输入​采用 Qwen 的tokenizer基于BBPE编码词表量为151643该分词器采用字节级字节对编码byte-level byte-pair encoding, BBPE包含 151,643 个token。对于音频输入及从​视频中提取的音频​将其重采样至 16 kHz再将原始波形转换为 128 通道的梅尔频谱mel-spectrogram采用 25 ms 的窗口长度window和 10 ms 的步长hop。使用 AuT 编码器作为音频编码器该编码器在 2000 万小时音频数据上从零开始训练且每帧音频表征对应原始音频信号约 80 ms 的片段。对于​图片和视频不含音频输入​采用 Qwen3-VL 的视觉编码器Vision Encode该编码器基于 SigLIP2-So400m 初始化参数量约为 5.43 亿能够同时处理图像和视频输入。该视觉编码器在图像与视频混合数据集上训练确保具备强大的图像理解和视频理解能力。此外为在与音频采样率对齐的同时尽可能完整地保留视频信息采用动态帧率对视频帧进行采样。三、关键性能瓶颈分析与优化实践在部署vLLM推理服务过程中Profiling分析发现部分算子存在性能瓶颈。我们聚焦于MoE与CUMSUM算子实施针对性优化。3.1 算子融合优化3.1.1 MoE路由算子替换为提升MoEMixture of Experts模块的执行效率将原生PyTorch算子替换为Ascend原生优化算子替换torch_npu.npu_moe_gating_top_k为torch.ops._C_ascend.moe_gating_top_k替换torch_npu.npu_moe_init_routing_v2为torch.ops._C_ascend.npu_moe_init_routing_custom上述替换基于vLLM-Ascend社区PR优化显著提升MoE路由阶段的算子执行效率。参考PR:https://github.com/vllm-project/vllm-ascend/pull/5332/files3.1.2 CUMSUM算子性能优化问题定位Profiling显示CUMSUM算子耗时异常且为AI_CPU算子。进一步分析发现其输入数据类型为INT64而Ascend芯片指令不支持INT64导致算子在CPU侧执行成为性能瓶颈。调用栈分析该算子位于vllm-ascend/vllm_ascend/ops/fused_moe/moe_mlp.py为MoE模块中路由计算的一部分。优化方案数据类型转换在CUMSUM算子输入前显式将INT64转换为INT32。显式指定Dtype参数CUMSUM算子默认Dtype为INT64若不传参即使输入为INT32系统仍会自动提升为INT64。因此必须显式传入dtypetorch.int32确保算子在AI-Core上执行。关键点仅加cast(torch.int32)不足以解决问题必须同时修改算子调用参数否则仍会因类型提升导致CPU执行。