在Kubernetes上运行AI/ML：从原型到生产

训练完机器学习模型后，推理阶段在生产环境中必须快速、可靠且成本高效。然而，大规模服务推理会带来难题：GPU/资源管理、延迟和批处理、模型/版本发布、可观测性以及辅助服务（预处理器、特征存储和向量数据库）的编排。在Kubernetes上运行人工智能和机器学习（AI/ML）为我们提供了一个可扩展、可移植的平台，用于训练和服务模型。

Kubernetes调度GPU和其他资源，使我们能够高效打包工作负载，并根据批处理作业和实时推理的流量自动扩缩容。它还能协调多组件堆栈（如模型服务器、预处理器、向量数据库和特征存储），使复杂流水线和低延迟端点可靠运行。

容器化确保了可重现的环境，并使模型的CI/CD变得实用。内置功能如滚动更新、流量拆分和指标/追踪帮助我们安全地进行生产发布，并满足实时端点的SLO。对于希望减少运维工作的团队，存在托管端点，但当控制、可移植性、高级编排和实时服务很重要时，Kubernetes是首选方案。

让我们看看下面使用Kubernetes上的KServer的典型ML推理设置：

图1. 使用KServe在Kubernetes上的ML推理设置

客户端（例如数据科学家、应用程序、批处理作业）通过入口将请求发送到KServe InferenceService。内部，可选的Transformer预处理输入，必需的Predictor加载模型并提供预测，可选的explainer返回洞察。模型工件从模型存储中拉取（如图中所示），并通过所选运行时（例如TensorFlow、PyTorch、scikit-learn、ONNX、Triton）提供服务。所有内容都在Knative/Kubernetes上运行，具有自动扩缩容和路由功能，使用来自AWS、Azure、Google Cloud或本地的NVIDIA/AMD/Intel等提供商的CPU/GPU计算层。

第一部分：MLFlow和KServe与Kubernetes

让我们深入探讨一个AI/ML场景的实际实现。我们将结合使用MLFlow来编排ML流程，scikit-learn来训练ML模型，以及KServe在Kubernetes集群中推理我们的模型。

MLFlow简介

MLflow是一个开源的ML框架，我们使用它来为模型从实验到生产过程中发生的混乱带来秩序。它帮助我们跟踪运行（参数、指标和文件），保存产生结果的确切环境和代码，并管理模型版本，以便我们知道哪个模型已准备好投入生产。

简单来说，MLflow解决了三个常见问题：

• 丢失实验数据
• 缺少重现结果所需的环境或代码
• 混淆哪个模型是“生产”模型；其主要部分——跟踪、项目、模型和模型注册表——直接对应这些需求

我们还可以使用MLflow来打包和服务模型（本地作为Docker镜像或通过注册表），这使得将模型移交给像Kubernetes这样的服务平台变得容易。

在Kubernetes上使用MLFlow和KServe

MLflow提供了一种通过基于FastAPI的推理服务器服务模型的直接方式，mlflow models build-docker允许您将该服务器容器化以进行Kubernetes部署。然而，这种方法可能不适合大规模生产；FastAPI是轻量级的，并非为极端并发或复杂的自动扩缩模式而构建，手动管理大量推理副本会产生显著的运营开销。

KServe（以前称为KFServing）提供了一个生产级、Kubernetes原生的推理平台，具有高性能、可扩展和框架无关的服务抽象，适用于流行的ML库，如TensorFlow、XGBoost、scikit-learn和PyTorch。

我们创建了一个简短的逐步指南，介绍如何使用MLflow和scikit-learn训练ML模型，以及如何使用KServe部署到Kubernetes。本指南引导您完成一个完整的MLflow工作流程，以训练一个带有MLflow跟踪的线性回归模型，并执行超参数调优以确定最佳模型：

先决条件 – 安装Docker、kubectl和本地集群（Kind或Minikube）或使用云Kubernetes集群。参见Kind/Minikube快速入门。

