1. 从一场大会的展台动线说起算力数字为什么不再是唯一焦点如果你今年在云栖大会的展区里从头走到尾会发现一个很微妙的变化前几年最热闹的展台往往是那些把TOPS数字印得比人还高的芯片厂商参数表上动辄几百上千TOPS观众围一圈拍照发朋友圈。但今年真正让人停下来聊很久的反而是那些讲一个机柜里怎么把几十张卡连成一台逻辑上的大机器训练框架怎么自动把算子切到最合适的硬件单元上的展台。这个变化不是偶然。它背后是一个行业共识正在形成单卡算力已经卷到了一个边际收益急剧下降的区间。你把一张卡的峰值算力再翻一倍落到真实的大模型训练任务上端到端吞吐可能只涨了百分之十几甚至因为互联瓶颈、内存墙、调度开销实际收益还要再打个折。这就是为什么只卷算力不够了这句话今年会被反复提起。我先把结论摆在前面方便你带着问题往下看国内AI芯片的竞争重心正在从单点峰值算力转向三个更硬核的维度——超节点级别的系统互联能力、全栈软件栈的成熟度、以及真实业务场景下的有效算力利用率。这三个维度里任何一个掉链子前面堆的算力数字都会大打折扣。这篇文章适合谁看如果你是做AI基础设施选型的技术负责人或者是在做推理/训练平台优化的工程师又或者你只是想知道为什么参数越来越漂亮但体感提升不明显那接下来的内容应该能帮你把这件事想清楚。我会尽量用从业者之间聊天的口吻把原理、实操、踩坑都摊开讲。2. 单卡算力堆到天花板之后瓶颈到底卡在哪2.1 内存墙算力再高喂不饱就是空转先讲一个最容易被忽略的事实芯片的峰值算力是在数据已经躺在计算单元旁边的理想状态下测出来的。真实训练里数据要从显存搬到片上缓存再从缓存喂给计算单元这个搬运过程的速度就是所谓的带宽。你可以把计算单元想象成一个超级能吃的胃算力就是它的消化能力而显存带宽就是食道。胃再大食道细进食速度上不去消化能力就是浪费的。大模型训练里大量的矩阵乘、注意力计算本质上都是数据搬运密集型操作对带宽的敏感度极高。这就解释了一个现象为什么有些卡纸面算力很高但跑起Transformer类模型来实际吞吐还不如一张算力数字低一截、但显存带宽和缓存设计更均衡的卡。算力与带宽的比例也就是常说的计算强度匹配比单纯的算力绝对值更重要。行业里有个粗略的经验当你的模型计算强度低于硬件的拐点时性能就被带宽锁死高于拐点时才轮到算力说话。而大模型里大量的逐元素操作、归一化、softmax计算强度都不高。2.2 互联墙卡越多通信开销越像滚雪球第二个瓶颈是互联。单机八卡时代卡间通信走的是板级高速总线延迟低、带宽高大家还能接受。但当集群规模上到几百上千卡跨机通信就成了大头。分布式训练里有个绕不开的环节叫梯度同步。数据并行下每张卡算完自己那份梯度要把梯度汇总再分发回去。这个all-reduce操作的通信量跟模型参数量成正比。模型越大通信量越大而通信带宽的增长速度远远赶不上算力增长速度。结果就是算力翻倍通信时间没怎么变通信占比反而越来越高卡越多等通信的时间越长有效算力利用率越低。我见过一个很典型的场景某团队把集群从64卡扩到256卡理论上训练速度该快4倍实测只快了不到2倍。排查下来通信占比从原来的15%涨到了接近50%。这就是典型的互联墙——你买的算力有一半在等数据。2.3 调度墙异构硬件让有效算力更难榨干第三个瓶颈更隐蔽叫调度。现在一个集群里往往不是清一色的同款卡可能有不同代际、不同厂商的加速卡混布。不同硬件的算子支持程度、编译路径、内存模型都不一样。如果调度层不能感知这些差异就会出现任务被分到了不擅长的硬件上的情况。举个具体的某些卡对特定精度的矩阵乘有专门优化另一些卡在同样的算子上要走通用路径性能差好几倍。如果调度器只看这张卡空着就派活那有效算力利用率会非常难看。调度墙的本质是软件层没有把硬件的差异化能力翻译成任务可感知的调度策略。把这三堵墙放在一起看你就明白了单卡算力只是入场券真正决定集群产出的是算力能不能被喂饱、能不能被连起来、能不能被精准调度。这也正是超节点和全栈这两个词今年被反复提的原因。3. 超节点不是堆卡它解决的是逻辑上一台机器的问题3.1 超节点的本质把互联做成系统级能力超节点Super Node这个词听起来很唬人但拆开看它要解决的核心问题很朴素让几十甚至上百张加速卡在软件视角下表现得像一台机器。传统集群里跨机通信要走网络协议栈层层封装延迟高、开销大。超节点通过更高带宽、更低延迟的互联拓扑比如把多张卡通过高速交换芯片组成一个更大的域把原本跨机的通信变成域内通信。这样all-reduce、all-gather这些集合通信操作的延迟能降一个数量级。为什么这件事重要因为大模型的并行策略越来越复杂。张量并行把一层拆到多张卡上对通信延迟极其敏感延迟高一点收益就被吃光。超节点让张量并行能跨更多卡而不用付出跨机的代价这直接决定了你能训多大的模型、用多高的并行度。3.2 互联拓扑的取舍全连接、胖树还是环超节点内部的互联拓扑是有取舍的。常见的有几类拓扑类型特点适用场景代价全连接任意两卡直连延迟最低小规模高密度域交换芯片成本高扩展性受限胖树分层交换带宽可收敛中大规模集群上层交换压力大配置复杂环状/网格结构简单成本低特定通信模式非邻居通信要绕路延迟高选哪种取决于你的主力负载是什么。如果你的训练任务大量用张量并行那域内延迟就是命根子值得为全连接或高带宽胖树多花钱。如果你的负载以数据并行为主通信模式规整那环状拓扑配合好的通信库也能接受。这里有个实操经验别只看标称互联带宽要看有效带宽。标称带宽是物理链路峰值实际能跑出多少取决于通信库对拓扑的利用效率、是否有拥塞控制、消息大小是否匹配。我见过标称带宽很高但小消息延迟拉胯的互联方案跑起真实负载来还不如老一代。3.3 超节点对软件栈提出的新要求超节点不是插上电就能用的。它把硬件复杂度转移到了软件层。通信库要能感知拓扑自动选择最优路径集合通信算法要根据域内域外的带宽差异做分层设计故障域管理要重新定义——以前一张卡挂了影响有限现在一个超节点域出问题可能影响几十张卡上的任务。所以你会发现能做好超节点的厂商往往软件栈也不弱。因为超节点的价值一大半要靠软件释放出来。硬件只是搭了台子戏怎么唱是软件的事。4. 全栈为什么成了分水岭从能跑到跑得好的距离4.1 全栈到底指什么四层缺一不可全栈这个词被用烂了但在AI芯片语境下它有明确的所指。我把它拆成四层硬件层加速卡、互联、内存子系统驱动与运行时层设备管理、内存分配、任务下发编译与算子层图编译、算子融合、自动调优框架与工具链层对主流训练/推理框架的适配、调试工具、性能分析这四层里任何一层薄弱用户体感就会差。硬件再强驱动不稳训练动不动挂算子库不全模型跑不起来框架适配差迁移成本高到劝退。4.2 算子覆盖度决定能不能跑的第一道门槛我接触过不少团队选型时第一句话就是你们支持哪些模型。这背后其实是算子覆盖度的问题。一个大模型里可能有几百种算子主流的有矩阵乘、卷积、注意力、各种归一化、激活函数。如果某个冷门但关键的算子没被高效实现整个模型就得回退到通用路径性能断崖式下跌。算子覆盖度不是有没有而是好不好。有算子但性能差等于没有。判断一个芯片的算子成熟度别只看官方列表要看它在真实模型上的端到端表现。我的做法是拿一个自己熟悉的、结构有代表性的模型直接跑一遍看哪些层耗时异常再针对性问厂商这些算子的实现细节。4.3 编译器的自动调优把硬件潜力翻译成实际性能编译器是连接模型和硬件的桥梁。好的编译器能做算子融合把多个小算子合成一个大算子减少访存、内存复用复用显存块降低峰值占用、自动调优为每个算子搜索最优的切分和调度方案。这里有个反直觉的点编译器的自动调优往往比手写算子更能榨干硬件。因为硬件参数空间太大人工调优只能覆盖常见配置而自动搜索能在编译期针对具体模型形状找到更优解。当然前提是编译器的搜索空间设计得合理否则会陷入调优时间比训练时间还长的尴尬。4.4 框架适配的隐性成本迁移不是改个import很多团队低估了框架适配的成本。以为换个后端就是改个import实际上从数据加载、分布式策略、混合精度、检查点保存到调试工具、性能分析每一环都可能踩坑。我建议在选型阶段就做一次小规模迁移验证拿一个中等规模的模型完整走一遍训练和推理流程记录每一步的耗时和报错。这个过程能暴露大量文档里不会写的问题。比如某些框架的分布式采样器在新硬件上行为不一致某些混合精度配置会导致数值不稳定。这些坑只有真跑过才知道。5. 有效算力利用率一个比峰值算力诚实得多的指标5.1 MFU衡量买到的算力用了多少行业里有个指标叫MFUModel FLOPs Utilization模型浮点运算利用率简单说就是你的模型实际需要的计算量除以硬件峰值算力乘以时间。这个比值越高说明算力浪费越少。一个健康的训练任务MFU能到40%到50%就算不错了很多场景其实只有20%到30%。这意味着你花大价钱买的算力一大半在空转或者等通信。所以选型时与其比峰值算力不如比在目标模型上的MFU。这个数字才是真金白银。5.2 影响MFU的几个隐形杀手我总结了几类最常见的MFU杀手数据加载瓶颈GPU在等CPU喂数据尤其是小文件多、预处理复杂的场景通信占比过高前面讲的互联墙直接吃掉有效算力算子效率低某些算子在特定硬件上走了低效路径显存碎片频繁分配释放导致显存利用率下降触发不必要的同步精度转换开销混合精度里频繁的cast操作累积起来很可观排查MFU我一般用性能分析工具先看时间都花在哪是计算、通信、还是等待。定位到瓶颈再针对性优化比盲目调参有效得多。5.3 从峰值到有效选型思路的转变这个转变很关键。以前选型看参数表现在应该看场景化的基准测试。具体做法明确你的主力负载是训练还是推理模型结构是什么规模多大准备一个有代表性的基准最好是你自己业务的真实模型脱敏版在候选硬件上跑记录端到端吞吐、MFU、稳定性把软件栈成熟度、迁移成本、长期维护纳入评估这套方法比看参数表麻烦但能避免买回来发现跑不动的尴尬。我见过太多团队被峰值数字忽悠上线后才发现有效算力只有预期的一半。6. 真实场景里全栈能力是怎么拉开差距的6.1 训练场景大规模并行下的稳定性考验训练场景最考验全栈能力。一个千卡级别的训练任务跑几天几夜中间任何一层出问题都会导致任务中断。驱动崩溃、通信超时、显存泄漏、检查点损坏每一个都是噩梦。全栈强的团队会在这些地方下功夫容错机制任务中断能快速恢复、健康检查提前发现慢卡、坏卡、弹性调度动态调整并行度。这些能力不是单点技术而是系统工程。我见过一个团队硬件配置不算顶尖但因为容错和调度做得好实际训练效率反而超过配置更高的集群。6.2 推理场景延迟、吞吐与成本的三角平衡推理场景的诉求和训练完全不同。训练看吞吐推理看延迟和成本。一个在线服务用户等不了几秒所以首token延迟、每token延迟都是硬指标。同时还要控制单位请求的成本。全栈能力在这里体现在量化支持把模型压到更低精度降本增效、动态批处理把多个请求合并提高吞吐、KV缓存优化减少重复计算、算子融合降低访存开销。这些优化每一项都需要软硬件协同。硬件不支持某种量化格式软件再优化也白搭软件调度不合理硬件能力也发挥不出来。6.3 一个具体的对比同样的卡不同的栈差距有多大我做过一个不太严谨但很有说服力的对比同一批加速卡分别用两套不同的软件栈跑同一个推理模型。结果A栈的吞吐是B栈的1.8倍延迟还低了30%。硬件完全一样差距全在软件。这个对比说明什么硬件是下限软件是上限。你买的卡决定了理论能力但软件栈决定了你能拿到多少。这也是为什么现在选型越来越看重厂商的软件团队规模和迭代速度而不是只看硬件参数。7. 给技术选型者的几条实操建议7.1 别被峰值数字带节奏先定义自己的有效算力选型第一步不是看别人推荐什么而是搞清楚自己的负载特征。你的模型是什么结构训练还是推理对延迟敏感还是对吞吐敏感把这些想清楚再去匹配硬件。我一般会做一个简单的负载画像计算强度分布、通信模式、内存占用峰值、精度要求。有了这个画像就能判断哪些硬件特性对你重要哪些可以妥协。7.2 用真实模型做基准而不是跑分工具跑分工具的结果参考价值有限因为它们的负载太理想化。真正有用的是拿你自己的模型跑。哪怕是一个缩小版的、脱敏的版本也比标准跑分有说服力。做基准时注意几点固定随机种子保证可复现多轮取稳定值避免冷启动干扰记录完整指标包括吞吐、延迟、显存、功耗模拟真实并发而不是单请求测试。7.3 把软件栈成熟度纳入评估权重软件栈成熟度很难量化但可以看几个信号文档是否完整、社区是否活跃、版本迭代是否规律、对主流框架的适配是否及时、有没有成熟的性能分析工具。这些信号综合起来能大致判断一个厂商的软件实力。我的经验是软件栈的差距在项目初期不明显在规模化阶段会急剧放大。小规模验证时大家都能跑一旦上量软件薄弱的方案就会各种掉链子。所以选型时宁可硬件参数保守一点也要选软件栈扎实的。7.4 留出迁移和调优的预算最后一条也是最容易被忽略的迁移和调优是要花时间和人力的。别以为买回来就能直接用。预算里要留出这部分包括人力、时间以及可能的试错成本。我见过太多项目硬件采购预算充足但没留调优预算结果上线时间一拖再拖。算力是买来的有效算力是调出来的。这句话值得每个做基础设施的人记在心里。8. 我在实际项目里踩过的几个坑说几个具体的都是真金白银换来的教训。第一个坑迷信峰值算力忽略显存容量。早期选型时盯着算力数字结果显存不够大模型根本放不下只能切得更碎通信开销暴涨算力优势全没了。后来才明白显存容量和带宽对大模型来说比峰值算力更关键。第二个坑低估了通信库的调优难度。以为买了高带宽互联就万事大吉结果通信库默认配置根本没发挥出硬件能力调了拓扑感知、消息大小、并发度之后性能才上来。这个过程花了两周但收益是训练速度提升40%。第三个坑忽略了框架版本兼容性。某次升级框架版本后新硬件的某些算子行为变了导致数值精度出问题训练loss异常。排查了很久才发现是版本兼容问题。从那以后我养成了锁定版本、做回归测试的习惯。第四个坑没有提前规划故障恢复。大规模训练跑了一半挂了检查点没存好几天的工作白费。后来加了定期检查点、断点续训、健康监控才把稳定性提上来。这些机制平时看不出价值出事的时候就是救命稻草。这些坑的共同点是它们都不在参数表上但都实实在在影响产出。这也是为什么我说AI芯片的竞争早就不是单卡算力的竞争了。谁能把这些系统级、软件级的问题解决好谁才能真正把算力变成生产力。9. 往后看竞争重心会往哪走从今年的趋势看我觉得有几个方向会持续升温。一是超节点的规模化落地。现在超节点还主要在头部客户和特定场景接下来会往更多行业渗透。谁能把超节点的部署门槛降下来谁就能吃到这波红利。二是全栈工具链的易用性。现在很多工具还是面向专家的学习曲线陡。未来会有更多开箱即用、自动化程度更高的工具出现把调优的门槛降下来。三是异构调度的智能化。随着集群里硬件种类越来越多怎么让调度器自动感知硬件差异、把任务派到最合适的地方会成为一个核心竞争力。四是有效算力的度量标准化。现在MFU这类指标还没有统一的、被广泛接受的测量方法。未来可能会出现更标准化的基准和度量体系让选型有据可依。这些方向本质上都指向同一件事从卖算力到卖有效算力。谁能帮用户把买来的算力真正用起来谁就有话语权。这也是只卷算力不够了这句话最实在的注脚。最后分享一个我自己的判断方法评估一个AI芯片方案我会问三个问题——它在我的模型上能跑出多少MFU它的软件栈多久迭代一次出了问题我找谁、多快能解决这三个问题的答案比任何参数表都更能说明问题。