昇腾 950 NPU 架构深度解析

基于华为《昇腾950 NPU 架构白皮书》（2026 年 7 月）的技术分析。

TL;DR

• 昇腾 950 是华为第三代 DaVinci 架构，核心变化是 Cube/Vector 核分离 + 全精度体系（MXFP4 / HiF8 / FP8 / BF16 / TF32）。
• 真正的差异化不在单卡峰值算力（仍落后 B200），而在 联算比（互联带宽/算力）与 8192 卡原生超节点规模——押注“瓶颈在通信与内存，不在计算”。
• 自研 HiF8 锥形精度是最具原创性的点，但价值兑现取决于框架生态。
• 一套 灵衢 UB 协议 统一 Die 内到机架间通信，是系统级的核心创新。

一、这颗芯片想解决什么问题

理解昇腾 950 的设计逻辑之前，需要先看清驱动它的三股力量。

通信模式的迁移

白皮书引用了一组关键数据：LLM 大模型预训练和后训练中，单次芯片间通信数据量达到数十 MB，一次迭代的总通信量相比小模型提升近百倍，达到数百 GB。

这不是简单的"模型变大了"能解释的。它背后是架构的结构性变化——Mixture-of-Experts（MoE）的普及和序列并行（Sequence Parallelism）的采用，使得通信模式从以 All-Reduce 为主转向 All-to-All 为主。All-Reduce 的通信量与模型参数量成正比（约 2× 参数量 per step），而 MoE 的 All-to-All 通信量与 token 数和 expert 容量有关，不受模型规模线性约束。当 expert 数从 8 增长到 128 甚至更多时，All-to-All 的通信量会超过 All-Reduce，成为系统瓶颈。

KV Cache 的指数增长

AI Agent 场景引入了超长上下文、多轮交互和长时任务规划，KV Cache 存储需求随之指数级增长。白皮书明确指出"单靠 AI 芯片内存存储已无法支撑业务的快速发展"——这解释了为什么昇腾 950DT 配备了 144GB 片上内存，以及在超节点层面构建统一内存池的动机。

算存比的分化

多模态生成（如文生图、文生视频）和多模态理解（如视觉问答）的算存比相差巨大。前者是 compute-intensive，后者是 memory-intensive。单一硬件配置无法在两个场景同时达到最佳性价比——这是 950PR 和 950DT 双产品线分化的直接原因。

  graph TD
    A["通信爆炸<br/>All-to-All 数百GB/迭代"] --> D["互联重构<br/>灵衢 2.0"]
    B["KV Cache 内存墙<br/>Agent 场景指数增长"] --> E["内存扩容<br/>144GB + 4TB/s + 超节点内存池"]
    C["多模态算存比分叉<br/>训练 vs 推理需求分化"] --> F["产品线分化<br/>950PR vs 950DT"]
    D --> G[昇腾 950 架构]
    E --> G
    F --> G

二、代际跃进：从 910B 到 950

将昇腾 950 放入昇腾系列的发展脉络中，能看到更清晰的架构演变逻辑。

三代演进概览

注：950 列为白皮书官方规格；910B/910C 为公开渠道估算，非华为官方确认（910C 尤其存在较大分歧），仅用于代际对照。

关键分析

算力演进:910C 的 752 TFLOPS FP16 看起来比 950PR 的 486 TFLOPS BF16 更高,但这掩盖了关键差异–910C（据公开拆解为双 Die 合封的两颗 910B），而 950PR 的 486 TFLOPS 是在引入 FP4/FP8 低精度支持的前提下,单 AI Die 的同代演化。950 真正的算力优势体现在低精度上:MXFP4 模式下达到 1,784 TFLOPS(950PR),这是 910C 完全不支持的精度域。

从 HCCS 到灵衢：910B/C 使用的 HCCS 互联带宽为 392 GB/s（8 卡），而灵衢 UB 2.0 的单芯片对外带宽达到 2,016 GB/s 双向——约 5 倍提升。更关键的是协议层面的变化：HCCS 是一个纯粹的芯片间互联协议，而灵衢是一套涵盖 D2D、芯片间、机架间的统一协议栈，支持同步 Load/Store（UB Memory）、异步拷贝（URMA）和以太网原生通信（UBoE）三种语义。

