最近两年在AI基础设施这个圈子里，我听到最多的就是某某新款AI芯片“算力又翻倍了”“性能直接碾压上一代”。但真去做过大规模训练或者长文本推理的人，心里都会有一笔账：峰值算力只是入场券，不是胜负手。一个方案能不能落地，电费能不能扛得住，集群跑起来利用率能到多少，瓶颈到底卡在计算、显存还是网络上，这些问题靠“堆更多FLOPS”根本解决不了。所以行业风向正在从“算力竞赛”转向“系统效率竞赛”——这不是概念包装，而是被功耗墙、内存墙、通信墙和成本账逼出来的必然选择。

这篇文章我想把这些墙一层层拆开，讲讲为什么单纯堆算力的增长逻辑正在失效，系统效率竞赛具体在“竞”哪些层面，以及我们在做芯片评估、集群搭建、推理优化时，怎么用这套新标尺去判断方案好坏。适合正在做AI基础设施、大模型部署、芯片选型，或者说想从“只看FLOPS”进阶到“看系统整体收益”的硬件工程师、算法工程师和技术决策者。

1. 为什么“堆算力”这招开始不灵了

1.1 算力数字看着很猛，为什么用到实处就缩水

先看一个最直观的问题：芯片标称算力越来越夸张，但客户实际用到的有多少？行业内经常谈MFU（Model FLOPs Utilization，模型算力利用率），用来衡量训练大模型时“实际有效计算”占“硬件峰值算力”的比例。早期很多训练集群跑分布式训练，MFU常年只有30%到50%，也就是一半以上的峰值算力都浪费在等待数据、通信同步、空转和低效kernel上。

问题出在哪？浮点峰值只是理论极限，它成立的前提是“数据永远供得上、指令永远排得开、算子永远能并行”。但真实模型是复杂计算图：有矩阵乘法，也有归一化、激活函数、注意力掩码、Loss计算这些无法完全打满张量核的操作；有前向又有反向，有流水线并行又有张量并行，层与层之间还要频繁做AllReduce通信。任何一个环节拖后腿，都会让标称的FLOPS在真实负载中缩水。

更要命的是，芯片厂商标注算力时用的精度和条件也值得细看。比如FP16算力、FP8算力、稀疏化算力，三个数字差距可以很大，但真实模型能不能用上取决于算法是否适配。稀疏化通常需要权重结构化稀疏率达到特定比例才有效，这在多数通用模型里并不现实。所以我一直建议，看到某个AI芯片的“XX PetaFLOPS”宣传时，先追问三个问题：这是什么精度下的数字、能不能连续跑满、跑什么模型结构的时候能接近这个值。

1.2 功耗、散热的物理天花板，躲不开

算力提升不是没有代价的，代价最直接的就是功耗和散热。过去十年，单颗AI加速卡的功耗从两三百瓦涨到现在普遍四百瓦朝上，高端产品甚至要往七百瓦、八百瓦走。在一个标准机柜里能放进多少瓦的设备，是有物理上限的：电力容量有限，散热能力有限，机柜空间也有限。

这带来的结果是，“性能”的定义变了。在数据中心里，真正稀缺的已经不是“每颗芯片多少算力”，而是“每千瓦电力和每平方米机房面积能产出多少有效计算”。一颗芯片哪怕FLOPS翻倍，如果功耗跟着涨了近一倍，那折算到单位电费上的算力几乎没有提升，反而让散热系统压力大增，可能需要从风冷改成液冷，机柜基础设施成本整体抬升。

我见过不少团队在做方案选型时，只盯着单卡算力峰值去了，等到整柜部署才发现电力预算根本不够，最后只能降频使用，性能打折到令人心疼。这就是典型的“没把系统当系统算账”。算力竞赛还能玩下去的前提是能耗曲线足够平缓，但现实是它已经逼近物理极限，所以大家必须转向效率竞争。

1.3 集群不是网吧攒机，互连和内存把算力卡住了

即便单卡功耗能接受，集群侧的瓶颈也不容小觑。很多人的直觉是：这台机器算力不够，我再加一张卡不就行了？逻辑上没错，但实际上多卡协同产生的通信开销、同步开销、内存容量和带宽限制，会吃掉大量新增算力。

