Reduce ASR inference costs by 75% with NVIDIA MPS on Amazon EC2

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Heidi Health의 음성 인식 사례는 Amazon EC2에서 NVIDIA CUDA MPS와 Triton을 결합해 초당 GPU당 92.1개 요청과 1초 미만 지연시간을 유지하면서 GPU 인프라를 16개에서 4개로 75% 줄이는 구성을 제시한다.

📌 핵심 요약

• Heidi Health는 190개국에서 주당 240만 건 이상의 임상 상담을 처리하며, 기존 구성은 최대 트래픽에서 지연시간 요구를 충족하기 위해 GPU 16개를 사용한다.
• Parakeet TDT 0.6B V2의 단일 요청은 NVIDIA L40S 연산 용량의 약 15~20%만 사용하며, 기본 시간 분할 방식에서는 GPU당 약 62 RPS를 평균 650ms 미만·p99 1,000ms 미만으로 처리한다.
• NVIDIA CUDA MPS는 여러 프로세스의 커널을 동시에 실행하며, 전사에는 프로세스 4개에 각각 SM 25%, 화자 분리에는 프로세스 8개에 각각 SM 12%를 배정하는 별도 구성을 사용한다.
• 연산량이 큰 Conformer 인코더는 ONNX Runtime과 TensorRT로 최적화하고, 가변 길이 토큰을 생성하는 TDT 디코더는 PyTorch CUDA에서 실행한다.
• Triton은 전사에 동적 배칭, 화자 분리에 시퀀스 배칭을 적용하며, 제공된 구현은 단일 통합 컨테이너와 GPU 추론·CPU 게이트웨이를 분리한 컨테이너 배포를 지원한다.

🧩 주요 포인트

1. 낮은 단일 요청 GPU 활용률과 순차 실행 → MPS 동시 실행으로 유휴 연산 자원을 활용하는 것이 인프라 축소의 핵심이다.
2. 인코더와 디코더의 실행 특성 차이 → ONNX Runtime·TensorRT와 PyTorch CUDA를 조합해 연산 최적화와 가변 길이 처리의 유연성을 함께 확보한다.
3. 전사와 화자 분리의 처리 방식 차이 → SM 배정과 Triton 배칭을 작업별로 달리하고, 컨테이너 분리 시 GPU 추론과 CPU 게이트웨이를 독립적으로 확장한다.

🧠 상세 정리

1. 임상 음성 인식의 비용과 지연시간 문제

이 글은 AWS, NVIDIA, Heidi의 협업으로 작성됐으며, 임상 음성 인식을 위한 모델 미세 조정 이후의 효율적인 추론 제공에 초점을 맞춘다. Heidi Health는 190개국에서 주당 240만 건 이상의 임상 상담을 처리하는 서비스로, 최대 트래픽에서도 1초 미만의 전사 지연시간을 유지해야 한다. 기존 환경에서는 요청 하나가 GPU 연산 용량의 일부만 사용하기 때문에 이러한 요구를 충족하려면 GPU 인스턴스 16개가 필요했다. 글은 Amazon EC2에서 NVIDIA CUDA MPS와 Triton을 결합해 필요한 인스턴스를 4개로 줄이는 구성을 제시한다. 제시된 결과는 GPU 인프라 요구량 75% 감소와 GPU당 92.1 RPS이며, 이때도 1초 미만의 지연시간을 유지한다고 설명한다.

2. 낮은 GPU 활용률과 기본 시간 분할의 한계

Parakeet TDT 0.6B V2의 단일 추론 요청은 NVIDIA L40S에 있는 142개 스트리밍 멀티프로세서인 SM의 약 15~20%만 사용한다. 따라서 각 순전파 동안 연산 자원의 약 80%가 사용되지 않는다고 원문은 설명한다. 여기에 CUDA의 기본 시간 분할 방식이 적용되면 프로세스들이 GPU를 번갈아 독점하며, 프로세스 전환에 따른 추가 비용도 발생한다. 이 구성에서 GPU 한 개의 처리량은 평균 지연시간 650ms 미만과 p99 지연시간 1,000ms 미만을 만족하는 조건에서 약 62 RPS다. Heidi의 기존 운영 환경은 최대 트래픽과 지연시간 서비스 수준 약정에 필요한 여유 용량을 확보하기 위해 GPU 16개를 사용하며, 글은 이 활용률 격차를 해결할 공유 방식들을 비교한다.

