“人工智能工厂”并不是单个模型或单独的 Kubernetes 集群，而是由并行团队出于不同目的共同使用的 GPU 图形处理单元集群：微调、推理运行和评估。CNCF 博客上发表的一篇文章认为，企业面临的真正挑战已不再只是训练模型，而是让每个团队都能安全、隔离地访问同一套硬件，同时保持较高的 GPU 利用率，并使成本可衡量。
本文作者 Hrittik Roy 是 CNCF Ambassador 和 vCluster Platform Advocate，文章以实践视角介绍了如何在 Kubernetes 之上构建这一环境。文章的核心观点是，Kubernetes 为容器、RBAC、自动扩展和策略提供了成熟基础，但要处理加速器以及同一节点上的租户隔离，还需要额外的生态系统。
瓶颈在于利用率，而不仅仅是推理速度
GPU 单元是人工智能基础设施中最大的资本支出，因此利用率比单次运行达到最高速度更具经济指标意义。文章提出了两个主要问题：资源分配模型和隔离模型。
在传统的 device plugin 模型中，工作负载可能请求 nvidia.com/gpu: 1，并占用整个单元，即使实际上只使用了其中百分之十。Dynamic Resource Allocation 或 DRA 已在 Kubernetes 1.34 中正式普遍可用，它允许调度器将加速器视为具有属性、内存和拓扑结构的设备。不过，它不会自动将 GPU 单元切分为配额；密度来自设备层，例如 HAMi。HAMi 是 CNCF 中处于 Incubating 阶段的项目，可在容器级别对内存和计算实施软件限制，并支持多种加速器供应商。
相反，为每个团队分配独立硬件可以实现强隔离，但会使大量容量处于未使用状态。因此，文章区分了两种方式：当信任边界严格时分配完整单元；在同一信任域内切分单元以提高密度。NVIDIA MIG 能够在硬件层面提供内存和故障隔离，但文章指出，将其作为恶意租户之间的隔离边界仍存在争议；因此，在低信任场景下，分配完整 GPU 仍是保守选择。
从裸机到工作负载的工厂层次
该体系从原始硬件供应开始。系统会发现节点并检查 GPU 单元、ECC 内存状态以及网卡身份，然后安装包含 GPU 驱动、CUDA 和 NCCL 库的操作系统镜像。之后应用适当的 BIOS 设置，并对节点进行压力测试和 NCCL 测试，以确认 GPU 单元能够以完整带宽互连，随后将结果登记到 NetBox 等事实来源中。这个流程可以通过供应商专用硬件管理器构建，也可以使用 Metal3 搭配 Ironic 或 vMetal 等开源工具。
完成分配后，KAI Scheduler 和 Volcano 等工具负责批量调度和拓扑感知调度，而 Kueue 管理排队、准入和配额。在工作负载层，可以使用 vLLM 作为推理引擎，使用 KServe 提供标准端点和自动扩展，还可以在更大规模环境中使用 NVIDIA Dynamo 和 llm-d 实现解耦推理。Gateway API 提供路由功能，而 LiteLLM 则增加了一个兼容 OpenAI 接口的网关。
平台并不局限于容器。文章说明，训练环境可以通过 SchedMD 的 Slinky 使用 Slurm。Slinky 将 Slurm 服务表示为专用资源，并与 GPU Operator 和 DRA 集成。KubeVirt 还可以将虚拟机作为 Kubernetes 工作负载运行，使虚拟机和容器能够由同一集群统一管理，并使用统一的权限和配额。
隔离不只是命名空间
文章将隔离问题分为两个层面。在控制层面，tenant cluster 模式为每个团队提供一个虚拟 Kubernetes 接口，其中包含 API 服务器、专用资源、独立的准入规则和 RBAC，并将其作为工作负载运行在一个基础集群之上。vCluster 就是一个例子，用户可以使用 kubectl、Helm 和 Argo CD 等熟悉工具，而无需依赖专有扩展。
数据层面则需要隔离网络、存储、配额和运行时环境。可以使用 Cilium 作为 CNI 和策略组件，使用 Multus 和 SR-IOV 实现快速路径，并使用 InfiniBand 或 RoCEv2 在节点之间传输 GPU 流量。还可以通过 VXLAN 和 EVPN 使用独立 VPC，或在 InfiniBand 中使用分区密钥；NVIDIA BlueField 或 AMD Pensando 等 DPU 单元则可以将部分隔离和加密功能从主机处理器中卸载。文章强调，真正云化的标准是在需要时通过硬件强制实施隔离，而不是仅仅依赖 namespaces。
什么才能让集群成为云服务？
编辑解读：这一观点的实际价值在于，它将讨论从“哪个模型更快？”转向了如何运行基础设施本身。平台并不会仅仅因为汇集了 GPU 单元就成为云服务；只有当租户能够通过 API、Terraform 或 GitOps 创建和删除集群，资源以声明式形式定义并由 Flux 或 Argo CD 管理，同时配备 OIDC 身份和 RBAC 权限时，平台才真正具备云服务特征。
这类服务还需要清晰的计量和计费机制。文章建议使用 DCGM 数据计算 GPU 秒数，然后通过 OpenCost 将其分配给租户。监控和可靠性同样是产品的一部分，而不是运营附属功能：DCGM 负责监测性能退化，Node Problem Detector 将故障信号转换为节点状态，处理流程则隔离可疑节点并在调度新工作负载之前将其清空。安全层包括通过 OIDC 使用 Keycloak、使用 OpenBao 搭配 External Secrets Operator、使用 Kyverno 或 OPA 实施控制，以及使用 Falco 和 Trivy 保障运行时安全和供应链安全。
最困难的测试仍然是从演示环境过渡到大规模生产环境。在一块经过切分的 GPU 上运行两个团队和两个模型的示例，并不能单独证明该设计在数百个节点和多个数据中心中的可行性。文章提到 NVIDIA AI Cluster Runtime 等验证工具，以及随 Kubernetes 1.35 发布的 Kubernetes AI Conformance 计划，但对于故障爆炸半径、租户间隔离边界，以及选择 NVIDIA DSX OS 方案还是组装开源层，仍留下了运营层面的开放问题。
总之，“人工智能工厂”的成功取决于在考虑硬件拓扑的同时，将密度、隔离和计费结合起来：GPU 单元相对于 NVLink 或 NVSwitch 的位置、GPU 与 InfiniBand 或 RoCE 网络的连接方式，以及 NUMA 节点上的 GPU、NIC 和 CPU 位置。若不考虑这些信息就调度工作负载，即使平台在软件层面看似正常，集体通信操作也可能在最慢的链路处变慢。