Kubernetes 规模化部署 AI 模型：完整 MLOps 指南（2026）

Kubernetes 已成为大规模服务 ML 和 LLM 模型的标准基础，因为其核心能力——自动扩缩、滚动/金丝雀更新、GPU 调度、多副本可靠性——正是生产环境所需。本指南涵盖服务框架及关键生产问题。

模型服务框架

KServe（原 KFServing）：Kubernetes 原生服务，支持自动扩缩（包括缩零）、金丝雀发布和标准推理协议；支持多种运行时（PyTorch、TF、sklearn、自定义容器及 LLM 运行时）。

Seldon Core：灵活的服务框架，支持推理图（模型链、转换器、解释器）——适用于多步骤流水线场景。

vLLM / TGI on K8s：针对 LLM，将高吞吐引擎（参见 LLM 推理优化）作为 Deployment 部署在 Service 后，按 GPU 扩缩。

生产关注点

GPU 调度：显式请求 GPU（nvidia.com/gpu: 1），使用节点选择器/污点将模型 Pod 绑定到 GPU 节点，考虑 MIG/时间切片以在大型 GPU 上共享小型模型。

自动扩缩：CPU/内存 HPA 不适合推理——应基于 GPU 利用率、队列深度或请求延迟（通过 KEDA 或自定义指标）进行扩缩。

金丝雀部署：将新模型版本发布到小部分流量，监控质量/延迟，然后逐步放量——与 AI 金丝雀分析 思路相同。

冷启动：大型模型加载缓慢；预拉取镜像、保持热副本，或仅在启动延迟可接受时使用缩零。

多区域：为全球延迟和容灾，跨区域复制——参见 多区域 AI 部署。

yaml
最小 KServe InferenceService 示例
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata: { name: my-llm }
spec:
  predictor:
    containers:
      - image: vllm/vllm-openai:latest
        args: ["--model", "meta-llama/Llama-3.1-8B-Instruct"]
        resources: { limits: { nvidia.com/gpu: "1" } }

别忘了可观测性

跟踪延迟百分位、GPU 利用率、tokens/秒以及错误/回退率。将服务与评估和追踪结合——参见 LangSmith 评估——以便及时发现“成功”部署但质量悄然下降的问题。

FAQ

KServe 还是 Seldon？ KServe 适用于标准自动扩缩服务；Seldon 适用于需要推理图/流水线的场景。 如何自动扩缩 GPU 工作负载？ 基于 GPU 利用率/队列深度/延迟（通过 KEDA 或自定义指标），而非 CPU。 如何安全更新？ 金丝雀：小部分流量，监控指标，然后逐步放量。 Pod 能否缩到零？ 可以（KServe），但需注意大型模型的冷启动延迟。

总结

Kubernetes 为 ML 服务提供了生产所需的自动扩缩、发布和 GPU 调度能力。使用 KServe（或针对 LLM 的 vLLM-on-K8s），基于推理相关指标扩缩，通过金丝雀发布，规划冷启动和多区域，并接入可观测性以快速发现质量退化。

---

*最后更新：2026 年 6 月。请以 KServe/Seldon 和 Kubernetes 官方文档为准。*