内存架构的质变：910B 的内存带宽仅为 ~400 GB/s，910C 提升到约 1,800 GB/s，而 950DT 达到 4 TB/s。但更重要的是架构层面的变化——910B/C 使用标准 HBM2e/HBM3e，而 950 白皮书使用"高速片上内存"这一术语，暗示了不同的封装或内存接口方案。配合 128MB 的全局 L2 Cache（910B/C 无同等级缓存），构成了一个完全不同的内存层次设计。

第三代 DaVinci 的新能力：910B/C 基于第二代 DaVinci 架构，Cube 和 Vector Core 是集成在一个 AI Core 内的。950 的第三代 DaVinci 将 Cube 和 Vector Core 分离（称为 AIC 和 AIV），各自独立演进——Cube Core 获得了 FP8/HiF8/MXFP4 低精度支持，Vector Core 从传统 SIMD 升级为双发射 Register-Based 新架构，并引入了 SIMD/SIMT 混合编程、NDDMA 和 BufferID 同步等 910B/C 不具备的能力。这些变化的细节将在下一章展开。

一句话总结：910C（据公开拆解）是 910B 的“拼两个 Die”（量变），昇腾 950 是整个架构的代际迭代（质变）。

三、架构全景：Chiplet 与产品矩阵

3.1 四 Die 合封的 UMA

昇腾 950 采用多 Die 合封方案，整芯片集成 2 个 AI Die、2 个 IO Die 和 4 个（950DT）或 8 个（950PR）高速片上内存模块，通过 D2D Clink 和 Memory Interface 构成统一内存访问（UMA）整体。

  graph TB
    subgraph Chiplet["昇腾950 Chiplet"]
        subgraph AI_Die0["AI Die 0"]
            AI0["18 × DaVinci Core (1 Cube + 2 Vector)"]
            CPU0["2 × Linx816 Cluster + 4MB L3"]
            L2_0["L2 Cache 分区 64MB"]
        end
        subgraph AI_Die1["AI Die 1"]
            AI1["18 × DaVinci Core (1 Cube + 2 Vector)"]
            CPU1["2 × Linx816 Cluster + 4MB L3"]
            L2_1["L2 Cache 分区 64MB"]
        end
        subgraph IO_Die0["IO Die 0"]
            UB0["9 × X4 HiLink Port"]
            STARS["STARS 2.0 调度器"]
        end
        subgraph IO_Die1["IO Die 1"]
            UB1["9 × X4 HiLink Port"]
            CCU["CCU 集合通信引擎"]
        end
        MEM["片上内存<br/>950PR: 128GB/1.6TB/s<br/>950DT: 144GB/4TB/s"]
    end
    AI_Die0 <-->|"D2D Clink<br/>硬件一致性"| AI_Die1
    AI_Die0 --> IO_Die0
    AI_Die1 --> IO_Die1
    AI_Die0 <-.->|"Memory IF"| MEM
    AI_Die1 <-.->|"Memory IF"| MEM

注：图中 STARS 2.0 与 CCU 分属哪个 IO Die 为推断（白皮书未明确两者的 Die 归属），但二者均位于 IO Die 内、与计算 Die 解耦这一关系是确定的。

两个 AI Die 共享同一个物理地址空间，跨 Die 的 L2 Cache 一致性由硬件维护，软件完全无感知。IO Die 独立的设计意味着通信流量和计算流量在物理上分离——这在传统单 Die 设计中是无法做到的。

3.2 950PR 与 950DT 的定位逻辑

DT 的内存带宽是 PR 的 2.5 倍。这不是随意的差异化——LLM Decode 阶段是典型的 memory-bound 工作负载，token 生成速度受限于 KV Cache 的读取带宽而非矩阵乘法速度。PR 的 1.6TB/s 在 Prefill（compute-bound）和推荐（compute-bound embedding lookup）场景中已经足够。

3.3 Binning 策略

白皮书披露了多 SKU 的 binning 方案，这是成熟芯片厂商的标准做法：

