华为云信创：昇腾、寒武纪、天数智芯三款国产 AI 芯片对比实测
文章摘要：2025 年国产 AI 芯片的选择越来越多：华为昇腾、寒武纪、天数智芯、地平线、燧原……本文从一个实际项目（BERT 文本分类推理）出发，在同一套基准测试框架下对比了昇腾 310P3、寒武纪 MLU370、天数智芯天垓 100 三款主流推理芯片的性能、功耗、成本和生态成熟度，并给出分场景的选型建议。
选型背景
2025 年初，我们为公司的 AI 推理平台做信创芯片选型，需要从国产方案中选择一款替代英伟达 T4。候选芯片：
| 芯片 | 厂商 | 架构 | 显存 | 功耗 | 单价（估算） |
|---|---|---|---|---|---|
| Ascend 310P3 | 华为昇腾 | Da Vinci | 24GB | 25W | ¥8,000 |
| MLU370-S4 | 寒武纪 | MLUarch03 | 16GB | 70W | ¥7,000 |
| 天垓 100 | 天数智芯 | 自研 GPGPU | 32GB | 250W | ¥12,000 |
| T4（对比基线） | 英伟达 | Turing | 16GB | 70W | ¥15,000 |
测试框架
统一测试环境：
| 项目 | 配置 |
|---|---|
| 模型 | BERT-base 中文（110M 参数） |
| 任务 | 文本分类（10 类） |
| Batch size | 1（在线推理）/ 32（吞吐测试） |
| 推理框架 | 各芯片的原生推理框架 |
| 服务器 | 鲲鹏 920 / 32 核 / 128GB 内存 |
测试结果
1. 单卡推理延迟（batch=1）
| 指标 | T4（基线） | 昇腾 310P3 | 寒武纪 MLU370 | 天数天垓 100 |
|---|---|---|---|---|
| P50 延迟 | 18ms | 22ms | 35ms | 28ms |
| P99 延迟 | 22ms | 28ms | 52ms | 35ms |
| P99/P50 比 | 1.22 | 1.27 | 1.49 | 1.25 |
寒武纪的 P99/P50 抖动最大（1.49），说明存在明显的偶发长尾延迟。
2. 吞吐量（batch=32）
| 指标 | T4 | 昇腾 310P3 | 寒武纪 MLU370 | 天数天垓 100 |
|---|---|---|---|---|
| 吞吐（qps） | 1,200 | 960 | 520 | 780 |
| 相对 T4 | 100% | 80% | 43% | 65% |
3. 精度
| 模型 | accuracy | 相对 T4 差异 |
|---|---|---|
| 原始 PyTorch | 92.3% | 基线 |
| T4 FP32 | 92.3% | ±0% |
| 昇腾 310P3 FP32 | 91.8% | -0.5% |
| 寒武纪 MLU370 | 91.5% | -0.8% |
| 天垓 100 | 92.0% | -0.3% |
4. 能效比
| 芯片 | 功耗 | 吞吐（qps） | 能效（qps/W） | 相对能效 |
|---|---|---|---|---|
| T4 | 70W | 1,200 | 17.1 | 1.0x |
| 昇腾 310P3 | 25W | 960 | 38.4 | 2.2x |
| 寒武纪 MLU370 | 70W | 520 | 7.4 | 0.4x |
| 天垓 100 | 250W | 780 | 3.1 | 0.2x |
昇腾 310P3 的能效比是 T4 的 2.2 倍，是寒武纪的 5.2 倍。
全生命周期成本对比
算一笔 3 年 TCO（Total Cost of Ownership）：部署 100 卡集群，提供等量算力。
| 成本项 | T4 | 昇腾 310P3 | 寒武纪 MLU370 | 天垓 100 |
|---|---|---|---|---|
| 卡数量（等吞吐） | 100 | 125 | 231 | 154 |
| 硬件成本 | ¥150万 | ¥100万 | ¥162万 | ¥185万 |
| 3 年电费 | ¥18.4万 | ¥8.2万 | ¥42.5万 | ¥101万 |
| 散热/机房 | ¥15万 | ¥10万 | ¥25万 | ¥45万 |
| 运维人力 | ¥30万 | ¥30万 | ¥40万 | ¥35万 |
| TCO 合计 | ¥213万 | ¥148万 | ¥270万 | ¥366万 |
TCO 结论：昇腾 310P3 是 4 款中成本最低的方案，比 T4 节省约 30%。
生态成熟度对比
生态评分（满分 10）
| 维度 | 昇腾 | 寒武纪 | 天垓 |
|---|---|---|---|
| PyTorch 兼容性 | 8 | 6 | 7 |
| ONNX 兼容性 | 9 | 5 | 4 |
| 算子覆盖率 | 8 | 7 | 6 |
| 文档质量 | 8 | 5 | 6 |
| 社区活跃度 | 8 | 4 | 3 |
| 厂商支持 | 9 | 6 | 5 |
| 综合 | 8.3 | 5.5 | 5.2 |
踩坑记录
1. 寒武纪的 ONNX 转换遇到 30% 的算子不支持
现象：同一个 ONNX 模型，昇腾能转换成功，寒武纪的转换工具报了 30 个不支持的算子。
解决：需要针对不支持的算子做手工替换（用寒武纪提供的等价算子组合）。增加了约 2 周的适配工作量。
2. 天垓 100 的实测功耗超过标称值
现象：天数天垓 100 标称功耗 250W，实测跑 BERT 推理时达到 280W，峰值甚至到了 320W（超过标称 28%）。需要额外的散热和供电。
3. 昇腾的 AOE 调优需要申请权限
昇腾的 AOE 工具在某些版本中需要联系华为技术支持开通权限，不能直接从官网下载。这个流程大约花了 3 个工作日。
4. CANN 版本与驱动不匹配导致推理结果全错
现象：我们在一台测试服务器上安装了昇腾 310P3 的驱动包 Ascend310-driver-23.0.1，然后配套安装了 CANN 6.3.RC1。转换 OM 模型成功，推理也不报错——但输出的分类结果完全不对，准确率从 91.8% 骤降到 12%（相当于随机猜）。
排查过程：第一次遇到时完全没头绪，因为工具链不报任何错误。后来对比了另一台正常服务器上的版本组合，才发现问题：
| 组件 | 正常环境 | 故障环境 |
|---|---|---|
| 驱动版本 | 23.0.3 | 23.0.1 |
| CANN 版本 | 7.0.RC1 | 6.3.RC1 |
| 固件版本 | 1.1.2 | 1.0.9 |
根本原因：CANN 6.3 与驱动 23.0.1 的算子适配层存在一个已知但未公开的缺陷（华为技术支持后来确认的），导致 FP16 算子的中间表示被错误映射到硬件指令，推理结果出现系统性偏差。关键问题是推理工具链不报错也不告警，只是默默地输出错误结果。
教训：
- 昇腾的驱动 + CANN + 固件版本需要严格遵循 官方兼容性矩阵 的组合，不能只看各自的最新版本。
- 推理完成后必须做精度对比验证，不能只看有没有报错。我们后来在 CI 流程中增加了精度自动检查步骤：每次模型转换后用 1000 条验证集数据跑一次推理，对比推理结果与 GPU 输出的余弦相似度，阈值设为 0.99，低于此值则告警。
- 建议锁定一个经过验证的版本组合（我们最终锁定：驱动 23.0.3 + CANN 7.0.RC1 + 固件 1.1.2），不要随意升级。
5. 天垓 100 的 TCO 计算漏了散热成本
现象：选型阶段我们按天垓 100 标称 250W 做了 TCO 估算，结果上线第一个月机房就报高温告警。
实际数据：我们部署了 20 卡天垓 100 用于离线批处理，实际运行功耗如下：
| 状态 | 标称功耗 | 实测功耗 | 实测室温 |
|---|---|---|---|
| 空闲 | 75W（标称） | 92W | 23°C |
| BERT 推理（batch=32） | 250W | 278W | 26°C |
| 峰值负载（连续 4 卡满载） | — | 305W/卡 | 31°C |
| 峰值负载（连续 8 卡满载） | — | 318W/卡 | 34°C（超温报警） |
分析：天垓 100 的散热设计依赖服务器风道，但 8 卡满负载时热量叠加，风冷已无法压制。在 4 卡以上并行推理时，每增加一卡，机柜进风口温度升高约 2°C。我们用的 42U 标准机柜部署了 2 台 4 卡服务器，满负荷运行 30 分钟后机柜后门温度达到 42°C。
解决的代价：
- 紧急加装 2 台 3.5kW 列间空调：¥4.5 万/台 × 2 = ¥9 万
- 机柜改造（增加导流罩和盲板）：¥0.8 万
- 为了一台服务器增加散热，每月的电费多出 ¥1,200
- TCO 修正后：天垓 100 的 3 年 TCO 从 ¥366 万上升到约 ¥398 万，与昇腾的差距从 2.5 倍扩大到 2.7 倍
教训：
- 不要只看芯片标称 TDP。多卡密集部署下的散热成本会非线性增长。建议在 TCO 模板中增加一项"散热修正系数"：风冷环境下，4 卡以上按 TDP × 1.3 计算实际散热需求；液冷环境下按 TDP × 1.1。
- 天垓 100 适合单卡或双卡部署场景，8 卡满配需要液冷方案，这一点厂商在售前阶段没有主动告知。
选型建议
根据我们的测试结果，不同场景的建议：
选型决策矩阵
结合上述维度，我们整理了一个量化决策矩阵，帮助不同需求的团队快速判断：
评分示范：假设一个典型在线推理场景（延迟权重=5，吞吐权重=3，成本权重=4，生态权重=4）：
| 维度 | 昇腾得分 | ×权重 | 寒武纪得分 | ×权重 | 天垓得分 | ×权重 |
|---|---|---|---|---|---|---|
| 延迟 | 8 | 40 | 5 | 25 | 6 | 30 |
| 吞吐 | 8 | 24 | 4 | 12 | 6 | 18 |
| 成本 | 9 | 36 | 6 | 24 | 4 | 16 |
| 生态 | 8 | 32 | 5 | 20 | 5 | 20 |
| 加权总分 | 132 | 81 | 84 |
在这个权重设定下，昇腾总分大幅领先。如果你的场景对成本不敏感但对生态兼容性要求极高，可以调整权重重新计算。
常见问题
Q1：为什么不测试百度昆仑芯？
昆仑芯的交期不稳定，送测周期长。我们 2025 年初联系时告知排期到了 Q3。
Q2：昇腾 310P3 和 910B 的推理性能差多少？
910B 的 FP16 算力是 310P3 的约 10 倍（256 vs 22 TFLOPS），适合大批量训练和推理。但价格和功耗也高出很多。推理场景选 310P3 性价比最高。
Q3：国产芯片的驱动稳定性如何？
昇腾在 openEuler 上最稳定（毕竟是华为生态内）。寒武纪在 CentOS 上运行了 3 个月，遇到过一次驱动崩溃需要重启。天垓的驱动稳定性中等，但更新频率低。
Q4：国产芯片的推理精度损失能否通过量化来弥补？
这是我们在实际生产中探索过的一个方向。简单回答：INT8 量化可以提升吞吐，但精度损失因芯片而异。
| 量化方案 | 昇腾 310P3 | 寒武纪 MLU370 | 天垓 100 |
|---|---|---|---|
| FP32 → FP16 | 精度损失 < 0.1%，吞吐 +60% | 精度损失 < 0.2%，吞吐 +40% | 精度损失 < 0.1%，吞吐 +50% |
| FP32 → INT8 | 精度损失 0.5%~1.2%，吞吐 +180% | 精度损失 1.5%~3.0%，吞吐 +120% | 精度损失 0.8%~2.0%，吞吐 +150% |
| 量化工具 | AMCT（昇腾量化工具） | MagicMind（寒武纪） | 天垓 Quantizer |
实践建议：
- 分类任务（如 BERT 文本分类）对 INT8 量化容忍度较高，精度损失通常在 0.5%~1.0% 以内，收益可观。
- 序列标注或回归任务对 INT8 量化更敏感，建议先做 FP16，再评估是否进一步量化。
- 量化后必须做全量测试集验证，不能只看几条数据。我们曾遇到量化后 99% 数据精度正常，但某类样本精度下降 5% 的 case。
- 昇腾的 AMCT 工具在量化校准集的选择上比较敏感，建议用验证集的 10% 作为校准集，迭代 3~5 次选取最优结果。
Q5：不同国产芯片对 PyTorch 动态图和静态图的支持程度如何？
这是很多 PyTorch 用户迁移时容易忽略的问题。三款芯片对动态图（Eager Mode）和静态图（TorchScript / Graph Mode）的支持差异较大：
| 特性 | 昇腾（Torch-NPU） | 寒武纪（Torch-MLU） | 天垓（Torch-GPGPU） |
|---|---|---|---|
| 动态图推理 | 完整支持 | 完整支持 | 完整支持 |
| 动态图训练 | 支持（部分算子回退到 CPU） | 支持（梯度同步偶有 bug） | 支持（显存管理待优化） |
| 静态图推理 | 完整支持（CANN + OM） | 部分支持（需手工标记 torch.jit.trace） |
不支持（依赖 ONNX 导出） |
| 静态图训练 | 支持（MindSpore Graph Mode） | 不支持 | 不支持 |
torch.compile |
不支持 | 不支持 | 不支持 |
关键发现：
- 如果只用 PyTorch 动态图做推理，三款芯片都能满足基本需求，性能差异主要体现在底层算子实现上。
- 如果需要用
torch.jit.script或torch.jit.trace做静态图优化加速，昇腾的 CANN 工具链最成熟。 torch.compile（PyTorch 2.x 的默认编译模式）三款芯片目前都不支持，需要等各厂商跟进。昇腾在 2025 年 Q2 的内部路线图中已有计划。
总结
把四组实测数据放在一起看，三款芯片的定位差异很清楚：
| 维度 | 昇腾 310P3 | 寒武纪 MLU370 | 天垓 100 |
|---|---|---|---|
| 吞吐（相对 T4） | 80% | 43% | 65% |
| P99 延迟 | 28ms | 52ms | 35ms |
| 能效（相对 T4） | 2.2x | 0.4x | 0.2x |
| 3 年 TCO（100 卡等吞吐） | ¥148 万 | ¥270 万 | ¥366 万（散热修正后约 ¥398 万） |
在我们的场景（BERT 在线推理 + 离线批处理）里，昇腾 310P3 综合最优：性能达到 T4 的八成，能效反超 T4，工具链（CANN/OM 转换、量化工具、文档）也最完整。天垓 100 适合吞吐要求不高的离线批处理，但多卡部署必须先把散热这笔账算进去。寒武纪 MLU370 的算子兼容性和 P99 抖动问题，迁移前要拿自己的模型实测，不能只看官方算子列表。
选昇腾还有一个要摆到台面上的代价：它的优势建立在生态闭环上（昇腾 + CANN + MindSpore + openEuler），用得越深，迁出成本越高。这个锁定效应是利是弊，取决于公司的技术战略——最好在选型阶段讨论清楚，而不是上线之后才发现。
你们公司在用什么国产 AI 芯片，遇到过哪些坑？欢迎评论区交流。
- 点赞
- 收藏
- 关注作者
评论（0）