先说内存墙：AI模型参数已经达到百亿、千亿甚至万亿规模，一次前向推理就需要把全部权重从显存搬运一遍。显存带宽如果不够，计算单元就是在“饿着肚子干活”。比起无限堆计算单元，更现实的是让内存离计算更近、让数据搬得更快。HBM（高带宽内存）之所以成为AI芯片的标配，本质就是为了缓解内存墙。

再说通信墙：分布式训练是同步训练，每个step结束都要做梯度同步，几千张卡之间需要高效AllReduce。如果网络带宽不足、拓扑设计不合理，大量时间会浪费在通信等待上，GPU利用率会非常难看。业内有个说法叫“scale-up”和“scale-out”，前者是单节点内多卡的高速互连（比如NVLink），后者是跨节点的集群网络（比如InfiniBand或RoCE）。系统效率竞赛里，两者缺一不可。单卡算力再强，互连性能差，集群就是个没有协作效率的“帮派混战”。

2. 系统效率竞赛到底在“竞”什么

2.1 架构：从通用算力转向“算得巧”

以前做AI芯片，方向是通用计算：什么模型都能跑，但不一定跑得最优。现在越来越多芯片开始走DSA（Domain-Specific Architecture，领域专用架构）路线，针对Transformer、卷积、注意力机制这些高频结构做专用化设计。好处很明显：把最常用的算子直接用硬件实现，省掉通用指令的取指、译码开销，用脉动阵列或专用数据流让计算单元持续满负荷运转。

行业里经典的例子是Google的TPU，从第一代开始就针对矩阵乘法设计了脉动阵列，没有走通用GPU路线。后来各家的AI推理芯片、训练芯片，很多都围绕矩阵单元、向量单元、张量核心的组合来做，本质都是“算得巧”而不是“算得多”。这种架构路线选择的背后逻辑是：实际模型的计算模式是高度规律的大规模矩阵运算，与其让通用核心用复杂调度去适配，不如把数据流安排到极致，省下能量和时间。

为什么说这是“系统效率”的一部分？因为同样的峰值FLOPS，不同的架构在真实模型上能发挥出的效率截然不同。架构设计时就要考虑内存层级怎么排、数据怎么流动、算子之间怎么融合，这些都属于系统级设计，而不是单个ALU快不快的问题。

2.2 内存：HBM和近存计算的真正价值

AI芯片里有一句老话叫“算力易得，带宽难求”。现在训练和推理大模型，显存容量和带宽的性价比甚至比纯粹计算性能更关键。HBM之所以重要，是因为它把几十上百颗DRAM die堆叠在计算芯片旁，通过硅中介层打出极宽的接口，带宽远超传统GDDR方案。

以一次大模型推理为例，每生成一个token，理论上都需要把整个模型参数从头到尾读一遍，这个数据量就锁定了最小访存需求。显存带宽越高，单位时间内能生成的token越多，推理吞吐直接跟带宽走。此时计算单元再快也没用，因为数据喂不上来，这就是典型的“memory-bound”场景。所以你会看到各家芯片越来越强调HBM容量和带宽，甚至在架构上做“近存计算”，把部分算力挪到内存旁边，减少数据搬运距离。

从系统效率角度看，内存设计的价值不只是“跑得更快”，更是“花更少的能量和等待拿数据”。数据在芯片内部搬运一次，能耗比做一次计算高出一个数量级；如果能减少数据搬运次数，整体能耗和延迟都能明显下降。这也是Chiplet、先进封装等技术火热的原因——它们都是在系统层面缩短数据通路。

2.3 互连：集群里的隐形决定性因素

当模型大到一张卡装不下，就需要多卡、多节点协同。这时候芯片之间怎么连、连多快、延迟多低，就成了系统效率的分水岭。英伟达构建NVLink加NVSwitch，把几十张卡做成一个超大的GPU集群视图；其他挑战者也在推自己的高带宽互连方案，比如AMD的Infinity Fabric、各家基于CXL或PCIe的variant。目的都相同：让多卡协同时的通信开销尽可能小，让计算和通信尽量重叠。