• 950DT：36/32/28 Cube Core（三种 SKU）
• 950PR：32/28 Cube Core（两种 SKU）
• 内存：PR 可选 128/112 GB，DT 可选 144/96 GB

通过精细的冗余设计，一次流片覆盖从旗舰到入门的多档产品。这不仅提升了良率（缺陷 Core 可以被 bin out），还大幅扩展了可服务市场。

四、第三代 DaVinci Core：计算引擎的拆解

第三代 DaVinci Core 相比 910B/C 的二代 DaVinci 有两项根本性的架构变更：Cube 和 Vector Core 的分离（AIC/AIV 分立），以及低精度格式体系的全面引入。

4.1 Cube Core：精度阶梯

第三代 Cube Core 构建了完整的精度体系：

每一级精度对应一种算力-精度权衡。精度降低一级，理论吞吐翻倍，但模型能否接受这种精度损失取决于具体任务和数值分布。昇腾 950 同时支持 HiF8、MXFP8、FP8 三种 8 位格式，覆盖了从保守（FP8 E4M3）到定制（HiF8）到标准化（MXFP8）的多种量化策略，这一点上选择面比 910B/C（仅支持 FP16/BF16/INT8）宽得多。

微架构层面值得关注的变化还包括：L0C Buffer 从上一代升级至 256KB，更大的 Tiling 空间提升数据复用率；L0C→Unified Buffer 回写路径上的随路量化（FP32→BF16/FP8）不额外占用带宽和 Buffer 空间。

4.2 HiF8：锥形精度的工程选择

HiF8 是这份白皮书中最具原创性的技术点。它不是 FP8 的参数变体，而是重新设计了 8-bit 浮点的编码逻辑。

目标：在 8 比特约束下同时满足三个条件——接近 FP16 的动态范围、不需要 MXFP8 的额外缩放因子、适应神经网络中间值的锥形分布特征（均值附近数值密集、远离均值逐渐稀疏）。

实现通过三个递进的设计决策完成：

1. 用变长前缀码编码点位域 Dot，前端 bit 决定后端 bit 的语义，而非固定分配。这意味着阶码和尾数的位宽可以在不同数值范围内动态调整。
2. 阶码采用原码编码并隐藏 1 比特固定值。关键性质是不同位宽的阶码表达范围不重复——即无冗余编码，所有 256 个编码值都有唯一的数值含义。
3. 通过特殊的 Subnormal 设计将综合阶码范围从 [-15, 15] 扩展到 [-22, 15]，共 38 个 powers of 2。

  graph LR
    subgraph FP8["FP8 E4M3"]
        S1["S 1b"] --> E1["E 4b 固定"] --> M1["M 3b 固定"]
    end
    subgraph HiF8Chart["HiF8"]
        S2["S 1b"] --> Dot["Dot 变长前缀码"] --> E2["E 可变长"] --> M2["M 可变长"]
    end
    FP8 --> HiF8Chart

HiF8 的特殊值编码：

不区分正负 0 是一个务实的工程选择——神经网络计算中两者的区别没有实际意义，节省一个编码值用于更大的表示范围才是正确的取舍。HiF8 作为华为独占格式，其实际价值的兑现速度取决于 PyTorch/TensorFlow 等框架的原生支持进度。

4.3 Vector Core：为什么要 SIMD 为主

第三代 Vector Core 的升级幅度不亚于 Cube Core：单核 FP16/FP32 算力翻倍，从传统 SIMD 升级为双发射 Register-Based SIMD，引入 SIMD/SIMT 混合编程模式。

核心问题是：为什么选择 SIMD 为主、SIMT 为辅，而非像 GPU 那样走纯 SIMT 路线？

NPU 的主要负载（95%+）是规则矩阵和向量运算，SIMD 在这些场景下有无法超越的能效优势。但对于推荐系统中的 Embedding Gather 和 Hash 操作，纯 SIMD 编程极为困难——因此引入 SIMT 作为补充。混合编程的基本单位是 Vector Function（VF），每个 VF 独立选择 SIMD 或 SIMT 模式，不同类型 VF 之间可快速切换。

4.4 Cube-Vector 融合：FlashAttention 的加速路径

