AI Infra 到底是什么

最近招聘市场上 AI Infra 这个词出现得越来越多。点开 JD 一看，要求写着：熟悉 Kubernetes、有分布式系统经验、了解 GPU 调度……

这不就是后端那套东西吗？但又多了些没见过的名词：NCCL、vLLM、Gang Scheduling……

这个系列就是来讲清楚这些东西的。目标是看完之后，能看懂 AI Infra 相关的招聘要求，能上手干活，能去面试聊得起来。

这篇先从最基本的问题开始：AI Infra 到底是干什么的。

一句话解释

AI Infra 就是让 AI 模型能跑起来的那套基础设施。

跟传统的后端基础设施差不多，只不过核心资源从 CPU 变成了 GPU。

但这个"只不过"带来了一堆新问题：GPU 很贵、GPU 之间的通信很复杂、GPU 任务的调度逻辑和普通服务不一样……这些问题加在一起，就成了一个需要专门团队来搞的方向。

为什么突然火了

其实 AI Infra 一直都存在，只是以前规模小，没那么受关注。

以前训练一个模型，一张 GPU 跑几个小时，自己 SSH 到机器上启动脚本就完事了。

现在不一样了。训练一个 GPT-4 级别的大模型：

• 需要上万张 GPU 跑几个月
• 一张 H100 大概 3 万美元，一个千卡集群硬件成本就是 3000 万美元
• 几千张卡要协同工作，任何一张出问题都可能影响整个训练任务

到了这个规模，"怎么把这堆 GPU 管好"本身就变成了一个大问题。所以各大公司都在招人专门搞这个。

而会搞这个的人还不多——既要懂分布式系统，又要懂 GPU，这个交叉领域的人本来就少。供需一失衡，薪资就上去了。

具体做什么

AI Infra 团队日常做的事情，可以分成四块：训练平台、推理服务、资源调度、工具链。

训练平台

简单说就是给算法工程师用的任务管理系统。

他们提交一个任务，说"我要用 8 张 GPU 跑这个脚本"，平台负责排队、分配资源、启动任务，跑起来之后让他们能看日志、看监控，挂了能帮忙恢复。

你可能会想：直接 SSH 到机器上跑不就行了？

小规模确实可以。但想象一下这个场景：

• 公司有 100 张 GPU，20 个算法工程师都想用
• 谁先用谁后用？有人申请 8 张但只用了 2 张怎么办？
• 有人的任务跑了一周，机器突然挂了，之前的进度全没了
• 月底老板问"这个月 GPU 都被谁用了，花了多少钱"，没人答得上来

训练平台就是来解决这些问题的。

一个典型的任务配置长这样（Volcano 调度器的格式）：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: llama-finetune
spec:
  minAvailable: 8           # 8 个 Pod 必须同时启动
  schedulerName: volcano
  queue: research-team      # 放到 research-team 队列排队
  policies:
    - event: PodEvicted
      action: RestartJob    # 被驱逐就重启
  tasks:
    - replicas: 8
      name: trainer
      template:
        spec:
          containers:
          - name: pytorch
            image: pytorch/pytorch:2.1.0-cuda12.1-cudnn8-devel
            command: ["torchrun"]
            args:
              - "--nproc_per_node=1"
              - "--nnodes=8"
              - "--rdzv_backend=c10d"
              - "train.py"
            resources:
              limits:
                nvidia.com/gpu: 1

这里面有个关键配置 minAvailable: 8，意思是这 8 个 Pod 必须同时调度成功，不能只启动一部分。

为什么要这样？因为分布式训练时，8 个 Pod 要互相通信。如果只起了 6 个，它们会傻等另外 2 个，既不能开始干活，又占着 GPU。

这个特性叫 Gang Scheduling，Kubernetes 默认调度器没有，得用 Volcano 这样的批处理调度器。面试经常问这个。

推理服务

训练完的模型要部署成 API 让用户调用。你在 ChatGPT 网页上打字，后台就有个推理服务在用 GPU 跑模型生成回复。

推理和训练的差别挺大的：

推理服务有几个麻烦的地方：

延迟。大模型生成文字是一个字一个字蹦出来的，生成一段话可能要蹦几百个字。怎么让用户等待时间短一点？这里面有一堆优化技术：KV Cache、Continuous Batching、量化，后面会专门讲。

显存。一个 7B 参数的模型，光是把参数加载到显存就要 14GB（70亿 × 2字节）。再加上推理过程中的缓存，24GB 显存的 4090 可能都不够用。

扩容。流量有高峰低谷，怎么自动扩缩容？多个 GPU 实例之间怎么分配请求？

