1. 算力数字背后的真实困境为什么堆卡不再是万能解2026年的云栖大会刚结束朋友圈里刷屏的还是那些老面孔——某厂商发布新一代训练芯片峰值算力又翻了一倍某大厂宣布建成十万卡集群总算力规模突破多少EFLOPS。数字一个比一个吓人PPT一页比一页炫酷。但如果你真在圈子里待过几年跟做模型训练和推理部署的一线工程师聊过就会发现一个很微妙的情绪大家对这些算力数字已经有点脱敏了。不是说算力不重要而是只卷算力这件事边际收益正在肉眼可见地往下掉。我拿一个实际场景来说明。去年帮一个团队做推理服务的成本优化他们用的是某国产训练卡做在线推理单卡标称算力很漂亮FP16峰值能到几百TFLOPS。但实际跑一个7B模型的服务吞吐量只有预期的一半不到。排查下来发现瓶颈根本不在计算单元而在显存带宽和卡间通信上——模型权重加载慢请求排队时KV Cache频繁换入换出多卡并行时AllReduce通信把计算时间吃掉了一大截。你算力再高数据喂不进去、中间结果传不出来那些峰值数字就是纸面上的。这就是当前国内AI芯片面临的核心矛盾算力峰值和实际有效算力之间的鸿沟。行业里有个不太成文的说法叫“算力利用率”训练场景下能到40%就算不错推理场景下能到60%已经算优化得很好了。剩下那些被浪费掉的算力不是芯片设计的问题而是整个系统的问题——内存墙、通信墙、调度墙每一堵墙都在吞噬你堆上去的算力。所以云栖大会上真正值得关注的不是又发了什么算力怪兽而是那些开始认真谈“超节点”架构、谈“全栈协同”、谈“软硬一体”的议题。这些词听起来没有“XX TFLOPS”那么刺激但它们指向的是同一个问题当单卡算力卷到一定程度之后系统级的效率才是决定AI基础设施竞争力的关键。我个人的判断是国内AI芯片的竞争正在从“单点算力竞赛”转向“系统效率竞赛”。这个转向不是某一家厂商的选择而是整个行业被现实逼出来的。你单卡算力再高如果集群规模上不去、通信效率跟不上、软件栈不成熟客户拿过去跑真实业务就是跑不动。而客户不会为你的峰值算力买单他们只为实际跑出来的吞吐和延迟买单。接下来的内容我会从几个维度拆解这个转向背后的逻辑超节点为什么成为热词、全栈能力到底指什么、算力约束下怎么做好资源配置、以及作为一线从业者应该怎么调整自己的技术判断框架。这些不是纸上谈兵每一条都对应着实际项目里踩过的坑和验证过的经验。2. 超节点架构从“堆卡”到“造系统”的范式转移2.1 传统集群的通信瓶颈到底有多严重先讲一个我亲身经历的项目。2025年初帮一个团队做百卡规模的训练集群调优模型是13B参数的语言模型用的是某国产训练卡。单卡跑单机的时候吞吐量还算正常但一扩展到多机多卡性能曲线就崩了。8卡的时候加速比还有6.5倍左右到64卡的时候加速比掉到30倍出头到128卡的时候只有40倍左右。也就是说你花了16倍的卡只换来了不到7倍的性能提升。问题出在哪通信。在传统的集群架构里卡和卡之间通过PCIe或者NVLink互联机器和机器之间通过RDMA网络互联。每次做数据并行训练梯度同步都要走一遍AllReduce这个过程中数据要在卡间、机间来回搬运。卡越多通信的跳数和竞争就越严重。更麻烦的是这种通信模式和计算模式是串行的——算完了要等通信通信完了才能继续算。你算力再快通信拖后腿整体效率就上不去。行业里有个经验公式当单次通信时间超过单次计算时间的30%时集群的扩展效率就会急剧下降。按照这个标准很多标称千卡、万卡的集群实际有效算力可能只有标称值的零头。这不是芯片的问题是架构的问题。2.2 超节点到底“超”在哪里超节点这个概念本质上是对传统集群架构的一次重构。它的核心思路是把更多计算单元放在同一个高速互联域内减少跨域通信的开销。传统架构里一台机器通常插8张卡这8张卡通过PCIe Switch或者NVLink连在一起形成一个小的互联域。机器和机器之间再通过以太网或InfiniBand连起来形成更大的集群。问题在于跨机的通信延迟和带宽比机内差了一个数量级。你做AllReduce的时候机内通信可能只要几微秒跨机通信可能要几十微秒甚至上百微秒。卡越多跨机通信的占比就越高效率就越低。超节点的做法是把这个互联域做大。比如把32张卡、64张卡甚至更多卡放在同一个高速背板上通过高带宽、低延迟的互联协议连在一起让它们之间的通信延迟接近机内水平。这样一来AllReduce的通信开销大幅降低集群的扩展效率就能维持在一个比较高的水平。我拿实际数据对比一下。同样是128卡做训练传统架构下加速比可能只有40倍左右而超节点架构下能到80倍甚至更高。这意味着什么意味着你花同样的钱买卡超节点架构能给你多出将近一倍的的有效算力。这个差距比单卡算力从500T涨到800T要实在得多。2.3 超节点对芯片设计提出了什么新要求超节点不是简单地把卡插在一起就完事了它对芯片本身的设计提出了新的要求。首先是互联接口。传统芯片的互联接口主要是为机内通信设计的带宽和协议都不太适合大规模跨节点通信。超节点要求芯片原生支持高带宽、低延迟的互联协议比如类似NVLink那样的专用互联通道。这对芯片的SerDes设计、协议栈实现都提出了更高的要求。其次是内存架构。超节点里多张卡要共享一个逻辑上的内存空间或者至少要做到内存的全局寻址。这就要求芯片支持更复杂的内存管理机制比如统一内存寻址、远程内存直接访问等。我见过一些国产芯片在这块做得不够好导致超节点里的卡没法高效地共享数据最后还是得靠显式的数据搬运效率大打折扣。第三是功耗和散热。把更多芯片塞进一个机柜功耗密度大幅上升。传统风冷可能压不住得考虑液冷方案。这对芯片的功耗设计、封装工艺都提出了新的挑战。我在展会上看过一些超节点方案整机柜功耗动辄几十千瓦没有液冷根本跑不起来。这里有个很容易被忽略的点超节点的竞争力不只看互联带宽还要看互联协议的成熟度和生态支持。带宽再高如果协议栈不成熟、编程接口不友好开发者用不起来也是白搭。2.4 超节点是不是唯一解超节点是一个重要方向但不是唯一解。有些场景下通过优化软件调度、改进通信算法也能在传统架构上拿到不错的效率提升。比如用梯度压缩减少通信量、用异步通信掩盖延迟、用拓扑感知的调度算法减少跨机通信。这些手段在超节点上同样适用而且能进一步放大超节点的优势。我的看法是超节点解决的是“物理层”的通信瓶颈软件优化解决的是“逻辑层”的通信效率。两者不是替代关系而是互补关系。一个成熟的AI基础设施应该是超节点硬件加上全栈软件优化的组合。3. 全栈能力为什么软件栈成了芯片厂商的生死线3.1 一个真实的迁移踩坑记录去年有个客户想把训练任务从某国际主流平台迁移到国产芯片平台上。模型不算复杂一个基于Transformer的视觉模型参数量大概2B左右。按理说这种规模的模型迁移应该不难但实际过程折腾了将近两个月。第一个坑是算子覆盖不全。模型里用了一些比较新的注意力机制变体国产芯片的算子库里没有对应的实现只能自己写。自己写也不是不行但性能调优又花了不少时间。第二个坑是精度对齐。同样的模型在国际平台上跑出来的精度是78.5%迁移过来只有76%出头。排查了很久才发现是某些算子在低精度下的数值行为不一致导致训练过程中梯度累积出现了偏差。第三个坑是分布式训练策略的适配。原来用的数据并行加流水线并行的混合策略在国产平台上因为通信库的差异效率掉了不少又得重新调参。这些问题单看每一个都不算致命但加在一起迁移成本就非常高了。对于企业来说迁移成本不只是人力成本还有时间成本和业务风险。如果软件栈不够成熟芯片算力再高客户也不敢轻易换。3.2 全栈到底包括哪些层“全栈”这个词被用得很泛我按自己的理解把它拆成几个层次。最底层是芯片和驱动。芯片提供算力驱动负责把算力暴露给上层软件。这一层的成熟度体现在驱动的稳定性、对主流框架的支持程度、以及性能调优的空间。往上一层是编译器和算子库。编译器负责把上层框架的计算图转换成芯片能执行的指令算子库提供常用算子的高效实现。这一层是芯片厂商软件能力的核心体现。编译器做得好同样的模型能跑出更高的性能算子库覆盖得全开发者迁移的成本就低。再往上是训练框架和推理引擎。这一层更多是适配工作把主流的PyTorch、TensorFlow等框架适配到自己的芯片上同时提供推理引擎支持在线服务部署。这一层的挑战在于主流框架的版本迭代很快芯片厂商的适配速度能不能跟上。最上层是工具链和生态。包括性能分析工具、调试工具、模型转换工具、以及开发者社区和文档。这一层看起来不那么“硬核”但实际影响很大。开发者遇到问题能不能快速找到答案有没有趁手的工具帮忙定位瓶颈这些直接决定了开发体验和迁移意愿。3.3 软件栈的成熟度怎么评估如果你在选型阶段想评估一个芯片平台的软件栈成熟度我建议从几个维度去看。第一看算子覆盖率和性能。拿你实际要跑的模型去测看有没有不支持的算子支持的算子性能怎么样。不要只看官方给的benchmark要跑自己的模型。第二看分布式训练的效率和稳定性。单卡跑得好不代表多卡跑得好。拿一个中等规模的模型做多机多卡的训练测试看扩展效率和训练稳定性。我见过一些平台单卡性能不错但多卡训练时经常出现hang住或者精度异常的问题。第三看工具链的完善程度。有没有性能profiling工具能不能定位到算子级别的瓶颈模型转换工具好不好用调试信息够不够详细这些在实际开发中非常影响效率。第四看社区和文档。遇到问题能不能找到人问文档是不是及时更新有没有活跃的开发者社区这些“软”指标在实际使用中往往比“硬”指标更重要。3.4 全栈能力为什么是长期竞争力从商业逻辑上看芯片厂商的竞争力正在从“卖硬件”转向“卖解决方案”。客户买的不是一张卡而是一个能跑通业务的基础设施。如果软件栈不成熟客户买回去跑不动下次就不会再买了。而且AI芯片的客户粘性很强一旦在一个平台上把模型调优好了迁移到另一个平台的成本很高。所以谁能先把软件栈做成熟谁就能锁定客户。从技术趋势上看AI模型和算法的迭代速度越来越快。今天支持的算子明天可能就过时了。芯片厂商的软件团队能不能跟上这个迭代速度决定了它的平台能不能持续满足客户需求。我见过一些厂商硬件参数很漂亮但软件更新速度跟不上半年后客户想跑新模型就跑不了了只能换平台。如果你在评估国产AI芯片平台建议把软件栈的评估权重放到至少50%。硬件参数只是入场券软件栈才是决定实际体验的关键。4. 算力约束下的资源配置怎么把每一分算力花在刀刃上4.1 先搞清楚你的任务到底需要什么精度的算力很多人一上来就问“这个芯片多少TFLOPS”但很少有人问“我需要什么精度的算力”。FP64、FP32、FP16、INT8、INT4不同精度下的算力需求差别巨大而且不同任务对精度的敏感度也不一样。训练场景下主流做法是混合精度训练——前向和反向用FP16或BF16权重更新用FP32。这样做的好处是计算密集的部分用低精度跑得快数值敏感的部分用高精度保证稳定性。推理场景下精度选择就更灵活了。很多模型用INT8量化之后精度损失很小但吞吐量能翻倍。再激进的用INT4精度损失大一些但在某些场景下也能接受。我做过一个对比测试同一个7B模型FP16推理的吞吐量是每秒多少tokenINT8量化之后吞吐量提升了将近一倍精度只掉了不到1个百分点。对于很多在线服务场景来说这个 trade-off 是完全值得的。所以你在规划算力资源的时候第一步不是看芯片峰值算力而是明确你的任务在什么精度下跑、能接受多大的精度损失、需要多大的吞吐量。这些确定了再去匹配芯片的算力规格。4.2 显存带宽往往比算力更关键在大语言模型推理场景下显存带宽的重要性经常被低估。我拿一个实际例子来说明。一个7B参数的模型FP16精度下权重大概占14GB显存。每次生成一个token都需要把全部权重从显存里读一遍。如果你的显存带宽是1TB/s那么读一遍权重需要14ms。假设你的芯片算力是200TFLOPS做一次前向计算需要的浮点运算量大概是14GFLOPs2乘以参数量理论上计算时间只要0.07ms。但实际上因为要等权重从显存里读出来实际延迟是14ms左右计算单元大部分时间在等数据。这就是典型的内存墙问题。算力再高显存带宽跟不上实际性能就被带宽卡死了。所以在推理场景下评估芯片不能只看算力还要看显存带宽和显存容量。显存带宽决定了你生成token的速度显存容量决定了你能跑多大的模型。训练场景下显存带宽同样重要但计算密集度更高算力和带宽的平衡点不一样。做训练选型的时候要综合考虑算力、显存带宽、显存容量、以及卡间互联带宽。4.3 集群规模不是越大越好我见过一些团队一上来就规划千卡甚至万卡集群觉得规模越大越好。但实际上集群规模要和你的任务规模匹配。任务规模不够大硬上大集群效率反而更低。原因很简单集群规模越大通信开销占比越高调度和容错的复杂度也越高。一个几十B参数的模型用几百卡训练可能效率很高用几千卡训练加速比可能反而下降。而且大集群的故障率更高训练中断的风险更大checkpoint和恢复的开销也不可忽略。我的经验是集群规模应该略大于任务的最优规模留出一定的弹性空间但不要盲目追求大规模。比如你的任务在256卡时效率最高那规划300到400卡的集群就够了没必要上1000卡。多出来的预算不如花在提升单卡效率或者优化软件栈上。4.4 推理场景下的算力调度策略推理场景和训练场景的算力调度逻辑完全不同。训练场景下任务相对固定资源可以静态分配。推理场景下请求量波动很大需要动态调度。常见的做法是动静结合。对于基线负载用静态分配的实例来承载保证延迟稳定。对于峰值负载用弹性伸缩的实例来承载按需扩缩容。这样既能保证服务质量又能控制成本。还有一个策略是模型分级部署。把不同大小的模型部署在不同的硬件上小模型用低算力芯片大模型用高算力芯片。请求进来之后根据请求的复杂度和延迟要求路由到不同的模型实例上。这样能更精细地匹配算力资源和业务需求。我在实际项目里用过这个策略推理成本降低了大概30%左右而且服务质量没有明显下降。关键是要做好请求路由和负载均衡这部分需要一些工程投入但回报是值得的。4.5 怎么评估你需要多少算力这个问题没有标准答案但有一个实用的估算方法。训练场景算力需求大概等于 6 × 参数量 × token数量。比如你要训练一个13B参数的模型用1T token的数据那总算力需求大概是 6 × 13e9 × 1e12 7.8e22 FLOPs。假设你的集群有效算力是100 PFLOPS也就是1e17 FLOPS那训练时间大概是 7.8e22 / 1e17 7.8e5秒大概9天左右。你可以根据这个公式反推你需要多大的集群。推理场景算力需求大概等于 2 × 参数量 × 每秒请求数 × 平均生成长度。比如一个7B模型每秒处理100个请求每个请求平均生成200个token那算力需求大概是 2 × 7e9 × 100 × 200 2.8e14 FLOPs也就是280 TFLOPS。考虑到实际效率你可能需要准备500 TFLOPS以上的算力。这些估算比较粗糙实际还要考虑通信开销、调度开销、峰值波动等因素。但作为一个初步的规划工具是够用的。5. 从云栖大会看趋势一线从业者应该关注什么5.1 别被峰值算力数字带偏云栖大会上发布的芯片峰值算力一个比一个高。但作为一线从业者你要清楚峰值算力只是在特定条件下的理论最大值实际能跑出多少取决于内存带宽、互联带宽、软件栈成熟度、以及你的任务特征。我建议关注几个更实际的指标实际吞吐量在真实模型上的表现、扩展效率多卡多机下的加速比、精度保持能力低精度下的精度损失、软件栈成熟度算子覆盖、工具链完善度。这些指标比峰值算力更能反映一个平台的实际竞争力。5.2 超节点和全栈是长期趋势超节点解决的是物理层的通信瓶颈全栈解决的是软件层的效率问题。这两个方向都不是短期热点而是长期趋势。随着模型规模继续增长集群规模继续扩大这两个方向的重要性只会越来越高。对于从业者来说这意味着你需要具备更系统的视角。不能只盯着芯片规格看还要理解互联架构、软件栈、调度策略、以及它们之间的相互作用。这种系统级的理解能力在未来会越来越值钱。5.3 国产芯片的差异化机会在哪里国产AI芯片和国际主流平台相比在单卡算力上可能还有差距但在系统级优化和场景化适配上有机会做出差异化。比如在超节点架构上国内厂商可以更激进地采用新技术不受既有生态的包袱。在全栈软件上可以针对国内主流模型和业务场景做深度优化形成场景化的竞争力。在成本上可以通过架构创新和供应链优化提供更有性价比的方案。我看到的趋势是国产芯片正在从“替代”走向“差异化”。替代阶段比的是兼容性和性价比差异化阶段比的是系统效率和场景适配能力。这个转变对从业者来说是个好消息因为这意味着更多的技术选择和创新空间。5.4 给一线工程师的实操建议如果你正在做AI基础设施的选型或优化我有几个实操建议。第一先跑自己的模型再看benchmark。官方benchmark只能作为参考实际表现要以你自己的模型为准。拿一个代表性的模型在目标平台上做完整的训练或推理测试记录吞吐量、延迟、精度、稳定性等指标。第二关注端到端的效率而不是单点指标。从数据加载、预处理、模型计算、到后处理整个链路的效率都要看。我见过一些平台单卡算力很高但数据加载成了瓶颈整体效率反而上不去。第三把软件栈的评估权重放高。硬件参数只是入场券软件栈才是决定实际体验的关键。花时间评估算子覆盖、工具链完善度、社区活跃度这些“软”指标。第四保持技术判断的独立性。行业里噪音很多厂商的宣传、媒体的报道、同行的观点都需要批判性地看待。最终还是要回到实际测试和业务需求上来。我在实际项目里最大的体会是选型决策不能只看技术参数还要看团队的技术栈匹配度、迁移成本、以及长期维护的可行性。一个技术上很先进但团队用不起来的平台不如一个技术上稍逊但团队能快速上手的平台。6. 算力之外AI基础设施的竞争维度正在重构回到云栖大会这个话题。每年大会都会发布很多新产品、新数字但真正值得关注的是那些反映行业趋势变化的信号。今年我看到的信号是算力不再是唯一的竞争维度系统效率、软件栈成熟度、场景适配能力正在成为更关键的差异化因素。这个变化对芯片厂商来说意味着竞争门槛更高了。以前只要把算力做上去就能拿到订单。现在还要把互联做好、把软件栈做成熟、把生态建起来。这是一个更长期、更系统的工程需要持续的投入和积累。对一线从业者来说这个变化意味着需要更全面的技术视野。不能只懂芯片规格还要懂互联架构、软件栈、调度策略、以及业务场景。这种系统级的理解能力是未来几年最稀缺的。我在这个行业里待了这些年最大的感受是技术趋势的变化往往比预期慢但一旦发生变化影响又比预期深。算力竞赛转向系统效率竞赛这个趋势才刚刚开始未来几年会看到更多实质性的变化。保持学习、保持实践、保持独立思考是在这个快速变化的领域里最可靠的策略。
