Right-size generative AI endpoints with concurrency sweeps on Amazon SageMaker AI

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon SageMaker AI의 동시성 스윕은 생성형 AI 엔드포인트의 처리량과 지연 시간을 측정하고 SLA를 충족하는 동시성을 탐색해 인스턴스 규모와 비용 대비 성능을 조정하는 방법이다.

📌 핵심 요약

• Amazon SageMaker AI Inference Recommendations에 내장된 동시성 스윕은 동시 요청 수를 단계적으로 높여 처리량, 지연 시간, 포화 지점을 측정하며 별도의 부하 테스트 인프라 구축을 줄인다.
• 예제는 활성 파라미터가 3B인 MoE 모델 NVIDIA Nemotron-3 Nano 30B를 NVIDIA Blackwell GPU 기반 ml.g7e.2xlarge에 네이티브 vLLM 컨테이너로 배포한다.
• 평균 입력 1,024토큰·출력 256토큰과 스트리밍을 설정하고, CreateAIBenchmarkJob으로 동시성 64·256·1,024를 각각 요청 1,024건으로 순차 시험한다. 이 시험에서는 동시성 256에서 처리량 증가가 둔화하고 p99 지연 시간이 급증하는 포화 지점이 나타났다.
• max-concurrency-under-sla 자동 탐색 예제는 p99 종단 간 지연 시간 50초 기준에서 동시성 320이 약 2,782 출력 토큰/초로 SLA를 충족한다고 설명한다. 여기에 p95 최초 토큰 도달 시간 1.5초 기준을 함께 적용한 예제에서는 최대 지원 동시성이 80으로 제시된다.
• 용량 판단에는 처리량, p99 종단 간 지연 시간, p50~p99 지연 시간 격차, 최초 토큰 도달 시간(TTFT)을 함께 사용한다. 시험 후에는 유휴 상태에서도 시간당 요금이 발생하는 엔드포인트와 관련 엔드포인트 구성·모델을 삭제한다.

🧩 주요 포인트

1. 동시성 256의 포화 지점은 해당 시험 조건의 결과 → 평균 입력 1,024토큰·출력 256토큰 같은 실제 워크로드 특성을 반영해야 인스턴스 용량 판단에 활용할 수 있다.
2. p99 종단 간 지연 시간 50초에 p95 최초 토큰 도달 시간 1.5초를 추가하면 동시성이 320에서 80으로 낮아지는 예제 → 대화형 서비스의 응답성 조건이 수용 가능한 부하를 크게 제한할 수 있다.
3. 인스턴스별 SLA 충족 용량과 피크 트래픽이 필요한 규모를 결정 → 과잉 배치의 유휴 GPU 비용과 부족한 배치의 요청 대기·지연 증가를 함께 줄이는 근거가 된다.

🧠 상세 정리

1. 수동 용량 조정의 한계와 동시성 스윕

생성형 AI 엔드포인트의 적정 규모를 정하려면 허용 가능한 지연 시간을 유지하면서 비용 대비 성능이 좋은 인스턴스 유형과 서빙 구성을 찾아야 한다. 원문은 체계적인 방법이 없으면 배포, 수동 부하 시험, 설정 변경을 반복하게 되며, ml.g7e.2xlarge 한 대로 충분한 상황에 다섯 대를 선택하면 유휴 GPU에 예산을 쓰게 된다고 설명한다. 반대로 인스턴스가 부족하면 요청이 대기열에 쌓이고 지연 시간이 급증해 서비스 품질이 떨어진다. 동시성 스윕은 동시에 보내는 요청 수를 통제하면서 점차 늘려 이러한 성능 변화를 측정하는 방식이며, Amazon SageMaker AI Inference Recommendations에 내장되어 별도의 부하 테스트 인프라를 구축하고 유지할 필요가 없다는 것이 글의 출발점이다.

2. 포화 지점과 네 단계의 실행 흐름

동시성 스윕은 각 동시 요청 수준에서 초당 생성 토큰 수인 처리량과 요청 처리에 걸리는 지연 시간을 측정한다. 예를 들어 동시 요청을 64개에서 256개, 다시 1,024개로 늘리면 요청을 더 추가해도 처리량은 개선되지 않고 지연 시간만 악화되는 포화 지점을 확인할 수 있다. 이 결과는 허용 지연 시간 안에서 처리량을 높이는 동시성, SLA를 넘는 한계, 인스턴스별 용량에 비추어 피크 트래픽을 감당하는 데 필요한 인스턴스 수를 판단하는 근거가 된다. 전체 절차는 네이티브 vLLM 컨테이너로 모델 배포, 입력·출력 토큰 수와 스트리밍을 포함한 워크로드 구성, CreateAIBenchmarkJob 실행, 결과 분석의 네 단계다. 실행 전에는 SageMaker AI 접근이 가능한 AWS 계정, SageMaker AI와 Amazon S3 권한이 있는 IAM 실행 역할, ml.g7e.2xlarge 엔드포인트 서비스 할당량이 필요하다.