在跨节点层面，网络拓扑和拥塞控制策略往往决定训练效率。简单说，如果采用传统的胖树拓扑，带宽规划不合理，某个节点可能成为通信瓶颈，造成整个集群每一轮都有人“等菜”。网络优化做得好的训练集群，通信等待时间可以压到训练总时长的10%到20%；做得差的集群，通信占比可以超过50%。这直接意味着：相同的芯片，不同的互连方案和网络规划，训练效率可能天差地别。

这也是为什么系统效率竞赛不能只看芯片本身。芯片的互连接口、交换芯片、网卡、光模块、拓扑设计，联合起来才构成“系统效率”。很多自研芯片迟迟难以落地，不是计算不够强，而是生态里没有配套的高速互连和网络方案，单卡再强也组不成高效集群。

2.4 软件栈：效率最终要靠“软硬协同”兑现

硬件只是提供了效率的“上限”，把上限兑现成可真实验证的价值，靠的是软件栈。没有成熟的编译器、运行时、算子库和推理引擎，再强的芯片也白搭。比如对Transformer模型做算子融合，把多个小kernel合并成一个大kernel，减少内存读写次数；又比如推理时的continuous batching，让多个请求动态拼装批处理，把GPU算力尽量占满——这些都不是硬件“自动”发生的，而是软件优化的结果。

软件栈的竞争，本质是“开发者时间”的竞争。CUDA生态为什么能成为事实标准？因为开发生态成熟，PyTorch、TensorFlow里调用一下cuda()就能跑，算子库琳琅满目，性能还经过多年打磨。后来者想挑战，除了硬件指标赶超，还得把编译工具链、算子库、调试工具、性能分析工具全部补齐，否则开发者根本进不来。

我在和一些做AI芯片的团队交流时，多次听到同一个感慨：芯片tape out只是开始，软件栈工作量往往是硬件的好几倍。很多团队低估了这块投入，结果芯片流片回来，跑一个Transformer模型费半天劲才能调出及格性能。这更印证了系统效率竞赛的另一个含义：比的是“从裸片到用户可见性能”的全链路转化率。

3. 系统效率在真实场景里的“体感”

3.1 大模型推理：高算力卡为何也会卡成PPT

纸上谈兵说完了，落到真实场景来看更直观。大模型推理，尤其是自回归解码，被业内戏称为“bandwidth-bound”：每生成一个新token，需要把整个模型参数重新读一遍，计算量反而不大。假设一个70B参数模型，以FP16精度存权重，光参数量就约140GB。如果单卡显存装不下，要多卡切分，还得通过高速互连来回搬运，此时推理速度往往卡在显存带宽和互连带宽上，而不是FLOPS。

那些标称算力极高的芯片，一旦做起长序列生成，如果不做量化、不做KV Cache优化、不做算子融合，性能可能比理论值差一个数量级。反过来，有些算力指标看似不高的推理芯片，因为内存带宽利用率高、互连设计合理、软件优化到位，实际吞吐反而更高。这在做RAG、Agent聊天、流式生成等场景时体感极其明显：单靠堆算力解决不了“卡顿”，系统效率才是真实体验。

3.2 大模型训练：MFU利用率差距才是胜负手

训练端的体感更明显。假设有两个同规格算力的集群，一个MFU做到60%，一个做到45%，前者的训练效率就要高出33%。这意味着时间成本、电费成本、设备折旧成本都直接拉开差距。MFU高低受哪些因素影响？包括通信拓扑、模型并行策略、梯度累积设置、算子实现效率、显存分配策略，甚至数据加载管线的深度。

我在实践中还遇到过一种隐蔽陷阱：芯片单卡性能很好，但多卡扩展性差。双卡跑效率还能看，加到八卡、十六卡，效率断崖式下跌。原因往往是互连带宽设计不足，或者软件层的集合通信库没做好。这种情况下，只看单卡基准测试完全被骗。所以评估真正的AI芯片水平，必须看“多卡到底能scale到什么程度”，这是系统效率的最硬指标。

3.3 数据中心总账：从每瓦算力算到每Token成本