安装MLflow + MLServer支持 – 安装带有MLServer附加功能的MLflow（pip install mlflow[mlserver]）并查看MLServer的MLflow示例。

训练和记录模型 – 使用mlflow.log_model()（或mlflow.sklearn.autolog()）训练和保存模型，遵循MLflow教程。

本地冒烟测试 – 使用MLflow/MLServer服务以在Kubernetes之前验证调用：mlflow models serve -m models:/<name> -p 1234 --enable-mlserver。参见MLflow模型/MLServer示例。

打包或发布

• 选项A – 构建Docker镜像：mlflow models build-docker -m runs:/<run_id>/model -n <your/image> --enable-mlserver → 推送到注册表。
• 选项B – 将工件推送到远程存储（S3/GCS）并在KServe中使用storageUri。可以在此处找到文档和示例。

部署到KServe – 创建一个命名空间并应用一个指向您的镜像或storageUri的InferenceService。参见KServe的InferenceService快速入门和仓库示例。下面是一个示例（Docker镜像方法+Kubernetes）InferenceService片段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: "serving.kserve.io/v1beta1"
kind: InferenceService
metadata:
  name: mlflow-wine-classifier
  namespace: mlflow-kserve-test
spec:
  predictor:
    containers:
      - name: mlflow-wine-classifier
        image: "<your_docker_user>/mlflow-wine-classifier"
        ports:
          - containerPort: 8080
            protocol: TCP
        env:
          - name: PROTOCOL
            value: "v2"

验证和生产化 – 检查Pods（kubectl get pods -n <ns>），调用端点，然后根据需要添加自动扩缩容、指标、金丝雀发布和可解释性（KServe支持这些功能）。

官方MLflow文档还有一个很好的逐步指南，涵盖了如何将模型工件和依赖环境打包为MLflow模型，使用mlserver通过mlflow models serve验证本地服务，以及将打包的模型部署到带有KServe的Kubernetes集群。

第二部分：托管AutoML：从Azure ML到AKS

对于此示例，我们选择了Azure。然而，Azure只是许多可以在此场景中工作的工具提供商之一。Azure Machine Learning是一个用于完整ML生命周期的托管平台——实验跟踪、模型注册、训练、部署和MLOps——帮助团队快速将模型投入生产。定义可靠的ML流程可能很困难，而自动化ML（AutoML）可以通过自动化算法选择、特征工程和超参数调优来简化这项工作。对于低延迟、大规模实时推理，您可以在Kubernetes上运行容器，这是生产工作负载的事实上的编排层。

当我们需要自定义运行时、严格的性能调优（GPU集群、自定义驱动程序）、与现有Kubernetes基础设施（服务网格、VNET）集成或高级自动扩缩规则时，我们选择Azure Kubernetes Service（AKS）。如果我们更喜欢托管、低运维路径且不需要深度集群控制，Azure ML的托管在线端点通常更容易采用。

我们在Azure ML中运行AutoML以找到最佳模型，注册它，并将其发布为AKS上的低延迟实时端点，以便我们保持对运行时、扩缩容和网络的完全控制：

先决条件 – 获取Azure订阅、Azure ML工作区、Azure CLI/ML CLI或SDK，以及AKS集群（创建一个或附加现有集群）。

运行AutoML并选择获胜者 – 从Azure ML工作室或SDK提交AutoML作业（分类/回归/预测），并在模型注册表中注册顶级模型。

准备评分+环境 – 添加一个最小的score.py（加载模型，处理请求）和一个环境规范（Conda/requirements）；您可以重用azureml-examples仓库中的示例。

附加AKS并部署 – 将您的AKS计算附加到工作区（或创建AKS），然后使用Azure ML CLI或Python SDK将注册的模型部署为在线/实时端点。

测试和监控 – 调用端点，添加日志记录/指标和自动扩缩规则，并使用滚动/金丝雀交换进行安全更新。

作为AutoML如何工作的示例，我将在下面提供一个典型的AI/ML流水线：

