昇腾 910B 显卡怎么选：64GB 显存、392GB/s 互联与部署门槛（2026）

快速结论

• 单颗昇腾 910（NPU）给 64GB 片上内存、1600GB/s；Atlas 800T A2 一台装 8 颗，FP16 313 或 376 TFLOPS（华为《Atlas 800T A2 训练服务器 技术白皮书》v16，2026-05-12 核对）。
• 8 颗之间是 HCCS 全互联，单颗 7 条链路、最大 392GB/s；跨机走 8 个 200GE RoCE 口。多机先把 ranktable 配好，再谈加卡。
• 推理卡是另一条产品线：300I Duo 有 96GB 内存，但只有 408GB/s、150W；300I A2 是 64GB、1.6TB/s、350W、560 TOPS INT8。
• 大模型 decode 的上限由带宽决定。27B、W8A8（约 27GB 权重）在 300I Duo 上约 66ms/token、15 token/s；换到 300I A2 约 59 token/s（按 1 字节/参数估算）。
• 软件栈按套验证：vLLM-Ascend 0.30.0 对应 CANN 9.2.1、PyTorch 2.10.0、torch_npu 2.10.0.post7，文档写明不要随意混用（《Installation》v0.30.0，2026-11 核对）。
• 供电往往比算力更早成为限制：800T A2 最大输入 5.8kW，配 4 个 2600W 或 3200W 电源；42U 机柜放 10 台就是 58kW（白皮书 v16）。

选型顺序：先定场景，再算显存，最后看配电

1. 先定训练还是推理。判据是有没有反向传播与优化器状态。训练看 8 卡整机、HCCS 与 200GE；推理看单卡显存与带宽。
2. 再算显存门槛。判据是参数量 × 精度字节 × 1.2，再加 KV Cache。64GB 单卡装不下 70B FP16 的 140GB 权重，TP 至少 4 卡。
3. 再选卡型。判据是长上下文和大模型 decode 先看带宽；OCR、视频分析先看编解码与 INT8 算力。
4. 最后核软件栈。判据是模型在不在 vLLM-Ascend 支持表里。不在表里就先做算子验证，不要先下单。

一、64GB 显存能装下什么

Atlas 800T A2 的 8 颗 910 各有 64GB 片上内存，整机 512GB。这个数决定单卡能放多大的模型，也决定要不要上多机。

70B 模型的 FP16 权重约 140GB（70×10^9 × 2 字节）。单卡 64GB 放不下，按 TP4 切分后每卡 35GB，余量留给 KV Cache 与激活。若做全参微调，按混合精度 Adam 估算，fp32 主权重、m、v 三项约 12 字节/参数。70B 下这三项是 840GB，再加权重与梯度 280GB，合计 1120GB。8×64GB=512GB，1120GB 是它的 2.19 倍。LoRA 只更新适配器，140GB 权重加少量适配器，单机 8 卡可以放下。

以上是显存预算。真实吞吐还受 HCCS、batch 与算子实现影响，不能当成性能承诺。

换到 A3，预算又不同：8×128GB=1024GB，3.2TB/s。同样按 235B 参数、FP16 权重 470GB 估算，A3 单机只占用 46%，70B 的 140GB 只占 13.7%。A3 把「单机装不下」变成「单机装得下」，代价是 10U 机箱与更复杂的供电散热（华为 Atlas 800T A3 产品页，2026-11 核对）。

二、8 卡整机：配电与机柜的硬约束

800T A2 是 4U 机箱、4 颗鲲鹏920、32 个 DDR4 插槽，8 个 200GE QSFP 口直出。整机最大输出 5.5kW、最大输入 5.8kW，配 4 个 2600W 或 3200W 电源；交流输入推荐 32A 空开（白皮书 v16）。

