Kubernetes 为什么逐渐进入 AI 基础设施，传统虚拟机架构有哪些不足

Kubernetes逐渐进入AI基础设施，并不是因为传统虚拟机已经不能运行AI，也不是简单地因为容器比虚拟机“更快”。真正推动这一变化的，是AI工作负载开始同时面对GPU资源调度、模型服务弹性、分布式训练、节点自动扩容以及复杂的软件依赖管理。

传统虚拟机依然具有很强的价值，尤其适合租户隔离、基础设施管理和需要完整操作系统环境的场景。现在很多企业的AI基础设施实际上采用的是“虚拟机承载Kubernetes，Kubernetes再运行AI容器”的多层架构。

因此，更准确的问题不是“Kubernetes能不能取代虚拟机”，而是为什么AI工作负载越来越需要Kubernetes这样的编排层。

一、AI基础设施的问题不是只有CPU和内存

传统业务服务器比较容易理解。一台虚拟机分配若干CPU核心、内存和磁盘，应用运行在这台机器上。

AI工作负载却复杂得多。

一个训练任务可能需要4张、8张甚至更多GPU，同时要求GPU之间具有良好的互联拓扑；模型推理则可能根据请求量动态增加副本；数据处理任务可能需要高速NVMe；分布式训练还可能需要高速网络和RDMA。

这意味着AI基础设施管理的已经不是简单的“几台服务器”，而是一组相互关联的GPU、CPU、内存、网络、存储和软件资源。

Kubernetes的价值首先体现在资源编排。

Kubernetes通过Device Plugin机制，可以把GPU这类专用硬件注册为集群资源。以NVIDIA GPU为例，节点上的设备插件可以向Kubernetes暴露类似 nvidia.com/gpu 的资源，Pod再通过资源限制请求GPU。

这样，GPU就从管理员手工分配的物理设备，变成了Kubernetes调度器可以识别的一种集群资源。

二、传统虚拟机的问题并不是“虚拟化一定很慢”

这是理解AI基础设施非常重要的一点。

GPU运行在虚拟机中完全可以获得很高的性能。NVIDIA目前针对虚拟化AI环境提供了GPU passthrough等方案，并强调正确保持GPU、NIC、PCIe和NUMA拓扑对于AI训练和推理的重要性。

所以不能简单说：

虚拟机 = GPU性能差；

容器 = GPU性能好。

真正影响性能的是GPU如何分配、GPU与NIC如何连接、NUMA如何布局，以及NCCL等通信库能否看到正确的硬件拓扑。

例如NVIDIA A100的HBM显存带宽达到1.6 TB/s，但这并不意味着所有GPU数据传输都能够以1.6 TB/s运行。GPU显存、PCIe、NVLink、NIC和存储设备属于不同的数据路径。A100的不同形态本身也具有不同的互联能力。

因此，不能拿显存带宽和PCIe带宽简单做一个数字比较，就得出“虚拟机导致GPU被PCIe限制”的结论。

三、Kubernetes真正解决的是资源调度问题

AI集群最大的变化之一，是GPU开始成为需要集中调度的稀缺资源。

假设一个集群有32台GPU服务器。

某个训练任务需要8张GPU，另一个推理服务需要2张，第三个批处理任务需要4张。

如果管理员手工分配机器，很容易出现一台服务器GPU已经被占满，而另一台服务器仍然空闲的情况。

Kubernetes可以把这些GPU注册成集群资源，再结合Pod的资源请求、节点标签、亲和性、污点和容忍度等规则，把任务放到满足条件的节点上。

如果集群存在不同型号GPU，还可以通过节点标签和调度约束把任务安排到对应GPU节点。Kubernetes官方GPU调度文档也明确支持这种方式。

这对于AI基础设施非常重要，因为GPU通常比CPU昂贵得多。GPU空闲一小时和普通CPU核心空闲一小时，其经济意义并不相同。

四、训练和推理需要完全不同的扩展方式

AI训练往往是长时间运行的任务。

一个训练Job可能运行数小时甚至数天，需要固定GPU资源、稳定网络和可靠存储。

在线推理则完全不同。

白天请求量可能快速增加，晚上又迅速下降。

这时候真正需要的是根据业务负载增加或减少模型服务副本。

Kubernetes的HorizontalPodAutoscaler可以根据配置的指标调整工作负载的Pod副本数量。它本身并不天然等于“GPU自动扩缩容”，GPU利用率等指标需要通过相应的监控和指标系统接入。

如果新增Pod导致现有GPU节点没有足够资源，节点自动扩容器还可以进一步创建新的节点。

Kubernetes官方的节点自动扩容机制就是围绕“无法调度的Pod需要更多节点容量”这一过程工作的。

因此AI弹性扩展实际上通常是两层：

业务负载增加 → 增加Pod；

GPU节点容量不足 → 增加GPU节点。

两者不能混为一个“HPA自动增加GPU”的动作。

五、GPU启动速度本身也是AI基础设施的问题

容器确实通常比创建完整虚拟机更轻量，但AI服务不能只看“容器启动用了几秒”。

一个GPU推理Pod真正可以接收请求之前，还可能经历：

节点创建、操作系统启动、GPU驱动初始化、设备插件注册、容器启动、镜像拉取、Python环境初始化、模型加载以及GPU显存分配。