现在最流行的推理框架是 vLLM，部署大概长这样：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: llm-service
  template:
    metadata:
      labels:
        app: llm-service
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
        - "--model=/models/Qwen-7B"
        - "--served-model-name=qwen"
        - "--max-model-len=4096"
        - "--gpu-memory-utilization=0.85"    # 用 85% 显存，留点余量
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 1
        volumeMounts:
        - name: model-volume
          mountPath: /models
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 60    # 模型加载要时间，别太早开始检查
          periodSeconds: 10
      volumes:
      - name: model-volume
        persistentVolumeClaim:
          claimName: model-pvc

gpu-memory-utilization=0.85 这个参数的意思是让 vLLM 最多用 85% 的显存。为什么不用满？因为 CUDA 运行时还要占一点，留点余量，不然容易 OOM。

部署好之后调用就是标准的 OpenAI API 格式：

curl http://llm-service:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [{"role": "user", "content": "你好"}],
    "max_tokens": 100
  }'

资源调度

就是决定"哪个任务用哪个 GPU"。

听起来简单，实际上挺麻烦的。

第一个麻烦：GPU 只能整卡分配

Kubernetes 里 CPU 可以细分，"给这个 Pod 0.5 核"完全没问题。但 GPU 默认不行，申请 1 个 GPU 就独占一整张卡。

问题是很多任务用不满一张卡。可能只用了 10% 算力和 5GB 显存，剩下 90% 就浪费了。所以业界 GPU 利用率普遍只有 30-40%，挺惨的。

第二个麻烦：GPU 之间不是对等的

一台机器上 8 张 GPU，它们的连接方式不一样：

GPU 0 ←── NVLink ──→ GPU 1
  ↑                    ↑
  │                    │
PCIe                 PCIe
  │                    │
  ↓                    ↓
CPU 0                CPU 1

GPU 0 和 GPU 1 之间有 NVLink 直连，带宽能到 600GB/s。但 GPU 0 和 GPU 2 之间要绕过 CPU，带宽可能只有 32GB/s。

如果调度器不考虑这个，随便分配，分布式训练的性能可能差好几倍。

第三个麻烦：碎片化

集群跑一段时间后，可能每台机器都剩 1-2 张空闲 GPU，加起来有 20 张，但想申请 8 张连续的却分配不出来。

这就是碎片化。

所以生产环境一般不用 Kubernetes 默认调度器，会用 Volcano、Yunikorn 这些专门的调度器，或者干脆自研。大厂基本都是自研，因为有很多定制需求。

工具链

除了上面三块核心业务，还有一堆配套设施要维护。

镜像管理

AI 镜像动不动 10GB 以上（CUDA + PyTorch + 各种依赖），拉取很慢。一般会搞内部镜像仓库加速，或者提前把镜像拉到所有节点。

监控告警

GPU 相关的指标：利用率、显存、温度、功耗。任务相关的指标：训练 loss、吞吐量、推理延迟。

告警规则比如"GPU 利用率低于 30% 持续 30 分钟"或者"GPU 温度超过 85 度"，该报警的要报。

存储

训练数据几百 GB 到几 TB，要高吞吐的分布式存储。Checkpoint（模型状态快照）写入量大、频率高，需要高性能存储。模型文件几十 GB，要求读取速度快，不然冷启动时间太长。

技术栈分层

把涉及到的技术分个层：

┌────────────────────────────────────────────────────────┐
│                      应用层                             │
│        训练平台 / 推理网关 / 模型管理 / 监控             │
├────────────────────────────────────────────────────────┤
│                      框架层                             │
│  PyTorch / DeepSpeed / Megatron / vLLM / TensorRT-LLM  │
├────────────────────────────────────────────────────────┤
│                      调度层                             │
│         Kubernetes / Volcano / Ray / Slurm             │
├────────────────────────────────────────────────────────┤
│                     运行时层                            │
│    CUDA / cuDNN / NCCL / NVIDIA Container Toolkit      │
├────────────────────────────────────────────────────────┤
│                      硬件层                             │
│       GPU / NVLink / InfiniBand / RDMA / NVMe          │
└────────────────────────────────────────────────────────┘

日常工作主要在调度层和应用层，但框架层和运行时层的原理也得懂，不然出问题没法排查。

每一层的技术，后面的文章会慢慢展开。

和传统后端的区别

如果有后端经验，会发现很多概念是熟悉的。但细节上区别不小：

这个系列的前置知识

假设你：

• 会用 Linux 命令行
• 知道 Kubernetes 的基本概念（Pod、Deployment、Service）
• 能看懂 YAML

不需要会机器学习。涉及到的算法概念我会解释。

如果完全没接触过 Kubernetes，建议先学一下 K8s 基础。

下一篇

下一篇讲 GPU 基础，从 nvidia-smi 这个命令开始。

nvidia-smi 是看 GPU 状态的命令，相当于 GPU 的 top。会逐行解释它的输出，包括：

• 显存使用率和 GPU 利用率有什么区别
• Volatile GPU-Util 是什么意思
• 怎么看哪个进程在占用 GPU
• 常见问题怎么排查