1. 从一场大会聊起算力数字背后的真实困境2026年云栖大会结束之后我跟几个做推理框架和芯片适配的朋友在群里聊到半夜。大家有一个高度一致的感受台上讲算力的数字依然在翻倍但台下真正做落地的人关注点已经明显不在多少TFLOPS上了。过去几年AI芯片行业几乎陷入了一场单维度的军备竞赛——谁的峰值算力高谁就能在PPT上压人一头。但到了今年这套叙事明显撑不住了。我自己从2023年开始陆续接触过几款国产AI加速卡的适配工作从最早的模型移植、算子对齐到后来的多卡并行调优踩过的坑基本覆盖了算力标称很美、实际跑起来很骨感的全过程。这篇文章想聊的核心就是一件事为什么国内AI芯片只卷算力已经不够了超节点、全栈能力、时延这些维度为什么开始变成真正的胜负手。不管你是做模型部署的工程师、做芯片选型的架构师还是刚入行想搞清楚算力到底怎么评估的新人这篇内容应该都能给你一些可以直接参考的判断框架。先把结论摆前面算力是入场券不是终点线。一颗芯片或者一个集群能不能真正把大模型跑好取决于算力、互联、时延、软件栈、精度支持这五个维度能不能协同。任何一环拖后腿峰值算力都会变成纸面数字。下面我按自己的理解把这几个维度拆开讲透。2. 算力到底该怎么看别被峰值数字骗了2.1 峰值算力、有效算力与算力利用率很多人评估算力第一反应就是看芯片手册上的峰值TFLOPS。这个数字通常是在理想条件下测出来的比如特定精度、特定矩阵尺寸、连续无中断的计算流。但真实的大模型推理和训练根本达不到这种理想状态。我一般会把算力分成三层来看峰值算力厂商标称的理论上限通常基于INT8或FP16的稠密矩阵乘。有效算力在真实模型、真实batch、真实序列长度下能跑出来的算力。算力利用率MFU有效算力除以峰值算力这个比值才是真正决定成本的东西。实测下来很多国产卡在跑主流大模型时MFU能到30%到50%就已经算不错了。也就是说标称256 TFLOPS的卡实际有效算力可能只有80到130 TFLOPS。如果互联和软件栈再拖后腿掉到20%以下也不罕见。所以选型时只盯峰值基本等于自欺欺人。2.2 INT8、FP16、FP32、FP64的算力需求差异热词里提到了int8、fp16、fp32、fp64的区别和算力需求这个点非常关键因为不同精度直接决定了芯片的实际吞吐。精度类型典型用途相对算力需求对芯片的要求INT8推理量化、部分训练最低整数单元功耗友好FP16/BF16主流训练与推理中等张量核心支持FP32高精度训练、科学计算较高通用浮点单元FP64科学仿真、HPC最高双精度单元成本极高这里有个常见的误区很多人以为精度越高越好。实际上大语言模型训练现在主流用的是BF16甚至FP8推理更是大量走INT8和INT4量化。FP64在AI场景里用得极少因为它的算力吞吐通常只有FP16的几十分之一而大模型对双精度的需求并不高。所以一颗芯片如果堆了大量FP64单元在AI场景里反而是资源浪费。反过来如果一颗芯片的INT8算力很强但FP16很弱那它在训练场景就会很吃力。评估算力需求第一步是明确你的主战场是训练还是推理、用什么精度、batch和序列长度大概多少脱离这些谈算力就是空谈。2.3 如何评估自己需要的算力这是我被问得最多的问题之一。我的经验是分三步走算模型规模参数量乘以每个参数在训练/推理时的计算量。粗略估算训练一个N参数的模型单次前向加反向大约需要6N次浮点运算。算吞吐目标你每天要处理多少token、多少请求换算成每秒需要的计算量。留冗余在理论值基础上乘1.5到2倍的冗余系数因为通信、调度、内存搬运都会吃掉算力。举个例子假设你要部署一个70B参数的模型做推理目标吞吐是每秒2000 token。按每token约2N次运算估算就是每秒约2.8乘10的14次方次运算也就是280 TFLOPS的有效算力需求。如果MFU按40%算那峰值算力至少要700 TFLOPS。这个数字一出来选型范围立刻就清晰了。提示算力评估一定要用真实业务数据回测别用厂商给的理想benchmark。我见过太多项目因为直接采信标称数字上线后性能只有预期的三分之一。3. 超节点与互联算力之外的第一个真战场3.1 为什么单卡算力再高也救不了集群大模型早就不是单卡能装下的了。70B模型用FP16存权重就要140GB加上优化器状态和激活值训练时轻松超过1TB。这意味着你必须把模型切到多张卡上而一旦切分卡与卡之间的通信就成了瓶颈。我做过一个对比实验同样8张卡一张互联带宽高的卡和一张互联带宽低的卡跑同一个模型端到端吞吐差了将近2.3倍。算力明明一样差距全在通信上。这就是为什么超节点这个概念开始火起来——它本质上是在解决大规模卡间互联的效率问题。3.2 超节点的核心把通信时延压到最低超节点SuperPod的核心思路是把几十甚至上百张加速卡通过高速互联组成一个逻辑上的大芯片让卡间通信尽可能接近片内通信的体验。这里面有几个关键技术点互联拓扑从传统的树形、环形演进到全互联或类全互联结构减少跳数。互联带宽单卡互联带宽从几百GB/s往TB/s级别走。通信协议需要专门的集合通信库来优化all-reduce、all-gather这些操作。时延在这里是致命的。大模型训练里每层都要做梯度同步如果每次同步的时延是毫秒级累积起来就是巨大的浪费。超节点要解决的就是把时延从毫秒压到微秒级让通信开销在总计算时间里占比尽可能小。3.3 多径时延与网络拥塞的实际影响热词里出现了多径时延这个词在网络领域很常见放到AI集群里同样适用。当你的集群规模上去之后数据包从一张卡到另一张卡可能走多条路径不同路径的时延不一样就会导致乱序和重传进一步拉高有效时延。我遇到过一个典型问题集群规模到64卡以上时训练吞吐突然掉了一大截。排查下来发现是某几条链路的拥塞导致all-reduce的尾时延被拉长整个同步操作要等最慢的那条路径。解决办法是引入更智能的拥塞控制和路径调度让流量分布更均匀。问题现象可能原因排查方向小规模正常大规模掉速互联拓扑瓶颈检查跨节点带宽训练吞吐波动大网络拥塞、多径时延抓包看尾时延同步操作耗时占比高集合通信未优化换通信库或调参注意超节点不是简单地把卡堆在一起互联设计、拓扑规划、通信库优化缺一不可。买回来插上就能跑出标称性能的情况基本不存在。4. 全栈能力芯片厂商的软实力较量4.1 为什么全栈成了高频词全栈这个词在AI芯片语境里指的是从芯片硬件、驱动、编译器、算子库、框架适配到上层模型部署工具链的完整能力。为什么它重要因为一颗芯片的硬件再强如果软件栈跟不上开发者用不起来那它就是一块昂贵的砖头。我接触过一款早期国产卡硬件参数很漂亮但算子库覆盖不全很多主流模型的算子要么没有、要么性能很差。结果团队花了两个月自己写算子项目周期直接翻倍。这就是全栈能力缺失的代价。4.2 全栈的五个层次我一般把AI芯片的全栈能力拆成五层硬件层芯片本身的计算单元、内存、互联。驱动与运行时让硬件能被操作系统和框架识别调度。编译器与算子库把模型图编译成硬件能执行的高效指令。框架适配对PyTorch、TensorFlow等主流框架的支持程度。应用工具链量化、蒸馏、部署、监控等配套工具。这五层里编译器与算子库是最容易拉开差距的地方。同样的硬件编译器优化得好性能能差出好几倍。这也是为什么很多厂商拼命招编译器团队——硬件可以买IP但编译器得自己啃。4.3 全栈实战中的真实体验我之前做过一个脑机加YOLOv11加全栈的demo项目虽然场景偏实验但把全栈的痛点暴露得很清楚。从数据采集、模型训练、量化压缩到边缘部署每一步都依赖不同的工具链。如果芯片厂商只提供底层驱动上层全靠自己搭工作量会大到离谱。反过来如果厂商提供了完整的模型转换工具、量化工具和部署SDK整个流程能压缩到几天。全栈能力的价值最终体现在开发者的时间成本上。这也是为什么现在选型时我会把软件栈成熟度和硬件参数放在同等重要的位置。5. 时延被长期低估的关键指标5.1 训练时延与推理时延的区别时延这个词在不同场景下含义完全不同。训练场景关注的是通信时延和同步时延推理场景关注的则是首token时延和单token时延。训练时延主要体现在梯度同步、参数更新上规模越大越敏感。推理首token时延用户发出请求到收到第一个token的时间直接影响体验。推理单token时延生成每个后续token的时间决定整体吞吐。很多芯片在吞吐benchmark上表现很好但首token时延很高因为prefill阶段的计算和内存访问模式跟decode阶段完全不同。如果你的业务是实时对话首token时延比吞吐更重要。5.2 时延优化的几个实操方向我总结了几条实际有效的优化路径KV Cache优化推理时把历史key/value缓存好避免重复计算能大幅降低单token时延。连续批处理把多个请求动态合并成batch提高计算密度摊薄单请求时延。算子融合把多个小算子合并成一个大算子减少kernel启动和内存搬运开销。量化INT8量化能把内存带宽压力降一半时延通常也能降30%以上。提示时延优化要先定位瓶颈。用profiler看清楚时间花在计算、内存还是通信上再对症下药。盲目优化往往事倍功半。5.3 时延与算力的权衡这里有个反直觉的点有时候降低算力反而能降低时延。比如在某些推理场景用更小的模型配合更好的量化虽然峰值算力需求低了但时延和成本都更优。所以卷算力的思路在时延敏感场景里未必成立关键是找到算力、时延、成本三者的平衡点。6. 常见问题与排查技巧实录6.1 算力评估类问题问题一标称算力很高实际跑不满怎么办先别怀疑硬件按这个顺序排查模型算子是否都被硬件原生支持、batch size是否太小、内存带宽是否成为瓶颈、通信是否拖后腿。我遇到过好几次都是因为batch太小硬件根本喂不饱。问题二怎么判断是算力不够还是软件不行做个对照实验用厂商提供的最优benchmark跑一遍再用你的真实模型跑一遍。如果差距巨大大概率是软件栈或算子适配问题不是算力问题。6.2 互联与时延类问题问题三集群规模上去后性能反而下降这是典型的互联瓶颈。检查跨节点带宽、集合通信库配置、网络拓扑。很多时候把all-reduce换成更高效的实现性能就能回来一大截。问题四推理首token特别慢重点看prefill阶段的算子效率和KV Cache的初始化。prefill是计算密集型如果算子没优化好首token时延会非常难看。6.3 全栈适配类问题问题五模型移植到新卡上跑不起来先确认框架版本和驱动版本匹配再确认算子覆盖。缺算子的话要么等厂商补要么自己写。自己写算子前先评估工作量和性能收益别一头扎进去。问题六量化后精度掉得厉害量化不是无脑INT8。要做校准、要选对量化粒度per-tensor还是per-channel、要对敏感层保留高精度。我一般会先做逐层敏感度分析再决定哪些层量化、哪些层保留。常见问题快速排查解决方向算力跑不满看batch、算子、带宽调batch、补算子大规模掉速查互联和通信库优化拓扑和集合通信首token慢看prefill算子算子融合、KV Cache量化掉精度逐层敏感度分析混合精度量化6.4 几条独家避坑心得第一选型时一定要做POC而且要用自己的模型。厂商的demo都是精心调过的参考价值有限。第二软件栈的成熟度比硬件参数更难补。硬件差一点可以忍软件栈差会让你寸步难行。第三时延指标要分场景看。训练看通信时延推理看首token和单token时延别混为一谈。第四超节点不是万能药。如果你的模型规模不大单节点甚至单卡就能跑好没必要上超节点反而增加复杂度和成本。7. 从算力单维到多维协同的选型思路回到最开始的问题为什么国内AI芯片只卷算力不够了因为大模型落地是一个系统工程算力只是其中一个维度。超节点解决互联全栈解决易用性时延解决体验精度支持解决场景适配。这几个维度任何一个短板都会让峰值算力变成空中楼阁。我自己现在的选型框架是这样的先明确业务场景训练还是推理、什么精度、什么时延要求再评估算力需求然后重点考察互联能力和软件栈成熟度最后用真实模型做POC验证。这套流程走下来基本能避开大部分坑。AI芯片的竞争已经从谁的算力数字大进入到谁能把整个系统跑通、跑好、跑便宜的阶段。这对厂商是挑战对开发者其实是好事——因为这意味着我们有了更多真正可用的选择而不是只能对着参数表做取舍。最后分享一个小技巧评估任何一款芯片或集群先别急着看峰值算力先问三个问题——互联带宽多少、算子库覆盖怎么样、真实模型MFU能到多少。这三个问题的答案比任何标称数字都更能说明问题。
