조정 및 처리량 모범 사례

이 주제에서는 Amazon Bedrock 엔드포인트에서 처리량 제한 및 일정이 작동하는 방법을 설명하고 생성형 AI 애플리케이션 규모 조정을 위한 모범 사례를 제공합니다.

Amazon Bedrock 엔드포인트

Amazon Bedrock은 추론을 위해 두 개의 엔드포인트를 지원합니다.

대부분의 새 애플리케이션의 경우 로 시작합니다bedrock-runtime. 서버 측 도구, 배경 추론, 프로젝트, Workspace 또는 에서만 사용할 수 있는 모델과 같이 해당 엔드포인트에서만 사용할 수 있는 기능이 필요한 bedrock-mantle 경우를 사용합니다bedrock-mantle. 동일한 애플리케이션에서 두 엔드포인트를 모두 사용할 수 있습니다. 전체 비교는 단원을 참조하십시오Amazon Bedrock에서 지원하는 엔드포인트.

두 엔드포인트가 다르게 작동하는 이유

두 엔드포인트 표면 모두 동일한 기본 추론 엔진을 사용하지만 할당량 회계 및 용량 옵션은 다릅니다. bedrock-runtime는 모델별 토큰 할당량과 일부 모델의 경우 requests-per-minute 수(RPM) 할당량을 사용합니다. bedrock-mantle는 RPM 할당량을 적용하지 않으며 게시된 할당량이 있는 모델에 대해 별도의 입력 토큰 및 출력 토큰 할당량을 사용합니다. 의 다른 모델에는 Service Quotas에 노출된 계정당 할당량이 없을 bedrock-mantle 수 있지만 처리량은 여전히 내부 서비스 용량에 의해 관리됩니다.

할당량은 상한이며 모든 온디맨드 요청이 즉시 처리된다는 보장은 아닙니다. 수요가 많은 기간에는 요청이 대기열에 추가되거나 일시적인 용량 오류가 발생할 수 있습니다. 재시도 급증을 생성하지 않고 애플리케이션을 제한된 동시성, 대기열 작업 및 임시 재시도 오류로 설계합니다.

bedrock-mantle 엔드포인트: 처리량 및 할당량

bedrock-mantle 엔드포인트에는 다음과 같은 할당량 동작이 있습니다.

기본값과 계정의 할당은 모델, 리전 및 사용 내역에 따라 다를 수 있습니다. 현재 값, 할당량 평가 세부 정보 및 증가 요청 AWS 지원 프로세스는 섹션을 참조하세요bedrock-mantle 엔드포인트 할당량. 모델별 엔드포인트, 서비스 계층 및 기능 지원한 눈에 보는 모델은 해당를 참조하세요.

bedrock-runtime 엔드포인트: 처리량 및 할당량

bedrock-runtime 엔드포인트에는 다음과 같은 할당량 동작이 있습니다.

현재 할당량 값, 토큰 감소 세부 정보 및 할당량 증가 프로세스는 섹션을 참조하세요bedrock-runtime 엔드포인트 할당량. 모델별 엔드포인트, 서비스 계층 및 기능 지원한 눈에 보는 모델은 해당를 참조하세요.

HTTP 오류 응답 이해

API별 원인 및 해결 단계는 섹션을 참조하세요Amazon Bedrock API 오류 코드 문제 해결.

권장 오류 처리

일시적 오류

일시적인 제한 및 용량 오류와 같이 재시도하기에 안전한 오류만 재시도합니다. 서비스가 Retry-After 헤더를 반환하는 경우 이를 준수합니다. 그렇지 않으면 무작위 지터를 사용하여 지수 백오프를 구현합니다.

AWS SDKs 및 인기 있는 HTTP 라이브러리는이 패턴에 대한 기본 지원을 제공합니다. 재시도 설정 이름은 다릅니다. botocore의 에는 초기 요청이 total_max_attempts 포함되는 반면 OpenAI 및 Anthropic SDKs의는 재시도만 max_retries 계산합니다. 따라서 다음 예제에서는 서로 다른 숫자 값을 사용하여 동일한 예제 6시도 예산을 제공합니다.

import boto3
from botocore.config import Config

config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)

from openai import OpenAI

client = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/v1",
    max_retries=5,
)

import anthropic

client = anthropic.Anthropic(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/anthropic",
    max_retries=5,
)

모델 및 작업의 문서화된 최대 추론 기간에 따라 재시도와 별도로 연결 및 읽기 제한 시간을 구성합니다. 제한 시간이 유효한 장기 실행 추론 요청보다 짧으면 재시도 및 중복 작업이 방지될 수 있습니다.

지속적인 용량 오류

영구 503 또는 529 오류가 발생하면 재시도만으로 로드가 증폭될 수 있습니다. 서비스에 일시적인 용량 제약이 발생하거나 워크로드가 모델 및 리전에 현재 사용 가능한 용량을 초과할 수 있습니다. 다음 단계를 따릅니다.

처리량 증가

온디맨드 용량은 모델, 리전 및 시간에 따라 다를 수 있습니다. 할당량 내의 모든 요청이 수요가 많은 기간 동안 성공할 수 있는 것은 아니므로 워크로드를 시작하거나 모델 또는 리전을 변경하거나 트래픽이 크게 증가할 때 점진적으로 증가합니다. 이는 게시된 계정당 할당량이 없는 bedrock-mantle 모델에서 특히 중요합니다.

권장 램프 업 절차

워크로드의 지연 시간 및 트래픽 패턴에서 단계 크기와 관찰 기간을 선택합니다. RPM을 유일한 제어 신호로 사용하지 마십시오. 요청 토큰 크기와 응답 길이는 RPM이 일정하게 유지되는 경우에도 용량 소비를 크게 변경할 수 있습니다.

할당bedrock-mantle량 증가의 경우를 따릅니다할당량 증가 요청. 의 경우 bedrock-runtime를 따릅니다할당량 증가 요청.

추가 모범 사례

리전 가용성 및 리전 간 추론

온디맨드 용량은 리전별로 다르며 리전마다 다를 수 있습니다. 워크로드가 단일 리전을 대상으로 하는 경우 수요가 많은 기간 동안 용량 오류가 발생할 수 있습니다. 에서는 모델 및 데이터 레지던시 요구 사항이 지원할 글로벌 리전 간 추론 때를 bedrock-runtime사용합니다. 자체 리전 장애 조치를 구현하는 경우 모든 대상 리전에서 모델 가용성을 확인하고 제한된 재시도를 적용하여 장애 조치로 인해 트래픽 급증이 발생하지 않도록 합니다.

도움말 가져오기

권장 사항 요약