3. 시간 분할·MIG·MPS의 차이와 작업별 자원 배정

원문은 GPU 공유 방식을 기본 시간 분할, 물리적으로 자원을 나누는 MIG, 여러 프로세스의 동시 실행을 지원하는 MPS로 구분한다. 시간 분할은 순차 실행 방식이고, MIG는 전용 메모리 컨트롤러를 갖는 고정 물리 파티션을 제공하며, MPS는 공유 컨텍스트와 유연한 SM 제한을 사용한다. MPS는 데몬이 관리하는 단일 GPU 컨텍스트로 CUDA 작업을 모아 컨텍스트 전환 비용을 없애고, 서로 다른 프로세스의 커널이 여러 SM에서 동시에 실행되도록 한다. 기존 CUDA 애플리케이션의 코드 변경 없이 사용할 수 있으며, 클라이언트별 주소 공간을 통해 메모리를 보호한다. 전사 전용 인스턴스는 프로세스 4개에 각각 SM 25%와 약 2.5GB의 메모리를 사용하고, 화자 분리 전용 인스턴스는 프로세스 8개에 각각 SM 12%와 약 1.8GB를 사용하는 별도 구성이다.

4. 인코더와 디코더를 나눈 모델 최적화

MPS가 GPU의 유휴 연산 자원을 활용하는 역할이라면, 모델 수준 최적화는 개별 요청에 필요한 연산 시간을 줄이는 역할을 맡는다. ONNX Runtime은 하드웨어별 실행 공급자를 통해 ONNX 모델을 실행하며, TensorRT 실행 공급자는 그래프 노드를 TensorRT로 보내 커널 융합과 정밀도 조정, 메모리 최적화를 적용한다. 이 사례의 Conformer 인코더는 24개 계층과 1024차원 은닉 표현을 갖는 연산 집약적인 부분으로, ONNX Runtime과 TensorRT 실행 공급자에서 연산자 융합과 FP16 최적화를 활용한다. 반면 RNN-T 계열의 TDT 디코더는 PyTorch CUDA에서 기본 방식으로 실행한다. 원문은 가변 길이 토큰 생성과 CUDA 그래프 캐싱을 처리할 때 정적인 TensorRT 엔진보다 이 방식이 유연하다는 점을 혼합 구성의 이유로 설명한다.

5. Triton의 전사 배칭과 화자 분리 상태 관리

NVIDIA Triton Inference Server는 운영 환경에서 요청 스케줄링과 배칭을 담당하며, 전사와 화자 분리에 서로 다른 전략을 사용한다. 전사는 동적 배칭으로 요청을 설정된 대기시간인 50ms 동안 모은 뒤 묶어서 실행하고, 선호 배치 크기는 4·8·16으로 지정한다. 화자 분리는 시퀀스 배칭으로 녹음별 스트리밍 상태를 서버에 유지하며, 클라이언트는 상관관계 식별자와 함께 15초 길이의 오디오 조각을 보낸다. Triton은 이 식별자를 바탕으로 요청을 해당 모델 인스턴스에 전달하고, 600초 동안 활동이 없는 세션은 자동으로 만료시킨다. 각 Triton 모델 인스턴스는 하나의 MPS 자원 배정 단위에 대응하므로, 요청을 묶고 배분하는 계층과 GPU에서 동시 실행을 관리하는 계층이 연결된다.

6. Amazon EC2의 추론 파이프라인과 지원 서비스

원문은 Amazon EC2의 g6e.4xlarge와 g7e.4xlarge를 배포 대상으로 제시하고, 추론 파이프라인을 FastAPI 게이트웨이, Triton, CUDA MPS 데몬의 세 계층으로 설명한다. 게이트웨이는 OpenAI Whisper 호환 REST API를 제공하며 업로드된 오디오를 16kHz 모노 float32 텐서로 변환한 뒤 gRPC로 Triton에 전달하고, 포트 8002에서 uvicorn 작업자 4개로 실행된다. Triton은 요청 배칭과 모델 인스턴스 배분을 맡으며, MPS 데몬은 Triton 컨테이너 내부에서 추론 서버보다 먼저 시작된다. 지원 서비스로는 컨테이너 이미지를 저장하는 Amazon ECR, 모델 체크포인트와 TensorRT 엔진 캐시 및 ONNX 내보내기 파일을 보관하는 Amazon EBS가 제시된다. Amazon CloudWatch는 지표 수집과 로그 집계 및 지연시간 관측을 담당하고, Amazon S3는 모델 산출물과 체크포인트의 보관에 사용된다.

