跳转至

Ascend 950 A5 Multimodal Quantization

导言

截至 2026-07-07，Ascend 950 A5 对多模态生成的公开支持已经不是零，但它更像三层拼图：vLLM-Omni 已把 Ascend NPU、Wan2.2/Qwen-Image 等 diffusion 量化路径写进文档；vLLM-Ascend 主分支出现 A5/950 与 MXFP/W8A8 等后端代码；VeRL-Omni 已能用 vLLM-Omni 做 Ascend NPU rollout，但量化默认仍是空配置，公开 recipe 还没有给出 A5 量化 RL 的性能和精度结论。本文只写可追溯来源，尤其区分“文档支持”“代码路径”“验证效果”和“仍需实测”。

先给结论

当前公开资料更支持一个谨慎判断：Ascend 950 A5 的多模态 serving 量化路径正在形成，但训练侧和效果侧还没有闭环到可以直接引用的公开 benchmark。

Ascend 950 A5 support stack

具体拆开看：

  • vLLM-Omni：量化文档已经把 Ascend NPU 纳入支持矩阵。对 diffusion 模型，Ascend NPU 支持 Int8 W8A8、MXFP8、MXFP4、msModelSlim，以及 diffusion attention/KV 的 FP8 量化；但 FP8 W8A8 和 AutoRound 在文档矩阵里不是 Ascend 支持项。
  • vLLM-Ascend：安装文档出现 Ascend 950 SOC_VERSION 约定，代码里有 A5 MoE 通信、MXFP 兼容、A5 设备适配和量化类型枚举。这说明 A5 不是只停留在路线图文字里。
  • VeRL-Omni：README 与 NPU quickstart 表明它已支持 Ascend NPU 的多模态 RL 训练编排，且公开宣称 Qwen-Image FlowGRPO 方案相对 diffusers-based flow_grpo 有约 25% 端到端吞吐提升。但这条提升主要来自 vLLM-Omni rollout、FSDP2 和异步 reward 等工程路径，不是 A5 量化收益。
  • 性能与精度损失：公开证据最薄。vLLM-Omni 论文报告的是 disaggregated serving 架构相对 Transformers 的 JCT/RTF 改善，不是量化 ablation。量化文档提供了验证工具、阈值建议和部分模型验证状态，但没有发布完整的 A5 BF16 vs Int8/MXFP8/MXFP4 端到端表格。

所以，如果要在工程上立项，比较稳的表述是：Wan2.2 A14B 在 A5 上尝试 MXFP8 或 MXFP4_dualscale serving 是合理方向；Qwen3-Omni 全链路量化和 VeRL-Omni A5 量化训练仍应先做本地基准。

支持栈分层

vLLM-Omni 论文提出的核心不是某一个 kernel，而是把任意到任意多模态模型拆成 stage graph，再交给不同 engine 执行。这个抽象解释了为什么多模态支持不能只看一个开关：同一个模型可能同时包含 AR language model、DiT、VAE、audio/talker/code2wav 等多个阶段。

vLLM-Omni stage architecture

对 Ascend 950 A5，至少要把证据拆成四层：

  1. 接口层：vLLM-Omni 是否公开了模型、量化模式和 CLI/config。
  2. 后端层：vLLM-Ascend 是否有 A5 的 kernel、dtype、通信和调度路径。
  3. 编排层：VeRL-Omni 是否能把 rollout/training 真正接到该路径上。
  4. 效果层：量化前后是否有同提示词、同分辨率、同 seed、同 batch 的性能与质量对照。

目前前三层都有公开信号，但第四层还明显不足。

vLLM-Omni 边界

vLLM-Omni 的量化总览页把量化分成在线量化、runtime attention quantization 和预量化 checkpoint 三类，并给出硬件矩阵。对 Ascend NPU 相关结论可归纳如下。