按机柜算一遍：42U 机柜按 4U 一台放 10 台，满载 58kW。这个数要先和机房确认单柜配电上限，再谈上架。A3 的机箱更高：10U 机箱，42U 只能放 4 台（40U），单机 8 颗 910、8×128GB、3.2TB/s、整机 6 PFLOPS FP16（华为 Atlas 800T A3 产品页，2026-11 核对）。

电费按最大输入连续跑 720 小时：5.8kW × 720 小时 = 4176 kWh/月。300I Duo 150W 是 108 kWh/月，300I A2 350W 是 252 kWh/月。各地电价不同，用当地账单单价乘一次即可。

节点内与节点间的带宽差 15.7 倍。HCCS 单颗 392GB/s，跨机 200GE 单口理论 25GB/s（200 Gbit/s ÷ 8），相差 15.7 倍。8 个口都接交换机，也要看收敛比与 ranktable 的映射；梯度同步一旦跨机，通信就会进入关键路径。

三、推理卡：96GB 不等于快

（华为 Atlas 300I Duo、Atlas 300I A2 产品页，2026-11 核对）

300I Duo 的强项是内存、功耗与编解码：单槽 150W，96GB 内存，H.264/H.265 解码 256 路 1080P 30FPS。它适合 OCR、内容审核、视频分析，以及多模型共卡。短板也明确：LPDDR4X 只有 408GB/s。

300I A2 把带宽提升到 1.6TB/s、INT8 算力 560 TOPS，代价是 350W 与双槽。两者都走 PCIe，不通过 HCCS 组网。

下面算 decode 的带宽下限。以 27B、W8A8 为例，按 1 字节/参数估算，权重约 27GB。单请求每生成 1 个 token 要把权重读一遍，带宽就是硬上限：

• 27GB ÷ 408GB/s ≈ 66ms/token ≈ 15 token/s（300I Duo）
• 27GB ÷ 1600GB/s ≈ 17ms/token ≈ 59 token/s（300I A2）

这是理论下限，不含 KV Cache、算子开销，也没算并发带来的摊薄。把精度换成 FP16，权重 54GB，300I Duo 降到约 7.5 token/s。显存够，带宽不够。

单请求延迟与总吞吐是两件事。按上面的算法，300I Duo 的一个 decode step 约 66ms，与 batch 大小关系不大（权重读取占主导）。batch 16 时，聚合吞吐上限约 16×15=240 token/s；实际会被 KV Cache 读取与算子开销压低。300I A2 按同一算法，上限约 16×59≈950 token/s。

支持表还会限制可用功能与上下文。在 vLLM-Ascend 的 300I DUO 表里，Qwen3-Dense 的 BF16 一栏标 ❌，LoRA 与 PD 分离同样标 ❌，max-model-len 为 20k；Qwen3-30B-A3B 的 max-model-len 为 16k（《Supported Models》v0.30.0，2026-11 核对）。96GB 能装下更多权重，但支持的功能与上下文要先对表。

四、软件栈：版本要成套对齐

vLLM-Ascend 0.30.0 的验证组合如下（《Installation》v0.30.0，2026-11 核对）：

• Ascend HDK 26.1.1
• CANN Toolkit + Ops 9.2.1，NNAL 9.2.1
• PyTorch 2.10.0，torch_npu 2.10.0.post7
• Triton Ascend 3.6.0.post2，FLA NPU 26.9.1
• vLLM 0.30.0，vLLM-Ascend 0.30.0

文档把上述版本列为一套验证过的组合，不要跨版本混用。设备列表覆盖 A2、A3、300I DUO、200I Pro、950DT；Triton Ascend 与 FLA 只用于 A2/A3/950DT，300I DUO 与 200I Pro 不走这两条内核路径。版本对应关系见《Versioning Policy》，每一行都是一个完整组合。

编译自定义算子还有一层约束。SOC_VERSION 只决定构建目标，不会去查询 npu-smi；它必须与目标硬件一致：A2 用 ascend910b1，A3 用 ascend910_9391，300I DUO/200I Pro 用 ascend310p1，950DT 用 ascend950dt_9582。

