在 Kubernetes 上跑大模型：GPU 调度与资源管理入门

为什么 LLM 让集群管理变了味

把大模型服务搬上 Kubernetes（下称 K8s，主流的容器编排系统）之前，先想清楚它和普通微服务的三个差别。第一，GPU 是贵重稀缺资源：一张数据中心级显卡的价格大致抵得上一整台普通服务器，集群里每一块卡都该有明确归属。第二，模型 Pod 又大又慢：推理镜像动辄几 GB，启动时还要把几十 GB 的权重从存储加载进显存，冷启动以分钟计，与「秒级扩容」的直觉相去甚远。第三，显存必须整卡规划：GPU 按张分配，模型装不下就是装不下，没有按字节细切的余地。

这三个特性决定了 K8s 管理普通应用的那套弹性叙事，套在 LLM 上会处处打折。下面按资源声明、调度、服务配置、治理四步过一遍。

GPU 资源声明

K8s 里 CPU 和内存是原生资源，GPU 以 extended resources（扩展资源）接入，标准资源名是 nvidia.com/gpu。它背后由 device plugin（设备插件）机制支撑：节点上的插件向 kubelet 上报本机 GPU 数量，调度器据此记账。最小声明如下：

apiVersion: v1
kind: Pod
metadata:
  name: llm-serve
spec:
  containers:
    - name: engine
      image: registry.example.com/llm-engine:v1
      resources:
        limits:
          nvidia.com/gpu: "1"
          cpu: "16"
          memory: 64Gi

两点注意：GPU 数量只能写在 limits 里，requests 会自动等于 limits；申请是整数张，没有「半张卡」。device plugin 本身通常以 DaemonSet 形式部署在 GPU 节点上，属于集群的「基础设施」，装好后用 kubectl describe node 能看到节点的 GPU 可分配量——排查「Pod 一直 Pending」时先看这里，是最常见的起点。

调度要点：选对节点，守住节点

按 GPU 型号选节点。 不同代际的卡显存与算力差异巨大，模型往往绑定某类卡才有预期效果。给 GPU 节点打上型号标签，用 nodeSelector 约束落点：

nodeSelector:
  nvidia.com/gpu.product: A100-SXM4-80GB

用污点隔离 GPU 节点。 给 GPU 节点打污点（taint），只有声明了容忍（toleration）的 Pod 才能落上去，防止无 GPU 需求的普通任务「蹭」进贵重节点。GPU 节点只跑 GPU 任务，这条纪律能省掉大量扯皮。

正视碎片问题。 整卡分配是刚性的：节点上剩两张 80G 的卡，而模型需要 160G 的跨卡算力，这两张卡就用不上。缓解思路有三：大模型与小模型分池部署；用支持多卡并行的引擎跨卡组装；按显存规格规划节点池，让「剩卡」尽量成对出现。硬件层面，部分数据中心卡支持把一张物理卡切分成多个小实例（如 MIG 技术），给小模型拼卡提供了官方方案，但切分后单实例显存与带宽相应缩水，仍要按整卡思维做规划。

模型服务的特殊配置

就绪探针要宽。 模型加载权重可能要几分钟，readiness 探针的初始延迟与失败阈值都要放宽，否则 Pod 会在启动阶段被反复重启；加载完成前不要接流量。

HPA 的尴尬。 水平扩容器（HPA）看指标涨了才扩容，但 GPU Pod 扩容慢、成本高，等指标报警再加卡往往已经晚了。常见替代是用 KEDA 这类事件驱动扩缩组件按队列长度提前扩容——请求开始排队，就是该加副本的信号。

优雅停机。 直接杀 Pod 会掐断正在生成的回答。把 terminationGracePeriodSeconds 配得足够长，让进程先停止接新请求、把手头生成完再退出。

权重加载别走弯路。 冷启动慢的大头是权重搬运：从对象存储拉几十 GB，网络抖一下就是失败重试。常见做法是把权重做成独立的数据卷（PVC）挂载、或用本地缓存盘预热热点模型，让镜像保持小、权重与镜像解耦——发布推理代码不必重拉权重，加载速度也稳定可控。

多模型共存的取舍

一卡一模型简单可靠，但利用率常常惨淡；按显存切分，一张大卡部署多个小模型能显著提高利用率，代价是隔离性变差、互相干扰要自己兜底。推理引擎也在给出折中：vLLM 等引擎支持共享同一基座加载多个 LoRA 变体，一份权重服务多个微调版本，资源收益更精细——本站 vLLM 一文有展开。选哪种，看模型大小分布与流量形态：大流量大模型独占，长尾小模型拼卡。

治理清单

namespace 配额：用 ResourceQuota 把 GPU 用量写进各团队配额，超了排队，而不是悄悄侵占。
优先级与抢占：在线推理给高优先级，离线批处理给低优先级，资源紧张时抢占机制让低优任务给推理服务让路。
可观测性：GPU 利用率与显存占用是核心指标，部署 DCGM 导出器接入常规监控；只看 CPU 的监控在 GPU 集群里等于盲飞。
节点池分层：按卡型与用途拆节点池（在线推理、离线批处理、开发调试），配合污点与优先级，让调度策略有清晰的物理边界。

小结

K8s 管 LLM 的核心矛盾，是弹性调度的理想与 GPU 刚性现实的落差：调度器可以自由排布 Pod，但显存整卡、启动缓慢、成本高昂把自由度压得很小。务实的姿势是承认刚性——整卡规划、分池部署、按队列扩容，把真正的弹性留给小模型和长尾流量。