SageMaker TTS 자동 확장, 추정치 대신 측정된 한계로 전환

AWS는 추정한 임계값을 엔드포인트 측정값으로 대체하는 SageMaker TTS 자동 확장 사례를 공개하며, 자동화만으로는 해소할 수 없는 한계도 함께 드러냈다. 10월 22일 공개된 가이드는 텍스트 입력을 오디오로 변환하는 텍스트 음성 변환 모델 Kokoro-82M을 커스텀 컨테이너 내부에 배포한다. 핵심 질문은 용량에 관한 것이다. 다른 인스턴스가 시작되는 동안 하나의 인스턴스는 얼마나 많은 작업을 받아들일 수 있을까?

이 사례는 자동 확장을 구성하는 일과 해당 설정이 워크로드에 적합한지 입증하는 일을 유용하게 구분한다. 서비스 수준 목표(SLO)는 지연 시간에 관한 약속을 정의한다. 동시성은 함께 대기하거나 실행되는 요청 수를 나타낸다. 이 측정값들을 연결하면 인프라 팀은 근거 있는 임계값을 설정할 수 있지만, 모든 트래픽 급증 상황에서 서비스 중단이 없음을 보장하지는 않는다.

이는 그럴듯한 사용률 목표를 선택한 뒤 장애가 발생한 후 조정하는 익숙한 방식과 측정 기반 용량 계획을 대비시킨다. Amazon Polly는 관리형 음성 서비스의 기준점이 되며, 이 사례는 자체 모델을 운영하는 팀을 대상으로 한다. 이들 팀은 배포에 대한 통제권을 유지하는 대신, 용량 부족의 결과도 감당해야 한다. 대응성과 상시 인프라 모두를 책임져야 하는 엔지니어에게 부담이 집중된다.

AWS, 확장 설정을 검증 가능한 주장으로 전환

이번 변화는 자동 확장이 용량 계획을 없앤다는 새로운 약속이 아니라, 공개된 측정 워크플로다.

AWS는 TTS 확장 가이드에서 두 가지 핵심 측정값을 설명한다. Q_max는 지연 시간 목표를 충족하는, 인스턴스당 테스트된 최대 동시성을 나타낸다. T_total은 추가 용량을 계획할 때 사용하는 반응 시간을 포착한다.

보고된 배포는 ml.g5.xlarge 인스턴스를 사용한다. 3,000밀리초 목표에 대해 통과한 최대 동시성 단계는 요청 50건이다. 다음으로 테스트한 60건 단계는 실패했다. AWS에 따르면 이는 모든 음성 엔드포인트에 권장되는 기본값이 아니라 워크로드별 결과다.

이 차이는 검토자가 인프라 구성을 읽는 방식을 바꾼다. 일반적으로 임계값은 컨트롤러에 대한 지시처럼 보인다. 그러나 여기서는 관측된 동작에 관한 주장도 의미한다. 배포를 검토하는 사람은 어떤 테스트가 그 주장을 뒷받침하는지, 그리고 해당 테스트가 여전히 실행 중인 서비스를 설명하는지 물을 수 있다.

구성이 초기 가정보다 오래 유지될 때 이 차이는 중요해진다. 모델 업데이트 후에도 확장 정책은 그대로 남을 수 있다. 컨테이너 변경은 엔드포인트 이름을 바꾸지 않고도 요청 처리를 변경할 수 있다. 기존 목표가 유지되는 동안 지연 시간 약속은 더 엄격해질 수 있다.

이런 상황에서 익숙한 설정은 오해를 부를 수 있다. 설정이 존재한다는 사실은 누군가가 이미 용량 문제를 해결했다는 인상을 준다. 실제로 그 근거는 다른 배포 환경을 설명하고 있을 수 있다. 측정은 팀이 그러한 겉보기 확실성에 이의를 제기할 수 있게 한다.

따라서 뉴스 가치는 테스트와 배포 의사결정의 연결에 있다. AWS는 엔드포인트 동작을 정책 입력값으로 전환하는 구체적 사례를 제시한다. 독자는 이를 독립적으로 확립된 업계 벤치마크가 아니라 운영 참조 구현으로 평가해야 한다.

보고된 동시성 단계가 확립하는 범위에도 한계가 있다. 통과한 단계 뒤에 실패한 단계가 있으면 테스트된 경계가 그 사이에 설정된다. 그렇다고 그 사이의 모든 가능한 운영 지점이 확인되는 것은 아니다. 이 결과를 테스트된 한계로 다루면 실용적 가치를 약화하지 않으면서도 그 차이를 유지할 수 있다.