图2. 示例AI/ML流水线

此ML流水线包含从数据集中选择、清理和转换数据的步骤；拆分数据用于训练、选择ML算法和测试模型；最后，评分和评估模型。所有这些步骤都可以通过AutoML自动化，包括几种将模型部署到AKS/Kubernetes实时API端点的选项。

第三部分：在Kubernetes上服务LLMs

让我们看看LLMs和Kubernetes的结合。我们在Kubernetes上运行LLMs以获得可靠、可扩展和可重现的推理：Kubernetes为我们提供了GPU调度、自动扩缩容和编排原语，以管理大型模型、批处理和多实例服务。通过结合优化的运行时、请求批处理和可观测性（指标、日志记录和健康检查），我们可以在控制成本和运营风险的同时提供低延迟API。为此，我们可以使用开源框架vLLM，当我们需要高吞吐量、内存高效的LLM推理时使用它。

在Kubernetes上，我们在容器内运行vLLM，并将其与服务控制平面（如KServe）结合，以便我们获得自动扩缩容、路由、金丝雀发布和标准InferenceService CRD，而无需重新实现运维逻辑。这种结合为我们提供了vLLM的低级性能和Kubernetes原生推理平台的操作特性。

让我们看看如何使用vLLM和KServe将LLM部署到Kubernetes：

准备集群和KServe – 配置Kubernetes集群（AKS/GKE/EKS或本地）并安装KServe，遵循快速入门。

获取vLLM – 克隆vLLM仓库或按照文档安装vLLM，并测试vllm serve本地以确认模型加载和API工作。

创建vLLM ServingRuntime/容器 – 构建容器镜像或使用KServe支持的vLLM ServingRuntime配置（运行时使用正确的参数和环境变量包装vllm serve）。

部署InferenceService – 应用一个引用vLLM服务运行时（或您的镜像）和模型存储（S3/HF缓存）的KServe InferenceService。KServe将创建pods，处理路由并暴露端点。

验证和调优 – 访问端点（通过入口/端口转发），测量延迟/吞吐量，并调优vLLM批处理/令牌缓存设置和KServe自动扩缩容以平衡延迟和GPU利用率。

最后，我们可以一起运行vLLM、KServe和BentoML，以获得高性能LLM推理和生产级运维。以下是一个简要分解：

• vLLM – 高吞吐量、GPU高效的推理引擎（令牌生成、KV缓存和批处理）——实际执行LLM的运行时
• BentoML – 开发人员打包层，包装模型加载、自定义预处理/后处理和稳定的REST/gRPC API，然后构建可重现的Docker镜像或工件
• KServe – Kubernetes控制平面，部署容器（Bento镜像或vLLM服务镜像）并处理自动扩缩容、路由/入口、金丝雀、健康检查和生命周期管理

它们如何组合？我们使用BentoML打包我们的模型和请求逻辑（镜像或Bento包），该逻辑运行vLLM服务器进行推理。KServe随后在Kubernetes上将该容器作为InferenceService（或ServingRuntime）运行，提供自动扩缩容、流量控制和可观测性。

ML的Kubernetes推理框架的优缺点

我们已经看过了KServe库。然而，还有其他强大的替代方案。让我们看看下面的表格：

表1. KServe替代工具和库

结论

我们的目标是在生产中运行可靠、低延迟的AI/ML，同时控制成本、性能和可重复性。Kubernetes为我们提供了所需的编排原语——GPU调度、自动扩缩容、流量控制和多服务协调——以便模型及其支持服务可以可预测地大规模运行。结合优化的运行时、服务层和推理引擎，我们既获得了高推理性能，又获得了生产级操作控制。结果是具有内置可观测性、安全发布模式和更好资源效率的可移植、可重现部署。

从小处着手，使用单一模型和清晰的SLO进行验证，选择符合您性能和运维需求的服务堆栈，然后迭代。Kubernetes让您从原型发展到有弹性、可扩展的服务。