AI算力基础设施升级：从GPU集群到大模型训练的落地实践

我们这次跑去参加第三届AI算力产业大会，说实话，主要目的不只是听厂商讲PPT，而是想看看真实落地的AI基础设施升级到底做到哪一步了。现场整体看下来，大家的讨论已经从“要不要训大模型”彻底转成了“怎么把算力成本降下来、怎么把集群跑稳、怎么让算力真正变成水电一样的基础服务”。绕着我关心的几个核心话题转了两天，结合这几年做智算中心建设和算力调度的经验，把关于AI算力基础设施升级的一些观察和实操思考整理出来，相信对正在规划算力平台或准备扩容的团队会很有帮助。

1. 为什么要提基础设施升级：算力早就不是买卡那么简单

1.1 行业集体转向的关键信号

大会第一天主论坛，几个头部云厂商和智算中心运营方的分享不约而同谈到了一组数字：很多千卡集群的真实利用率其实不到一半，真正能把万卡集群跑出理想线性加速比的项目更是屈指可数。买回来的GPU卡堆积在机房里，但算力并没有真正“流动”起来。这恰恰是为什么大家都在喊AI基础设施升级，因为瓶颈已经不再是单颗芯片的算力，而是整个系统能不能把这些算力高效地调度、分发、连接起来。

可以这么理解：单卡算力就像一个个水龙头，出水能力再大，如果管道太细或者水塔压力不够，用户端依然放不出多少水。AI基础设施就是那套管道、水塔和调度系统。这两年国内智算中心从百卡规模向千卡、万卡规模跨越，如果基础设施不做对应的升级，卡越多浪费越严重，故障恢复越困难，训练效率甚至可能不升反降。

1.2 奇点算力受邀参会的实际场景

奇点算力此次受邀参会，展台位置不算大，但来交流的人一直没有断过。过来问得最多的几个问题非常集中：第一，现有机房能不能直接扩到千卡以上规模，网络架构需不需要推翻重来；第二，GPU利用率低的问题，到底是通过调度平台解决，还是需要改上层训练框架；第三，推理场景和训练场景的基础设施能不能共用一个底座。

这些问题的背后，本质上是大家在为“算力基础设施升级”找一条可落地的路径。在大会上和奇点的技术团队聊下来，他们目前实际在做的算力底座升级，并不是简单地把显卡从A800换成H800再把网络从25G升到100G，而是从资源抽象、调度策略、故障自愈三个层面做整体重构。而这，也正是我认为AI基础设施升级最容易被低估、但又最值得投入的部分。

1.3 为什么说基础设施是下一个主战场

大会上有一句话我印象很深：“大模型的上半场拼算法，下半场拼基建”。当模型架构趋同、算法差距缩小，最终拼的就是谁的基础设施更稳、更省、更能弹性伸缩。这就像快递行业，电商平台谁都能开，但最后拼的是仓储网络和干线物流。

算力基础设施也是一样，GPU只是算力行业里的一个基础单元，真正决定竞争力的是算力网络、存储、调度、运维这一整套体系。这也是本次大会把“AI基础设施升级”放在核心议题的原因，背后确实是整个产业从粗放建设向精细化运营的必然转型。

2. 算力基础设施升级的几个核心工程维度

2.1 集群网络：从计算瓶颈到通信瓶颈

在任何一个超千卡规模的AI训练集群里，通信开销都是不可回避的硬问题。很多人以为买了最新的GPU卡，训练速度就自然会快，但实际跑到大规模并行训练就会发现，数据并行时的梯度同步、模型并行时的激活传输、流水线并行时的微批次通信，全部压在网络上。

这次大会上，多个技术演讲都提到RoCE（RDMA over Converged Ethernet）与InfiniBand的选择问题。从工程师视角，我的体会是，中小规模集群（千卡上下）用RoCE方案性价比很高，配合好的拥塞控制算法，实际吞吐能接近InfiniBand的八成以上，但成本和生态开放性优势非常明显。而到了万卡规模，InfiniBand的稳定性依然不可替代，毕竟通信抖动对几千卡同时跑的训练任务影响是灾难性的。

