大规模算力集群建设：从千卡到万卡的演进路径

大规模算力集群建设并不是把 GPU 数量从一千张直接扩成一万张那么简单，而是一条伴随网络架构、资源调度、存储吞吐、运维体系和组织协同不断升级的演进路径。千卡集群更多是在验证资源池是否可用，万卡集群则要求整个基础设施像工业化系统一样稳定运转：调度不能失控，网络不能拖后腿，故障不能靠人海战术，资源成本也不能随着规模线性失真。

很多企业在做算力规划时，会把“规模”理解成采购量，把“建设”理解成机房上架和网络打通。但真正难的地方恰恰发生在规模跨过某些门槛之后：训练作业开始频繁跨节点，数据路径开始成为瓶颈，队列争抢让优先级治理复杂化，设备故障率因为基数变大而显著上升。也就是说，从千卡到万卡，本质上是从“资源可用”走向“系统可运营”。

为什么千卡到万卡是一个质变过程

在小规模集群里，很多问题还可以靠经验和人工协调解决，例如手工挑节点、临时调优网络、定向支持重点任务。但规模一旦上来，这些做法会迅速失效。

第一，节点数量增多后，单点故障会成为常态而不是例外。第二，训练与推理、在线与离线、多团队共享资源会让调度冲突显著增加。第三，作业规模变大后，网络拓扑和存储路径对训练效率的影响会远高于单卡性能差异。第四，平台团队需要面对的是连续运营，而不是一次性交付。

因此，建设重点必须随着规模变化而变化。千卡阶段强调“把集群建起来”，万卡阶段强调“让集群长期稳定跑起来”。

可以把演进路径分成四个阶段理解

第一阶段：百卡到千卡，验证资源池可用性

这个阶段的重点不是极限性能，而是把基础链路打通：服务器、GPU、基础网络、存储、镜像、作业提交、监控和基础权限体系先能稳定运行。企业通常在这一阶段完成第一版算力纳管和作业调度平台建设。

核心问题是“能不能交付”，而不是“能不能最优”。如果百卡到千卡阶段基础组件不稳，后面规模再大也只会把问题放大。

第二阶段：千卡级，建立统一调度与资源治理能力

到了千卡规模，多团队共享资源会成为主要矛盾。谁先用、谁能抢占、谁的任务优先、资源如何计量、训练和推理如何隔离，这些都必须制度化、平台化。

这个阶段的重点是把资源池从“若干 GPU 机器集合”变成“可被规则管理的统一算力服务”。如果调度策略仍然依赖人工协调，千卡集群很快就会陷入资源争用和优先级失衡。

第三阶段：数千卡级，解决网络与数据路径瓶颈

当训练任务开始大量跨节点、跨机架甚至跨资源池运行时，网络拓扑、链路拥塞、存储吞吐和数据预热机制会变成核心瓶颈。此时企业会发现，光有 GPU 不代表训练效率高，真正限制大作业吞吐的往往是东西向网络和数据管道。

这一阶段的重点从“有没有资源”转向“资源协同是否高效”。

第四阶段：万卡级，进入运营工业化阶段

万卡集群的挑战已经不只是基础设施，而是整体运营体系。设备生命周期管理、批次上架、故障率统计、备件体系、作业优先级模型、容量预测、能耗控制、SLA 分层、跨区域资源协同，都要被系统化纳入平台治理。

此时算力平台的角色更像生产控制系统，而不只是作业提交入口。

每个阶段的建设重点并不相同

下面这张表更适合用来理解“阶段变化带来的建设重心变化”。

从千卡迈向万卡，最先出现的 5 个拐点

拐点一：调度复杂度暴涨

规模一大，资源不再是“有空就用”，而是要结合 GPU 型号、显存规格、节点拓扑、网络条件、优先级、配额和任务时长来综合分配。调度器如果只看空闲卡数，很快就会造成资源碎片化和大作业排队拥堵。

拐点二：网络从基础设施变成性能决定项