量化路径 Ascend NPU 状态 公开模型边界 效果证据
FP8 W8A8 不支持 Qwen3-Omni thinker/AR 可走特定 checkpoint 路径，但不是 A5 通用在线 FP8 文档只说 memory reduction；非 A5 通用结论
Int8 W8A8 支持 Qwen-Image、Z-Image 有 validation；Wan2.2 未验证 缺少 A5 公开性能/质量表
MXFP8 W8A8 支持，文档明确写到 Atlas 950 A5 Wan2.2 T2V/I2V/TI2V 支持 online/offline 文档说明 offline 直接加载 FP8 权重、online 首次加载有转换开销；缺少公开 A5 数字
MXFP4 W4A4 支持，文档明确写到 Atlas 950 A5 Wan2.2 T2V-A14B/I2V-A14B 支持；TI2V-5B 不支持 文档说 TI2V-5B 对 W4A4 过于敏感，精度损失不可接受
msModelSlim 支持，仅 Ascend Wan2.2 recipe；HunyuanImage-3.0 可适配；Qwen3-Omni/TTS 未验证 需要离线量化与本地质量评估
Diffusion FP8 attention/KV 支持，仅 Ascend Wan2.2 测试过，其他 diffusion 模型未测试 文档要求与 BF16 对照质量和延迟
AutoRound W4A16 Ascend 不支持 Qwen2.5-Omni/Qwen3-Omni thinker、FLUX.1-dev、Wan2.2 等 checkpoint 方向 vLLM 博客给出 Intel XPU/NVIDIA 证据，不是 A5 证据

最容易误读的是 Qwen3-Omni。文档把 Qwen3-Omni/Qwen3-TTS 的量化范围限定在 thinker 或 AR language-model 阶段，且依赖 checkpoint 的 quantization_config；audio、vision、talker、TTS、code2wav 等非 AR 阶段默认仍是 BF16。换句话说，Qwen3-Omni 可以局部量化，不等于全链路 A5 量化已验证。

MXFP4 也需要谨慎。mxfp4_dualscale 比单尺度 mxfp4 更偏生产推荐，因为它增加了 per-32 fine scale、per-512 coarse scale 和 per-channel calibrated mul_scale；在线 DualScale 默认还会保留前 5 个 transformer blocks 为 BF16，以守住质量。这个设计本身说明 W4A4 的质量边界并不宽。

vLLM-Ascend 信号

vLLM-Ascend 是 A5 支持能否落地的关键后端层。公开资料里有几类硬证据：

  • 安装层：文档说明在没有 npu-smi 的 CPU-only 构建场景中可设置 SOC_VERSION，其中 Ascend 950 产品使用以 ascend950 开头的值。
  • 量化类型层：QuantType 枚举包含 W8A8、W4A8、MXFP8、W4A16、MXFP4、W4A8MXFP、W8A8FP8、W4A16MXFP4 等类型。
  • A5 运行时层：ascend_forward_context.py 中 MoE 通信选择有 A2/A3/A5 分支；A5 会在 MC2、allgather、alltoall 之间按 token、world size、topK 等条件选择。
  • MXFP 兼容层：mxfp_compat.py 写明动态 MX 量化融合只在 AscendDeviceType.A5 下启用，并在缺少 torch_npu dtype/op 时要求升级 torch_npu 或关闭 MXFP 量化。
  • 设备适配层：device_op.py 中存在 A5DeviceAdaptor，并对 MXFP MoE 量化加了 “only supported on Ascend A5” 的保护。

这些代码证据很有价值，但还不能替代产品化证据。vLLM-Omni 的 NPU 安装页目前主要列出 Atlas A2/A3 Docker 镜像，而不是把 Atlas 950 A5 作为完整安装矩阵单独列出。因此文章里应把 A5 说成 后端路径明确出现，而不是说 端到端交付体验已经完整稳定。

VeRL-Omni 位置

VeRL-Omni 是训练编排层，不是量化 kernel 项目。它的 README 已经把 Ascend NPU 支持写入 quickstart，并把 vLLM-Omni rollout、FSDP2、异步 reward 作为吞吐提升来源。NPU quickstart 里 Qwen-Image OCR FlowGRPO LoRA 训练面向 Atlas 800T A2；install 文档也主要列出 A2/A3 Dockerfile。

代码侧更能说明边界：verl_omni/trainer/config/diffusion/rollout/diffusion_rollout.yaml 里有：

# type of quantization in vllm-omni
quantization: null

这意味着 VeRL-Omni 已经预留了把 vLLM-Omni 量化参数传下去的入口，但默认不是量化运行。公开 examples 里也没有看到 A5 + MXFP8/MXFP4 + RL training 的完整 recipe、吞吐曲线或质量损失记录。

因此对 VeRL-Omni 的准确结论是：它可能成为 A5 量化 rollout 的训练编排入口，但截至 2026-07-07，公开仓库没有给出“VeRL-Omni 在 A5 上量化训练性能提升多少、精度损失多少”的可引用答案。

性能与精度

这里必须把 serving 架构收益和量化收益分开。vLLM-Omni 论文 Figure 6 报告的是 vLLM-Omni 相对 Transformers 在 Qwen2.5-Omni/Qwen3-Omni 上的端到端 serving 效果：论文正文描述 Qwen2.5-Omni 的 RTF/JCT 分别降低 61.4%/61.6%，Qwen3-Omni 的 RTF/JCT 分别降低 90.7%/91.4%。这说明分阶段 serving 架构很强，但它不是 A5 量化实验。