尤其是大型模型，真正耗时间的可能不是Docker启动，而是模型权重从存储加载到GPU显存。

因此，AI基础设施中的冷启动应该测量从“Pod Pending”到“模型真正Ready”的完整时间，而不能简单拿普通Web容器的启动速度进行比较。

六、Kubernetes网络并不会自动让GPU通信更快

原文把CNI、eBPF和Service Mesh与GPU AllReduce性能直接联系起来，这需要修正。

分布式AI训练真正关心的是GPU之间的数据交换。

在单台服务器内部，可能涉及PCIe、NVLink或NVSwitch。

跨服务器时，则可能使用高速以太网或InfiniBand，以及RDMA。

NCCL等通信库会根据硬件拓扑选择合适的通信路径。

因此GPU训练性能优化的核心通常是GPU、NIC、PCIe、NVLink、NUMA和RDMA之间的关系，而不是简单地把Service Mesh装上去。

事实上，Service Mesh主要解决的是服务网络治理、流量管理、安全和可观测性问题，并不是专门为GPU AllReduce设计的。

对于高性能GPU通信，反而需要避免不必要的网络代理和数据路径开销。

七、传统虚拟机真正需要解决的是拓扑透明性

虚拟化环境最大的挑战之一，是AI应用需要知道底层硬件拓扑。

例如一个服务器里有8张GPU。

如果其中4张GPU通过NVLink连接，而另外4张位于另一组PCIe拓扑下，那么不同GPU之间的通信成本可能不同。

NVIDIA针对虚拟化AI环境的技术文档特别强调GPU、NIC、NUMA、PCIe和NVLink拓扑信息，因为NCCL需要这些信息来选择更合理的通信路径。

所以真正成熟的虚拟化AI环境，并不是简单地“给虚拟机一张GPU”，而是要尽可能保留对底层硬件拓扑的正确认知。

这也是为什么GPU passthrough、SR-IOV、vGPU以及其他硬件加速技术会成为AI虚拟化的重要组成部分。

八、存储问题也不能简单归因于虚拟机

AI训练经常需要读取大量数据。

这时候NVMe、并行文件系统、对象存储、缓存以及GPU与存储之间的数据路径都可能成为瓶颈。

但是不能简单说“NVMe经过虚拟机后固定下降40%”。

实际性能取决于设备、文件系统、虚拟化方式、队列深度、CPU、PCIe拓扑以及应用访问模式。

如果工作负载确实受到CPU数据搬运影响，NVIDIA GPUDirect Storage提供了一条不同的数据路径，可以让支持的存储系统通过DMA直接在存储和GPU显存之间传输数据，从而减少经过CPU系统内存的bounce buffer。

这里还需要特别注意，PVC只是Kubernetes的存储抽象。PVC本身不会让GPU直接访问NVMe。

真正实现GPU与存储直接数据路径的是GPUDirect Storage等具体技术，而且它需要特定的GPU、存储、文件系统和应用条件。

九、Kubernetes并没有消灭虚拟机

这是整篇文章最应该避免的一个误解。

现实中的AI基础设施完全可能是：

物理服务器 → 虚拟机 → Kubernetes节点 → GPU容器 → AI模型。

虚拟机负责基础设施层面的隔离、标准化和生命周期管理，Kubernetes负责容器编排、服务部署和资源调度。

NVIDIA目前仍然维护和认证GPU虚拟化环境，并明确指出虚拟化对于多租户、工作负载隔离、策略控制和基础设施生命周期管理仍然具有价值。

所以Kubernetes进入AI基础设施，并不意味着虚拟机消失了。

更常见的变化是两者开始承担不同层次的任务。

十、AI基础设施最终需要的是多层资源管理

真正成熟的AI平台往往同时管理几个层次。

最底层是物理硬件，包括GPU、CPU、内存、PCIe、NVLink、NIC和存储。

上面可能存在虚拟机和Hypervisor。

再上一层是Linux和容器运行时。

Kubernetes负责Pod调度、GPU资源管理、服务部署和节点扩缩容。

NVIDIA Container Toolkit以及GPU Device Plugin负责把GPU能力连接到容器和Kubernetes。

再上面才是PyTorch、TensorFlow、推理服务器和具体模型。

每一层解决的问题不同。

因此，Kubernetes进入AI基础设施的真正原因，不是“容器比虚拟机先进”，而是AI工作负载已经从单机程序变成了需要统一管理GPU、网络、存储、模型服务和计算任务的复杂分布式系统。

传统虚拟机依然适合做基础设施隔离和资源承载，而Kubernetes则提供了更高一层的编排能力。

最终的工程目标也不是单纯追求容器启动快几秒，而是让昂贵的GPU能够被正确发现、合理调度、稳定运行，并在训练、推理和批处理任务之间尽可能减少长期闲置。

从这个角度看，Kubernetes并不是虚拟机的简单替代品，而更像是AI基础设施进入大规模运营以后所需要的一层资源控制和应用编排系统。真正成熟的架构，往往不是在“虚拟机还是Kubernetes”之间二选一，而是根据隔离、性能、GPU拓扑、弹性、成本和运维要求，把物理机、虚拟机、Kubernetes和GPU容器组合成一个完整的平台。