算力竞赛深水区：从堆卡到算力基础设施的综合效率之战

算力竞赛这件事，行业内聊了大半年，从最初比谁家卡多、谁家模型参数大，到现在已经明显换了打法。前阵子跟几个做智算中心的朋友聊，大家的共识是：单纯堆卡的窗口期已经过了，真正拼的是算力基础设施的综合效率——从芯片到集群、从网络到调度、从电力到运维，每一个环节都在决定整个系统的实际产出。今天这篇就想从产业逻辑的角度，把这场竞赛的“深水区”拆开聊透，包括算力需求怎么评估、基础设施怎么搭、多卡集群怎么管，以及我在实操中踩过的那些坑。

1. 算力竞赛进入深水区的真实含义

1.1 从“拼参数”到“拼系统”的范式转换

很多关注AI行业的人，习惯用大模型的参数规模来衡量技术进展。一百亿、一千亿、甚至万亿参数，听起来确实震撼。但真正深入产业一线就会发现，2024年下半年之后，整个行业的关注点已经发生了明显转移——从“能不能训出来”变成了“能不能算得动”、“能不能用得起”、“能不能上线跑稳”。

为什么会有这个转变？核心原因在于，模型训练只是算力需求的一部分，而且正在变成越来越小的一部分。我给你算一笔账：一个千亿参数的大模型，假设训练用了一万张GPU，跑了两三个月，消耗的算力固然惊人。但模型上线之后，每天面对海量用户请求，每一次对话、每一次生成都要走一遍推理计算，这部分算力消耗是持续性的、7x24小时的，而且会随着用户量增长持续攀升。

我做过一个粗略统计，在典型的商业化大模型应用中，推理算力消耗与训练算力消耗的比例，大约在3比1到7比1之间，具体取决于应用场景的并发量和交互频率。也就是说，训练再贵，也只是“一次性投入”，推理才是每天都要烧钱的“持续性开支”。

这就解释了为什么行业里越来越强调“算力基础设施”而不是单纯的人说“算力芯片”。芯片只是算力的载体，让芯片真正发挥价值，需要的是整套系统的协同：高速互联网络、分布式存储、调度平台、运维体系、电力供应，甚至机房的地理位置和散热方案。这些合在一起，才是AI基础设施建设。

1.2 深水区的三个典型特征

既然说是深水区，那必然和浅水区有着本质区别。我梳理了三个典型特征，方便大家对照判断自己所在的阶段。

第一个特征是规模化带来的系统工程复杂度急剧上升。一千张卡的集群和一万张卡的集群，不是简单的10倍关系。规模超过一定阈值后，网络拥塞、故障恢复、任务调度、散热管理这些问题的复杂度会指数级上升。小集群里跑得好好的代码，搬到大规模集群上可能三天两头出问题。

第二个特征是成本结构从建设成本转向运营成本。早期大家比拼的是谁买卡买得快、建机房建得多。但进入深水区后，电费、运维人员成本、设备折旧、故障替换这些运营性开支，会逐渐超过一次性建设投入，成为决定项目能否持续的关键因素。我见过不少项目，前期大手笔投入，结果运营半年后发现自己每天的开销比预期高出40%，整个商业模式瞬间不成立了。

第三个特征是生态和工具的成熟度成为关键竞争力。硬件只是底座，真正让算力跑起来的是上层的软件栈。分布式训练框架、推理加速引擎、资源调度系统、模型部署工具，这些构成了“算力基础设施”的软性部分。在这个层面的竞争，远比单纯比硬件参数更有门槛，也更考验一个团队的综合工程能力。

2. 算力需求侧的真实逻辑：从训练到推理再到Agent

2.1 算力、Token、API这三者的关系

聊算力需求之前，很有必要先把几个高频词的关系整理清楚，这是我被问得最多的问题之一。

算力是底层的计算能力，通常用FLOPs（每秒浮点运算次数）来衡量，落到设备上就是GPU/TPU这类加速卡的处理能力。Token是模型处理文本的最小单位，可以粗略理解为一个词或者半个词。模型在你输入内容、生成回复时，每处理一个Token都要消耗一定量的计算。API则是算力能力对外提供的服务接口，用户不需要关心底层有多少张卡，只需要按调用量付费。

打个比方，算力就像是发电厂的总装机容量，Token是居民用电的度数，API则是你家里墙上的插座。发电厂能不能满足一个城市的用电需求，取决于总装机容量；但每个家庭实际用多少电，看的是电表上走的度数。

理解这层关系后，算力需求评估的底层思路就清晰了：先从业务场景预估Token消耗量，再由Token量反推需要的总算力，最后落到API服务或者自建集群上。

2.2 训练、微调、推理各自算的是哪本账