엔지니어링 관리자의 경우, 즉각적인 시사점은 검토 품질에 있다. 확장 구성을 승인할 때는 자동 확장이 활성화되어 있는지만 확인해서는 안 된다. 검토자는 목표가 무엇을 의미하는지, 어떤 워크로드가 이를 산출했는지, 무엇이 적용 범위 밖에 남는지를 이해할 수 있을 만큼의 근거가 필요하다.

이는 보편적 최적화보다 더 좁은 주장이다. 그러나 장애가 발생했을 때 팀이 인프라가 왜 구성된 대로 동작했는지 설명해야 하는 상황에서는 더 유용하다.

커스텀 음성 배포는 운영자에게 용량 위험을 이전한다

음성 모델에 대한 통제권은 그 모델을 둘러싼 동작에 대한 책임을 수반한다.

Kokoro 모델 카드는 8,200만 개 매개변수를 갖고 Apache 라이선스 가중치를 사용하는 공개 가중치 모델을 설명한다. 따라서 자체 운영 배포를 평가하는 팀에게 구체적인 후보가 된다. 모델 카드의 품질 및 효율성 설명은 이 확장 실험으로 확립된 결과가 아니라 게시자의 주장으로 남는다.

모델 선택만으로는 프로덕션 결정을 내릴 수 없다. 애플리케이션에는 예측 가능한 응답, 유용한 장애 처리, 수요가 서비스를 압도하기 전에 확보되는 용량도 필요하다. 이러한 요구사항은 모델 주변의 서빙 시스템에 속한다.

고객 요청을 처리하는 가상의 음성 비서를 생각해 보자. 음성 생성은 다른 애플리케이션 구성요소가 이미 응답 예산의 일부를 사용한 뒤에 시작된다. 오디오가 결국 도착하고 품질이 양호하더라도, 답변이 늦으면 서비스가 고장 난 것처럼 느껴질 수 있다.

이제 백그라운드에서 자료를 처리하는 가상의 내레이션 서비스를 생각해 보자. 같은 지연도 작업이 납품 기한 전에 완료된다면 허용될 수 있다. 이들 애플리케이션은 유사한 음성 합성 기술을 사용할 수 있지만, 서로 다른 인프라 정책이 필요하다.

이 비교는 일반적인 확장 목표가 제한적인 지침만 제공하는 이유를 보여준다. 운영자는 배포가 어떤 사용자 경험을 약속하는지 결정해야 한다. 그 이후에야 성능 측정이 시스템이 그 약속을 뒷받침하는지 답할 수 있다.

그래픽 처리 장치(GPU)는 모델 연산을 가속하지만, 활동 수준은 사용자 경험의 간접적인 신호다. 가동 중인 가속기만으로는 특정 요청이 얼마나 오래 기다렸는지 알 수 없다. 한가한 가속기 역시 모든 요청이 적시에 응답을 받았음을 입증하지 않는다.

SageMaker TTS 자동 확장의 경우, 이는 여러 역할에 걸쳐 부담을 만든다. 플랫폼 엔지니어에게는 사용 가능한 제어 신호가 필요하다. 애플리케이션 개발자에게는 용량이 소진될 때의 명시적 동작이 필요하다. 제품 책임자에게는 사용자가 실제로 경험하는 것과 일치하는 지연 시간 약속이 필요하다.

재무팀은 같은 결정의 다른 측면을 마주한다. 추가 상시 용량은 지속적인 리소스 투자를 만든다. 이를 없애면 수요를 감지하고 회복하는 시스템의 능력에 더 큰 책임이 전가된다. 컨트롤러가 이를 자동으로 실행한다고 해서 어느 쪽 결정도 중립적이 되지는 않는다.

관련 대안에는 관리형 음성 합성이 포함된다. Amazon의 관리형 음성 서비스는 뉴스 리더, 학습 플랫폼, 접근성 도구와 같은 애플리케이션을 위한 음성 생성을 지원한다. 이는 배포 대안을 제시하지만, Kokoro와 비교해 품질이나 지연 시간에서 우위가 있음을 입증하지는 않는다.

공정한 비교는 누가 어떤 의무를 맡는지 살펴봐야 한다. 커스텀 배포를 선택하는 팀은 모델 제어와 함께 운영 업무를 떠안을 이유가 필요하다. AWS 사례는 그 업무의 일부를 가시화하는 데 도움을 준다.

