Alauda AI
  • Русский

    • Configure Scaling for Inference Services

    Содержание

    IntroductionSteps

    Introduction

    В этом документе представлен пошаговый гид по настройке автоматического масштабирования вверх и вниз для сервисов вывода. С помощью этих настроек вы сможете оптимизировать использование ресурсов, обеспечить доступность сервиса при высокой нагрузке и освободить ресурсы при низкой нагрузке.

    О Автомасштабировщике

    Knative Serving поддерживает два автомасштабировщика: Knative Pod Autoscaler (KPA) и Kubernetes' Horizontal Pod Autoscaler (HPA). По умолчанию наши сервисы используют Knative Pod Autoscaler (KPA).

    KPA разработан для serverless-нагрузок и может быстро масштабироваться вверх на основе количества одновременных запросов или RPS (запросов в секунду), а также может масштабировать сервисы до нуля реплик для экономии затрат. HPA более универсален и обычно масштабируется на основе метрик, таких как использование CPU или памяти. В этом руководстве основное внимание уделяется настройке сервисов через Knative Pod Autoscaler (KPA).

    Steps

    Конфигурация автоматического масштабирования вниз

    В этом разделе описывается, как настроить сервисы вывода для автоматического масштабирования вниз до нуля реплик при отсутствии трафика или для поддержания минимального количества реплик.

    Включение/отключение масштабирования до нуля

    Вы можете настроить, разрешать ли сервису вывода масштабироваться до нуля реплик при отсутствии трафика. По умолчанию это значение true, что позволяет масштабироваться до нуля.

    Использование параметров ресурса InferenceService

    В поле spec.predictor объекта InferenceService установите параметр 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.

    В ConfigMap config-autoscaler в пространстве имён knative-serving измените значение 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 после масштабирования до нуля

    Эта настройка определяет минимальное время, в течение которого последний Pod остаётся активным после того, как автомасштабировщик решил масштабироваться до нуля. Это помогает сервису быстро реагировать при возобновлении трафика. Значение по умолчанию — 0s

    Вы можете настроить это для отдельного сервиса или изменить глобальный ConfigMap, чтобы сделать настройку эффективной для всех сервисов.

    Метод 1: Использование аннотаций InferenceService

    В spec.predictor.annotations объекта InferenceService добавьте аннотацию 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

    В ConfigMap config-autoscaler в пространстве имён knative-serving измените значение 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/маршрутизатора и предотвращая потерю запросов во время перехода к нулю.

    TIP

    Это значение следует изменять только в случае потери запросов из-за масштабирования сервисов до нуля. Оно не влияет на время удержания последней реплики после отсутствия трафика и не гарантирует сохранение реплики в этот период.

    Метод: Использование глобального ConfigMap

    В ConfigMap config-autoscaler в пространстве имён knative-serving измените значение 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. Пожалуйста, убедитесь, что эта аннотация существует, иначе ваша конфигурация будет сброшена к значению по умолчанию.

    Конфигурация автоматического масштабирования вверх

    В этом разделе описывается, как настроить сервис вывода для автоматического масштабирования вверх в ответ на увеличение трафика.

    Настройка порогов одновременных запросов (concurrency)

    Одновременность определяет количество запросов, которые каждая реплика приложения может обрабатывать одновременно. Вы можете задать одновременность с мягким или жёстким лимитом.

    • Мягкий лимит: Целевое значение, которое может временно превышаться при всплеске трафика, но при этом запускается автомасштабирование для поддержания целевого значения. Значение по умолчанию — 100.
    • Жёсткий лимит: Строгий верхний предел. При достижении этого значения одновременности избыточные запросы будут буферизоваться и ставиться в очередь на обработку. Значение по умолчанию — 0, что означает отсутствие ограничения.
    WARNING

    Если указаны оба лимита — мягкий и жёсткий, будет использоваться меньшее из двух значений. Это предотвращает установку автомасштабировщиком целевого значения, не допускаемого жёстким лимитом.

    Вы можете настроить это для отдельного сервиса или изменить глобальный ConfigMap, чтобы сделать настройку эффективной для всех сервисов.

    Метод 1: Использование параметров ресурса InferenceService

    • Мягкий лимит: В spec.predictor установите scaleTarget и scaleMetric в concurrency.

    • Жёсткий лимит: В spec.predictor установите containerConcurrency.

      # Установка мягкого и жёсткого лимитов
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: demo
  namespace: demo-space
spec:
  predictor:
    scaleTarget: 200
    scaleMetric: concurrency
    containerConcurrency: 50
    ...

    Метод 2: Использование глобального ConfigMap

    • Мягкий лимит: В ConfigMap config-autoscaler установите container-concurrency-target-default.
    • Жёсткий лимит: Глобальной настройки для жёсткого лимита нет, так как он влияет на буферизацию и очередь запросов.

    Целевой процент использования

    Это значение указывает целевой процент, к которому стремится автомасштабировщик при метрике concurrency, позволяя проактивно масштабироваться до достижения жёсткого лимита. По умолчанию: 70. Не применяется при использовании RPS.

    Метод 1: Использование аннотаций InferenceService

    В spec.predictor.annotations объекта InferenceService добавьте аннотацию autoscaling.knative.dev/target-utilization-percentage.

    # Установка целевого процента использования для сервиса
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

    В ConfigMap config-autoscaler установите 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)

    Вы можете изменить метрику масштабирования с concurrency на запросы в секунду (RPS). Значение по умолчанию — 200. Примечание: В режиме RPS настройка target-percentage для concurrency не используется.

    Метод 1: Использование параметров ресурса InferenceService

    В spec.predictor установите scaleTarget и scaleMetric в rps.

    # Установка целевого значения RPS для сервиса
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: qwen2
  namespace: fy-1
spec:
  predictor:
    scaleTarget: 150
    scaleMetric: rps
    ...

    Метод 2: Использование глобального ConfigMap

    В ConfigMap config-autoscaler установите 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. Пожалуйста, убедитесь, что эта аннотация существует, иначе ваша конфигурация будет сброшена к значению по умолчанию.