所以在基础设施升级时，建议先把通信模型算清楚：训练数据量多大、参数规模多少、并行策略是哪一种、期望的迭代时间是多少。这些参数直接决定网络带宽和拓扑选型，而不是单纯看端口速率。

2.2 存储：数据管道决定训练效率上限

存储系统是AI基础设施里最容易被低估的部分。训练任务开始前需要加载海量数据集，训练过程中需要周期性写入检查点（checkpoint），这些操作如果存储性能跟不上，GPU就只能空转等待。很多团队把精力花在调优GPU利用率上，却没发现瓶颈其实在存储的IO路径上。

大会上有一组实测数据挺有参考价值：同样一个千亿参数模型的训练任务，使用普通分布式文件系统和优化后的并行文件系统（如Lustre或WEKA这类方案），检查点保存时间可以相差十倍以上。在万卡集群上，如果每个检查点要保存几分钟甚至十几分钟，累积下来的时间损耗就非常可观了。

因此我在多个场合的建议都是：基础设施升级存储一定要和大模型训练特性绑定设计，不要买一套通用存储然后期望它适配所有场景。读多写少的数据集场景和写多读少的检查点场景，在存储架构设计上应该是两套不同的策略，必要时可以做分层存储。

2.3 调度系统：让算力真正流动起来

调度系统是AI基础设施的神经中枢。为什么很多集群GPU利用率上不去？去看调度策略往往就能发现问题。静态分配、缺乏弹性、不支持资源抢占，这三大问题在最常见的调度系统里都存在。

好的算力调度平台应该像打车软件一样：用户提出需求，平台自动匹配最合适的车辆和路线，不需要用户自己去选车、谈价格、找司机。而现在很多算力平台还停留在“电话叫车”阶段，用户得自己指定用哪几台机器、怎么组网、怎么分配资源，非常低效。

奇点算力这次分享的天机算力调度平台，核心思路就是三个词：资源池化、智能调度、故障自愈。把分散的GPU资源抽象成统一资源池，通过调度算法匹配任务需求和硬件状态，并对故障节点做自动隔离和迁移，这套逻辑是当前AI基础设施升级里值得借鉴的一个思路。

2.4 在大会现场看到的方案趋势

今年展区有一个非常明显的变化：液冷方案几乎成了标配。不管是传统服务器厂商还是新兴算力公司，展台上都放着液冷板、快接头和CDU（冷量分配单元）。风冷方案在单机柜功率达到20kW以上后，散热能力基本到顶，而液冷可以轻松支持50kW甚至100kW以上的功率密度。

另外一个明显趋势是“超节点”概念开始走向落地。传统8卡服务器通过交换机构建集群，胖树拓扑下跨节点通信延迟较高。而超节点架构通过高速互连把更多GPU直接连在一起，逻辑上形成一个更大的“单机”，对超大规模模型训练十分友好。但超节点也带来新的运维挑战，比如故障域变大、单点风险更高，这需要调度系统做更精细的应对。

3. 实操视角：面向AI基础设施升级的落地部署方案

3.1 整体评估：先知道自己的瓶颈在哪

算力基础设施升级，最忌讳的就是“看着别人上什么我也上什么”。每个团队的业务场景不同、预算规模不同、技术储备不同，适用的方案也不同。做升级规划前，我建议先做一次系统性的瓶颈评估，重点关注基础设施的资源利用率、任务排队情况、故障频率与恢复时长、存储IO性能这四项指标。通过一段时间的监控数据收集，基本就能定位当前系统的主要瓶颈点。

我在会上遇到一个实际的案例：某个做自动驾驶模型训练的团队，他们一直以为是训练框架调优不到位，导致GPU利用率只有30%左右。后来做了性能剖析才发现，瓶颈根本不是GPU，而是数据加载环节的存储IO太慢，GPU大部分时间在等数据。换了高性能存储并调整数据预取策略后，利用率轻松到了70%，没花一分钱在GPU上就解决了问题。