이 때문에 이 이야기는 인프라 전문가를 넘어선다. 음성 기능을 평가하는 기업 구매자는 공급업체가 수요 변동을 어떻게 처리하는지 물어야 한다. 모델 시연은 음성을 생성할 수 있는지에 답한다. 용량 문제는 여전히 열려 있다.

SageMaker TTS 자동 확장, 동시성을 복구 시간과 연결

동시성 한계는 추가 용량이 도움이 되기까지 걸리는 시간까지 정책이 고려할 때 운영상 의미를 갖는다.

저장소의 벤치마킹 예시는 약 260초로 측정된 확장 소요 시간을 보고한다. 이 계획은 별도로 한정된 감지 여유 시간을 추가한 뒤 약 320초를 허용한다.

이 수치에는 서로 다른 명칭이 필요하다. 강제 확장 측정은 정책의 감지 과정을 우회한다. 여유 시간을 추가하는 것은 계획에 도움이 되지만, 그 여유 시간이 관측된 종단 간 결과로 바뀌는 것은 아니다.

예시 계산은 확장 목표 37.5개의 동시 요청과 축소 임계값 25를 산출한다. 확장은 용량을 추가하고, 축소는 용량을 제거한다. 그 차이는 상반된 두 동작의 조건을 분리한다.

이 분리에서 중요한 시사점이 나온다. 가장 바쁜 허용 가능한 운영 지점이 반드시 도움을 요청하기에 적절한 시점은 아니다. 새 용량이 도착하는 데 시간이 걸린다면, 기존 인스턴스 집합은 반응 시간 동안 계속 작업을 처리해야 한다.

이 시간 간격은 이 이야기의 핵심 메커니즘을 만든다. 용량 계획은 서비스 상태와 대응 속도를 연결해야 한다. 컨트롤러는 압력을 정확히 감지하더라도 이미 대기 중인 요청에는 너무 늦게 반응할 수 있다.

정책을 평가하는 독자에게 유용한 질문은 그 사이의 기간에 관한 것이다. 확장 조건이 나타난 뒤 추가 용량이 서비스를 개선하기 전까지 무슨 일이 일어나는가? 인스턴스를 언제 추가할지만 답하는 구성은 그 기간을 설명하지 못한다.

같은 논리는 용량 제거에도 적용된다. 축소 결정은 남은 인스턴스 집합이 처리하는 워크로드를 바꾼다. 대체 용량이 유용해지기 전에 수요가 다시 돌아오면 시스템은 그 반전을 흡수해야 한다.

반복적인 확장 동작을 제한하는 간격인 쿨다운은 이러한 동작에 영향을 줄 수 있다. 그러나 더 오래 기다린다고 처리 용량이 생기지는 않는다. 이는 컨트롤러가 다시 동작하는 시점만 바꾼다. 이 효과들을 혼동하면 정책이 기본 리소스가 정당화하는 수준보다 더 안전해 보이게 된다.

재현 가능성이 가치 있는 지점도 여기다. 저장된 측정값으로 정책 결과를 다시 계산하면 검토자는 산술과 가정을 구분할 수 있다. 모든 입력값을 보편적으로 유효하다고 받아들이지 않고도 결과가 입력값에서 도출되는지 점검할 수 있다.

이 차이는 기술 논의를 이끌어야 한다. 엔지니어는 계산이 정확하다는 데 동의하면서도 가정된 트래픽 증가율에는 이의를 제기할 수 있다. 제품 관리자는 측정값을 수용하면서도 선택된 지연 시간 목표가 애플리케이션에 적합한지 질문할 수 있다.

이러한 이견은 실제 근원을 드러내므로 의사결정을 개선한다. 이런 분리가 없으면 팀은 종종 최종 임계값을 마치 고립된 선호처럼 논쟁한다. 측정 접근 방식은 그 뒤에 있는 의존성을 드러낸다.

따라서 이 메커니즘은 더 정밀한 운영 계약을 뒷받침한다. 배포에는 테스트된 워크로드 경계, 계획된 반응 시간, 인스턴스 집합 크기를 변경하기 위한 조건이 있다. 이 요소들은 함께 사용률 비율 하나보다 더 많은 것을 설명한다.