3. Nemotron 모델 배포와 vLLM 설정

배포 대상인 NVIDIA Nemotron-3 Nano 30B는 활성 파라미터가 3B인 Mixture-of-Experts 모델이며, 예제에서는 NVIDIA Blackwell GPU 기반 ml.g7e.2xlarge 인스턴스를 사용한다. SageMaker AI용 vLLM Deep Learning Container의 SM_VLLM_* 환경 변수로 모델과 실행 조건을 지정하며, Mamba-Transformer 하이브리드 구조 때문에 SM_VLLM_ENFORCE_EAGER를 true로 설정해야 한다고 설명한다. 단일 GPU에 맞춰 텐서 병렬 크기를 1로 지정하고, GPU 메모리 사용 비율은 높은 동시성에서 KV 캐시가 늘어날 여유를 남기기 위해 0.85로 설정하며, 최대 모델 길이는 10240으로 둔다. 프리픽스 캐싱은 여러 요청에서 같은 시스템 프롬프트가 반복될 때 캐시된 키·값 쌍을 재사용하도록 활성화한다. 모델, 엔드포인트 구성, 엔드포인트를 생성한 뒤에는 배포가 정상인지 검증하고 벤치마크로 넘어간다.

4. 실제 요청 특성을 반영한 워크로드 구성

부하 시험에 앞서 CreateAIWorkloadConfig로 어떤 트래픽을 재현할지 정의하며, 토큰 수를 정확히 계산하기 위한 모델 토크나이저 ID도 지정한다. 예제의 평균 입력 길이는 1,024토큰, 평균 생성 응답 길이는 256토큰으로, 원문은 이를 검색 증강 생성(RAG)이나 요약 워크로드를 대표하는 설정으로 제시한다. 코드 생성처럼 입력은 더 짧고 출력은 더 긴 애플리케이션이라면 이 값을 해당 요청 특성에 맞게 바꿔야 하므로, 예제의 용량 결과를 모든 서비스에 그대로 적용하는 방식은 적절하지 않다. 스트리밍은 최초 토큰 도달 시간인 TTFT를 측정하기 위해 활성화하며, 대화형 서비스에서는 전체 처리량뿐 아니라 사용자가 처음 응답을 받는 시점도 중요하다고 설명한다. 따라서 이 단계에서 정한 입력·출력 길이와 응답 방식은 이후 동시성 시험 결과를 해석하는 전제가 된다.

5. 고정 동시성 스윕 실행과 성능 곡선 해석

CreateAIBenchmarkJob에 동시성 목록 64·256·1,024와 단계별 요청 수 1,024를 전달하면 AIPerf 벤치마크 엔진이 하나의 작업 안에서 각 수준을 순차 실행한다. 여러 수준을 동시에 시험하지 않기 때문에 각 측정이 서로 분리된 부하를 반영하며, 원문은 이 접근이 비용을 억제하면서 통계적으로 안정적인 추정치를 제공한다고 설명한다. 완료된 결과는 OutputConfig에 지정한 Amazon S3 경로에 동시성별 JSON 지표를 담은 tarball로 저장되며, 분석에서는 처리량, p99 종단 간 지연 시간, p50~p99 격차, TTFT를 확인한다. 처리량이 평탄해지는 동시에 p99 지연 시간이 급격히 상승하는 곡선의 꺾임이 포화 지점이며, 제시된 시험에서는 동시성 256에서 나타났다. 원문은 이 지점 아래를 안전한 운영 구간으로 설명하고, 그 위에서는 과부하로 사용자의 대기가 늘어난다고 해석한다.

6. SLA 기반 자동 탐색과 결과의 해석 범위

적절한 시험 범위를 모르거나 모델 버전·인스턴스 유형별 탐색을 자동화하려면 고정 동시성 목록 대신 같은 CreateAIBenchmarkJob 호출에 max-concurrency-under-sla 레시피를 지정할 수 있다. p99 종단 간 지연 시간 50초 기준 예제는 동시성 범위를 16~4,096, 최대 반복 수를 10, search_initial_points를 512, 단계별 요청 수를 1,024로 설정하며, 최적화 계획기가 범위를 좁혀 선형 스윕보다 적은 반복과 비용으로 경계를 찾을 수 있다고 설명한다. 제시된 실행 표에서는 동시성 16부터 두 배씩 증가해 256까지 통과하고 512에서 처음 실패한 뒤, 320에서 초당 출력 2,781.8토큰으로 통과한다. 원문은 이를 약 2,782토큰/초로 요약하고 첫 실패 원인을 p99 지연 시간 초과 또는 호출 실패 가능성으로 설명한다. 다만 같은 표의 다음 행에서는 더 낮은 동시성 284도 실패로 표시되어 있으므로, 제시된 자료만으로 모든 낮은 동시성이 통과하는 일관된 경계나 그 불일치의 원인을 확정할 수는 없다.

