Atlas 300I Pro vs T4/A10推理卡实测：算力与能效比深度对比

1. 这项测试的出发点：推理卡的算力不能只看账面TOPS

给智算机房做推理服务器选型评估那阵子，业务方给的需求很直白：要在单卡功耗尽量低的前提下，把视频结构化和NLP推理链路跑起来，每路视频的处理成本压到最低。市面能选的推理卡就那几款，NVIDIA T4是保守答案，A10性能上去了但功耗翻倍，于是Atlas 300I Pro这张昇腾推理卡进了测试名单。前后跑了几周，核心就一件事：把Atlas 300I Pro的算力、能效比和T4/A10放在同一套测试口径下，用真实模型和真实业务负载说话，而不是拿厂商白皮书上的TOPS数字直接做账。

1.1 为什么拿Atlas 300I Pro和T4、A10去对比

先交代一下背景。当时项目的推理链路主要跑两类负载：一类是视觉模型，ResNet-50做图像分类，YOLOv5s做目标检测，输入分辨率统一为640x640；另一类是NLP模型，BERT-Base做文本分类，序列长度128。这些都是推理场景里最常见的模型，网上公开的性能数据很多，方便交叉验证。选择对比对象的时候，第一顺位是NVIDIA T4，因为T4标称功耗70W、INT8算力最高130 TOPS，和Atlas 300I Pro的72W、INT8算力140 TOPS几乎在同一能效区间；第二顺位是A10，标称功耗150W、INT8算力250 TOPS，用来观察"功耗翻倍能否换来实打实的性能翻倍"。

很多人选型时喜欢直接拉一张算力表：140 TOPS对130 TOPS，看起来Atlas 300I Pro比T4略强一点；再一看FP16，70 TFLOPS对65 TFLOPS，还是略强一点。但实际部署过推理卡的人都清楚，标称算力是芯片在理想条件下能达到的上限，真实吞吐还要看算力利用率、内存带宽、数据搬运开销、框架调度效率这一整套东西。同样是INT8模型，有的卡能做到标称算力60%以上的利用率，有的卡拼死拼活只有30%，业务上就是一倍差距。所以这轮测试从一开始就定了一个原则：所有对比数据必须来自同一套模型、同一个batch size、同一个数据预处理流程，甚至在可能的情况下跑同一个推理框架版本。

1.2 本次测试的基本原则与口径说明

测试没有采用厂商自带的性能报告，而是自己从ONNX模型开始走完整条链路：先准备模型，再用ATC工具转换成昇腾的om格式；T4和A10那边用TensorRT做转换，两者都关闭了动态shape，统一用固定batch的静态引擎。这样虽然牺牲了一部分灵活性，但能保证压测时的最优性能，也更接近生产环境里"整形输入"的常态。

另一个重要口径是功耗测量。整机功耗通过服务器BMC接口读取，单卡功耗用卡上的传感器读取：NVIDIA卡用nvidia-smi的Power Draw字段，Atlas 300I Pro用npu-smi info的输出。读取频率统一为每秒一次，取30分钟满载测试最后10分钟的均值。这里要说清楚，npu-smi读到的功耗是AI芯片当前的实际功耗，不代表整卡PCIE插槽的全部耗电，但用于对比能效比是够用的，因为三张卡的数据都来自同一类传感器口径。

测试软件版本也容易被忽略。CANN 7.0和CANN 6.x之间的算子库差异很大，同样的ResNet-50，不同版本转换出来的om模型性能能差10%到20%。NVIDIA那边TensorRT 8.6和8.5也有类似差别。我的做法是把所有软件版本记录在案，对比时确保同一个模型在三张卡上都是用各自生态里当前比较稳定的版本跑的，不追求最新，只追求"各自优化到位"。这样才能相对公平地反映硬件本身的差距。

2. 测试平台搭建：CANN环境、模型转换与压测工具的取舍

搭建Atlas 300I Pro的测试环境，比装一张NVIDIA卡要繁琐不少。NVIDIA这边，驱动加CUDA加TensorRT，一条龙下来半天搞定；昇腾这边需要装驱动、固件、CANN Toolkit、算子包，还要配置环境变量，对不熟悉华为工具链的人来说第一个坎就是环境搭建。但考虑到Atlas 300I Pro的优势场景恰恰是国产化推理部署，这个学习成本在实际项目中绕不开，所以我把搭建过程里容易出问题的点单独拿出来说。

2.1 硬件平台与软件栈清单

测试服务器配置如下：