不同类型的AI任务，对算力需求的评估逻辑完全不同，放在一起算必然出错。

先看预训练。这是最“吃算力”的场景，通常在数千到数万张加速卡上运行数周到数月。评估预训练算力需求，业内常用一个经验公式：训练算力约等于6乘以模型参数量再乘以训练Token数。举个例子，一个700亿参数的模型，训练2万亿Token，需要的总算力大约是6乘以700亿乘以2万亿，也就是8.4乘以10的23次方FLOPs。假设单张加速卡的有效算力是2乘以10的14次方FLOPs（这是比较理想的实际利用率下的大致水平），那么这张卡需要跑大约4.2乘以10的9次方秒，换算下来就是一千多张卡跑一个多月。当然这是理论值，实际训练中要考虑并行效率、日志保存、断点恢复等因素，通常要在理论基础上乘以1.2到1.5的安全系数。

再看微调。参数高效微调（比如LoRA）只更新一小部分参数，算力需求比预训练低好几个数量级，一般几张卡到几十张卡就能搞定。即使全参数微调，也只需要预训练几十分之一到百分之一的算力。这部分的评估重点反而在数据准备和实验迭代上——试错次数多了，累计消耗也会很可观。

最后是推理。这部分的算力估算逻辑又不一样，核心看三个指标：并发请求数、单请求的输入输出Token长度、单Token推理耗时。举个例子，假设一台推理服务器平均每秒能处理500个Token（这个数字跟模型大小、量化方式、批处理设置都有关），那它一小时就能处理180万个Token。如果业务高峰期需要同时服务1000个用户，平均每个用户每分钟产生200个Token的交互，那一小时就是1200万Token，粗略估算需要7台这样的服务器才能扛住高峰期流量。

2.3 AI Agent对算力需求形态的改变

不得不提一下Agent对算力需求的影响，这是最近半年算力需求结构里变化最快的部分。

传统的单轮对话应用，一次请求就是一次“输入-输出”的往返。但Agent应用不同，它需要在内部做规划、调工具、读文档、反思修正，一次用户请求背后可能触发十几次甚至几十次模型调用。这意味着同样的用户量，Agent应用的Token消耗可能是传统聊天应用的5到10倍。

更棘手的是，Agent的算力消耗存在明显的“长尾特征”——有的任务几十秒就结束，有的任务可能需要几分钟甚至更久才能完成。这种不确定性让推理集群的流量模型变得很难预测，对弹性扩缩容能力提出了更高要求。如果在设计算力基础设施时没有考虑这个变量，高峰期大概率会频繁触发限流或者超时。

我在实际项目中采用的评估方法是：先定义Agent的“任务图”，把一次完整任务拆解成若干步骤，估算每个步骤的Token消耗，再乘上预期的任务并发数。这样算出来的结果比拍脑袋凭感觉靠谱得多。

3. 算力供给侧的基础设施博弈：芯片、集群与网络

3.1 加速卡选型不是越强越好

很多刚开始自建算力集群的团队，第一个问题就是“该买什么卡”。我的建议是：先别急着追求最强的卡，算力选型的本质是性价比匹配。

市面上的加速卡从几十TFLOPS到上千TFLOPS（这里指FP16精度下的算力）都有，价格跨度也非常大。选型时一般要综合考虑三个维度：单卡算力、卡间互联带宽、软件生态成熟度。

单卡算力决定单张卡能干多少活，这个好理解。卡间互联带宽则决定了多卡协同的效率——如果互联带宽不够，GPU之间传输数据的耗时可能比计算还长，再强的单卡也会被拖累。软件生态更是关键中的关键，加速卡再强，如果主流的分布式训练框架不支持、适配不完善，你的工程团队会非常痛苦。

我建议的做法是：先明确自己的核心负载类型，再根据负载特点倒推需求。如果主要做推理，中端卡+高吞吐配置往往比纯堆高端卡更划算；如果主要做预训练，那确实需要最强算力和最高互联带宽，这部分省不得。

3.2 集群组网的三个关键参数

多卡集群的性能上限，很大程度上取决于网络设计。如果网络是瓶颈，GPU的利用率会惨不忍睹。我有一次排查集群性能问题，发现GPU利用率长期在30%以下，折腾了半天，最后定位到是网络拓扑配置不当，交换机之间形成了严重的拥塞点。改完配置，利用率直接翻倍。

网络设计需要重点关注的参数有三个。第一个是网卡带宽，目前主流方案是200Gbps起步，超大规模集群甚至已经用上400Gbps或更高。第二个是网络收敛比，简单说就是上行带宽和下行带宽的比例，训练集群最好做到1比1收敛（也就是无收敛），否则数据搬移就会成为瓶颈。第三个是东西向流量处理能力，分布式训练中GPU和GPU之间有大量的数据交换，这种流量不经过外部网络，而是在数据中心内部横向流动，对交换机的缓存和转发能力要求极高。