7. 배포 전제조건과 저장소의 구성

배포 전제조건에는 대상 Amazon EC2 인스턴스를 사용할 수 있는 AWS 계정, NVIDIA 드라이버 535 이상, CUDA 12.x, NVIDIA Container Toolkit을 갖춘 Docker가 포함된다. 모델 준비에는 NVIDIA NeMo Toolkit 2.7 이상과 .nemo 형식의 Parakeet TDT 0.6B V2 체크포인트가 필요하며, 오디오 디코딩에는 torchcodec, 게이트웨이와 Triton 통신에는 tritonclient의 gRPC 기능을 사용한다. 함께 제공되는 공개 저장소에는 Dockerfile, Triton 모델 백엔드, FastAPI 게이트웨이와 실행 구성이 들어 있다. 배포 방식은 MPS 데몬과 Triton 및 게이트웨이를 함께 넣는 단일 컨테이너 방식과, Docker Compose로 GPU 추론 컨테이너와 CPU 게이트웨이 컨테이너를 분리하는 방식이다. 분리 배포는 두 계층의 독립적인 확장을 지원하며, auto_config.py는 MPS 인스턴스 수를 Triton 설정으로 연결한다.

8. 컨테이너 빌드와 시작 절차

실행 예시는 미세 조정한 .nemo 체크포인트를 빌드 인자로 전달해 이미지를 만들고, MPS_INSTANCE_COUNT를 4로 설정해 GPU 한 개에서 네 모델 인스턴스를 실행하는 순서다. Dockerfile은 체크포인트를 이미지에 포함하고 빌드 단계에서 로컬 어텐션 최적화를 적용하며, 실행 예시는 공유 메모리 2GB와 포트 8002 매핑을 사용한다. 컨테이너가 시작되면 먼저 CUDA MPS 데몬을 실행하고, auto_config.py가 Triton 인스턴스 수와 SM 비율을 설정한 다음 tritonserver를 시작한다. 컨테이너는 모델 로딩과 상태 감시도 자동으로 처리하며, 일반적으로 시작 후 90~120초에 /health가 200을 반환하면 서비스가 준비된 상태다. 이후 Whisper 호환 전사 경로로 오디오 파일을 전송할 수 있으나, 제공된 본문은 배포 설정용 환경변수를 열거하는 부분에서 끝나므로 그 뒤의 상세 설정이나 추가 실험 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 이 사례의 핵심 병목은 단일 요청이 GPU를 충분히 활용하지 못하는 상황에서 순차 실행이 겹친다는 점이며, 동시 실행은 남는 연산 자원을 처리량으로 전환하는 수단이다.
• MPS의 자원 공유, TensorRT의 모델 연산 최적화, Triton의 요청 배칭은 각각 다른 계층을 개선하므로 전체 결과를 이해할 때 세 역할을 함께 살펴볼 필요가 있다.
• 전사와 화자 분리에 서로 다른 SM 비율과 배칭 방식을 적용한 구성은 요청의 연산 특성과 상태 유지 요구가 자원 배정 방식에 연결됨을 보여준다.

✅ 액션 아이템

• Parakeet TDT 0.6B V2의 GPU 활용률과 처리량을 약 15~20% 활용률·약 62 RPS·평균 650ms 미만·p99 1,000ms 미만의 기준과 비교 검토.
• 전사에는 SM 25%씩 프로세스 4개, 화자 분리에는 SM 12%씩 프로세스 8개를 사용하는 NVIDIA CUDA MPS 구성의 적용 가능성 검토.
• ONNX Runtime·TensorRT와 PyTorch CUDA의 역할 분담 및 GPU 추론·CPU 게이트웨이의 독립 확장 필요성을 기준으로 배포 방식 검토.

❓ 열린 질문

• GPU당 92.1 RPS와 1초 미만 지연시간을 함께 유지한 요청 조건은 무엇인가?
• 기존 GPU당 약 62 RPS와 개선 후 92.1 RPS의 처리량 차이는 GPU 16개에서 4개로의 축소와 어떻게 연결되는가?
• 전사와 화자 분리에 각각 SM 25%와 SM 12%를 배정한 기준은 무엇인가?