nvidia/Gemma-4-26B-A4B-NVFP4 昇腾 NPU 适配分析报告

1. 简介

本文档记录 nvidia/Gemma-4-26B-A4B-NVFP4 在 Ascend 910B4 NPU 环境下的适配分析结果。

核心结论：该模型在当前昇腾环境中存在多项根本性技术障碍，无法直接完成适配验证。主要阻塞点为：

1. NVFP4 量化格式不兼容 — NVIDIA 专有格式，Ascend NPU 无解码能力
2. vLLM 版本缺失 gemma4 模型实现 — 当前 vLLM-Ascend 0.18.0 不支持 Gemma-4 架构
3. MoE 基础设施依赖 — Gemma-4 的 MoE 实现需要 vLLM 0.20+ 的 FusedMoE 等模块
4. 单卡显存不足 — 26B MoE 模型即使 BF16 也需要远超 32GB HBM

2. 验证环境

• NPU：1 逻辑卡（Ascend 910B4，32GB HBM）
• CANN：8.5.1

3. 阻塞性技术分析

3.1 NVFP4 量化格式 — 根本阻塞

问题描述：

nvidia/Gemma-4-26B-A4B-NVFP4 使用 NVFP4（NVIDIA 4-bit Floating Point）量化格式。这是一种 NVIDIA Blackwell 架构引入的专有数值格式，具备以下特征：

• W4A4 量化：权重和激活均为 4-bit
• 专有权值缩放：依赖 NVIDIA modelopt 工具链的特定 scale 编码方式
• 硬件依赖：原生推理需要 NVIDIA Blackwell（B200/B300/GB10）或特定 CUDA kernel

Ascend 兼容性：

结论：即使模型架构本身可适配，NVFP4 格式的权重文件在 Ascend NPU 上无法加载和解析。

3.2 vLLM 缺失 gemma4 模型实现 — 根本阻塞

问题描述：

当前安装的 vllm 0.18.0 的模型目录中不存在 gemma4.py：

vllm/model_executor/models/
├── gemma.py      # Gemma (original)
├── gemma2.py     # Gemma 2
├── gemma3.py     # Gemma 3
├── gemma3_mm.py  # Gemma 3 Multimodal
├── gemma3n.py    # Gemma 3n
└── ...
# 无 gemma4.py

vLLM 上游在 v0.20.x 版本中通过 PR #16588 引入 gemma4.py（约 1718 行），实现了 Gemma-4 的 MoE 架构、Dual Attention、Vision Encoder 等模块。

vLLM-Ascend 版本约束：

结论：vLLM-Ascend 当前最新版本（0.18.0rc1）不支持 vLLM 0.20+，因此无法通过简单升级获取 gemma4 支持。

3.3 MoE 基础设施依赖 — 架构阻塞

问题描述：

Gemma-4 采用 Mixture-of-Experts (MoE) 架构，vLLM 中的 gemma4.py 依赖以下 0.20+ 引入的 MoE 基础设施：

from vllm.model_executor.layers.fused_moe import (
    FusedMoE,
    GateLinear,
    fused_moe_make_expert_params_mapping,
)

当前 vLLM 0.18.0 中的 MoE 模块 API 与 0.20+ 存在差异。将 1718 行的 gemma4.py 及其依赖移植到 vLLM 0.18.0：

• 需要重写大量接口适配代码
• 需要验证 vLLM-Ascend 对 MoE 的 attention/communication 路径支持
• 工作量大，成功概率低

3.4 单卡显存不足 — 硬件阻塞

问题描述：

即使忽略上述格式和架构问题，使用 BF16 原始权重（google/gemma-4-26B-A4B-it）在单卡 32GB HBM 上运行也不可行：

结论：当前单卡 32GB HBM 环境无法运行 26B BF16 模型，至少需要 2 卡 Tensor Parallel。

4. 可行路径分析

路径 A：等待 vLLM-Ascend 更新（推荐）

等待 vLLM-Ascend 发布支持 vLLM 0.20+ 的版本，届时：

1. 使用 google/gemma-4-26B-A4B-it BF16 原始权重（非 NVFP4）
2. 在多卡环境（TP≥2）中部署
3. vLLM-Ascend 需验证 MoE 架构的兼容性

预计时间：取决于 vLLM-Ascend 社区迭代节奏

路径 B：使用 transformers + torch_npu（绕过 vLLM）

不通过 vLLM，直接使用 transformers 库加载 Gemma-4：

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained(
    "google/gemma-4-26B-A4B-it",
    torch_dtype=torch.bfloat16,
    device_map="auto",  # 自动分配到 NPU
)

限制：

• transformers 对 Gemma-4 MoE 的支持需验证（transformers 4.57.6 可能已支持）
• 推理性能远低于 vLLM（无 PagedAttention、无 continuous batching）
• 仍需 BF16 权重，单卡 32GB 仍不足
• NVFP4 格式仍然不支持

路径 C：手动移植 gemma4 到 vLLM 0.18.0（高风险）

将 vLLM 0.20+ 的 gemma4.py 和 MoE 基础设施反向移植到 vLLM 0.18.0：

• 工作量：极大（1718 行核心代码 + 依赖模块）
• 风险：vLLM-Ascend 0.18.0 的 MoE/communication 路径可能不兼容
• 维护成本：高，后续 vLLM-Ascend 更新可能破坏移植代码

不建议在当前项目中采用此路径。

5. 验证结果汇总

6. 推荐替代模型

若需在昇腾 NPU 上运行类似的文本生成模型，建议考虑以下已验证兼容的替代方案：

Gemma-2 和 Gemma-3 系列为 Dense 架构（非 MoE），在当前 vLLM-Ascend 0.18.0 环境中可直接运行。

7. 参考资源

• nvidia/Gemma-4-26B-A4B-NVFP4 on HuggingFace
• google/gemma-4-26B-A4B-it on HuggingFace
• vLLM Gemma 4 Recipes
• vLLM PR #16588 — Add Gemma-4 multimodal support
• vLLM-Ascend 官方文档
• 昇腾 MoE 适配指南

报告生成日期: 2026-05-12 适配文档版本: v1.0.0 分析工具: vLLM 0.18.0, vLLM-Ascend 0.18.0rc1, transformers 4.57.6 GitCode 仓库: https://gitcode.com/wilyw/Gemma-4-26B-A4B-NVFP4