7. 복수 SLA가 허용 동시성에 미치는 영향

자동 탐색은 하나 이상의 SLA를 받아 모든 조건을 충족하는 가장 높은 동시성을 찾으며, 원문은 많은 운영 워크로드에서 단일 지표만으로는 충분하지 않다고 설명한다. 지원하는 기준은 p95 TTFT, p95 출력 토큰당 시간(TPOT), p99 종단 간 지연 시간, 평균 실패 요청 비율이며, TTFT와 TPOT 기준에는 스트리밍이 필요하다. 복수 조건 예제에서는 p99 종단 간 지연 시간 50초와 p95 TTFT 1.5초를 함께 적용하고 동시성 범위 16~4,096, 최대 반복 수 10, 단계별 요청 수 1,024를 사용한다. 결과 표는 동시성 16·32·64에서 통과하고 128에서 실패한 뒤 80에서 초당 출력 1,599.3토큰으로 통과하며, 원문은 이 경우 최대 지원 동시성을 80으로 제시한다. 이는 전체 응답 완료 시간뿐 아니라 첫 응답의 신속성까지 요구하면 허용 가능한 동시 요청 규모가 더 작아질 수 있음을 보여주는 예제다.

8. 시험 자원 정리와 용량 계획에의 적용

벤치마크가 끝나면 계속 발생하는 비용을 피하기 위해 SageMaker 엔드포인트, 엔드포인트 구성, 모델을 삭제해야 한다고 원문은 안내한다. 특히 엔드포인트는 요청을 받지 않는 동안에도 시간당 요금이 부과되므로, 부하 시험이 끝났다는 사실만으로 비용 발생이 멈추지는 않는다. 글의 결론은 동시성 스윕으로 엔드포인트의 부하별 성능 범위를 체계적으로 파악하면, 예방적인 과잉 배치나 운영 중 병목 발견에 의존하는 대신 실제 측정값을 바탕으로 규모를 결정할 수 있다는 것이다. 이를 위해서는 허용 지연 시간 안에서의 인스턴스별 처리 능력을 확인하고 예상 피크 트래픽과 연결해야 하며, 고정 스윕과 SLA 기반 자동 탐색은 그 판단을 지원하는 두 가지 방식으로 제시된다. 다만 본문의 수치는 특정 모델·인스턴스·워크로드 및 SLA 조건의 예제이며, 모든 배포에 공통으로 적용되는 용량 수치로 제시된 것은 아니다.

🧾 핵심 주장 / 시사점

• 처리량이 높아도 p99 지연 시간과 TTFT가 허용 범위를 벗어나면 운영 용량으로 채택하기 어렵다. 포화 지점과 SLA 충족 지점은 함께 검토할 필요가 있다.
• 동시성 320과 80의 예제 차이는 용량이 모델과 GPU뿐 아니라 서비스가 요구하는 응답성 기준에도 좌우된다는 점을 보여준다.
• 자동 탐색은 시험 범위를 수동으로 정하는 부담을 줄이지만, 단일 SLA 결과 표의 동시성 320 통과·284 실패처럼 해석이 필요한 결과까지 제거해 주는 것은 아니다.

✅ 액션 아이템

• 평균 입력 1,024토큰·출력 256토큰이 실제 워크로드를 대표하는지 검토하고 동시성 스윕의 요청 조건에 반영.
• p99 종단 간 지연 시간 50초와 p95 최초 토큰 도달 시간 1.5초의 적용 필요성을 검토하고, SLA 충족 용량과 피크 트래픽을 기준으로 인스턴스 규모 산정.
• 시험 종료 후 Amazon SageMaker AI 엔드포인트와 관련 엔드포인트 구성·모델을 삭제해 유휴 엔드포인트의 시간당 비용 방지.

❓ 열린 질문

• 평균 입력 1,024토큰·출력 256토큰은 실제 서비스의 워크로드 특성을 얼마나 잘 대표하는가?
• 서비스에 필요한 SLA는 p99 종단 간 지연 시간 50초만으로 충분한가, 아니면 p95 최초 토큰 도달 시간 1.5초도 함께 적용해야 하는가?
• 인스턴스별 SLA 충족 용량과 피크 트래픽을 기준으로 필요한 인스턴스 수는 얼마인가?