白皮书披露 FlashAttention 单核算力较上一代提升 1.5 到 2 倍，背后是三条协同优化：

  sequenceDiagram
    participant L2 as L2 Cache
    participant L1 as Cube L1 Buffer
    participant CUBE as Cube Core (MatMul)
    participant VEC as Vector Core (Softmax/GELU)
    participant UB as Unified Buffer

    Note over CUBE,VEC: ① CV 直通：Cube L1 ↔ Vector UB 不经 L2
    CUBE-->>VEC: 中间矩阵直传 + 随路精度/排布转换
    Note over VEC: ② Softmax 微架构优化：减少数据相关气泡
    VEC-->>CUBE: 结果回传
    Note over L1,UB: ③ 随路量化：回写时 FP32→BF16/FP8
    L1-->>UB: 量化回写不额外占带宽

三条优化各有侧重：CV 直通解决 FlashAttention 最核心的开销——中间矩阵（S = Q×K^T）在 Cube 和 Vector 之间的来回搬运；Softmax 微架构优化解决之前流水线中的计算瓶颈站；随路量化降低中间结果对 UB 空间的占用。

4.5 NDDMA 与 BufferID

NDDMA 将数据搬移、排布转换和地址生成融合为一条指令：支持最多 5 维重排（覆盖 NCHW/NHWC/NDHWC 等全部主流排布），地址生成硬件化（软件配置参数即可），内置缓存将元素粒度的多次读取聚合成 128 字节的 burst 访问。对开发者而言，一条指令替代了此前需要多行代码完成的"搬移 + reshape + transpose"组合操作。

BufferID 同步是另一个值得注意的硬件创新。它直接借鉴了软件工程中互斥锁的模式——get_buf() 对应加锁（获取缓冲区使用权），rel_buf() 对应解锁（释放缓冲区）。相比传统的 set_flag/wait_flag 同步（需要在不同流水线之间维护显式的标志位依赖图），BufferID 将同步语义绑定到缓冲区本身，不同流水线自然解耦。这本质上是把"管道内（intra-pipeline）同步"和"管道间（inter-pipeline）同步"做了正交化。

五、存储体系：三道防线

5.1 内存层次

  graph TB
    subgraph Core["单 AI Core 内部"]
        L0["L0A/L0B: 64KB each<br/>~0 cycle"] --> L1B["L1 Buffer: 512KB<br/>~10 cycles"] --> UB["Unified Buffer: 512KB<br/>~20 cycles"]
    end
    subgraph Die["Die 级"]
        L2["L2 Cache: 128MB (2 Die, UMA)<br/>~100 cycles"]
    end
    subgraph Chip["芯片级"]
        HBM["片上内存<br/>950PR: 128GB/1.6TB/s<br/>950DT: 144GB/4TB/s<br/>~500 cycles"]
    end
    subgraph System["系统级 (UB Memory)"]
        EXT["CPU 内存池 最大 128TB<br/>~μs 级延迟"]
    end
    L0 --> L1B --> UB --> L2 --> HBM --> EXT

5.2 L2 Cache：容量与策略并重

128MB L2 Cache 是 910B/C 所没有的缓存层级。这个容量足以容纳典型 7B 参数 Transformer 模型的单层中间激活值（BF16 下约 8-32MB）。

Sector Cache 的设计将 512B Cache Line 细分为 4 个 128B Sector，在离散小包和随机访存场景下可将性能提升 2 倍以上——典型受益场景是稀疏特征查找（推荐系统）和 Gather 操作。同带宽条件下这个提升来自更好的 Cache 利用率：避免了"读 128B 但带回 512B"的空间浪费。

Cache Hint 策略允许软件标记数据的分配策略——一个典型用法是：Task0 的输出 data_B 是 Task1 的输入（标记为 allocate，保留在 Cache 中），而 data_A 后续不再使用（标记为 non-allocate，直接写回 Global Memory 而不驱逐有用数据）。在 GEMM 流水线中，这种精细控制可能带来数十个百分点的 Cache 命中率差异。

CMO（Cache Maintenance Operation）通过 SDMA 实现 Prefetch、Writeback、Invalid 和 Flush 四种操作，程序员可以精确控制数据在 Cache 中的生命周期和时机。

