NPU 全景——昇腾/寒武纪/TPU/苹果生态 / The NPU Landscape: Ascend, Cambricon, TPU, and Apple
📅 创建时间:2026-06-02 🏷️ 标签:#NPU #昇腾 #寒武纪 #TPU #CoreML #边缘AI 📚 前置知识:[[03-gpu-architecture]](GPU 架构) [[04-cuda-programming-model]](CUDA 编程) 📚 相关知识:[[13-future-trends]](未来趋势)
先抓住直觉
NPU、TPU、GPU 都是在计算、存储和数据通路之间做不同取舍。学习这一章不应背厂商参数,而应比较:擅长哪些算子、数据如何流动、软件栈是否成熟、迁移成本有多高。
- 必须理解:专用化为何能提高效率;硬件能力与软件生态缺一不可。
- 用到再查:芯片型号、峰值算力、SDK 名称和版本差异。
- 读完能回答:选型时为什么不能只比较 TOPS/TFLOPS?
场景:除了 NVIDIA,还有哪些 AI 芯片?
┌─────────────────────────────────────────────────────────────┐
│ │
│ 你在写简历,技能栏写的是: │
│ "熟悉 CUDA 编程" │
│ │
│ 面试官问: │
│ "你们公司用昇腾 NPU 吗?" │
│ "对苹果的 ANE 了解多少?" │
│ "TPU 和 GPU 训练有什么区别?" │
│ │
│ 你一脸茫然。 │
│ 这章让你对这些 NPU 有一个全局认识, │
│ 至少被问到时能说出个所以然。 │
│ │
└─────────────────────────────────────────────────────────────┘第1节:为什么需要 NPU?
┌─────────────────────────────────────────────────────────────┐
│ AI 芯片市场格局 │
├─────────────────────────────────────────────────────────────┤
│ │
│ NVIDIA GPU: │
│ - 霸主地位,80%+ 市场份额 │
│ - CUDA 生态完善 │
│ - 训练推理通吃 │
│ - 价格贵,供货不稳定 │
│ │
│ 原因导致市场需要替代品: │
│ 1. 美国出口管制 → 中国公司需要国产替代 │
│ 2. 移动端/边缘端 GPU 太贵太耗电 → 专用 NPU │
│ 3. 成本控制 → 不同场景用不同芯片 │
│ │
│ 主要玩家: │
│ - 昇腾 NPU(华为) │
│ - 寒武纪 MLU(国内) │
│ - Google TPU(云端) │
│ - 苹果 ANE(移动端) │
│ - 高通/联发科 NPU(移动端) │
│ │
└─────────────────────────────────────────────────────────────┘第2节:昇腾 NPU(华为)
基本信息
┌─────────────────────────────────────────────────────────────┐
│ 昇腾 NPU 系列 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 昇腾 910(训练): │
│ - 16×16 NPU Core(达芬奇架构) │
│ - FP16 算力:256 TFLOPS │
│ - 32 GB HBM │
│ - 对标 A100 │
│ │
│ 昇腾 310(推理): │
│ - 8×8 NPU Core │
│ - INT8 算力:64 TOPS │
│ - 功耗:8W(移动端) │
│ - 用于手机、汽车、IoT │
│ │
│ 生态: │
│ - CANN(Compute Architecture for Neural Networks) │
│ - Ascend CL(类 CUDA C++ 编程) │
│ - MindSpore(华为自研框架) │
│ - 支持 PyTorch、TensorFlow(通过 ACL) │
│ │
└─────────────────────────────────────────────────────────────┘编程模型(Ascend C)
// Ascend C:昇腾的类 CUDA 编程语言
// 类比 CUDA,但语法和 API 不同
#include "acl/acl.h"
// 数据类型
aclFloat16* d_a; // 类比 float*
// 内存分配
aclrtMalloc(&d_a, size, ACL_MEM_MALLOC_HUGE_FIRST, ACL_MEMTYPE_UNIFIED);
// 内存拷贝
aclrtMemcpy(d_a, size, h_a, size, ACL_MEMCPY_HOST_TO_DEVICE);
// Kernel 类比 __global__
class MatMulKernel : public KernelBuild {
public:
bool Compute(KernelContext& ctx) {
// 类似 CUDA kernel
int32_t pos = GetBlockDim() * GetBlockIdx() + GetThreadIdx();
// 矩阵乘法计算...
return true;
}
};
// 启动
MatMulKernel kernel;
kernel.SetBlockDim(8);
kernel.Execute(inputs, outputs);生态对比
┌─────────────────────────────────────────────────────────────┐
│ CUDA vs CANN 对比 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 维度 │ CUDA(NVIDIA) │ CANN(昇腾) │
│ ──────────────┼────────────────────┼─────────────────── │
│ 编程语言 │ CUDA C++ (.cu) │ Ascend C / Python│
│ 编译器 │ nvcc │ ACCA / ACL │
│ 调试工具 │ cuda-gdb │ msRuntime │
│ 性能分析 │ Nsight │ Ascend Profiler │
│ 深度学习框架 │ PyTorch/TF │ MindSpore/PyTorch │
│ 生态成熟度 │ ★★★★★ │ ★★★☆☆ │
│ │
└─────────────────────────────────────────────────────────────┘第3节:寒武纪 MLU
┌─────────────────────────────────────────────────────────────┐
│ 寒武纪 MLU 系列 │
├─────────────────────────────────────────────────────────────┤
│ │
│ MLU290(训练): │
│ - 架构:Cambricon MLUv02 │
│ - FP16 算力:256 TFLOPS │
│ - 内存:64 GB HBM │
│ │
│ MLU370(推理): │
│ - INT8 算力:256 TOPS │
│ - 功耗:150W │
│ │
│ 编程生态: │
│ - NeuWare SDK │
│ - 支持 PyTorch、TensorFlow │
│ - 类 CUDA 编程风格 │
│ │
│ 国内市场:主要在智算中心、政府项目 │
│ │
└─────────────────────────────────────────────────────────────┘第4节:Google TPU
┌─────────────────────────────────────────────────────────────┐
│ Google TPU 系列 │
├─────────────────────────────────────────────────────────────┤
│ │
│ TPU v4(当前主力): │
│ - 架构:专用矩阵乘法器(Systolic Array) │
│ - BF16 算力:275 TFLOPS/chip │
│ - 互联:ICL(Inter-Core Interconnect) │
│ - 用途:Google 内部训练,主要给 Google Cloud 用户用 │
│ │
│ TPU 特点: │
│ - 不支持任意 CUDA 代码(专用) │
│ - 只运行 TensorFlow / JAX / PyTorch(via XLA) │
│ - 通过 XLA(Accelerated Linear Algebra)编译优化 │
│ - 训练和推理效率极高 │
│ │
│ 使用方式: │
│ - Google Cloud TPU 虚拟机 │
│ - JAX 或 PyTorch + XLA │
│ - 没法本地跑,只能云端用 │
│ │
└─────────────────────────────────────────────────────────────┘TPU vs GPU 架构差异
┌─────────────────────────────────────────────────────────────┐
│ Systolic Array vs GPU │
├─────────────────────────────────────────────────────────────┤
│ │
│ GPU(SIMD): │
│ - 通用并行计算 │
│ - 灵活,支持任意算法 │
│ - CUDA 生态完善 │
│ │
│ TPU(Systolic Array): │
│ - 专用矩阵乘法 │
│ - 矩阵乘效率极高(省去寄存器访问) │
│ - 但灵活性差 │
│ │
│ 比喻: │
│ GPU = 瑞士军刀(什么都能干,但不是每个都最快) │
│ TPU = 专用冲床(只能冲孔,但冲孔极快) │
│ │
└─────────────────────────────────────────────────────────────┘第5节:苹果 Apple Silicon ANE
┌─────────────────────────────────────────────────────────────┐
│ 苹果 ANE(Neural Engine) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Apple Silicon 系列(M1/M2/M3 芯片): │
│ - ANE:16 核神经网络引擎 │
│ - INT8 算力:38 TOPS(M2 Ultra) │
│ - 功耗:极低(手机/PC 级别) │
│ - 主要用于:图像处理、语音识别、AR │
│ │
│ 编程方式: │
│ - Core ML(Apple 的机器学习框架) │
│ - 开发者通过 Core ML 部署模型 │
│ - 不需要手写 kernel,框架自动调度 ANE │
│ │
│ #include <CoreML/CoreML.h> │
│ MLModel* model = [[MLModel alloc] initWithContentsOfURL:url];│
│ MLFeatureProvider* input = ...; │
│ MLFeatureProvider* output = [model predictionFromFeatures:input];│
│ │
│ 特点: │
│ - 完全不需要理解硬件 │
│ - 苹果屏蔽了所有底层细节 │
│ - 开发者体验好,但控制力弱 │
│ │
└─────────────────────────────────────────────────────────────┘第6节:各 NPU 生态对比
┌─────────────────────────────────────────────────────────────────────────┐
│ AI 芯片生态全景对比 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 芯片 │ 公司 │ 算力(FP16) │ 生态成熟度 │ 编程方式 │
│ ────────────┼───────────┼──────────────┼─────────────┼─────────────────│
│ A100/H100 │ NVIDIA │ 312/989 TFLOPS│ ★★★★★ │ CUDA C++ │
│ 昇腾 910 │ 华为 │ 256 TFLOPS │ ★★★☆☆ │ Ascend C/CANN │
│ MLU290 │ 寒武纪 │ 256 TFLOPS │ ★★☆☆☆ │ NeuWare │
│ TPU v4 │ Google │ 275 TFLOPS │ ★★★★☆ │ XLA/JAX/TF │
│ ANE │ 苹果 │ N/A (INT8) │ ★★★★★ │ Core ML │
│ Hexagon │ 高通 │ ~60 TOPS(INT8)│ ★★★☆☆ │ SNPE/QNN │
│ │
│ 选择建议: │
│ - 深度学习训练/研究:→ NVIDIA GPU(CUDA 生态) │
│ - 国产化/昇腾项目:→ 昇腾 NPU + CANN │
│ - 云端大模型训练:→ Google TPU 或 NVIDIA H100 │
│ - 移动端/边缘推理:→ 苹果 ANE / 高通 Hexagon │
│ - 成本敏感项目:→ 国产 NPU(昇腾/寒武纪) │
│ │
└─────────────────────────────────────────────────────────────────────────┘升华:理解 NPU 生态的价值
┌─────────────────────────────────────────────────────────────┐
│ 为什么工程狮要了解 NPU? │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 面试加分 │
│ 能说出昇腾 vs GPU 的生态差异,比只会 CUDA 更全面 │
│ │
│ 2. 国产化趋势 │
│ 越来越多的政府和国企项目要求使用国产芯片 │
│ │
│ 3. 场景适配 │
│ 移动端用 ANE,服务器用 GPU,智算中心用昇腾 │
│ 不同场景选不同芯片是工程能力 │
│ │
│ 4. 理解计算本质 │
│ 所有 NPU/GPU 都是矩阵乘法的加速器 │
│ 理解了本质,换平台只是 API 不同 │
│ │
└─────────────────────────────────────────────────────────────┘"AI 可查 vs 必须理解"清单
AI 可查:
✅ 昇腾/寒武纪/TPU 的具体 SDK API
✅ Core ML 的具体使用方法
✅ 各芯片的具体算力参数
必须理解:
🔴 NVIDIA CUDA 是生态最完善的,其他都是类比
🔴 昇腾用 CANN + Ascend C,类 CUDA 但生态不如 CUDA
🔴 TPU = Systolic Array,专为矩阵乘法设计,效率高但灵活性差
🔴 苹果 ANE = Core ML 屏蔽底层,开发者体验好但控制力弱
🔴 选型原则:训练用 GPU/TPU,移动端用 NPU,国产化用昇腾/寒武纪学习状态:🟡 开始学习
选型结论的版本边界
NPU、GPU 与 TPU 的软件栈、算子覆盖和工具链持续变化。 “生态最好”“灵活性差”或“适合某类任务”都必须绑定具体模型、版本和部署目标。
实际选型应重新测量:
- 目标模型算子覆盖;
- 精度与量化;
- 动态形状;
- 编译和部署;
- 内存容量;
- 延迟、吞吐与能耗;
- 调试和回退;
- 供应与长期维护。
从目标模型而不是峰值参数开始
NPU 选型首先要拿到真实模型的计算图、输入形状、Batch、精度要求和延迟目标。芯片公布的峰值通常对应特定数据类型、矩阵形状和理想利用率,无法直接预测包含预处理、动态控制和不支持算子的完整应用。最有说服力的证据是在目标软件栈上编译真实模型,并记录哪些算子进入加速器、哪些回退到 CPU,以及回退之间产生了多少布局转换和数据搬运。
算子覆盖决定可用性
“支持 Transformer”过于宽泛。模型可能包含自定义归一化、稀疏操作、动态索引、控制流或特殊后处理,只要关键路径中的一个算子无法下沉,就可能把数据频繁拉回 Host。覆盖检查需要精确到算子版本、数据类型、形状约束和融合模式,并保存编译器诊断。框架能够导出模型,只代表格式转换成功,不代表整图在设备上高效执行。
编译器是硬件能力的一部分
NPU 通常依赖图编译器完成算子融合、布局选择、内存规划、量化和 Kernel 生成。相同硬件在不同编译器版本上可能具有不同算子覆盖和性能。评估应记录编译时间、生成缓存、失败诊断、动态形状策略和回退路径。生产部署还要考虑模型升级后是否需要重新编译,以及旧编译产物能否在新驱动或运行时继续使用。
精度与量化需要领域验收
INT8、INT4 或混合精度可以提高吞吐并降低内存,但误差不能只用少量随机输入检查。量化需要代表性校准数据、逐层或逐算子误差分析,以及最终任务指标。模型在公开数据集上保持平均准确率,不代表少数高风险样本没有明显退化。对科学计算或工业检测,还应检查守恒量、阈值附近行为和重复运行稳定性。
内存容量与数据流
模型能否装入设备只是第一步。权重、激活、KV Cache、临时 Workspace 和并发 Batch 会共同占用内存。运行时可能为了容量切分模型或把张量换出到 Host,导致延迟抖动。评估报告应包含峰值设备内存、Host 内存、传输字节、并发下的内存增长,以及 OOM 后的明确失败或降级策略。
端到端基准
基准从请求进入应用开始,到最终可消费结果结束。需要包含预处理、格式转换、编译缓存命中或冷启动、设备队列、执行、后处理和数据返回。分别报告首请求、预热后 P50/P95/P99、吞吐、并发、能耗和成本。只报告设备 Kernel 或厂商样例吞吐,不能支持产品选型。
可观测性与故障处理
生产系统需要知道每次请求使用了哪个模型版本、编译产物、设备和执行路径。算子回退、重新编译、设备重置、超时和 OOM 都应进入结构化日志与指标。设备不可用时,系统是拒绝、排队、转到其他设备还是 CPU 回退,必须由明确策略决定;静默回退可能让延迟突然增加数十倍并拖垮 CPU 服务。
可维护性
硬件采购之外,还要评估 SDK 发布节奏、驱动兼容、离线安装、容器支持、调试器、Profiler、问题定位和供应周期。一个 Benchmark 更快但工具链无法诊断生产错误的设备,会把性能收益换成长期运维成本。最终决策应保留候选模型、原始结果、失败样本和退出条件,便于软件栈变化后重新评估。