3.2 算力资源规划和硬件选型方法

硬件选型方面，核心原则是“按应用场景倒推资源需求”。如果主要跑千亿参数大模型预训练，那么显存容量和HBM带宽是第一优先级，同时网络互联能力也至关重要；如果主要做推理服务，那么需要重点关注延迟和吞吐的平衡；如果场景主要是微调和数据分析，则可以考虑用性价比更优的方案。

有个容易被忽视的细节是CPU和内存的配比。在数据预处理、tokenization、数据增强等环节，CPU计算密集度其实很高。很多AI集群CPU配比偏低，导致GPU喂不饱，数据处理反而成了瓶颈。经验上，一台8卡GPU服务器至少需要配64核以上的CPU和512GB以上内存，并且要预留足够的NVMe缓存盘空间。

网络层面需要关注的不仅是带宽，还有拥塞控制能力和故障域隔离。40Gbps内网带宽对千卡集群训练是下限，如果预算允许，直接上400Gbps的RDMA网络能为未来的集群规模扩展留足空间。

3.3 设计和部署一套AI基础设施的步骤拆解

结合这几年做算力平台的经验，我把AI基础设施的部署过程拆成八个主要步骤：

第一步：业务需求梳理
明确未来一年内要支撑哪些AI业务场景，大概的训练任务规模、推理并发量是多少，数据量增长预期是怎样的。这一步是整个设计的源头，需求没搞清楚后面的架构全是空中楼阁。

第二步：算力规模规划
根据模型参数量、训练数据量、目标交付周期，测算需要的总算力规模。一个经典的经验公式是：训练一个X亿参数的大模型，需要约6X TFLOPS的算力处理每条训练样本，乘以总样本数和训练轮数再除以目标时间窗口，就能得出理论上需要的总算力。

第三步：硬件选型
结合预算规模和应用场景，确定GPU型号、服务器配置、网络规格、存储方案。这一步需要和多个供应商做对比测试，不能只看纸面参数，建议用自己真实的训练脚本在候选硬件上做小规模验证。

第四步：机房基础设施评估
确认电力容量、散热能力、机柜空间是否满足高密度AI集群的要求。这一步在升级项目中尤其重要，因为很多现有机房当初并不是按AI算力场景设计的，电力余量和散热能力都可能是硬伤。

第五步：网络和存储架构设计
根据集群规模设计网络拓扑，计算带宽需求，确定存储方案。这里建议先做流量模型仿真，把训练过程中的通信模式在图纸上先跑一遍，避免上线后才发现网络瓶颈。

第六步：平台软件部署
安装GPU驱动、容器运行时、调度平台、监控系统。现在主流的方案是Kubernetes搭配GPU调度插件，再加一层面向AI任务的工作负载编排层，把训练、推理、数据预处理等任务统一管理起来。

第七步：性能测试与调优
用小规模数据集跑通端到端流程，逐步扩展到大规模，记录各个阶段的吞吐和延迟数据，和理论值做对比，找出差距并针对性地优化。

第八步：运维体系建设
建立监控告警、日志采集、故障处理流程。在AI集群里，GPU故障、网络抖动、存储异常都是常态，体系的自动化程度决定了运维效率和集群可用性。每个步骤之间都有紧密的依赖关系，建议不要跳步，否则后期返工成本会非常高。

3.4 一条实际可参考的部署路径

我整理的部署路径核心原则是“先小后大、先通后优”。不管目标规模是千卡还是万卡，第一步一定先把最小可用闭环跑通。所谓最小可用闭环，就是几十张卡规模的集群上，完成从数据准备、模型训练、模型评估到服务发布的完整流程。这个闭环验证通过后，再逐步扩展集群规模。

盲目追求一步到位直接上超大集群，往往会遇到难以排查的分布式问题。分布式训练中有一类经典问题：小规模跑得好好的，一上大规模就崩溃或者性能骤降，这类问题往往涉及通信模式、数据加载、任务调度等多方面因素，在规模扩展后才会暴露。

