AI服务器算力云原生配置：用容器和调度器管好多卡资源

AI服务器做云原生配置，目标不是把驱动装完就结束，而是让容器能安全、可控地使用GPU算力。
判断标准很简单：容器里能执行 nvidia-smi 看到显卡，调度器能把GPU当作资源分配，单个任务不能随意占满整卡。
下面按这个顺序展开。

先确认驱动和容器运行时是否就绪

在物理机或云主机上，先检查NVIDIA驱动是否正常。
执行：

nvidia-smi

能看到显卡型号、驱动版本和显存占用，说明驱动层没问题。
如果命令不存在或报错，先装驱动，不要继续往下配。
接着确认Docker是否已安装：

docker info | grep -i runtime

默认输出里通常只有 runc。
要让容器访问GPU，还需要安装 nvidia-container-toolkit，并把 nvidia 注册为Docker运行时。
以常见Debian/Ubuntu环境为例，配置运行时后重启Docker：

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

重启后再次执行 docker info，应能看到 nvidia 运行时。
这一步是后续Kubernetes设备插件工作的基础，跳过它，Pod里大概率看不到GPU。

让Kubernetes识别GPU资源

如果使用Kubernetes管理算力，需要部署NVIDIA设备插件。
设备插件的作用是把节点上的GPU数量上报给调度器，让Pod可以通过资源声明申请显卡。
常见方式是使用Helm安装：

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install nvidia-device-plugin nvidia/nvidia-device-plugin \
  --namespace kube-system

安装后检查节点资源：

kubectl describe node <节点名> | grep -i nvidia

如果输出中出现 nvidia.com/gpu: 1 或对应卡数，说明调度器已经能识别GPU。
如果数量为0，优先检查节点上 nvidia-smi 是否正常、设备插件Pod日志是否有报错，以及容器运行时是否配置正确。

用资源声明限制单任务算力

云原生配置算力的关键动作，是在Pod或Deployment里声明GPU资源。
下面是一个最小示例，申请1张GPU：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-test
spec:
  containers:
  - name: cuda
    image: nvidia/cuda:12.2.0-base-ubuntu22.04
    command: ["nvidia-smi"]
    resources:
      limits:
        nvidia.com/gpu: 1

应用后查看日志：

kubectl apply -f gpu-test.yaml
kubectl logs gpu-test

日志中应输出显卡信息。
注意 nvidia.com/gpu 目前通常按整卡分配，不能直接写 0.5 来切半张卡。
如果业务需要更细粒度共享，要结合MIG或时间片方案单独评估，不能只靠资源声明解决。

避坑：别让容器“看见卡”却“用不上卡”

常见问题有三个。
第一，只在Docker里配了运行时，没有部署Kubernetes设备插件，Pod申请GPU会一直Pending。
第二，资源声明写在 requests 里但没写 limits，部分调度器行为不一致，建议显式写 limits。
第三，节点驱动版本与容器镜像内CUDA版本不匹配，容器能启动但计算报错，部署前先核对驱动支持的最高CUDA版本。

另外，多任务场景下不要默认所有Pod都申请整卡。
训练任务和推理任务对显存、算力持续占用差异很大，建议按业务拆分节点池或命名空间，再配合资源配额限制总量，避免一个团队占满集群GPU。

验证配置是否真正生效

完成上述步骤后，按三层验证：节点层执行 nvidia-smi 确认显卡健康；
调度层执行 kubectl describe node 确认GPU资源可分配；
任务层运行一个申请GPU的Pod并查看日志。
三层都通过，才算云原生算力配置完成。
后续如果出现任务排队或显卡闲置并存，优先检查资源声明是否过大、节点标签是否匹配，以及设备插件Pod是否持续运行。