系统效率的终极考量，还是落到钱上。一个数据中心从建设到运营，最大头的成本是电和散热，其次是网络设备和服务器折旧。AI芯片之间的竞争，比拼的是“每瓦算力”“每元算力”“每小时有效训练量”，甚至落实到推理场景就是“每百万Token成本”。

举一个很现实的计算方法：假设你看上一个高算力方案，单卡功耗650W，每张卡FP16标称算力是另一方案的1.8倍，但真实MFU只高1.1倍，功耗却高了1.5倍。这样折算下来，单位有效算力的能耗反而更差，电费那笔账完全划不来。再算上液冷改造的机房成本和更复杂的运维，优势就更不显著了。

这就是系统效率竞赛的核心逻辑：芯片厂商不再只吹“我的算力世界第一”，而是强调“我的方案在同功耗下能完成更多训练、推理吞吐更高、每Token成本更低”。对客户而言，最终买的是一个“跑得快的系统”，而不是一颗“参数好看的单卡”。

4. 系统效率时代，个人和团队如何调整打法

4.1 评估AI芯片方案时，别再用“峰值算力”一票定音

如果现在让我去评估一款AI芯片或一个计算方案，我会重新建一套评估指标体系，避免被宣传单页的FLOPS数字牵着走。主观上我会把“系统效率”相关指标权重调高，比如：

这套指标不要求完全量化，但我建议任何时候都至少跑一个小规模的“真实负载压测”：用你实际要跑的模型结构和batch size，测一下多卡情况下的性能和扩展性，再核算电能消耗，比任何宣传数据都靠谱。

4.2 落地优化时，可以从这几个方向快速见效

如果团队已经在使用某款芯片，想在当下系统里把效率挖出来，优先级可以参考这样排：

• 把能合并的算子都合并：尤其是Transformer里的Attention系列算子，做算子融合能显著减少中间张量读写和kernel启动开销。
• 留意推理时的批处理策略：传统静态batching在请求稀疏时严重浪费算力，continuous batching可以在batch里动态腾挪位置，吞吐提升往往是倍数级别。
• 重新审视KV Cache管理：大模型的长序列推理非常依赖KV Cache，PagedAttention这类把显存“页式化管理”的思路，能有效减缓显存碎片问题，支持更大并发。
• 细查通信模式：训练集群里AllReduce频繁且数据量大，调节梯度累积步数、分层同步策略，或者改用更优的ring/树形拓扑，能明显降低通信等待。
• 别忽略数据管线：数据加载慢到一定程度，GPU就全程在“摸鱼”。增加数据预处理并发度、做预取、减少跨节点IO，效果一样可观。

这些优化方向本质都在打磨系统效率。做完一轮回头看，你会发现“能用上的算力”明显变多，而硬件本身什么都没变。这也是我一直强调的：不是只有换更强芯片才能提效，先把系统榨干再谈升级，成本会友好得多。

4.3 行业协作方式与团队知识结构，也得跟着系统效率走

系统效率竞赛带来一个连锁变化：AI芯片公司不再只是硬件公司，必须同时具备系统软件、编译器、分布式部署、数据中心基础设施的基因。团队里不能只有数字电路工程师，还需要有高性能计算背景、内核优化、网络架构、甚至液冷系统工程师一起参与定义产品。

对下游使用方也一样。以前选芯片可能只需要比算力表，现在最好组织一个跨团队“效率评估组”，把算法、系统、运维的人拉在一起，分别从模型结构适配、集群扩展、电力预算三方面打分。这样选型结论才不会被单点指标带偏。

我自己的体感是，这几年见到的优秀AI基础设施团队，普遍有一个共性：他们很少谈“我的单卡多少T”，更多谈“我的集群训练一版模型多少天、推理一个token多少毫秒、千卡规模下通信占比压到多少”。这种从芯片指标到系统指标的迁移，本身就是对系统效率竞赛的直觉回应。

最后分享一个实际建议：如果你所在团队正要采购或选型AI计算方案，不妨要求供应商按“标准模型压测+故障注入+能耗采样”三个环节提交报告，而定制芯片团队也可以把“能在多大batch size和吞吐下稳定运行”列为硬性验收指标。系统效率是设计出来的，更是验收出来的。把这个维度嵌入到日常决策流程里，会比任何口号都管用。