• 服务器：2U机架式，双路Intel Xeon Silver 4314，内存256GB DDR4，系统盘1TB NVMe SSD
• 系统：Ubuntu 20.04 LTS，内核5.4，关闭图形界面
• Atlas 300I Pro：单卡插在PCIe 4.0 x16插槽，驱动版本23.0.x，CANN Toolkit 7.0
• NVIDIA T4和A10：分别装在另外两台相同配置的服务器上，驱动535.x，CUDA 12.2，TensorRT 8.6

有一点必须提醒：Atlas 300I Pro的驱动和固件升级要配套，不能只升驱动不升固件，否则CANN Toolkit初始化时会报version mismatch。官方文档一般会给出配套关系表，建议严格按照列表来。我最初因为固件没升级，跑ATC转换时报了GE算子编译错误，排查了大半天才发现是固件版本落后，这个坑后面会细说。

2.2 ATC模型转换与msame压测命令的实际调整

模型转换是昇腾部署里最关键的环节。TensorRT有trtexec，昇腾这边官方推荐的推理测速工具是msame，但模型要先用ATC工具转成om格式。以ResNet-50为例，ONNX转om的命令大概是这样：

atc --model=resnet50.onnx \ --framework=5 \ --output=resnet50_bs1 \ --input_format=NCHW \ --input-shape="input:1,3,224,224" \ --soc_version=Ascend310P3 \ --insert-op-conf=aipp.cfg \ --precision_mode=allow_fp32_to_fp16

这里面单个参数聊一下。soc_version必须和卡上的芯片型号严格对应，Atlas 300I Pro用的是昇腾310P系列芯片，不同规格的310P对应不同的soc_version，写错了转换时不报错，但推理时会提示模型和芯片不匹配。precision_mode控制精度策略，纯推理场景可以放开到fp16，但如果模型里有对精度敏感的算子，建议保留fp32，否则精度掉点容易甩锅给测试流程。aipp.cfg是图像预处理配置，把归一化、缩放这些操作下沉到AI Core里做，省掉CPU预处理的时间，这一步优化对端到端时延影响很明显，特别是batch size为1的小包场景。

转换完模型后，用msame做推理测速，命令很简单：

msame --model resnet50_bs1.om \ --input data.bin \ --output ./out \ --outfmt TXT

msame输出的信息里有几个关键字段：模型推理的总耗时、平均耗时、吞吐率。不过msame默认是单次推理，为了压测吞吐，我用shell脚本循环跑多次，取稳定段的平均值。还有一个需要注意的地方是batch size。msame会把输入数据按batch拆分成多次推理，如果你的输入data.bin本身就是1张图，那跑batch=4的模型时，msame默认只会推理一次，这个逻辑容易让人误以为测试无效。实际上要准备4张图拼成一个批次输入，或者直接用法B，用benchmark工具指定虚拟输入shape，让它自动填充随机数据。我在实际测试里两种方式都验证过，手工构造数据的实测值和benchmark自动填充的值非常接近，所以后续统一用benchmark工具做大规模压测，msame只用于单帧时延验证。

2.3 功耗采集方式与能效比计算口径

能效比的定义是"单位功耗下完成的推理次数"，公式是fps除以瓦特，单位是fps/W。这个口径本身没问题，但计算时很多人会踩坑：是把整机功耗算进去，还是只用卡上传感器读到的功耗？

我的建议是分开算两套数据。第一套只看卡本身的能效比，用npu-smi info或者nvidia-smi读到的卡功耗；第二套算整机增量功耗，即服务器满载跑推理时的整机功耗减去服务器空载的整机功耗。第二套数据更贴近实际机房电费账单，但注意整机功耗里包含CPU、内存、风扇这些环节的损耗，在batch size小、CPU预处理占比高的场景里，两张卡的整机能效比差距会比卡级能效比缩小，因为CPU成了公共瓶颈。

npu-smi info的典型输出里能看到芯片温度和当前功耗，测试期间我每5秒记录一次：

NPU ID : 3 Chip : Ascend 310P Temperature : 62°C Current Power : 68W AICore Usage : 97%

三张卡满载30分钟后，Atlas 300I Pro记录到的稳定功耗在68W到72W之间，T4稳定在70W到75W，A10稳定在145W到155W。这个数据和标称基本一致，没有出现某些卡满载时功耗远超标称的情况。也就是说，后续算能效比时，分母是有实际数据支撑的，不是拿标称值硬算。

3. 纯算力表现：ResNet-50与YOLOv5s的实测吞吐和时延

账面算力对比只是热身，真正需要关注的是实测吞吐。这里我以ResNet-50 INT8 batch=1和batch=8两组数据为基准，先把三张卡的"硬算力"亮出来，再看框架开销能吃掉多少理论性能。