建议的做法是把扩展过程分成几个阶段，每到一个规模档位就做一次完整的稳定性测试和性能记录。比如128卡验证通过后再上512卡，512卡稳定后再上1000卡以上。这种阶梯式扩展虽然看起来周期更长，但实际反而更快，因为每个阶段的问题都在可控范围内被消化掉了，不会等到大规模阶段集中爆发。

4. 大会现场收集到的一线问题与排查经验

4.1 GPU利用率异常偏低的典型场景

这次展位上遇到不少运维工程师来问GPU利用率的问题，大部分情况都集中在数据和通信瓶颈上。数据瓶颈的排查方法很简单：在训练脚本里记录每个step的数据加载耗时和计算耗时，如果数据加载耗时占比超过20%，存储系统或数据预处理流程大概率需要优化。

还有一个会场上大家讨论较多的GPU利用率问题来自框架层面，当模型采用张量并行时，通信量非常大。此时需要注意通信计算的相互掩盖，在代码层面如果不能做到通信和计算重叠，再好的网络也发挥不出性能。多卡通信效率可以通过NCCL的all_reduce测试单独验证；如果通信测试没问题而实际训练利用率低，问题往往出在训练脚本本身，而不是基础设施。基础设施团队和算法团队各自排查很容易互相甩锅，比较高效的方式是一起坐下来，把训练过程的性能画像完整拉出来，数据说话，问题通常能浮出水面。

4.2 分布式训练突然中断的排查思路

分布式训练中断是很影响进度的问题，特别是规模大了以后几乎不可避免。排查这类问题，我的经验是第一步先看是否是硬件故障。GPU卡在持续高负载下出现ECC错误或者温度过高导致降频掉卡，这种情况可以通过查看系统日志和GPU状态来确认，一旦发现硬件问题，先隔离故障节点再谈其他。

第二步检查网络是否出现丢包。在RoCE网络中，丢包对训练的影响是致命的，很小的丢包率都会导致通信效率断崖式下降。可以通过统计网络计数器是否有大量重传判断是否存在丢包，并结合拥塞控制策略和流控机制做针对性优化。网络问题必须在基础设施层解决，光在应用层重试没有意义。

如果硬件和网络都正常，第三步要看是不是存储或数据问题导致任务异常退出。例如某个数据分片损坏、数据读取超时等，都可能导致训练进程崩溃。这种问题相对隐蔽，建议在数据加载环节做好完整性校验和故障重试机制，把偶发异常的影响降到最低。

4.3 一次真实的大规模训练性能排查案例

之前在协助一个客户做训练性能优化时遇到过一个比较典型的问题：集群规模从256卡扩展到512卡后，理论算力翻倍，但实际训练吞吐只提升了不到40%。通过性能剖析工具发现，随着规模扩大，通信时间占比从15%飙升到了45%，这说明扩展性瓶颈主要在通信而非计算。

进一步排查发现两个问题：第一是网络拓扑中部分交换机端口存在拥塞，导致跨Pod通信性能严重劣化；第二是训练作业的资源调度不够紧凑，任务被分配到了不同机柜的机器上，跨机柜通信比例过高。针对这两个问题，分别优化了网络流量负载均衡，同时在调度策略上增加了拓扑亲和性配置，把同一个训练任务的节点尽量调度到同一棵交换子树下。优化后500卡规模的训练吞吐提升了近一倍，已经接近理论线性扩展比。

这个案例说明，大规模训练的调优是一个系统性工程，基础设施层和应用层必须打通来看。只调网络不管调度，或者只优化训练脚本不管网络架构，都很难达到理想的性能水平。这也是为什么现在甲方越来越倾向于找像奇点算力这类有全栈能力的服务商，而不是分别找网络厂商、服务器厂商和软件厂商各管一段。

4.4 一张适合保存的算力基础设施常见问题排查表

5. 大会上几个值得关注的行业趋势信号

5.1 统一调度成为基础设施软件栈的核心