5.3 4TB/s 的算力-带宽匹配

950DT 的 4TB/s 是否过度设计？关键不在峰值算力，而在 Decode 阶段的访存特征——LLM 逐 token 生成时是典型的 memory-bound，token 吞吐由 KV Cache 的读取带宽决定，而非矩阵乘法速度。

以大 batch、长序列 Decode 为例:
batch=128, seq_len=8K, num_heads=32, head_dim=128
KV Cache ≈ 2 × 128 × 8192 × 32 × 128 × 2 bytes ≈ 16 GB
以 50 tokens/s 速度生成时 KV 读取 ≈ 16GB × 50 ≈ 0.8 TB/s

在更大规模下（seq_len=128K, batch=256），KV Cache 读取可轻松超过 2 TB/s，
叠加 Attention 中间矩阵、激活值交换等开销，总带宽需求落在 3~5 TB/s 区间。

4TB/s 大致匹配了大 batch、长序列 Decode 的边界需求。对于 950PR 的 1.6TB/s，在 Prefill 为主（compute-bound，靠 Cube 分块复用数据，对带宽需求低）和推荐（Embedding Lookup 在几百 GB/s 就够用）的场景中已经充分。

注：不能从「峰值 FLOPS × bytes/op」反推带宽需求——GEMM 是 compute-bound，通过分块复用使字节/算子比值趋近于零，峰值算力并不构成 HBM 带宽的硬性约束；真正的带宽压力来自 memory-bound 的 Decode 访存。

5.4 RAS

白皮书描述了片上内存的 RAS 特性：Online ECC、巡检（Scrubbing）和行失效透明隔离。在大规模集群中，这些特性比峰值算力更重要——128K 卡集群即使单卡内存故障率为 0.01%/年，每周也约有 2-3 张卡发生内存故障。没有透明故障隔离，集群有效利用率会随规模增长而急剧下降。

六、灵衢 2.0：统一互联协议的架构意义

灵衢 2.0 是昇腾 950 区别于竞品的核心系统级创新。其架构哲学可以用一句话概括：用一套协议栈覆盖从 Die 内到跨机架的全部通信场景。

传统方案中，Die 内用 NoC，芯片间用 NVLink/Infinity Fabric，跨机架用 InfiniBand/RoCE——三套协议、三种地址空间、三种编程模型。灵衢的做法是统一为一个 UB 协议栈。

6.1 协议栈全景

  graph TB
    subgraph API["编程接口"]
        SYNC["同步语义<br/>UB Memory<br/>Load / Store / Atomic"]
        ASYNC["异步语义<br/>URMA<br/>Write / Read / Send / Atomic"]
        COLL["集合通信<br/>CCU<br/>AllReduce / AllGather / ..."]
    end
    subgraph Transport["传输层"]
        RTP["RTP (可靠模式)<br/>端到端重传 / 多路径<br/>最大 4 Port<br/>用于权重同步"]
        CTP["CTP (轻量模式)<br/>无端到端重传<br/>最大 9 Port<br/>用于数据搬运"]
    end
    subgraph Link["链路层"]
        HL["HiLink SerDes<br/>72 Lane × 112Gbps<br/>18 × X4 Port"]
    end
    subgraph PHY["物理层"]
        UB_PHY["UB 原生: D2D / Inter-Chip<br/>2,016 GB/s 双向"]
        UBoE_PHY["UBoE: 2×400Gbps<br/>接以太网交换机"]
        PCIe_PHY["PCIe 5.0: ×16<br/>128 GB/s 双向"]
    end
    SYNC --> RTP
    ASYNC --> RTP
    ASYNC --> CTP
    COLL --> RTP
    RTP --> HL
    CTP --> HL
    HL --> UB_PHY
    HL --> UBoE_PHY
    HL --> PCIe_PHY

6.2 URMA 的双模式选择

URMA 提供了 RTP（可靠传输）和 CTP（轻量传输）两种模式，分别对应不同的取舍：