3.1 INT8与FP16双精度的吞吐数据

先说INT8的ResNet-50测试结果，输入固定为224x224，数据预处理统一走各自框架的TensorRT/ATC算子，不额外统计CPU端的预处理时间：

这个结果基本符合预期：Atlas 300I Pro和T4处在同一水平线上，INT8 batch=1时T4略高约10%，batch=8时差距扩大到约16%。A10凭借翻倍的功耗和算力，吞吐大约能达到T4的两倍，符合"功耗翻倍、性能翻倍"的线性预期。值得注意的是，Atlas 300I Pro的FP16性能差距比INT8更大，batch=8时FP16吞吐只有T4的79%左右。这说明310P芯片的FP16算力相对INT8并不算突出，如果业务对精度要求高、必须跑FP16，那Atlas 300I Pro的竞争力会打折扣。

3.2 批处理大小对吞吐的影响

把batch size从1调到8，三张卡都出现了明显的吞吐增长，但增长的斜率不同。Atlas 300I Pro从2840fps涨到5910fps，约为2.08倍；T4从3120fps涨到6850fps，约2.20倍；A10从5860fps涨到12860fps，约2.19倍。也就是说，在ResNet-50这种计算密集型小模型上，batch size扩大带来的收益是稳定且一致的，没有出现某张卡在batch=4以后就"吃饱了"的情况。

但batch size继续往上走，内存带宽的瓶颈就开始显现。我额外测了batch=32的INT8数据，Atlas 300I Pro吞吐约7210fps，T4约9130fps，A10约16450fps。从batch=8到batch=32，Atlas 300I Pro只增长了22%，T4增长了33%，A10增长了28%。这说明Atlas 300I Pro在较大batch下的扩展能力偏弱，推测和显存带宽以及多芯调度效率有关。实际选型时如果业务并发量大、单请求batch大，这一条要重点权衡。

3.3 从算力利用率看框架开销

很多人拿到TOPS数会直接算一个"理论最高帧率"，然后发现实测值差得远。这里面的差距就是框架开销。ResNet-50 INT8的理论算力需求大约为3.5 GOPs，如果用Atlas 300I Pro的140 TOPS去除以3.5G，理论帧率高达4万fps，但实测batch=1只有2840fps，算力利用率大概20%。T4理论帧率更高，但实测利用率也在18%左右。这说明推理卡实际能发挥的算力，主要受限于算子执行效率、显存访问和调度延迟，而不是芯片的理论上限。

A10的batch=1利用率反而最低，原因在于它标称算力太高，单帧延迟极短时，调度和显存访问开销占比更大。这个现象说明，标称算力越高的卡，如果不在batch size上做足，越容易出现"算力空转"。所以测试推理卡时，不能只看单帧fps，必须把时延和吞吐放在一起看。Atlas 300I Pro在batch=1时0.35ms的时延，与T4的0.32ms已经非常接近，这在实时视频流处理场景里意味着：AI分析不会成为链路瓶颈，CPU解码和前后处理的耗时反而更值得优化。

4. 能效比真刀真枪对比：每瓦特究竟能处理多少帧

算力表现只是上半场，能效比才是这次选型的核心。毕竟机房不是只装一张卡，而是一台服务器塞4张、8张卡，电费是按整个机柜来算的。如果某张卡性能高10%但功耗高30%，大规模部署时电费成本会非常吓人。

4.1 三款主流推理卡的能效比数据

把上文的实测吞吐和实测功耗放在一起，能效比就出来了。还是以INT8数据为例：

这个表格里的数据很有意思。单看能效比，T4依然是最优的，每瓦能处理95帧；Atlas 300I Pro是84.4帧每瓦，比T4低11%左右；A10反而不高，只有85.7帧每瓦，和Atlas 300I Pro几乎持平。换句话说，在INT8推理场景里，A10虽然绝对吞吐高，但它是靠翻倍功耗换来的，能效比并没有比72W的Atlas 300I Pro优势，甚至略低一点。

A10能效比不够突出，其实不奇怪。A10本身定位是通用计算卡，兼顾训练和推理，对推理场景的功耗优化不如T4这种纯推理卡来得彻底。Atlas 300I Pro能在这个对比中和A10打个平手，说明昇腾310P在单位功耗下的INT8算力确实有两把刷子。但要注意，这个优势集中在INT8计算密集场景，FP16下Atlas 300I Pro的能效比会明显掉队。

4.2 长期满载下的功耗曲线与散热表现

能效比只反映稳态数据，长期满载时的功耗波动和散热表现同样决定部署方案。我在连续满载运行2小时后记录了温度数据：

