从单机、虚拟化到资源池：数据中心如何走向算力中心？

摘要

算力中心不仅是服务器、GPU 和高速网络的集合，更重要的是通过软件平台，把分散的硬件变成可以统一申请、调度和回收的资源。从单机、虚拟化、容器到 Kubernetes，数据中心管理的对象不断变化，最终形成了今天面向 AI 任务的云原生算力平台。

前面几篇文章，我们聊了算力中心是什么，也介绍了 GPU、存储和网络等关键硬件。但如果只看到这些设备，仍然很难真正理解算力中心是怎么工作的。

系列回顾： 算力中心到底是什么：它不是一个更大的数据中心一提算力就想到显卡？算力中心里其实不只有GPU 你买的美光、铠侠、长鑫，背后的HBM、DDR5、NAND都在算力中心哪里？ GPU为什么也会等网络？从机房互联到算力集群

因为用户并不会抱着一台 GPU 服务器回去训练模型，也不会亲自选择某一块显卡、某一张网卡和某一组磁盘。用户真正需要的是：提交一个任务，说明需要多少算力、使用什么环境、读取哪些数据，然后等待平台把任务运行起来。

从硬件设备到可使用的算力，中间还隔着一整套软件平台。

这一层不像服务器、机柜和交换机那样看得见、摸得着，却决定了硬件能不能被统一管理，任务能不能被合理安排，资源能不能在使用结束后重新回到池中。它也是数据中心走向算力中心过程中，最容易被忽略的一部分。

如果回头看这段技术演进，会发现今天的算力中心并不是突然出现的。它是在单机、虚拟化、容器和 Kubernetes 等多轮技术变化中逐渐形成的。每一轮变化，都在解决上一阶段留下的问题，也在改变我们管理数据中心的方式。

先看现在：AI 算力中心怎样把硬件变成资源池

先不急着回顾历史，我们从今天的 AI 算力中心开始看。

假设一位算法工程师要训练一个模型，他需要 8 张 GPU、一套指定版本的 CUDA 环境、一份训练数据，还希望任务能够持续运行几天。

如果没有统一的软件平台，他可能需要先找到合适的服务器，确认 GPU 型号和数量，再安装驱动、配置环境、准备数据、启动任务。服务器出现故障后，还要自己判断任务停在了哪里。

这就像一个人要完成一项工程，却需要先到仓库里寻找设备、检查型号、组装工具，最后还要自己维护整套设备。硬件虽然都在，但还不能被方便地使用。

资源池化要做的，就是在硬件和使用者之间增加一个统一的管理层。

平台首先需要知道自己手里有什么：

哪些服务器安装了 GPU，每个节点有多少张卡；
GPU 的型号、状态和占用情况是什么；
存储在哪里，网络是否满足任务要求；
哪些资源正在使用，哪些资源还可以分配。

在云原生平台中，Kubernetes 负责管理集群中的节点和工作负载。GPU 等特殊硬件通常通过 Device Plugin 等机制暴露给 Kubernetes，使调度系统能够识别和分配这些设备。驱动、运行时和相关组件，则可以通过 GPU Operator 一类的工具统一部署和维护。

但“看见资源”只是第一步。

当用户提交训练任务时，平台还需要理解任务的要求：申请多少 CPU、内存和 GPU，使用什么镜像，数据从哪里读取，任务优先级如何，是否允许等待，以及失败以后应该怎样处理。

容器镜像解决了运行环境的一致性问题。它把应用程序、依赖库和运行环境一起打包，使任务不再过度依赖某一台服务器上临时安装的软件。对使用者来说，这相当于把一套已经准备好的工具箱带到平台上，而不是每换一个工作地点，就重新组装一次工具。

接下来，平台要判断任务现在能不能进入集群。对于资源紧张的 AI 训练环境，仅依靠 Kubernetes 默认调度器通常还不够。Kueue 等队列与准入管理组件，会结合配额、优先级和资源余量，决定哪些任务先进入，哪些任务继续等待。

任务获得准入后，Kubernetes 调度器再为工作负载选择具体节点。平台同时完成网络、存储和运行环境的准备，最终让任务真正启动。任务结束以后，CPU、内存和 GPU 等资源被释放，重新进入可申请状态。