不强制所有流量走可靠性路径是一个务实的架构决策。训练中有大量数据搬运（读 batch、交换中间激活）不需要端到端可靠传输——丢失的数据可以在上层协议或重计算中恢复。只有关键的模型同步和梯度汇聚才走 RTP 路径。

6.3 CCU 的定位

CCU 通过 Mission 编程接口接收集合通信任务，内置 MemorySlice（数据暂存）和 Reduce Unit（计算单元）构成微型处理流水线。支持的集合通信原语覆盖 Broadcast、Reduce Scatter、All Gather、All Reduce、All2All 和 All2Allv。

核心价值不是"能做 AllReduce"，而是两个"释放"：释放 AI Core 算力（通信任务不占用计算资源），释放系统总线带宽（CCU 直接通过 UB 端口通信，不走 NoC）。

6.4 UBoE 与 On Chip Switch

UBoE 将 UB 协议栈直接承载在以太网物理层上，使超节点可以通过标准以太网交换机扩展。Port Bifurcation（1×400G → 2×200G → 4×100G）提供了网络拓扑粒度上的灵活性。

On Chip Switch 让 IO Die 内的 9 个 X4 Port 之间可以转发流量，转发路径不经过计算 Die、不占用 DRAM 带宽。这意味着昇腾 950 芯片可以在 Clos 组网中充当中间路由节点，使拓扑更加灵活。

七、超节点：从芯片到集群的推演

7.1 规模跃升

超节点规模从上一代的 384 卡跃升至 8,192 卡（21 倍增长），整集群可超过 128K 卡。这个规模的提升不是简单增加交换机能实现的，而需要整套协议栈（URMA 可靠传输、CCU 通信卸载、On Chip Switch 灵活路由）的协同支撑。

支持三种组网拓扑：Clos、Full Mesh+Clos 混合、nD-Mesh。

7.2 三种资源池化

  graph TB
    subgraph SuperNode["昇腾 超节点 (8,192 卡)"]
        CHIP["8,192 × 昇腾 950"]
        UBS["UB Switch"]
        ETH_WORLD["以太网世界"]
    end
    CHIP <-->|"UB 原生"| UBS
    UBS -->|"UB→Eth 转换"| ETH_WORLD
    CHIP -->|"UBoE 直连"| ETH_WORLD

    subgraph Pool["资源池化"]
        MEM_POOL["CPU 内存池<br/>UB 直访 CPU 内存<br/>解决 KV Cache 溢出"]
        STORAGE_POOL["存储池<br/>UB 直访存储<br/>跳过协议转换开销"]
    end
    CHIP <-->|"UB Memory"| MEM_POOL
    CHIP <-->|"UB"| STORAGE_POOL

CPU 内存池解决 Agent 场景超长上下文的 KV Cache 溢出问题；存储池解决训练数据的直接加载路径；以太网互通降低超节点与已有数据中心的集成成本。

八、调度与通用计算

8.1 STARS 2.0

STARS 2.0 的关键升级是调度延迟和隔离性。通过专用的 HSCB（高速控制总线）与硬件交互，调度延迟降至 ns 级。HSCB 物理上独立于 NoC，不受数据流量干扰，这对大规模集群的集合通信同步至关重要。

Group 调度支持将 AI Core 按 Die 分成最多 8 个 Group，算子可以做亲和性调度来利用 L2 Cache 的局部性。资源池支持最多 16 个 AIC/AIV/SDMA 资源池，每个虚拟机绑定独立的计算和 IO 资源，实现多租户隔离。

8.2 AI CPU：Linx816

4 个 CPU Cluster，每 Cluster 含 2 个自研 ARMv8-A 核心 + 4MB L3 Cache，每个核心支持物理双线程。定位清晰：不是独立的通用计算引擎，而是 NPU 侧的"管家"——运行操作系统、做算子编译、处理性能监控和页表管理。与 NVIDIA Grace（72 核 Neoverse V2）不同，Linx816 不需要在通用计算上竞争，其唯一的任务是让 NPU 侧的计算流水线不依赖 Host CPU。

与 910B 相比，910B 使用的也是自研 CPU 核心，但白皮书未提及其规模和 Cache 层级，950 的 Linx816 配备了明确的多级 Cache（L1 64KB/Core, L2 1MB/Core, L3 4MB/Cluster）并支持全局缓存一致性。