• Atlas 300I Pro芯片温度稳定在62°C左右，风扇转速中等，卡上没有出现降频迹象。
• T4温度稳定在70°C上下，散热器尺寸小但工作正常。
• A10温度稳定在75°C以内，毕竟150W发热量摆在那里，对服务器风道要求更高。

这里要特别说一下Atlas 300I Pro的散热优势。它是被动散热设计，发热量低意味着服务器风扇不用拉到很高转速，机柜噪音和散热功耗都会下降。在4卡满配的服务器里，Atlas 300I Pro平台的风扇转速比A10平台低至少15%，整机噪音低不少。机房部署时如果对噪音有要求，这个差距比性能指标更直观。

4.3 能效比之外的隐藏成本：平台调优成本

能效比好看不等于省钱省心。测试期间我花了大量时间在CANN环境调优上。T4加上TensorRT，基本是"开箱即用"，模型转完TensorRT引擎，性能直接达标；Atlas 300I Pro这边，ATC模型转换之后，还得盯着算子的融合情况，有些模型转换后性能很差，需要检查是哪类算子没有落到AI Core上，甚至要手动改网络结构或者插入Transpose算子来规避低效的数据排布。

举一个具体例子：YOLOv5s的原始ONNX模型直接转om后，INT8 batch=1的实测吞吐只有430fps，明显低于预期。排查过程发现是模型里的Focus层在昇腾上没有对应的高效算子，ATC把它拆成了多个小算子组合，导致AI Core利用率只有50%左右。后来通过手动改模型结构，把Focus层替换成普通的Conv加上Slice和Concat组合，才把吞吐拉到560fps。这个调优过程需要熟悉CANN算子支持列表，T4上跑同一个模型，TensorRT会自动完成等价替换，几乎没有人工干预。所以"能效比高"的卡，其实把一部分隐藏成本转移到了工程师的时间上。这批时间的成本，小规模部署时不明显，大规模部署时是实打实的人力投入。

5. BERT与视频结构化：更贴近真实业务的验证结果

光测ResNet-50和YOLOv5s还不够，业务方真正关心的是自己的链路能不能跑起来。所以我又加了两组更贴近生产场景的测试：BERT文本分类和视频结构化全链路模拟。这两组结果直接影响最终选型，也顺便验证了一个问题：Atlas 300I Pro在非纯卷积网络上的表现到底行不行。

5.1 NLP场景的实测：动态shape带来的性能折扣

BERT-Base是Transformer结构，和CNN最大的区别在于attention类算子对算子和内存的消耗模式完全不同。测试输入序列长度固定为128，batch=1和batch=8两组，精度统一为INT8。

这个结果是全轮测试里Atlas 300I Pro与T4差距最大的一项。batch=1时只有T4的73%，batch=8时只有71%。虽然绝对数字没有差到无法接受，但能从侧面看出昇腾310P在Transformer类算子上的优化深度不如卷积算子。排除了精度问题后，我发现主要是两个原因：一是昇腾的AI Core对矩阵乘的调度效率很高，但attention里的Softmax、LayerNorm这类小算子执行效率一般；二是动态shape支持有限，一旦序列长度在运行时有波动，om模型只能退回到更保守的调度策略。

如果业务主要跑BERT这类Transformer模型，而且序列长度变化很大，建议多考虑T4或者A10。如果模型结构以CNN为主体、少量Transformer分支辅助，Atlas 300I Pro的差距不会那么明显，可以接受。

5.2 CV场景的实测：视频结构化的全链路计算

视频结构化的典型链路是：解码 -> 抽帧 -> 目标检测 -> 特征提取 -> 结构化输出。其中最有计算压力的是目标检测和特征提取两个模型。我在测试里模拟了一路1080p视频流，每秒25帧，目标检测用YOLOv5s，特征提取用ResNet-50，两个模型都跑INT8，Atlas 300I Pro单卡实际能扛住8路视频流，T4能扛住9路，A10能扛住16路。折算到单路视频流的功耗：

• Atlas 300I Pro: 约8.75W每路
• T4: 约8W每路
• A10: 约9.4W每路

视频链路里Atlas 300I Pro和T4的差距缩小到了10%以内，主要原因在于视频流处理负载里更深的是数据搬移和预处理，计算密集度反而不如纯ResNet-50压测时那么极端。这个结果说明一个问题：评估推理卡不能只跑单模型基准，而是要把整条业务链路的算子组合跑一遍。

5.3 多路并发决策：算力之外还要关注内存带宽