多个演讲嘉宾都在强调，接下来算力基础设施的软件栈会明显分层。最底层是硬件资源层，中间是资源抽象与调度层，最上层才是各类AI应用和开发框架。而中间这层，正是国内相对比较薄弱的地方。

目前大家用得比较多的开源调度框架还是以Kubernetes为主，但它在处理AI任务时还是有不少需要补强的地方，包括对GPU特殊资源的调度语义不完善、对RDMA网络的感知能力不足、对多任务混合编排的支持有限等。所以出现了越来越多的专业调度平台，把GPU资源池化、拓扑感知调度、故障自愈等能力做深做透。

5.2 多元算力融合趋势明显

大会现场一个很明显的信号是“不把鸡蛋放在一个篮子里”。过去很多智算中心规划时基本只考虑单一品牌GPU，现在越来越多的项目开始考虑多元算力融合方案。不同芯片在不同场景下有各自的优势：有些适合训练，有些适合推理，有些在功耗比上表现更好。

多元算力融合的挑战在软件层，不同的加速卡有不同的驱动、不同的算子库、不同的框架适配程度，如何在上层抽象屏蔽这些差异，是基础设施平台要解决的关键问题。目前业界的做法是在调度平台层做适配，通过统一的资源描述和任务抽象来承接不同芯片的差异。

5.3 智算中心从建设导向转向运营导向

前几年智算中心的建设模式更多是“建完就完”，政府或企业投钱把机房和各种设备建好，之后运营情况如何关注度不高。而这次大会上，很多分享都在谈算力运营，包括怎么提高算力利用率、怎么设计计费模式、怎么做算力消纳等。

这个转变我认为是非常及时的，AI基础设施如果只建不用或者用不好，那才是最大的浪费。算力运营的核心是要把算力变成可计量、可调度、可交易的标准服务，让算力像水电一样方便获取。这需要底层基础设施具备完善的资源计量、计费、编排能力，也需要运营方对行业客户的真实需求有深刻认知。那种单纯“出租GPU资源”的粗放模式已经越来越难走通了，给客户提供带行业know-how的一体化AI解决方案才是更有壁垒的模式。

5.4 数据与算力的协同开始被重视

过去“数据”和“算力”往往是分开讨论的，数据工程归数据工程，算力平台归算力平台。但这届大会上，好几个嘉宾开始把数据准备、数据管理、数据流转放到AI基础设施的范畴里整体考虑。这个思路是对的，算力再强，数据质量不行、数据流转效率低，AI项目的整体进度仍然会被严重拖慢。

基础设施升级规划中，我认为数据平台的升级应该和算力集群的扩容同步推进。特别是数据标注、数据版本管理、数据血缘追踪等能力，在规模化AI生产中几乎成了刚需。算力基础设施和数据基础设施的融合设计，会是接下来AI工程化落地的一个重要方向。

6. 关于AI基础设施升级，我的一些体会

参加完这届大会，最深的感受是AI基础设施这个赛道已经进入了深水区。过去我们聊算力，更多是看GPU型号、看总算力峰值；现在大家关心的是集群的可用算力、有效算力，是GPU利用率能到多少，是故障恢复需要多长时间，是调度效率高不高。这说明整个产业在快速走向成熟。

记得和一位来展台交流的客户聊天，他说了句话：“我以前觉得买一千张卡就拥有了算力，后来才发现买到的只是一堆需要伺候的硬件。”这句话很形象。AI基础设施的本质，是把硬件变成好用、易用、可规模化的服务，这是一个系统工程，也是接下来产业竞争的关键。

文章最后分享一个实用建议：在升级自己的AI基础设施之前，先把需求梳理清楚比什么都重要。你的业务到底需要什么样的算力、要支撑多大的并发、允许什么样的延迟、预算是多少，这些问题如果回答不清楚，方案设计就无从谈起。建议先花时间把业务场景摸透，再做小规模的技术验证，最后才进入大规模采购和部署阶段。这个顺序如果反过来，先买设备再找场景，十有八九会踩坑。我在实际项目中见过太多这样的例子，最后不仅预算超支，项目周期也被拖得很久。先想清楚，比什么都重要。