在万卡路线中，网络不是附属项，而是训练效率和稳定性的核心变量。节点间通信、参数同步、检查点写回、数据加载，都会持续冲击网络与存储链路。规模上来后，很多性能问题看似是模型问题，实际是网络与数据路径问题。

拐点三：故障处理必须从“维修”变成“运营”

千卡时一台机器坏了还可以人工跟进，万卡时硬件故障会持续发生。平台需要建立自动隔离、健康评分、维修流转、备件策略和批量问题识别机制，否则团队永远在被动救火。

拐点四：组织协同开始影响平台效率

算力团队、网络团队、存储团队、算法团队和运维团队如果没有统一接口和责任边界，规模越大，扯皮成本越高。万卡集群对组织协同的要求，不亚于对技术架构的要求。

拐点五：成本治理成为一等公民

从千卡到万卡，成本不只是采购成本，还包括机柜、电力、网络、冷却、空闲率、排队损耗和任务失败重跑成本。没有成本视角，集群规模越大，资源浪费越难控制。

企业应该如何规划这条演进路线

与其一开始就按“最终万卡形态”重投入，不如按阶段建设，但阶段之间必须预留演进接口。

步骤一：先定义未来两到三年的规模路径

不是问“今年买多少卡”，而是问明年、后年会不会进入多租户共享、跨区域训练、训推混部或异构算力阶段。没有未来路径，当前架构很容易走成死路。

步骤二：把网络和存储提前纳入一体规划

很多项目早期只围绕 GPU 和服务器采购展开，等到规模上来才补网络和数据链路，代价通常更高。正确做法是在千卡阶段就为数千卡和万卡阶段预留拓扑与带宽演进能力。

步骤三：尽早把调度规则平台化

配额、优先级、抢占、队列、公平共享、资源计量这些能力，越早制度化越好。否则团队会先形成一堆临时协调习惯，后期再改会非常痛苦。

步骤四：把可观测性建设成运营底座

万卡集群不可能靠人工去看单台服务器状态。必须建立从节点健康、GPU 利用率、作业排队、网络拥塞、存储热点到失败原因归类的一体化观察体系。

步骤五：在路线中预留混合架构能力

很多企业后续都会出现多地域机房、不同芯片类型、训推混部、外部云算力接入等需求。前期如果完全按单一资源池设计，后期扩展成本会急剧上升。

不同阶段更该关注哪些建设成果

如果只看“卡数增长”很容易产生错觉，更应该看每个阶段是否交付了正确成果。

• 千卡阶段要交付统一纳管和稳定调度。
• 数千卡阶段要交付高效协同和可预测性能。
• 万卡阶段要交付工业化运营与可持续扩容能力。

这也是为什么大规模算力集群建设不能只讨论设备清单。真正决定成败的，是每次扩容之后，平台是否仍然可控、可观测、可运营。

结语

大规模算力集群建设：从千卡到万卡的演进路径，核心并不是规模数字本身，而是每跨过一个阶段，建设重点都要同步升级。千卡阶段重在把资源池做成平台，数千卡阶段重在把网络与数据路径打通，万卡阶段重在把整套算力系统运营工业化。只有把这条演进路线看成持续升级的系统工程，企业才能真正把大规模算力资源转化为稳定、可持续的生产能力。

FAQ

千卡集群和万卡集群最大的差别是什么？

最大的差别不是设备数量，而是治理复杂度。千卡集群更多关注资源可用与统一纳管，万卡集群则必须同时解决调度策略、网络协同、故障运营、容量预测和多团队共享等问题。也就是说，千卡偏建设，万卡偏运营。

企业一定要一步到位按万卡标准建设吗？

通常没有必要。更现实的做法是按业务增长分阶段建设，但前期架构设计必须为后续扩容留出接口，特别是在网络、存储、调度规则和可观测性方面。否则早期看似省钱，后期重构成本会更高。

从千卡往上扩时，最容易被忽略的环节是什么？

最容易被忽略的是网络与数据路径，以及故障运营体系。很多团队会优先关注 GPU 采购和算力总量，却低估了东西向通信、数据加载、节点健康管理和维修周转对整体效率的影响。规模越大，这些问题越会成为主瓶颈。