多路视频流本质上是多个推理请求并发，batch size会自然变大。这个场景下，Atlas 300I Pro板载显存带宽在并发压力下有些吃紧。测试8路视频流时，整卡AI Core利用率约90%，部分算子已经在等数据从显存搬到芯片上。T4表现稍好，同样8路时利用率约85%，还有一定余量。A10则完全没有带宽压力，16路满载时利用率才刚过80%。

这个细节提醒我们：只看算力利用率是不够的，要同时看显存带宽饱和度和AI Core利用率。如果两者都经常接近100%，说明卡的性能已经被榨干；如果算力利用率不高但显存带宽已经满了，那就是数据搬移成为瓶颈，优化方向应该放在减少Host与Device之间的交互、增大batch size、或者使用模型并行拆分数据通路。

6. 测试过程中踩过的坑：CANN工具链与数据搬运的那些事

每轮测试总会踩几个坑，这轮也不例外。CANN工具链和TensorRT的调试思路差异很大，很多在NVIDIA平台可行的优化手段在昇腾上不奏效，反过来也一样。这些坑如果不提前排掉，很容易把它误判成"卡本身性能差"。

6.1 单芯片模式与双芯片模式的差别

Atlas 300I Pro板载两颗昇腾310P芯片，系统里会识别出两个Device。一开始我直接用默认配置跑msame，发现总吞吐确实高，但时延不稳定，高负载时偶尔出现单帧时延突然翻倍的情况。排查发现是默认调度把请求随机分配到两颗芯片上，而msame统计时延是按整卡维度汇总的，一旦两颗芯片负载不均衡，整体时延自然波动。

解决办法是业务接入口显式指定device_id，比如用环境变量ASCEND_DEVICE_ID把每个推理进程绑定到单独一颗芯片上，或者通过模型实例配置让两个芯片各跑各的模型实例。对于单路低时延请求，绑定单芯片能获得更稳定的时延；对于高吞吐批量请求，则可以保持双芯片并行。生产环境里建议按模型分芯片部署，而不是让两张芯片同时跑同一个模型，避免互相抢占资源。

6.2 数据在Host与Device之间的搬运开销

昇腾架构的Host和Device通信开销比NVIDIA平台更大一些，尤其在Host侧用小CPU做图像解码再拷给Device的场景。我测试视频结构化时发现，如果把解码和预处理全部放在CPU端，然后逐帧拷贝数据给AI Core，端到端时延多出1ms到2ms，几乎占了总时延的30%。

解决思路是尽量把预处理算子下沉到AIPP配置里，让图像缩放、归一化、色彩空间转换这些操作在Device侧完成，减少一次数据来回搬运。还有一个优化点是用异步接口，不要让推理等待CPU预处理完成后再启动，而是用双缓冲策略，前一个batch推理的同时，CPU已经在准备下一个batch的数据。这个优化在CPU性能不太强的主机上效果特别明显，可以把有效吞吐提升20%左右。

6.3 模型转换时精度掉点的排查思路

有一轮YOLOv5s从ONNX转om并量化到INT8后，mAP掉了5个百分点，明显超出正常范围。这个坑最磨人，因为同样的操作在TensorRT上只掉了2个百分点。排查路径是先用FP16跑一遍，确认精度没有明显掉点；再用INT8跑，发现是量化敏感性高而不是算子转换错误。昇腾的INT8量化需要用校准集重新生成量化因子，不能直接沿用TensorRT的校准结果。建议在ATC转换时提供有代表性的校准数据，校准集规模至少500张，覆盖不同光照和物体类别的图像，量化后的精度损失能控制在合理范围。

6.4 归纳一下：昇腾推理卡的适用场景边界

几轮测试下来，我对Atlas 300I Pro的定位有个比较清晰的判断。它最适合的场景是：以CNN为主的视频类推理业务，INT8精度，对功耗和散热敏感，需要大规模部署但不追求极致的单卡延迟表现。在这些场景里，它的能效比接近T4，部分场景甚至能打平A10。不太适合的场景则是：以Transformer为主的大模型推理，或者对FP16精度和动态shape要求极高的业务。这些场景下建议优先考虑T4或A10，避免在模型适配和算子调优上耗费过多精力。

以我这次实际测试的数据和经验来看，单从行业选型角度出发，如果局域网内的推理业务以视频结构化、质检分类、OCR为主，且对华为工具链有一定接受度，Atlas 300I Pro完全值得纳入对比名单；如果团队里都是TensorRT生态的老手、模型以NLP为主，那老老实实用T4/A10会是更省事的选择。性能测试表格只能代表测试样卡在特定软硬件版本下的表现，不同批次、不同固件、不同CANN版本的结果会有浮动，但测试方法和坑位排查思路是通用的，希望对正在做同类选型的人有一点参考价值。