AI芯片参数避坑指南：算力、功耗与端到端吞吐的真相

1. 算力参数里的三类水分为什么标称值要打七八折每次打开一款AI加速卡的规格表最显眼的一定是算力数字。几百TOPS、几百TFLOPS看着就很有冲击力。但我在实际项目里拿这些芯片跑模型时很少能看到标称值的80%多数场景甚至只有50%到60%。这不是厂商造假而是因为标称算力本身描述的是一种极端理想状态真实负载根本到不了。下面拆开看三类水分。1.1 峰值频率不可持续标称算力是极限运动成绩芯片规格表里的算力默认是满频率、满负载、供电充足、散热到位同时流水线没有任何停顿浪费的条件。这就像汽车宣传的最高时速它在封闭赛道上能跑出来但在城市道路走走停停的状态下完全没意义。AI计算负载恰恰是走走停停的一个Transformer模型里有矩阵乘法、Norm、激活、注意力、Reshape每个算子的计算密度和访存行为都不一样计算单元一会儿被喂满一会儿又停下来等数据。实际统计下来一个优化得不错的训练脚本能把芯片算力用到标称值的五成到六成已经算调度高手了。如果模型里还带着大量动态shape、小算子、控制流利用率掉到四成以下都不奇怪。所以看到标称算力以后我习惯先在心里乘个0.5再决定硬件够不够这个习惯帮我避掉了很多理论上跑得动的坑。1.2 稀疏算力不一定用得上别被两倍数字迷惑很多芯片会同时宣传两个算力数字稠密算力和稀疏算力。稀疏算力通常约等于稠密算力的两倍原理是计算单元能跳过权重矩阵中的零元素只算非零部分。听上去很划算但这里有个前置条件硬件通常只对严格的结构化稀疏加速典型的是2:4模式——每四个元素里恰好两个为零计算单元才能走专用流水线。现实中的模型权重极少天生满足这种整齐的稀疏分布想用上这份稀疏算力就得先做结构化剪枝而剪枝往往带来精度损失微调成本也不低。所以我在选型时干脆只看稠密算力稀疏算力只当加分项参考从来不拿它做算力预算。供应商拿稀疏数字来对比时我一般会直接问一句我的模型不做结构化剪枝实际能吃到多少加速比例对方支支吾吾的时候答案基本也就清楚了。1.3 精度档位换来换去先问清楚是在什么精度下测的同样是每秒几百万亿次运算FP32、TF32、FP16、INT8、INT4代表着完全不同的能力等级。很多芯片标称的超高算力是在它最擅长的精度档位下测出来的换一个精度档位数字可能直接腰斩甚至更低。以前遇到过一个典型案例某块加速卡宣传页上INT8算力非常猛我拿它跑量化推理框架吞吐却平平无奇。后来一查那个亮眼数字依赖一种特定的数据布局和缓存模式推理框架的默认路径根本走不到。反过来如果拿FP16算力去估训练任务也容易偏乐观因为训练里大量算子为了保证收敛精度会落到FP32或混合精度。所以看算力前先弄清楚四件事什么运算精度、稠密还是稀疏、峰值还是持续、缓存命中的理想条件是什么。问完这四件事算力数字里的水分基本就挤掉大半了。2. 把TOPS、TFLOPS和真实吞吐放进同一张表里对比算力数字本身不复杂复杂的是单位。同一块芯片看TOPS和看TFLOPS会得出完全不同的印象更别说不同厂商各说各话。把基础概念理清楚才能避免拿苹果比橘子。2.1 整数与浮点TOPS和TFLOPS根本不是一回事TOPS里的OPS泛指操作数通常指整数运算TFLOPS里的FLOPS专指浮点运算。量化推理、图像预处理、传统信号处理主要消耗整数算力用TOPS衡量合适训练、科学计算以及大模型中非量化的矩阵运算需要浮点精度用TFLOPS更合适。指标含义典型适用场景TOPS每秒万亿次整数操作量化推理、边缘AI、图像处理TFLOPS每秒万亿次浮点操作训练、科学计算、高精度推理硬件层面还有一个细节一条乘加指令在浮点场景下算两个FLOPs但TOPS只把它计成一次操作所以同频率下TOPS数值天然要高一些。实际做评估时我建议不要强行换算两个单位而是按业务主场景挑对应指标——推理为主盯TOPS训练为主盯TFLOPS别混着比。2.2 用7B模型做例子推算推理需要多少算力如果要评估一块芯片能不能满足某个大模型推理需求可以用一个粗公式估计理论下限。以70亿参数量的模型为例生成一个token前向计算大约要执行两倍于参数量的浮点运算也就是约140亿次。假设目标是每秒生成20个token那理论上只需要0.28 TFLOPS左右的计算力。听起来是不是特别低这里要注意理论下限四个字。实际推理引擎还有注意力计算、KV Cache更新、中间激活、多batch并发、框架调度开销真实所需算力是这个值的好几倍以上。而且大模型生成token时权重要反复从显存搬到计算单元如果带宽跟不上高算力芯片一样跑不快。所以算力估算只用于初筛最终还得看端到端实测。2.3 单指标对比无效六项联合视图才是正确姿势AI芯片性能不是木桶里最长的那块板而是最短的那块。只看算力很容易得出错误结论。我们团队内部遇到过一个典型案例A芯片的INT8算力标称比B芯片高30%但跑同一个目标检测模型时A的帧率反而比B芯片低两成。查到最后瓶颈在显存带宽——A的带宽只有B的六成小batch时喂不饱算力大batch时显存又先不够。从那以后我们做选型对比只用一张固定模板表把六项指标放一起看稠密FP16算力、稠密INT8算力、显存容量、显存带宽、整卡峰值功耗、卡间互联带宽。任何一款新芯片进来先填这张表再去谈场景适配。单独拿一个数字来比性能的多半会踩坑。3. 功耗和能效比真正决定集群规模的上限变量很多算法出身的朋友看芯片只关心算力直到把设备买回来、装进机房、跑上高负载才意识到功耗才是真正决定规模的天花板。这一节说说功耗指标怎么看。3.1 TDP不是实测功耗配电与散热要按更高余量设计规格表里的TDP热设计功耗可以理解成散热系统要压住的最大发热量但它不是实际功耗上限。不少芯片在高负载下瞬时功耗能冲到TDP的110%如果是boost机制比较激进的型号持续时间还不短。数据中心规划如果按TDP乘卡数来算电源和空调容量压力测试时大概率出事。我参与过的一个模拟集群项目按标称功耗配的机柜电源系统一跑满几分钟就开始告警最后配电全部重做整个项目的交付周期都被拖了。现在做方案我习惯在TDP基础上加20%到30%的功率余量同时留出未来换更高功耗卡也不跳闸的冗余这是被现实教育出来的经验。3.2 能效比横向对比一瓦换多少有效算力最实在能效比的公式很简单算力除以功耗。但要注意分母和分子各自取的是什么值。拿峰值算力算能效比只能说明理论极限更有意义的做法是拿实测算力除以整卡实测功耗。芯片标称算力实测功耗能效比实测3000W机柜可部署卡数A500 TFLOPS450W1.11 TFLOPS/W约6张B400 TFLOPS250W1.6 TFLOPS/W约12张纸面上A性能更强但在功率预算固定的机柜里B能塞进去的卡数更多总有效算力反而更高。大规模集群里单卡绝对算力再高用得上多少卡才决定最终性能。所以我做集群方案时能效比优先级常常排在峰值算力前面。3.3 全生命周期电费账低能效卡用起来更贵算力卡通常要开好几年电费是笔不小的运营开销边缘场景里这个差距更明显。举个例子某视频分析设备方案对比两款算力接近的边缘芯片一张8W一张20W。单看单卡功耗差12W好像没什么但设备7×24小时连续跑一年下来单卡多耗一百多度电。如果项目规模是几百台设备一年多出来的电费就非常可观足够把采购成本差倒转过来。所以选型时别只看采购价把生命周期电费、散热成本、机房租金摊进去算总账。业内那句话是真的便宜的卡用起来贵贵一点的卡可能反而更省钱。4. 显存、带宽与互联数据喂不饱算力就是白搭算力决定你算得快不快存储和互联决定你能不能把数据送进计算单元。这两个维度很容易在参数表里被忽略却是真实项目的头号瓶颈。4.1 显存容量和带宽决定模型能不能装、token出得快不快先看容量。现在的大模型动辄几十GB起步7B模型纯权重按FP16存就是14GB训练模式下还要加上优化器状态、梯度、激活值轻松超过30GB甚至50GB。显存容量不够就得引入重计算、梯度检查点、流水并行训练代码复杂度立刻上一个台阶。再看带宽。大模型推理生成每个token时都要把权重从显存搬到计算单元带宽直接决定这个过程的下限。还是7B模型权重14GB带宽1TB/s时读一遍大约14毫秒带宽500GB/s时就要28毫秒。这就解释了为什么很多标称算力很高的芯片跑对话模型生成token的速度反而一般——瓶颈根本不在算力在显存带宽。选型时先看模型规模和带宽需求再谈算力。4.2 多卡互联拓扑训练缩放效率的命门单卡装不下大模型就得靠多卡并行。这时候卡间互联带宽和拓扑结构决定了梯度同步要花多久。训练过程中每过一个batch所有卡都要用AllReduce之类的集合通信把梯度汇总通信时间占比越高整体加速比越差。如果节点内八张卡是环形互联数据要绕一圈才能汇总如果是全互联拓扑所有卡可以同时交换数据效率完全两个量级。所以看互联指标不能只看单条链路速率还要看拓扑结构、端口数量以及是否支持RDMA这类低时延机制。实际做8卡和16卡扩展性测试时如果加卡之后吞吐不是线性增长八成是先卡在通信瓶颈上。4.3 用profiling确认瓶颈计算单元空闲往往指向带宽问题拿到芯片后怎么确认瓶颈到底在哪别拍脑袋用性能剖析工具看数据。最经典的判断方法计算单元利用率很低但显存带宽利用率很高说明任务卡在带宽上反过来计算单元跑满了带宽还有余量才说明算力调度到位。还有一种典型场景是通信占比过高明明计算单元在忙但一个训练step的总时间有很大比例耗在梯度同步上这时就得考虑通信计算重叠、梯度压缩或者换互联更强的硬件。我见过不少团队训练变慢了就以为算力不够急急忙忙换卡最后profiling一查连带宽瓶颈都没定位到钱花得冤枉。养成跑profiling的习惯比多看十页参数表都管用。5. 端到端吞吐才是最终裁判从参数表到真实表现的最后一公里说了这么多硬件指标最终让业务跑起来的其实是软件生态把硬件能力兑现了多少。有些芯片参数很漂亮真要上手跑模型才发现框架适配不完整、算子覆盖不全性能表现远远达不到预期。5.1 算子覆盖率和编译器效率硬件很强但软件拖后腿即使芯片计算单元很强如果上层框架没针对核心算子做过深度优化调用时会落到通用实现甚至CPU兼容路径性能快速劣化。算子覆盖率可以简单理解成目标模型用到的算子里有多少能在该芯片上走高效加速路径。覆盖率不够模型性能不是线性下降而是断崖式下跌。编译器效率同样重要。同一个Transformer结构在不同芯片的编译优化下推理延迟可能差两三倍。所以芯片选型时软件栈成熟度和硬件参数要放同等重要位置。最靠谱的验证方式就是拿自己业务里最典型、最有代表性的模型在原厂SDK环境下真跑一遍别用厂商给的参考跑分下结论。5.2 训练吞吐和推理延迟实测benchmark的正确姿势真正决定AI芯片价值的指标是端到端性能。训练场景看训练吞吐单位常见是samples/sec或tokens/sec推理场景除了总吞吐还要看首token延迟TTFT和后续token生成延迟TPOT这两个指标对在线对话场景尤其关键。做对比测试时有几个变量必须固定模型结构、参数量、batch大小、序列长度、量化精度、并发数。厂商提供的benchmark很容易在某个变量上做有利于自己的微调比如缩短序列长度或者用小batch刷高吞吐。我的习惯是自己搭一套相同配置在两个候选芯片上分别跑然后画吞吐-延迟曲线。有些芯片低batch性能惊艳高并发后性能坍塌这种芯片做离线批量任务可以做在线服务就要小心。5.3 选型前务必确认的五个关键问题把前面所有内容梳理完落到实际操作我建议任何人在敲定AI芯片方案前至少向供应商问清楚下面五件事目标模型在芯片上的参考成绩是什么测试配置是否可复现推理引擎对INT8、FP8等低精度量化的支持成熟度怎么样有没有配套量化工具链主流训练框架的实现是官方原生支持还是社区补丁在维护这关系到后续升级框架会不会踩坑。多卡并行在8卡、16卡集群下的实际集合通信效率是多少扩展性曲线是不是接近线性官方性能剖析工具能否定位算力、带宽、通信三类瓶颈这决定了上线后做性能调优的难度。这五个问题问完参数表里那些数字才真正有了落地的参照系。硬件指标只是上限软件能兑现多少才是你真正拿到的性能。最后补充一句我从选型踩坑里学到的体会AI芯片指标这件事最怕的不是某个数字虚高而是只看一个数字就做决定。算力、功耗、显存、带宽、互联、软件它们是一个系统任何一个短板都会拖垮整体。我现在的习惯是拿到新芯片先翻显存带宽和算子支持列表再拿一个业务里最有代表性的小模型跑端到端吞吐两三轮下来基本不会被花哨参数带偏。希望这篇内容能帮你在下次看AI芯片参数时多留一个心眼。