所以，资源池化不是把服务器和 GPU 摆在同一个机房里，也不是在管理界面上把数量简单相加。它至少包含七个连续动作：

识别资源；
统一登记；
接收任务申请；
排队与准入；
匹配运行节点；
监控任务状态；
结束后回收资源。

今天看起来理所当然的这套流程，其实经历了很长时间的演进。要理解它为什么会变成现在这样，还要从一台机器运行一套系统的时代说起。

单机时代：一套系统对应一台机器

早期的数据中心里，应用、操作系统和物理服务器往往是绑定在一起的。

一套业务系统需要上线，通常先采购服务器，再安装操作系统、数据库和应用程序。服务器属于这套业务，资源也很难被其他系统灵活使用。

这种方式最大的优点是直观。哪台服务器运行什么业务，打开机柜就能找到；系统出了问题，也可以直接围绕这台机器排查。但随着系统越来越多，它的问题也逐渐暴露出来：

有的服务器长期高负载，有的服务器大部分时间处于空闲状态；
新业务上线需要重新采购和部署设备；
硬件故障可能直接影响整套系统；
操作系统、驱动和应用之间的依赖，让迁移和扩容变得复杂。

2011 年，我刚参加工作不久，主要负责公司集成部门的售后技术支持。一个烟草客户的 SAP 系统运行在两台 IBM 小型机上，从安装 UNIX 操作系统、配置 DB2 数据库到部署应用，整套系统都围绕这几台固定设备搭建。

一次直连 SAS 存储扩容让我印象很深。真正紧张的不是把磁盘扩展柜接上去，而是在 RAID 扩容和数据卷调整过程中，保证 DB2 数据与订货文件不受影响。任何一步出现问题，都可能影响整套订货业务。

那时我们管理的是一台台具体的设备。业务、操作系统、数据库、数据卷和硬件之间的关系非常紧密，任何调整都需要围绕这套固定环境进行。

单机时代最典型的特征是：应用运行在哪里，几乎等同于应用属于哪台服务器。

VMware 虚拟化：先把系统从物理服务器里抽出来

虚拟化带来的第一个重要变化，是把操作系统与物理服务器分开。

在之前的[[一提算力就想到显卡？算力中心里其实不只有GPU（终稿）]]中，我介绍过虚拟化：一台物理服务器可以运行多台虚拟机。每台虚拟机都有自己的 CPU、内存、磁盘和操作系统，看起来像一台独立服务器，但底层资源来自同一套物理设备。

如果把物理服务器比作一栋办公楼，虚拟机就像楼里的独立办公室。过去一家公司需要占用整栋楼，虚拟化以后，可以根据实际需要划分不同面积的房间。办公室仍然彼此隔离，但楼里的空间得到了更充分的利用。

虚拟化解决了很多单机时代的问题。业务不再必须独占一台物理服务器，虚拟机可以更快创建，硬件利用率也得到提升。在共享存储和集群能力的配合下，虚拟机还可以在物理节点之间迁移，设备故障也不再必然意味着业务长期中断。

我第一次接触 VMware，还是在这个烟草客户的项目里。过去给业务准备环境，首先要确认物理服务器；进入虚拟化平台以后，我们面对的变成了一个资源池：先创建虚拟机，再分配 CPU、内存和存储。

真正让我理解虚拟化价值的，是一次紧急的新业务上线。当时留给我们的准备时间很短，现有 vSphere 集群的剩余资源又不足以承载新业务，采购服务器也赶不上上线进度。我们只能先关停集群中优先级较低的业务，释放出足够资源，让新业务按期上线。等新服务器加入集群后，再恢复此前暂停的系统。

虚拟化不会凭空创造算力，但它让有限的资源可以按照业务优先级重新分配。

物理服务器也不再只是一台固定的业务主机，而是资源池中的一个节点，业务调整因此有了更大的回旋空间。

不过，虚拟化主要解决的是“如何更灵活地使用服务器”。每台虚拟机仍然包含一套完整的操作系统，系统镜像通常比较大，启动需要时间，环境维护也依然复杂。

