解构非 GPU 算力平台的大模型推理之困：华为昇腾 910 承载 MoE 与多模态服务的现场研究

m0_52144241

14人浏览 · 2026-08-14 15:01:37

m0_52144241 · 2026-08-14 15:01:37 发布

解构非 GPU 算力平台的大模型推理之困：华为昇腾 910 承载 MoE 与多模态服务的现场研究

香港中文大学发布研究报告探讨了在华为昇腾（Huawei Ascend） 平台上部署大型混合专家模型（MoE） 和多模态模型 推理任务的实际挑战。尽管该平台可作为传统GPU的替代方案，但研究指出其软件栈成熟度不足，在运行复杂工作负载时存在算子覆盖缺失、并行机制脆弱以及低层内核故障等显著局限。作者记录了为了维持系统正常运行而必须进行的源码级修补与功能限制，并详细分析了硬件在大规模推理中的性能瓶颈。报告最终总结了一系列软硬件优化策略和外部监控手段，为希望从CUDA生态迁移到国产AI加速器的团队提供了实战参考。通过对端到端基准测试的量化分析，研究证明了在克服工程障碍后，昇腾平台能够正确执行高难度的AI服务任务。

一、核心观点

迁移并非简单的“重新编译”（Not just a recompile）
大模型（特别是 MoE 和多模态模型）从成熟的 CUDA 生态迁移到非 GPU AI 加速器（如昇腾 910）时，工程迁移成本极其高昂。即使硬件的互联带宽和显存规格足够，也无法实现“即插即用”。
总拥有成本（TCO）向“工程人力”倾斜
采用非 GPU 加速器的实际成本，不再主要由硬件采购决定，而是由后期的源码级补丁编写、多维并行重构、性能妥协和外部高可靠运维等工程开发代价主导。
“特性组合”是故障发生的重灾区
许多特性（如 MoE、流水线并行、多模态）在供应商的单一测试用例中是可行的，但当多种高级特性组合在复杂生产场景下相交时（如流水线并行 > 1 × 多模态 × MoE），代码覆盖率的缺失会直接暴露，引发系统崩溃或静默数据损坏（SDC）。
主动采取“降级防御”与“外部容错”
为确保推理结果的数值正确性，必须采取主动妥协的姿态（如关闭部分高性能特性，偏向安全的 Eager 执行模式），并使用外部监控/看门狗机制来吸收间歇性抛出的低级硬件故障。
必须引入基于 CUDA/CPU 参照物的“差分测试”
由于移植过程中常常遇到模型输出静默损坏（不报错，但模型推理出的文本或逻辑退化），团队必须通过层对层（layer-by-layer）对比激活值等“差分测试”（Differential Testing）手段来确保算子的数值对齐。

二、核心挑战

根据源文献的现场研究（Field Study），在昇腾 910 NPU 上使用 CANN 软件栈和 vLLM-Ascend 推理引擎部署大型 MoE 模型（如 DeepSeek-V4-Flash）时，面临以下八个核心挑战：

1. 软件栈成熟度不足与算子/特性覆盖缺失（Software-Stack Maturity & Operator Gaps）

初始化与运行崩溃：模型在部署初期经常遭遇各种硬崩溃，研究团队在启动时必须对供应商的推理插件进行 12 处源码级的补丁修改 才能使服务进入可用状态。
多特性组合覆盖极差：虽然单个特性（如 MoE 路由或多模态）可能在特定独立用例中可行，但在处理多种特性交叉（例如：流水线并行 PP > 1 × 多模态 × MoE 稀疏注意力变体）的复杂生产场景时，由于测试覆盖不全，平台经常发生硬崩溃，且缺乏优雅的降级或回退机制。

2. 多维并行机制脆弱（Fragile Multi-Axis Parallelism）

张量并行（TP）受硬上限限制：受注意力头分组因子的物理限制，张量并行度被硬性限制在 TP = 8。若要在 16 卡系统上部署大型模型，必须引入第二并行轴（如多模态模型采用 TP = 8 × PP = 2，量化模型采用 TP = 8 × DP = 2），这导致未经测试的代码路径呈指数级增加。
高性能特性不得不禁用：为了确保输出结果的数值正确性，必须主动关闭序列并行（Sequence Parallelism / FlashComm 路径）和融合 MC2 专家路由（fused MC2 expert routing）。
流水线并行（PP）数据损坏：在 PP > 1 的情况下，多头状态在层与层之间的隐藏流和残差流传输时，其维度在各 rank 上被错误折叠又重新展开，导致 per-head 状态发生退化，从而在不报错的情况下静默损坏模型输出。

3. 算子层面的数值与稳定性故障（Kernel-Level Numerical & Stability Faults）

间歇性低级硬件异常：在持续负载（sustained load）下，NPU 会间歇性抛出 aicore 异常（错误码 507015） 和 vector core 异常（错误码 507035） 并直接杀死工作进程。这些错误通常指向 MTE（内存传输引擎）的内存寻址越界（DDR 地址越界）。
极难定位调试：这些错误发生在已编译的算子内部，且仅提供不透明的硬件错误码和寄存器转储（register dumps），在应用层或推理引擎层几乎完全无法调试，只能通过外部看门狗强制重启进行恢复。

4. 图编译技术不成熟（Immature Graph Compilation）

全图捕获风险高：平台不支持 TorchInductor 等 JIT 内核编译器，仅能使用 ACL 图模式。且在使用全解码图捕获（full-decode graph capture）时，引擎会频繁发出实验性阶段警告，称捕获过多的 Batch Size 会直接导致 OOM（显存溢出）或推理挂起（hang）。
被迫退回 Eager 模式：由于图模式的不稳定性，用户在部署多模态 MoE 等复杂架构时往往被迫退回到性能更低但更安全、更稳定的迫切执行模式（Eager Mode）。