vLLM-Omni Qwen Omni serving evidence

真正关于量化效果，公开资料只能得出几条窄结论：

  • MXFP8/MXFP4 有 A5 文档路径：但缺少公开的 A5 BF16 vs MXFP8/MXFP4 延迟、显存和质量表。
  • W4A4 有明确负例：Wan2.2-TI2V-5B 因模型更小、更敏感，被文档标记为 W4A4 精度损失不可接受，应使用 MXFP8。
  • FP8 attention/KV 是单独问题：它不是权重量化，文档要求自己对 BF16 比较质量和延迟。
  • AutoRound 的性能数字不能迁移到 A5：vLLM 官方博客给出的是 Intel XPU/NVIDIA 侧的 W4A16 证据，例如 Intel XPU B60 上 CFG Parallel 比顺序 BF16 baseline 快 1.55-1.67x；这不能写成 Ascend 950 A5 结论。
  • vLLM-Ascend 测试有点状证据：仓库里存在 Qwen3-VL-8B-Instruct-W8A8 的 MMMU validation 配置，硬件标注为 Atlas A2，acc,none = 0.52；这证明 W8A8 VLM 路径在测试矩阵里出现，但仍不是 A5 多模态生成量化效果表。

如果要在 A5 上给出可信结论，建议最小 benchmark 包含：

  1. 同一模型：Wan2.2 T2V-A14B、Wan2.2 I2V-A14B、Qwen-Image、Z-Image 至少选一个。
  2. 同一输入：固定 prompt、negative prompt、resolution、steps、seed、batch、并发和 tokenizer/image processor 版本。
  3. 同一服务形态：BF16 baseline、Int8 W8A8、MXFP8、MXFP4_dualscale、可选 FP8 attention/KV 分别跑。
  4. 同一指标：JCT、首帧/首 token 延迟、吞吐、峰值显存、avg_generation_time_s、max_peak_memory_mb。
  5. 同一质量评估：PSNR、MAE、cosine similarity、relative L2 只能做像素/张量 smoke test；生成质量还要补语义评测或人工 blind review。

实测清单

可以把 first-pass A5 实测设计成先 serving、后 training：

# BF16 baseline
vllm-omni serve <model> --served-model-name bf16-baseline

# Ascend Int8 W8A8
vllm-omni serve <model> --served-model-name int8-w8a8 --quantization int8

# Ascend MXFP8
vllm-omni serve <model> --served-model-name mxfp8 --quantization mxfp8

# Ascend MXFP4 DualScale, only for documented A14B paths
vllm-omni serve <model> --served-model-name mxfp4 --quantization mxfp4_dualscale

这段命令只表达实验分组，不代表所有模型都能直接用同一参数跑通。实际执行时要对照 vLLM-Omni 对应模型页、量化页和 vLLM-Ascend 版本约束。

VeRL-Omni 侧更建议先不要把 RL 训练作为第一跳。先确认 vLLM-Omni serving 在 A5 上的 BF16/MXFP8/MXFP4 质量与性能，再把稳定组合接回 actor_rollout_ref.rollout.quantization 或等价配置。否则 RL reward 曲线和量化误差会互相污染，很难定位问题来自 rollout 引擎、量化 kernel、采样随机性还是 reward 模型。

我的判断

目前最务实的路径是：

  • 优先尝试 Wan2.2 A14B + MXFP8：支持边界最清楚，W8A8 精度风险比 W4A4 更可控。
  • 谨慎尝试 Wan2.2 A14B + MXFP4_dualscale：文档给出 A5 路径，但要接受部分 BF16 fallback 和质量验证成本。
  • 不要把 Qwen3-Omni 写成全链路量化已成熟：当前公开文档更像 AR/thinker 阶段量化，非 AR 阶段仍有 BF16 边界。
  • 不要宣称 VeRL-Omni 已验证 A5 量化训练收益：它有 NPU 编排入口和 throughput 方向，但公开资料没有 A5 量化 RL 的性能/精度损失数字。

一个可复用的写作规则已经沉淀到 wiki：[[Hardware Support Survey Rule]]。以后再评估某个硬件支持情况时，先把证据分成 packaging、framework、backend、workflow、effect 五层；如果缺的是 effect，就明确写缺失，不用接口或 kernel 的存在替代 benchmark。

参考资料

评论