View a markdown version of this page

为您的 HyperPod 推理模型部署配置请求限制 - 亚马逊 SageMaker AI
先决条件在部署 YAML 中配置请求限制字段的解释请求限制的工作原理示例
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

为您的 HyperPod 推理模型部署配置请求限制

您可以在 Amazon SageMaker HyperPod 推理模型部署中配置请求限制，以控制每个 Pod 接受的并发请求数。当达到限制时，超出的请求会收到可配置的 HTTP 错误响应，从而实现快速失败行为，并允许负载均衡器将流量重定向到其他 pod。

请求限制由与模型容器一起运行的 nginx sidecar 代理强制执行。这需要在您的部署中启用指标。

先决条件

在配置请求限制之前，请验证：

  • 指标已在您的部署中启用 (metrics.enabled: true)。只有在启用指标时才会创建强制执行请求限制的 nginx sidecar 代理。

在部署 YAML 中配置请求限制

在你的 InferenceEndpointConfig YAML worker 中添加下面的requestLimits部分。以下示例将每个 Pod 的并发请求限制为 10 个，队列为 5，超过限制时返回 HTTP 503。

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: my-model
  namespace: ns-team-a
spec:
  modelName: my-model-name
  instanceType: ml.g5.8xlarge
  invocationEndpoint: invocations
  modelSourceConfig:
    modelSourceType: s3
    s3Storage:
      bucketName: my-model-bucket
      region: us-east-2
      modelLocation: models/my-model
  worker:
    image: my-model-image:latest
    modelInvocationPort:
      containerPort: 8080
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: "1"
      requests:
        cpu: "4"
        memory: "32Gi"
        nvidia.com/gpu: "1"
    requestLimits:
      maxConcurrentRequests: 10
      maxQueueSize: 5
      overflowStatusCode: 503
  metrics:
    enabled: true
  tlsConfig:
    tlsCertificateOutputS3Uri: "s3://my-tls-bucket/certs"

字段的解释

maxConcurrentRequests（可选，整数）

nginx sidecar 代理每个 pod 接受的最大并发请求数。达到限制后，新请求要么排队（如果已配置）maxQueueSize，要么立即拒绝并显示溢出状态代码。最小值：1。如果未设置或设置为 0，则不强制执行并发限制。

maxQueueSize（可选，整数）

达到并发请求限制时要排队的最大请求数。排队的请求会等到正在处理的请求完成。队列已满时，新请求会收到溢出状态码响应。最小值：0。如果未设置或设置为 0，则不应用排队——当达到并发请求限制时，请求会立即被拒绝。

overflowStatusCode（可选，整数）

超出请求限制时返回的 HTTP 状态码。必须介于 400 和 599 之间。默认：429（请求过多）。常见取值：

  • 429— 请求过多（默认）。用于速率限制的标准 HTTP 状态。

  • 503— 服务不可用。当您希望负载均衡器在不同的 pod 上重试时很有用。

请求限制的工作原理

当推理请求到达 nginx sidecar 代理时：

  1. 如果活跃请求的数量低于maxConcurrentRequests，则请求会被转发到模型容器。

  2. 如果达到限制且大maxQueueSize于 0，则请求将排队并等待（最多 60 秒）活动插槽变为可用。

  3. 如果队列已满（或未配置队列），则请求会立即被拒绝，overflowStatusCode并显示配置的 JSON 错误响应：

    {
  "error": "Too many concurrent requests",
  "max_concurrent": 10,
  "max_queue_size": 5,
  "current": 10
}

示例

严格的并发限制，无需排队

要在不排队的情况下立即拒绝多余的请求，请执行以下操作：

requestLimits:
  maxConcurrentRequests: 5
  overflowStatusCode: 429

排队的并发限制

要在拒绝之前允许一个小队列，请执行以下操作：

requestLimits:
  maxConcurrentRequests: 10
  maxQueueSize: 5
  overflowStatusCode: 503

在此配置中，最多可同时处理 10 个请求。当第 11 个到第 15 个请求到达时，他们会排队等待活动时段。第 16 个及以后的请求会收到 HTTP 503。