九、竞品对比：昇腾 950 处于什么位置

9.1 单芯片规格对比

注：NVIDIA 算力均取 dense（非稀疏）峰值口径，950 为白皮书规格；910B/910C 为公开估算、非官方确认。

9.2 关键解读

算力绝对值的差距需要正视。B200 的 BF16 算力是昇腾 950DT 的约 4 倍，H200 是约 1.8 倍。910C（双 Die 910B）的 752 TFLOPS BF16 约等于 H200 的 76%。

但算力数字本身不构成完整的竞争判断。几个结构性因素需要考虑：

联算比（互联带宽 / 计算算力，算力均取 dense 峰值口径）：

• 昇腾 950DT：2,016 GB/s / 547 TFLOPS = 3.69 GB/s per TFLOPS
• H200 SXM：900 GB/s / 989 TFLOPS = 0.91 GB/s per TFLOPS
• B200：1,800 GB/s / 2,250 TFLOPS = 0.80 GB/s per TFLOPS

在 All-to-All 通信密集的 MoE 训练中，通信带宽而非单卡算力成为系统瓶颈。昇腾 950 在这类工作负载下呈现出结构性的联算比优势——单卡峰值算力相对克制，互联带宽则大幅超配。（联算比分母取 BF16；若改用 FP8 算力作分母，950/H200/B200 分别为 1.95 / 0.45 / 0.40，结论不变。）这种取舍是否正确，取决于工作负载的通信密集程度。

超节点规模是另一个结构性差异。NVL72 将 72 颗 B200 连接为一个超节点（机架级），昇腾 950 的 8,192 卡超节点是前者的 114 倍。在超大模型需要跨超节点通信时，更大的超节点意味着更少的跨节点流量和更低的延迟。

精度生态的时间窗口。H200（Hopper 架构）不支持 FP4，昇腾 950 在 FP4 域相对它有绝对优势（2,007 TFLOPS vs 0）；但 B200（Blackwell）已支持 FP4 且吞吐更高（4,500 TFLOPS dense vs 950 的 2,007），昇腾 950 在纯 FP4 算力上并不占优。950 真正的精度差异化不在 FP4 吞吐，而在标准化的 MXFP4（对接 OCP 开放生态）与自研 HiF8 锥形精度（8-bit 下兼顾动态范围与精度）。

十、竞争力判断

优势

昇腾 950 在三个维度上建立了差异化:一是精度的完整度（MXFP4→HiF8→FP8→BF16→TF32 覆盖了四个位宽档位 4/8/16/19-bit，其中 8-bit 含 HiF8 与 FP8 两种格式，HiF8 为自研独占）;二是互联的系统设计哲学(一套 UB 协议统治 Die 内到机架间,大幅降低了分布式编程的复杂度);三是超节点的极限规模(8,192 卡原生组网,同时代竞品无法匹敌)。

风险

最大的未知是功耗和制程——白皮书未披露这两个关键参数，而 TDP 直接决定 TCO。HiF8 作为独占格式的生态推广也需要时间和投入，如果主流框架不支持，实际的性能优势将被打折扣。CANN 相比 CUDA 的软件生态差距仍然存在，第三代引入的 SIMD/SIMT 混合编程虽然提升了灵活性，但学习曲线相比 CUDA 更高。

路线判断

昇腾 950 代表的不是"在 NVIDIA 规则下追赶"的路线，而是尝试重新定义竞争维度——不是比单卡算力，而是比系统级的互联效率和精度创新。这个选择的底层判断是：未来 AI 工作负载的瓶颈不在计算而在通信和内存，因此值得用单卡算力换取联算比和超节点规模。这个判断是否正确，需要等待集群规模下的实际表现来验证。

本分析为独立技术解读，与华为无任何关联或授权。基于华为《昇腾950 NPU 架构白皮书》（2026 年 7 月）、NVIDIA H200/B200 公开规格以及公开渠道获取的 910B/910C 参数。竞品数据引用公开来源，未经厂商逐一确认；910B/910C 规格存在不确定性，请独立核实。