5. 高级推理特性缺失与不稳定（Advanced-Feature Gaps）

投机解码不可用：多Token预测（MTP）等在 CUDA 生态中非常成熟的投机解码加速技术，在昇腾平台上极不稳定。其不仅在不同软件版本间频繁改名、变动接口，甚至投机量化参数也会被系统默默覆盖。
牺牲性能换稳定性：结合算子层面的间歇性故障，最安全的部署姿态通常是彻底关闭投机解码，被迫用吞吐量的下降来换取系统整体可靠性。

6. 性能与扩展性瓶颈（Performance & Scalability Ceilings）

并发吞吐量非单调特征：系统在极低的并发度下即达到吞吐峰值。测试表明，量化 MoE 服务的最佳并发“甜蜜点”仅为 4 个活跃的流（in-flight streams）。一旦并发度增加到 6 或更高，等待队列会瞬间过载，系统开销剧增，导致整体（aggregate）吞吐量不升反降，且单路流的响应时间严重恶化。
极其漫长的启动时间：由于需要进行 AOT（提前）算子编译、权重加载以及 KV 缓存的量化操作，冷启动通常长达数分钟，极大地影响了弹性扩缩容效率。

7. 运维可靠性与可观测性弱（Operational Reliability & Observability）

缺乏弹性保护：系统缺乏精细的多层异常捕获和弹性容错机制，任何 kernel 级或网络层面的偶发抖动都会导致服务彻底挂掉，必须依赖外围看门狗进行每 30 秒的健康检查和自动冷启动恢复。
日志诊断困难：诸如进程挂起或长时间编译时，引擎只会重复输出“未找到共享内存广播块（No available shared memory broadcast block）”等含糊日志，难以进行精细化告警或故障工作流溯源。

8. 生态碎片化与高昂的迁移税（Ecosystem Fragmentation & Portability Tax）

严重依赖复杂配置：昇腾推理完全依赖一套由特定环境参数（如 ACL_OP_INIT_MODE, VLLM_ASCEND_ENABLE_*, HCCL_BUFFSIZE）、供应商专有分支（vLLM-Ascend）和启动打补丁脚本组成的精细平衡。
版本更新迁移成本极高：由于昇腾插件是一个与上游 vLLM 分离且快速分叉的年轻分支，每一次微小的引擎版本升级，都会带来高昂的重新调试、打补丁和数值对齐的“迁移税”。

三、关键数据

1. 硬件配置与实验负载

硬件设备：单节点内包含 16 张华为昇腾 910 NPU，运行 CANN 软件栈与 vLLM-Ascend 推理引擎。
工作负载 A（LLM-as-a-judge 评估服务）：
- 模型与精度：DeepSeek-V4-Flash，采用 W8A8 量化，模型体积约 ~300 GB。
- 部署架构：张量并行 TP = 8 × 数据并行 DP = 2，采用专家并行。
- 负载规模：自动评估并对 20 个前沿大模型的回复进行打分，处理了数万个提示词。
工作负载 B（多模态医学 VLM）：
- 模型与精度：DeepSeek-V4-Flash-Vision（由 Qwen3.5 视觉塔与 DeepSeek-V4-Flash 解码器融合），采用 bf16 精度，体积约 ~540 GB。
- 部署架构：由于注意力头分组限制，张量并行被硬锁在 TP = 8，迫使引入 TP = 8 × 流水线并行 PP = 2 的双轴并行。
- 显存分配：在 64 GB 单卡显存中，解码器分片占约 34 GB，复制的视觉塔占 2 GB，工作显存预算为 ~59 GB（0.92 比例），剩余用于激活值和 KV 缓存。

2. 工程集成代价与缺陷修复

源码级补丁：为了使模型在昇腾平台上成功初始化并正确推理，研究团队在启动阶段对供应商的 vLLM 插件应用了 12 处源码级修补（Patches）。
- 这些修补分布在 4 个核心源文件中：model_runner_v1.py 占 7 处，deepseek_v4.py 占 3 处，dsa_v1.py 与 models/__init__.py 各占 1 处。

3. 推理性能与扩展瓶颈

并发甜蜜点：在量化 MoE 评测中，系统的最佳并发（Concurrency）仅为 4 个在活跃状态的流（in-flight streams）。
吞吐量崩溃：当并发数达到 6 或更高时，等待队列严重饱和，整体吞吐量开始下滑。此时，单路流的吞吐量从最佳状态的 900 req/h 暴跌 5 倍至 180 req/h。
数值基准对齐：通过多维调优，该模型在 MMMU-Pro 达到 48.0% 的准确率，在 MMMU 验证集达到 57.8%（强制直接回答协议下），对齐并部分超越了原生框架参考，验证了修复补丁在数值上的完全正确性。
底层硬件故障：系统在持续负载下频繁抛出 CANN 内部错误码 507015（aicore 异常） 与 507035（vector core 异常），皆因为底层内存移动引擎（MTE）地址越界所致，需要依赖外部看门狗每 30 秒 进行一次自动冷重启恢复。

核心结论：昇腾 NPU 硬件本身在卡间互联和显存容量上足以支撑千亿级大型 MoE 模型，但软件栈成熟度不足、多维并行冲突、低并发天花板以及偶发性的算子级硬件异常，构成了阻碍其即插即用（plug-and-play）的核心技术挑战。在部署大型 MoE 模型时，企业必须建立“容错优先、低并发运行、外部看门狗守护”的架构，并将长期的工程调优和运维集成时间作为迁移决策的关键考量。

https://arxiv.org/abs/2607.08215