그럼에도 이는 서비스의 모델을 설명할 뿐이다. 프로덕션 검증은 이 모델이 애플리케이션이 받는 트래픽과 얼마나 밀접하게 일치하는지 확인해야 한다.

급증 가정은 여전히 비즈니스 결정이다

엔드포인트 동작을 측정하면 불확실성은 줄어들지만, 운영자는 서비스가 견뎌야 할 수요 변화를 여전히 선택해야 한다.

프로젝트의 용량 모델은 선택한 가정과 측정된 입력값을 명시적으로 구분합니다. 지연 시간 목표와 급증 비율은 선택한 범주에 속합니다. 급증 비율은 스케일링 반응 시간 간격 내 예상되는 트래픽 증가 배수를 설명합니다.

급증 비율이 1.25인 경우, 예시는 테스트된 동시성 경계의 일부를 사용해 임계값 여유 용량을 확보합니다. 문서화된 방정식은 보고된 스케일 아웃 및 스케일 인 값을 산출합니다. 이 계산은 선택된 가정을 표현할 뿐, 미래 수요를 독립적으로 검증하지는 않습니다.

이러한 단서는 “측정된 정책”이라는 표현이 지나치게 광범위해지는 것을 막습니다. 엔드포인트는 테스트 환경에서의 동작에 관한 증거를 제공할 수 있습니다. 하지만 조직이 어느 정도의 비즈니스 위험을 수용해야 하는지는 결정할 수 없습니다.

계획된 출시가 그 차이를 잘 보여 줍니다. 마케팅 활동은 이례적인 수요를 예상할 근거가 될 수 있지만, 그 자체로 신뢰할 만한 도착 패턴을 제공하지는 않습니다. 인프라 계획에는 여전히 해당 수요가 얼마나 집중될지에 대한 판단이 필요합니다.

과거 트래픽 역시 해석이 필요합니다. 서비스는 일반적인 사용에 대한 광범위한 기록을 보유할 수 있지만, 새롭게 도입된 기능에 관한 증거는 없을 수 있습니다. 기록은 여전히 유용하지만, 새 워크로드가 이전 워크로드와 유사한지에 따라 관련성이 달라집니다.

수요가 양이 아닌 형태를 바꿀 때도 같은 문제가 나타납니다. 음성 애플리케이션은 서로 다른 텍스트 길이 또는 상호작용 패턴을 받을 수 있습니다. 요청 수가 변하지 않았다고 해서 워크로드까지 동일하다는 뜻은 아닙니다.

이는 AWS가 보고한 실행에서 새롭게 발견된 내용이 아니라, 측정 접근 방식에서 도출되는 분석적 함의입니다. 측정된 입력값에 맥락이 필요한 이유를 설명합니다. 테스트 조건이 없는 수치는 또 다른 근거 없는 기본값이 될 수 있습니다.

용량 모델은 지연 시간 목표가 허용 가능한 동시성 결과를 정의하는 데도 도움이 된다는 점을 분명히 합니다. 약속을 변경하면 테스트가 답해야 하는 질문도 달라집니다. 응답 약속을 더 엄격하게 설정한 뒤에도 이전 경계가 유효하다고 팀이 가정할 수는 없습니다.

운영자에게 실질적인 결과는 책임 소재와 관련됩니다. 누군가는 트래픽 가정을 책임져야 하며, 또 다른 누군가는 사용자 대면 목표를 책임져야 합니다. 둘 중 하나라도 암묵적으로 남겨 두면, 최종 구성은 그 기반이 된 결정보다 더 권위 있어 보일 수 있습니다.

구매자에게는 증거 요청이 중요합니다. 공급업체가 자동 스케일링을 사용하는지 묻는 것만으로는 큰 통찰을 얻기 어렵습니다. 해당 서비스가 어떤 트래픽 패턴을 견뎌 냈는지 물으면 더 유익한 논의가 가능합니다.

따라서 SageMaker TTS autoscaling은 리소스 할당만큼이나 책임성을 정리하는 방법이 됩니다. 시스템이 측정한 것, 운영자가 가정한 것, 애플리케이션이 약속한 것을 분리하는 데 도움이 됩니다.

결과가 대시보드나 계획 문서로 옮겨갈 때도 이러한 구분은 유지되어야 합니다. 주변의 가정이 사라지면 정밀한 임계값도 불확실성을 가릴 수 있습니다. 이러한 가정을 함께 보존해야 측정의 의미를 지킬 수 있습니다.