升级时先跑 npu-smi info，确认设备数与 Health 正常。再按兼容表整行替换，不要只升 CANN 或只升 torch_npu。支持表也会过期：Qwen3-235B-A22B 与 DeepSeek R1 在 2026-11 的表里标为「不再维护」，选型时按当期表，不要按旧部署笔记。

五、两个现场故障，先看日志再改环境

1. 单机 8 卡，HCCL Error 19

vLLM-Ascend issue #21122（2026-11-06）记录了一个 Atlas A3 的案例：单机 8 NPU、DeepSeek-V4-Flash W8A8、镜像 vllm-ascend:v0.30.0、--net=host、物理断网。模型初始化到 W8A8 MoE 量化阶段时崩溃：

RuntimeError: createHcclCommOrigin:
../torch_npu/csrc/distributed/ProcessGroupHCCL.cpp:3101

HCCL function error:
hcclGetRootInfo(&hcclID), error code is 19
(call network api fail)

复现者试过接通物理网络、只在宿主机设 HCCL_SOCKET_IFNAME=lo、只用 --net=host，均未解决。有效的做法是在容器内、启动 vllm 之前设置：

export HCCL_SOCKET_IFNAME="lo"
unset HCCL_IF_IP
export GLOO_SOCKET_IFNAME=lo
export TP_SOCKET_IFNAME=lo

报错文本是 call network api fail，复现环境是物理断网。把容器内通信网卡绑定到 lo 后，初始化通过。截至 2026-11-09，该 issue 仍为 open；这是可复现的绕过方案，不是官方修复。

2. 310P 双实例：第二个容器无法启动

issue #19995（2026-10-27）里，8 卡 310P（300I Duo 与 200I Pro 使用的芯片）分成 4+4，两个容器各跑 Qwen3.8-27B。配置是 W8A8、TP4、max-model-len 16384、gpu-memory-utilization 0.90，镜像 v0.30.0-rc2-310p。第一个容器正常，第二个报图捕获资源不足。

issue 里的回复是：启动容器时不要挂载全部 8 张卡，用到哪 4 张就挂哪 4 张。复现者用的是官方脚本，只改了端口和权重目录；容器挂载的卡数不同。

共用同一张卡跑多进程还有另一个问题。PR #19984（2026-10-27）修的是 NPUWorker310.determine_available_memory()：它把其他进程占用的 HBM 与驱动预留重复扣了一次。KV Cache 预算因此被算成负数，第二个实例启动失败。修复后两个实例都能启动，日志里的 KV Cache 为非负值。该 PR 于 2026-10-28 合入，所用的 release 需包含这次修复。

多实例前先看两处：容器的设备映射是否只挂了分配给它的卡；启动日志的 Available KV cache memory 是否为非负。310P 的采样与 MRV2 支持仍在补齐（issue #21124，2026-11-06），功能表以当期分支为准。

适用与不适用

适用：

• 已有昇腾整机或 300I 系列卡，要在 vLLM 上做推理、LoRA 微调。
• 有国产化或信创约束，必须走 CANN，不能走 CUDA。
• OCR、内容审核、视频分析这类依赖编解码与 INT8 的场景，300I Duo 的 96GB 与 256 路解码已经够用。

不适用于：

• 只跑 7B/14B、追求最低单 token 成本：24GB NVIDIA 卡的选择更多，生态更成熟。
• 需要 FP8/INT4 新量化，或要求模型发布当天可用：先查支持表，不要只按参数表买卡。
• 机房单柜配电低于 6kW：800T A2 单机 5.8kW，无法上架。
• 团队有大量自定义 CUDA 算子：迁到 Ascend C 或 ACLNN 的改造量要先评估，再谈替换。

延伸阅读：70B 模型的显存门槛与月账单 · GPU 租用价格页（当前收录 NVIDIA 机型，可作单位算力价格参照）