Bedrock 프로비저닝된 처리량과 용량 변경 조건

MU는 공통 GPU 개수나 고정 RPS가 아니다

모델 단위(Model Unit, MU)는 특정 모델이 분당 처리할 수 있는 입력·출력 토큰(token) 용량을 나타낸다. 공통 GPU 개수나 고정된 초당 요청 수(requests per second, RPS)가 아니다. 같은 1 MU라도 모델별 성능이 다를 수 있고, 요청마다 입력과 출력 길이가 달라지면 같은 요청률에 필요한 용량도 달라진다.

프로비저닝된 처리량(Provisioned Throughput)의 지원 여부는 모델명만 아니라 모델 ID, 컨텍스트(context) 길이와 리전으로 확인한다. 같은 이름의 모델도 컨텍스트가 다른 ID가 별도 행으로 나올 수 있다. 예를 들어 참고 표에서 Nova Lite의 두 컨텍스트 변형은 us-east-1, Llama 3.1 70B Instruct는 us-west-2를 표시한다. 이 사례를 모든 모델·리전의 지원 목록으로 확대하거나 계정별 구매 가능성과 미래 지원을 보장하는 목록으로 사용하지 않는다.

구매·약정·할당량은 별도의 조건이다

MU 방식에서는 약정(commitment)이 없는 용량은 삭제할 수 있지만, 1개월 또는 6개월 약정은 기간이 끝나기 전에 삭제하는 데 제한이 있다. 약정 만료가 자동 과금 종료를 뜻하지는 않으며, 삭제할 때까지 과금(billing)이 계속된다는 조건도 확인해야 한다. 요금은 모델, MU 수와 약정 기간에 따라 달라진다. 실제 구매 전 현재 단가와 자동 갱신 해제 절차를 확인한다.

MU 방식의 용량을 구매하려면 약정 수준과 MU 수를 정하고 계정에 필요한 MU 할당량(quota)을 요청해 승인받는다. 모델 접근 권한, 필요한 IAM API 권한과 해당 사용자 지정 모델(custom model)의 AWS KMS 복호화(decryption) 권한도 확인한다. FullAccess 정책 전체가 항상 필수인 것은 아니다. 실제 필요한 Action과 Resource로 권한을 제한하는 방법을 검토하며, 적용할 정책은 해당 API 문서와 계정에서 검증한다.

지원 표의 GovCloud 참고는 무약정 사용자 지정 모델 조건을 따로 기술하고, 끝 참고는 Titan Image Generator G1 V1/V2의 기본 모델에 대한 무약정 구매 제한을 명시한다. 이런 예외 때문에 모든 모델에 세 약정 옵션이 동일하게 제공된다고 단정할 수 없다. 표의 일부 모델 ID에 철자·공백이 어색한 표기도 있어 이를 실행용 ID로 복사하지 않는다.

MU 변경과 모델 교체와 토큰 변경을 분리한다

MU 방식의 수정 문서는 편집 가능한 항목을 이름, 태그(tag), 그리고 사용자 지정 모델(custom model)에 연결된 경우의 모델로 설명한다. 따라서 MU 10개를 경보 하나로 25개로 자동 확장(auto scaling)하는 사례를 현재 내장 기능의 보장으로 받아들이지 않는다. 실제 용량 변경을 설계하려면 제공 방식별로 수정 가능한 항목과 API를 확인해야 한다. 이 MU 방식의 제한을 다른 제공 방식에까지 일반화해서도 안 된다.

토큰 방식(token-based provisioning)에서는 분당 입력·출력 토큰 수를 수정하는 등 다른 옵션을 제공한다. 따라서 모든 Bedrock 프로비저닝 용량을 어떤 방식에서도 변경할 수 없다고 단정해서는 안 된다. 반대로 토큰 수를 수정할 수 있다고 자동 확장(auto scaling) 정책이 기본으로 제공된다고 판단해서도 안 된다.

모델 교체도 별개의 작업이다. MU 설명에서 기본 모델에 연결된 처리량의 모델은 변경할 수 없고, 사용자 지정 모델에 연결된 경우에는 그 기본 모델 또는 같은 기본 모델에서 파생된 다른 사용자 지정 모델로 전환할 수 있다. 업데이트 동안 추론은 계속할 수 있지만 완전히 배포되기 전에는 이전 모델의 출력을 받을 수 있다. 무중단 호출 가능성과 즉시 새 모델로 전환됨을 구분해야 한다.

용량 수정과 자동 확장을 구분하기

질문	구현 전에 확인할 내용
MU 10 → 25 사례를 내장 자동 확장 기능으로 보아도 되는가?	설계 예시와 실제 제품 기능은 다르다. MU 방식에서 수정 가능한 항목과 API를 확인하고 경보가 실제 용량 변경으로 이어지는지 검증해야 한다.
모든 프로비저닝 방식이 자동 확장(Auto Scaling)을 지원하지 않는가?	그렇게 일반화할 수 없다. MU 방식과 토큰 방식을 나누고, 방식별 지원 API와 자동 확장 정책의 제공 여부를 확인한다.
토큰 수를 수정할 수 있으면 바로 사용할 수 있는가?	수정 기능의 존재와 실제 적용 조건은 다르다. 지원 모델, 절차, 약정과 자동화 연계 조건을 확인해야 한다.
자체 경보와 자동화로 용량을 조절하려면 무엇이 필요한가?	변경 가능한 API, 할당량(quota), 약정과 전환 지연을 확인하고 실제로 구현·검증해야 한다. 이 교재가 그 동작을 실행해 보장하는 것은 아니다.

개요의 ‘사용자 지정 모델 사용에는 프로비저닝 구매 필요’라는 표현도 이 MU 중심 설명 범위에서 읽었으며 모든 새 배포 방식에 적용되는 보편 명제로 확대하지 않는다. 계정 실제 이용권한·용량 확보·모델 단종 여부는 확인하지 않았다.

적용 범위: 위 제약과 예외를 적용 대상의 현재 공식 문서와 대조한다. 이 해설은 API 실행 성공이나 법적 준수를 보증하지 않는다.

공식 출처와 이어 읽기

용어 확인: 파운데이션 모델(foundation model, FM) · 프로비저닝된 처리량(Provisioned Throughput) · 처리량(throughput).