남은 질문은 실제로 수요가 변할 때 그 정책이 안전하게 작동하는지 여부입니다. 샘플 자체의 경고는 이 질문에 별도의 증거가 필요한 이유를 보여 줍니다.

샘플은 임계값 산술만으로 지울 수 없는 위험을 드러냅니다

방어 가능한 임계값이라도 상당한 신뢰성 타협을 수용하는 배포와 함께 적용될 수 있습니다.

작업 예시는 급증 대응 능력과 스케일 인 안정성에 관한 경고를 보고합니다. 이러한 경고는 정책의 운영 범위를 한정하기 때문에 중요합니다. 공개 요약에서 사라지는 대신 구성과 함께 전달되어야 합니다.

실행 대기 중인 작업인 큐는 수요를 위한 일시적 공간을 제공할 수 있습니다. 하지만 추가 처리 속도를 제공하지는 않습니다. 따라서 큐 용량을 확보한다고 해서 바쁜 인스턴스가 급증 기간 내내 유입 작업을 충분히 빠르게 처리할 수 있다는 점이 입증되지는 않습니다.

이 차이는 줄을 수용하는 것과 줄을 처리하는 것의 차이와 비슷합니다. 대기 공간을 늘리면 즉각적인 거부는 막을 수 있지만, 대기 시간은 여전히 허용하기 어려울 수 있습니다. 음성 애플리케이션에서 사용자는 요청이 내부적으로 어디에 있든 지연을 경험합니다.

따라서 엄격한 평가는 성공한 응답과 거부된 작업을 모두 검토해야 합니다. 완료된 요청에 대해서만 지연 시간을 보고하면 서비스의 불완전한 모습을 제시할 수 있습니다. 어려운 요청을 거절하는 시스템은 그러한 결과도 신뢰성 평가에 포함해야 합니다.

스케일 인은 다른 형태의 집중 위험을 야기합니다. 용량을 제거하면 책임이 남은 용량으로 이전됩니다. 이 이전이 즉시 확장을 위한 조건을 재현한다면, 컨트롤러는 상반된 결정을 반복할 수 있습니다.

중요한 질문은 서비스가 실제로 사용하는 플릿 규모에서의 안정성입니다. 혼잡한 기간에 적절하게 동작하는 정책도 한산한 기간에는 까다로울 수 있습니다. 트래픽이 적다고 해서 모든 용량 축소가 자동으로 무해해지는 것은 아닙니다.

이러한 우려는 성공적인 구성 확인의 해석도 제한합니다. 배포된 설정이 계획과 일치하는지 확인하면 일관성은 입증됩니다. 하지만 그 계획이 모든 프로덕션 요구 사항을 충족한다는 점까지 입증하지는 않습니다.

sample implementation은 자신을 프로덕션 준비가 완료된 시스템이 아닌 가치 검증으로 설명합니다. 문서는 고정된 PyTorch 종속성에 알려진 권고 사항이 있음을 표시하기도 합니다. 이 공개는 팀이 컨테이너를 프로덕션에 맞게 적용하기 전에 구체적인 검토 의무를 만듭니다.

종속성을 업데이트하면 또 다른 운영상 질문이 생깁니다. 보안 수정은 성능 결과의 기반이 되는 소프트웨어 환경을 바꿀 수 있습니다. 적절한 대응은 기존 측정값이 여전히 해당 정책을 뒷받침하는지 검토하는 것입니다.

이는 참조 구현을 공개하지 말자는 주장이 아닙니다. 명시적인 제한 사항은 샘플을 더 쉽게 평가할 수 있게 합니다. 독자가 유용한 설계와 완전한 프로덕션 서비스를 구분할 수 있게 해 줍니다.

여기서 검토한 증거 역시 보고된 실시간 측정값의 독립적인 재현을 확립하지는 않습니다. AWS의 구현과 문서는 검토 가능한 자료를 제공하지만, 동일한 원천 작업에 속합니다. 계산을 재현하는 일과 엔드포인트 동작을 재현하는 일은 다릅니다.

중립적인 해석은 이 구분을 유지해야 합니다. 이용 가능한 자료는 접근 방식과 명시된 결과의 분석을 뒷받침합니다. 하지만 보편적인 비용 절감, 보장된 지연 시간 또는 관리형 음성 대안 대비 우월성에 대한 주장을 뒷받침하지는 않습니다.

