配置推理服务自动扩缩容

简介

本文档提供了逐步指南,用于为以 Knative 部署模式运行的推理服务配置自动向上和向下扩缩容。通过这些设置,您可以优化资源使用、确保服务在高负载期间的可用性,并在低负载期间释放资源。

WARNING

本页上的每一项设置都适用于以 Knative 部署模式运行的推理服务。Alauda AI 默认以 Standard 模式部署推理服务, 该模式不使用 Knative——在该模式下,下面的 config-autoscaler ConfigMap 和 autoscaling.knative.dev/* 注解都不会生效,并且 minReplicas: 0 也不会 将服务缩容到零。

如需在 Standard 模式下对服务进行自动扩缩容,请参阅 使用 KEDA 为推理服务设置自动扩缩容

关于 Autoscaler

Knative Serving 支持两种 autoscaler:Knative Pod Autoscaler (KPA) 和 Kubernetes 的 Horizontal Pod Autoscaler (HPA)。以 Knative 模式部署的服务默认使用 Knative Pod Autoscaler (KPA)。

KPA 面向无服务器工作负载,可以根据并发请求数或 RPS(每秒请求数)快速扩容,并且可以将服务缩容到零个从节点以节省成本。HPA 更通用,通常基于 CPU 或内存使用率等指标进行扩缩容。本指南主要介绍如何通过 Knative Pod Autoscaler (KPA) 配置服务。

前提条件

  1. 已安装 Knative Operator,且存在一个 KnativeServing 实例。请参阅 安装 Alauda AI

  2. 目标 InferenceService 已以 Knative 模式部署。请确认服务上的注解:

    kubectl get inferenceservice <name> -n <your-namespace> \
      -o jsonpath='{.metadata.annotations.serving\.kserve\.io/deploymentMode}{"\n"}'

    该命令必须输出 Knative。如果输出 Standard 或无输出,请改用 KEDA 指南。

  3. 您有权限编辑 knative-serving 命名空间中的 config-autoscaler ConfigMap,以进行平台级设置。

步骤

下行扩缩容配置

本节介绍如何配置推理服务在没有流量时自动缩容到零个从节点,或保持最少数量的从节点。

启用/禁用缩容到零

您可以配置是否允许推理服务在没有流量时缩容到零个从节点。默认值为 true,即允许缩容到零。

使用 InferenceService 资源参数

InferenceServicespec.predictor 字段中,设置 minReplicas 参数。

  • minReplicas: 0:允许缩容到零个从节点。

  • minReplicas: 1:禁止缩容到零个从节点,至少保留一个从节点。

    apiVersion: serving.kserve.io/v1beta1
    kind: InferenceService
    metadata:
      name: demo
      namespace: demo-space
    spec:
      predictor:
        minReplicas: 0
        ...

全局禁用缩容到零

WARNING

一旦禁用了平台级功能,所有服务中的 minReplicas: 0 配置都将被忽略。

您可以修改全局 ConfigMap 来禁用平台的缩容到零功能。此配置具有最高优先级,会覆盖所有单独 InferenceService 资源中的设置。

knative-serving 命名空间中的 config-autoscaler ConfigMap 里,将 enable-scale-to-zero 的值修改为 "false"

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    "helm.sh/resource-policy": keep
  name: config-autoscaler
  namespace: knative-serving
data:
  enable-scale-to-zero: "false"
  1. 请确保该注解存在,否则您的配置将恢复为默认值。

配置缩容到零后的 Pod 保留时间

此设置决定了 autoscaler 判定缩容到零后,最后一个 Pod 保持活跃的最短时间。这有助于服务在再次接收流量时快速响应。默认值为 0s

您可以选择为单个服务配置此项,或修改全局 ConfigMap 使该设置对所有服务生效。

方法 1:使用 InferenceService 注解

InferenceServicespec.predictor.annotations 中,添加 autoscaling.knative.dev/scale-to-zero-pod-retention-period 注解。

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: qwen2
  namespace: fy-1
spec:
  predictor:
    annotations:
      autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    ...

方法 2:使用全局 ConfigMap

knative-serving 命名空间中的 config-autoscaler ConfigMap 里,将 scale-to-zero-pod-retention-period 的值修改为非负的时长字符串,例如 "1m5s"

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    "helm.sh/resource-policy": keep
  name: config-autoscaler
  namespace: knative-serving
data:
  scale-to-zero-pod-retention-period: "1m5s"
  1. 请确保该注解存在,否则您的配置将恢复为默认值。

配置缩容到零的宽限期

此设置会在流量停止后延迟移除最后一个从节点,确保 activator/routing 路径已准备就绪,并防止在过渡到零的过程中丢失请求。

TIP

只有在因服务缩容到零而遇到请求丢失时,才应调整此值。它不会影响在没有流量后的最后一个从节点保留时间,也不能保证在此期间该从节点一定会被保留。

方法:使用全局 ConfigMap

knative-serving 命名空间中的 config-autoscaler ConfigMap 里,将 scale-to-zero-grace-period 的值修改为一个时长字符串,例如 "40s"

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    "helm.sh/resource-policy": keep
  name: config-autoscaler
  namespace: knative-serving
data:
  scale-to-zero-grace-period: "40s"
  1. 请确保该注解存在,否则您的配置将恢复为默认值。

上行扩缩容配置

本节介绍如何配置推理服务,以便在流量增加时自动扩容。

配置并发阈值

并发决定了每个应用副本可以同时处理的请求数。您可以使用软限制或硬限制来设置并发。

  • 软限制:目标限制,在流量激增期间可以暂时超过,但会触发自动扩缩容以维持目标值。默认值为 100
  • 硬限制:严格的上限。当并发达到该值时,超出部分的请求将被缓冲并排队处理。默认值为 0,表示无限制。
WARNING

如果同时指定了软限制和硬限制,将使用两者中较小的值。这可以防止 Autoscaler 的目标值高于硬限制所允许的值。

您可以选择为单个服务配置此项,或修改全局 ConfigMap 使该设置对所有服务生效。

方法 1:使用 InferenceService 资源参数

  • 软限制:在 spec.predictor 中设置 scaleTarget,并将 scaleMetric 设为 concurrency

  • 硬限制:在 spec.predictor 中设置 containerConcurrency

    # Set soft and hard limits
    apiVersion: serving.kserve.io/v1beta1
    kind: InferenceService
    metadata:
      name: demo
      namespace: demo-space
    spec:
      predictor:
        scaleTarget: 200
        scaleMetric: concurrency
        containerConcurrency: 50
        ...

方法 2:使用全局 ConfigMap

  • 软限制:在 config-autoscaler ConfigMap 中设置 container-concurrency-target-default
  • 硬限制:没有全局设置可用于硬限制,因为它会影响请求缓冲和排队。

目标利用率百分比

此值指定在 metric=concurrency 时 autoscaler 期望达到的目标百分比,从而允许在达到硬限制之前提前扩容。默认值:70 使用 RPS 时不适用。

方法 1:使用 InferenceService 注解

InferenceServicespec.predictor.annotations 中,添加 autoscaling.knative.dev/target-utilization-percentage 注解。

# Set target utilization by service
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: qwen2
  namespace: fy-1
spec:
  predictor:
    annotations:
      autoscaling.knative.dev/target-utilization-percentage: "80"

方法 2:使用全局 ConfigMap

config-autoscaler ConfigMap 中,设置 container-concurrency-target-percentage

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    "helm.sh/resource-policy": keep
  name: config-autoscaler
  namespace: knative-serving
data:
  container-concurrency-target-percentage: "80"
  1. 请确保该注解存在,否则您的配置将恢复为默认值。

配置每秒请求数(RPS)目标

您可以将扩缩容指标从并发改为每秒请求数(RPS)。默认值为 200 注意:在 RPS 模式下,不会使用并发目标百分比设置。

方法 1:使用 InferenceService 资源参数

spec.predictor 中,设置 scaleTarget 并将 scaleMetric 设为 rps

# Set RPS target by service
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: qwen2
  namespace: fy-1
spec:
  predictor:
    scaleTarget: 150
    scaleMetric: rps
    ...

方法 2:使用全局 ConfigMap

config-autoscaler ConfigMap 中,设置 requests-per-second-target-default

apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    "helm.sh/resource-policy": keep
  name: config-autoscaler
  namespace: knative-serving
data:
  requests-per-second-target-default: "200"
  1. 请确保该注解存在,否则您的配置将恢复为默认值。