这些参数不用死记数字，但你需要能在方案评审时看懂对比表格，知道什么样的配置对应什么样的性能预期。团队里最好有一个懂网络的专家，算力集群出问题的场景里，网络相关的至少占三成。

3.3 数据中心选址背后其实是能源逻辑

算力基础设施和普通机房最大的区别在于电力消耗密度。一个大型AI训练集群的功率密度，可能是传统机房的5到10倍，这意味着选址时首先要考虑的不是城市品牌，而是能源供应能力。

一个10000张加速卡的集群，如果平均单卡功耗500瓦，那总功耗就是5兆瓦，这还不包括制冷和其他辅助设备的耗电。再加上配套的制冷系统，总电力需求可能要到8到10兆瓦。这个量级的电力需求，不是随便哪个写字楼、普通机房能扛下来的。

国内很多CDN机房、云计算机房都集中在传统的通信枢纽城市，但大型智算中心的选址已经开始向能源富集地区转移。原因也简单：一是电力供应更有保障，二是电价相对便宜。对于长期运行的算力基础设施来说，一度电差一毛钱，一年下来的差异都是千万级甚至亿级的。

除了电力，散热方案也是选址时必须考虑的。液冷方案和风冷方案对机房的层高、承重、管道布局要求完全不同，如果在机房建设早期没有规划好，后期改造的代价极高。我个人经验是，单机柜功率超过15千瓦时，液冷就是必然选项，别犹豫。

4. 算力平台与统一管理：从裸金属到一键调度

4.1 为什么需要算力平台这一层

很多小团队刚起步时，直接用裸金属服务器跑训练任务，几张卡、几台机器，手动配置一下环境就能跑。这个阶段确实不需要复杂的平台层。

但机器数量一旦超过某个阈值——以我的经验是50台左右——再靠手动管理就不现实了。这时候需要一套算力平台来做资源池化、任务调度、监控告警、权限管理。平台层解决的核心问题，就是把“机器”抽象成“资源”，让研发人员不需要关心任务跑在哪台机器上，只需要声明需要多少资源、跑什么任务。

这就很像从自己开车到用打车软件的变化。自己开车你得管油、管停车、管保养；用打车软件，你只需要告诉它从哪到哪、要什么车型，剩下的交给平台调度。算力平台之于GPU集群，正是这么个角色。

4.2 统一管理多台算力服务器的三个核心模块

市场上开源的算力平台方案不少，接触下来，三个核心模块是必须配齐的。

第一个是资源管理模块，负责把集群中所有GPU、CPU、内存、存储资源做统一登记和分配。你需要能随时看到当前集群有多少可用资源、被谁占用了多少、用了多久。没有这个模块，资源分配基本靠喊，效率极低。

第二个是任务调度模块，负责把用户提交的训练或推理任务安排到合适的机器上执行。调度器需要考虑任务的资源需求、优先级、数据本地性等因素，好的调度策略能显著提升集群的GPU利用率。我见过一套考虑周全的调度配置，把集群整体利用率从50%提升到接近80%。

第三个是监控告警模块，负责实时采集每台机器的健康状态和运行指标。GPU温度过高、显存泄漏、网络丢包、卡死无响应，这些异常如果能被及时感知并触发告警，很多灾难性事故本来是可以避免的。我自己的经验是，告警规则宁多勿少，但要把告警分级，别什么事都拉群轰炸，否则大家很快会麻木。

4.3 小型团队落地算力平台的实操路径

对于规模不大的团队，直接上一套商业化的集群管理方案可能既贵又重。我的建议是分三步渐进式落地。

第一步，先用开源容器编排平台把环境管理起来，让任务跑在容器里，而不是直接跑在裸金属上。这一步解决了环境隔离和依赖冲突的问题，成本也不高。

第二步，部署一个轻量级任务编排工具，把训练脚本、数据加载、结果保存这些步骤编排成可以复用的工作流。这一步让团队成员不再需要每次都手工处理繁琐的中间步骤。

第三步，等团队规模扩大、任务类型复杂化之后，再考虑引入功能更完整的算力平台。核心是不要让平台建设本身成为负担——工具的价值在于提升业务效率，而不是为了用工具而用工具。

5. 算力基础设施建设的常见问题与实操心得

5.1 硬件故障处理与容错设计

大集群下，硬件故障不是“会不会发生”的问题，而是“多久发生一次”的问题。一个一万张卡的集群，即使单卡年故障率只有1%，平均每天也有大约0.27张卡出问题。看着不多，但GPU故障往往不是均匀分布的，一组机柜同时出问题的概率并不低。