의사결정권자에게 가장 강력한 특징은 타협 사항의 가시성입니다. 약점을 보고하는 정책은 팀이 조사할 구체적인 대상을 제공합니다. 설명되지 않은 기본값은 프로덕션 동작이 기대에서 벗어날 때 도움이 덜 됩니다.

재현, 급증 복구 및 릴리스 규율을 살펴보세요

다음으로 유용한 증거는 반복되는 동작, 현실적인 수요 변화, 그리고 측정값이 소프트웨어 릴리스와 계속 연결되는지에 관한 것입니다.

향후 몇 달간 가장 먼저 살펴볼 신호는 배포 조건 전반에서의 독립적 재현입니다. 유용한 보고서는 결과와 함께 워크로드, 소프트웨어 버전, 인스턴스 구성 및 지연 시간 목표를 식별할 것입니다.

AWS의 정확한 수치와 일치하는 것만이 의미 있는 결과는 아닙니다. 명확한 설명이 있는 다른 결과도 접근 방식에 대한 신뢰를 높일 수 있습니다. 이는 워크플로가 미리 정해진 답을 단순히 재현하는 것이 아니라 배포 간 차이를 구분한다는 점을 보여 줍니다.

설명되지 않은 변동은 특정 임계값의 이식성에 대한 신뢰를 약화시킬 것입니다. 테스트 기간, 워크로드 선택 및 환경 조건의 중요성도 커질 것입니다. 대응은 호환되지 않는 결과를 새로운 기본값으로 평균 내는 것이 아니라 조사여야 합니다.

두 번째 신호는 정책 기반의 급증 복구입니다. 가장 강력한 검증은 수요가 증가하는 순간부터 감지, 용량 추가, 서비스 복구에 이르는 과정을 추적합니다. 이 관찰은 강제 스케일 아웃 테스트가 일부 우회하는 시간 간격을 다룹니다.

그러한 증거에는 성공적인 응답 지연 시간과 함께 대기 시간 및 실패한 요청도 포함되어야 합니다. 유입 부하의 형태도 보존해야 합니다. 그렇지 않으면 요약이 복구를 더 쉽거나 어렵게 만든 정확한 조건을 숨길 수 있습니다.

급증을 성공적으로 처리하면 선택한 여유 용량이 애플리케이션 요구 사항에 맞는다는 주장이 강화됩니다. 반응 시간 간격 동안 반복적으로 과부하가 발생한다면, 컨트롤러가 결국 적절한 플릿 규모에 도달하더라도 그 결론은 약화됩니다.

세 번째 신호는 릴리스 규율입니다. 팀은 모델, 컨테이너 및 서빙 변경이 용량 증거 검토를 촉발한다는 점을 보여야 합니다. 측정 워크플로는 초기 배포 이후에도 계속 작동할 때 더 가치 있어집니다.

이는 모든 변경이 동일한 결과를 내야 한다는 뜻은 아닙니다. 결과가 바뀔 때 추적 가능한 설명이 필요하다는 뜻입니다. 더 느린 릴리스라도 다른 요구 사항을 개선하고 플릿 정책이 그에 맞게 조정된다면 수용 가능할 수 있습니다.

이러한 이력을 보존하면 운영 지식을 더 쉽게 재사용할 수 있습니다. 엔지니어는 이전 임계값의 대체안을 평가할 때 그 임계값의 근거가 필요합니다. 이 자료를 정리하는 팀은 검색 가능한 엔지니어링 지식 베이스를 활용해 테스트 기록, 릴리스 결정 및 장애 조사 결과를 연결할 수 있습니다.

예시를 도입하기 전에 팀에 현재 음성 엔드포인트의 근거 자료를 수집하도록 요청하세요. 지연 시간 약속, 이를 테스트한 워크로드, 그리고 추가 용량이 도움이 되기까지 필요한 시간을 식별하세요. 이러한 기록을 실제로 실행 중인 모델 및 컨테이너와 비교하세요. 그런 다음 수요 증가 중과 용량 제거 후에 어떤 일이 발생하는지 검토하세요. 성공적인 응답과 함께 거부된 요청도 논의에 포함하세요. SageMaker TTS autoscaling은 이러한 검토를 위한 구체적인 출발점을 제공하지만, 설정에는 여러분의 배포 환경에서 나온 증거가 필요합니다. 팀이 재현 가능한 측정으로 설명할 수 있는 현재 임계값은 무엇이며, 최근 아무도 테스트하지 않은 가정에 여전히 의존하는 임계값은 무엇인가요?