随着互联网应用快速迭代，新的问题出现了：如果只是发布一个应用，是否还需要连同一整套操作系统一起交付？

容器：被交付的对象从操作系统变成应用

容器进一步改变了应用与基础设施的关系。

虚拟机通常打包的是一台完整的“虚拟电脑”，容器打包的则主要是应用程序及其运行所需的依赖。多个容器可以共享宿主机内核，因此比虚拟机更轻，启动也更快。

如果说虚拟机是为每位住户准备一套完整公寓，那么容器更像一组标准化房间：房间里放好了应用需要的家具和用品，而供水、供电等基础设施由整栋建筑共享。

容器解决了一个长期困扰开发和运维的问题：同一个应用在开发环境里能够运行，到了测试或生产环境，却可能因为软件版本和依赖不同而出错。

应用被制作成容器镜像以后，代码、依赖和运行环境可以一起交付。部署的对象不再是“某台已经手工配置好的服务器”，而是一个可以重复创建的标准化应用单元。

容器改变的不只是启动速度，更重要的是把交付对象从一套完整操作系统，变成了标准化的应用单元。

但容器越多，新的管理问题也随之出现：

容器应该运行在哪台服务器上？
一台服务器故障后，容器由谁重新启动？
应用需要多个副本时，怎样分散到不同节点？
升级过程中，怎样逐步替换旧版本？
资源不足时，哪些任务应该优先运行？

单台机器上的容器工具可以创建和运行容器，却不能独自解决大规模集群中的协调问题。数据中心需要一个新的控制系统。

Kubernetes：让整个集群开始按照任务运转

Kubernetes 的核心价值，不只是“管理容器”，而是把一组服务器组织成一个可以统一调度的集群。

使用者不必指定应用一定运行在某一台机器上，而是描述自己想要的结果：

运行多少个副本；
需要多少 CPU 和内存；
开放哪些端口；
挂载什么存储。

Kubernetes 再根据集群状态选择合适的节点，并持续检查实际状态是否符合预期。如果实例异常退出，控制系统会尝试重新创建；如果节点不可用，工作负载可以在条件允许的情况下重新调度；如果需要扩容，也可以增加副本数量。

Kubernetes 不是只执行一次命令，而是持续让实际状态靠近期望状态。

这是一种管理思路上的变化。过去，运维人员关心的是“这台服务器上运行了什么”；到了 Kubernetes，平台更关心的是“整个集群还有多少资源，以及这些任务应该怎样运行”。

以前发布应用，我们需要登录业务虚拟机逐台操作；节点出现异常后，也要先确认应用原来运行在哪里。接触 Kubernetes 以后，我们更多描述应用需要多少副本、申请多少资源，平台再据此安排工作负载。在实例异常或节点不可用时，控制系统会在条件允许的情况下重新调度。

这不意味着服务器和虚拟机的健康状态不再重要，基础设施团队仍然要维护它们。真正改变的是应用团队的工作重心：从逐台登录机器、维护具体运行位置，转向声明并维持应用应该处于什么状态。

不过，普通互联网应用和 AI 任务仍然存在明显差异。

AI 训练可能一次申请多张 GPU，需要高速网络连接多个节点，还要读取大规模数据集。某些分布式训练任务必须等所有资源准备齐全后一起启动，不能先运行一半，再慢慢补充另一半。

这意味着，Kubernetes 提供了集群管理的基础，但要支撑真正的 AI 算力中心，还需要在它之上增加 GPU 管理、批任务队列、配额、优先级、训练任务编排、模型管理和可观测性等能力。

回到今天：云原生 AI 平台怎样把这些技术叠在一起

这里所说的“云原生”，不等于业务一定运行在公有云上。它更强调应用以容器为交付方式，以 Kubernetes 为基础进行编排，并通过声明式配置、自动化调度和平台化管理，让工作负载可以更灵活地使用底层资源。

一套完整的 AI 算力平台，大致可以分成四层。

第一层：物理基础设施

这一层包括 CPU 服务器、GPU 服务器、存储系统和高速网络。

它们提供真实的计算、存储和通信能力，也是算力中心最容易被看见的一部分。但硬件本身不会理解训练任务，更不会自动决定资源应该分给谁。