应对策略是必须在软件层面做好容错设计。训练任务要有周期性的检查点保存机制，故障后可以从最近的检查点恢复，而不是从头再来。我曾经历过一次训练跑了两周，因为忘记开检查点保存，一次电源故障让所有进度清零，那种感觉至今记忆犹新。

另外，建议在硬件到位后立刻做48小时以上的长时间压测。新设备的不良率通常遵循浴缸曲线——初期故障率和末期故障率偏高、中间稳定期故障率低。通过压测把前期的不良设备筛出来，比上线后再跟供应商搞售后拉锯要省心得多。

5.2 算力利用率的真实瓶颈排查思路

当你发现GPU利用率不高时，不要立刻断定是芯片不行或者集群规模不够。排查算力利用率的真实瓶颈，我一般是按下面这个顺序来：

先看任务本身是不是有计算密集型的瓶颈代码。有些数据预处理、日志打印、指标上报的逻辑没有异步化，会阻塞GPU计算，导致GPU只能等CPU。这类问题通过简单的代码调整就能解决。

再看数据加载链路。如果数据读取速度跟不上GPU的消费速度，GPU就会频繁陷入等待状态。存储侧的IOPS和带宽、数据预处理管道的吞吐量，都是常见的瓶颈点。

最后看网络。如果任务涉及大规模分布式并行，网络延迟和带宽问题会直接影响集群规模扩展效率。NCCL这类集合通信库的耗时，就是衡量网络健康度的关键指标。如果你发现GPU利用率不低但训练速度上不去，大概率问题出在这里。

带宽大、规模大不代表没问题，用细颗粒度的profiling工具去分析真正的时间线，才是定位问题的最快路径。

5.3 算力成本控制的几条实用建议

成本控制这个话题，技术含量不亚于性能优化。我的几条建议都是从真金白银的教训里总结出来的。

第一，算力资源一定要做精细的生命周期管理。闲置的集群节点、无人使用的开发机、挂了一夜没跑完的调试任务，这些都是在默默烧钱。建议定期巡检并对连续闲置超过一定时间的资源做自动回收或降配处理。

第二，合理利用多级存储策略。热数据放在高IOPS的高性能存储上，冷数据自动迁移到大容量低成本存储介质上。数据分层可以显著降低存储成本，而存储成本在整个基础设施开销中占比不小，往往容易被忽视。

第三，推理场景优先考虑量化优化。把模型从FP16量化到INT8或者更低精度，虽然有一定的精度损失，但能大幅提升单卡并发能力、降低单次推理的算力消耗。对很多业务场景来说，这点精度损失完全在可接受范围内，省下来的成本却是实打实的。

5.4 算力需求评估速查表

最后整理一张速查表，方便遇到算力评估问题时快速对照参考。这张表结合了我做过的多个项目经验，具体数值会因场景和硬件不同而有差异，但思路是通用的。

我个人在项目里还有一个习惯：预算评估时永远把估算值再上浮20%。因为这个行业里几乎所有的需求预估都比实际来得保守，业务量一旦增长起来，基础设施扩容的周期又长，前期多规划一点容量，好过后期顶着业务压力做紧急扩容。适当的余量，也是基础设施设计的重要一环。

6. 产业逻辑之外：算力设施建设的几个长期判断

聊完了技术细节，最后说几点我对算力基础设施产业走向的判断，算是给还处于规划阶段的团队一些参考。

第一个判断是，算力基础设施的竞争正在从芯片层向上迁移。单纯比较“我有什么卡、你有几张卡”已经成为过去式。真正决定胜负的，是谁能把卡变成高效、稳定、低成本的AI服务能力。这个转变意味着软件栈、平台工具、运营体系的价值权重会持续上升。

第二个判断是，智能算力的规模化应用一定会走向生态化。没有哪一家能包揽从芯片到应用到服务的所有环节，分工协作是必然趋势。对团队来说，尽早选好自己所在的生态位，比盲目追求大而全重要得多。

第三个判断是，算力本身的密度提升还远未到天花板。芯片制程、封装技术、互联方式都在持续演进，未来单个机柜的算力密度会继续提升，也会对供配电和散热方案提出新一轮挑战。现在建设基础设施时，尽可能为功率密度升级预留空间，是很有远见的做法。

回到开头说的“深水区”，对这个阶段最贴切的描述其实是：行业已经不再被单纯的规模叙事驱动，而是回归到工程、效率和商业本质上来。AI基础设施的本质不是炫技，而是以合理的成本把算力变成可靠的产品力。谁能把这件事做好，谁就能在接下来的周期里站稳脚跟。