第二层：容器与集群编排

容器负责封装应用和运行环境，Kubernetes 负责管理节点、工作负载和基础资源。

GPU 驱动、容器运行时和设备插件等组件，则把 GPU 纳入集群的资源体系，让平台能够知道哪些节点有 GPU，以及任务可以申请多少张卡。

第三层：调度与管理

这一层开始处理 AI 场景中特有的问题。

当多个团队同时提交任务时，平台需要管理项目配额、任务队列和优先级；当训练任务需要多张 GPU 或多个节点时，平台要尽量保证资源能够成组分配；资源不足时，还要决定任务是等待、抢占，还是转移到其他可用资源池。

这里有两个容易混淆的问题：

队列与准入系统回答的是：“这个任务现在是否应该进入集群？”
Kubernetes 默认调度器回答的是：“一个已经允许运行的 Pod 应该放在哪个节点？”

两者配合，才能让有限而昂贵的 GPU 资源被更有秩序地使用。

第四层：面向 AI 的平台服务

最上层才是算法工程师和业务人员直接接触的部分，可能包括：

开发环境与 Notebook；
训练任务与推理服务；
数据集、模型仓库与实验记录；
监控、计费和任务状态管理。

用户看到的是一个提交任务的入口，平台背后完成的却是环境准备、资源申请、任务调度、状态监控和资源回收。

到了这一层，算力中心提供的就不再是某一台服务器，而是一种可以按任务使用的能力。

从物理服务器到 AI 任务，管理对象一直在变化

回顾这段演进，可以发现每一代技术都没有让上一代彻底消失，而是在它的基础上增加了一层抽象。

这条技术路线可以概括为：

单机时代，我们围绕物理服务器组织业务；
虚拟化时代，我们围绕资源池和虚拟机创建系统；
容器时代，我们围绕应用与依赖交付环境；
Kubernetes 时代，我们围绕集群中的工作负载维持期望状态；
云原生 AI 平台进一步管理任务、配额和服务。

这条技术路线表面上是在不断增加软件层次，实质上是在逐渐降低人和具体硬件之间的耦合。

底层硬件并没有消失。相反，GPU、存储和网络的重要性比过去更高。只是它们不再直接暴露给每一位使用者，而是由平台统一组织，再以任务所需的方式交付出去。

结语：软件把硬件组织起来，能源让算力持续运行

从数据中心走向算力中心，真正发生变化的，不只是服务器里多了 GPU。

更深层的变化，是管理对象从一台台设备转向整个资源池，从维护某台机器转向描述任务需要什么，再由平台完成资源识别、排队、调度、运行和回收。

虚拟化让操作系统摆脱了对固定物理服务器的依赖，容器让应用摆脱了对固定运行环境的依赖，Kubernetes 又让工作负载摆脱了对固定节点的依赖。在这些技术基础上，云原生 AI 平台才有可能把分散的 CPU、GPU、存储和网络，组合成用户可以直接申请的算力。

硬件决定算力中心能提供多大的能力，软件平台决定这些能力能不能被有效组织和使用。

但任务真正开始运行以后，另一个无法被软件抽象掉的问题马上出现：电从哪里来，热又怎样带走？

GPU 集群持续运行会带来更高的供电和散热压力；越来越多的高功耗设备集中在同一机柜，也会把机柜密度推到新的水平。此时，算力中心不仅要回答“任务调度到哪里”，还要回答“这一排机柜能不能供得上电、能不能及时散热、能以多高的能源效率持续运行”。

下一篇文章，我会把视角从软件平台移到机房里的电与热，继续讨论：

GPU 集群的功耗是怎样累积起来的；
机柜密度为什么成为算力中心的新约束；
PUE 衡量的是什么，又不能代表什么；
“绿色算力”除了使用绿色能源，还涉及哪些系统效率问题。

算力中心不是把更多 GPU 塞进机房，而是让计算、存储、网络、软件和能源共同形成一种可以持续交付的能力。

软件平台回答了“算力怎样被组织起来”。下一篇，我们继续看支撑这一切运行的底层条件：算力中心怎样获得电，又怎样把热带走。