실시간 음성 통화 GPU 서빙: 노드당 동시 통화 1→4, 통화당 원가 −69%
GPU 노드 한 대가 통화 1건밖에 못 받던 병목을 실측으로 찾아 TTS 엔진 다중화와 다중 웨이트 상주로 풀고, 24/7 가동을 요청 시 기동으로 바꿨다.
- 역할
- MLOps · GPU 서빙 설계와 실측 · 비용 통제
- 기술
- Python (TTS · Whisper STT 서빙) · NVIDIA L4 (AWS g6) · nginx least_conn · AWS Lambda · EventBridge · CloudWatch · Budgets · Terraform (별도 루트 · VPC peering) · SSM 램프 스크립트 · k6
- 1→4
- GPU 노드당 품질 유지 동시 통화
- −69%
- 5분 통화당 GPU 원가 ($0.097 → $0.030)
- 4.3~6.0 → 1.4~2.7초
- TTS 요청당 벽시계 시간
- 약 1/5
- GPU 노드 월 비용 (24/7 → 요청 시 기동, 추정)
캐릭터와 실시간으로 통화하는 기능의 GPU 노드 한 대가 품질을 지키며 받는 동시 통화는 1건이었고, GPU 사용률은 20%를 넘지 않았습니다. 램프 스크립트로 통화 원가와 용량을 실측해 TTS 서버의 전역 락이 원인임을 찾고, 엔진 다중화와 다중 웨이트 상주로 노드당 4통화까지 끌어올렸습니다. 스테이징 노드의 24/7 가동은 요청 로그 기반 수요 기동으로 바꿨습니다.
상황
실시간 음성 통화는 STT, LLM, TTS가 한 턴 안에 이어지는 파이프라인이고, 지연 예산은 수백 ms입니다. 처음 실측에서 통화 1건 원가의 70~90%가 GPU(TTS)였고, 노드 1대가 품질을 지키며 받는 동시 통화는 1건, TTS 첫 바이트는 약 1초로 예산을 크게 넘었습니다. 부하가 꽉 차도 GPU 사용률은 20% 이하였습니다.
한편 스테이징 GPU 노드는 24시간 떠 있어 월 AWS 청구의 절반 가까이를 혼자 차지하고 있었습니다.
한 일
- 01
원가·용량 실측 체계
SSM으로 돌리는 표준 라이브러리 기반 통화 램프 스크립트와 LLM usage 로그 계측을 만들어 통화 1건의 원가(5분·20분), 노드당 동시 통화 수, 첫 바이트 지연, GPU 사용률을 같은 조건에서 반복 측정할 수 있게 했습니다. 모든 결정은 이 숫자 위에서 내렸습니다.
- 02
병목 규명과 엔진 다중화
TTS 서버가 합성을 전역 락으로 직렬 처리하는 것이 원인이었습니다. 엔진 하나가 호스트 RAM 6.6GB를 쓰는 점을 감안해 메모리 여유가 있는 인스턴스로 옮기고 노드당 엔진 3개를 nginx least_conn 뒤에 세웠습니다. 단일 캐릭터 기준 4통화까지 끊김 0, GPU p95 사용률 99%로 노드를 꽉 채우게 됐습니다.
- 03
다중 웨이트 상주
캐릭터가 섞이면 2통화부터 끊김 21%, 첫 바이트 2.2~2.5초로 무너졌습니다. 원인은 요청마다 1.2초씩 걸리는 웨이트 교체였고, TTS 서버에 다중 웨이트 상주를 직접 구현해 요청당 벽시계 시간을 4.3~6.0초에서 1.4~2.7초로, 디스크 로드를 16회에서 0회로 줄였습니다. 재측정에서 혼합 캐릭터도 4통화 끊김 0, 첫 바이트 p50 1.09초였습니다.
- 04
요청 시 기동과 비용 가드
요청 로그 기반 Lambda 기동과 30분 idle 정지로 24/7 가동을 끝냈습니다. CloudWatch 알람의 EC2 stop 액션이 재발동하지 않는 결함을 발견해 5분 EventBridge 요청 수 점검으로 교체했고, 앱 진입 시 미리 깨우기로 부팅을 통째로 기다리는 통화를 절반 이하로 줄였습니다. GPU 월 예산 알람과 하루 가동 20시간 초과 알람을 두었고, 보이스 노드는 별도 Terraform 루트(자체 VPC, staging/prod peering)로 분리했습니다.
- 05
부팅 시간과 운영 선택지
루트 디스크 처리량을 올려(gp3 125 → 250MB/s, 3000 → 4000 IOPS, 월 +$12) TTS ready를 55초에서 44초로, 병렬 읽기를 125 → 285MB/s로 개선했습니다. 연결 전 음성 서빙 ready 대기(기본 90초)를 넣고, 요청 시 기동·16시간·24시간 세 운영안의 월 비용 비교표를 팀 결정 자료로 남겼습니다.
- 06
STT 서빙과 LLM 비용 지표
Whisper STT 서빙 서버를 세워 L4 GPU 벤치로 노드당 동시 통화 용량과 원가를 실측했고, LLM 턴당 비용을 지표로 계량해 일일 예산이 몇 턴에 해당하는지 바로 읽히게 했습니다. 외부 LLM 추론 지역 고정과 호출 차단 게이트도 같이 걸었습니다.
결과
- GPU 노드당 품질 유지 동시 통화 1건 → 4건(재측정 기준), 5분 통화당 GPU 원가 $0.097 → $0.030.
- TTS 요청당 벽시계 시간 4.3~6.0초 → 1.4~2.7초, 혼합 캐릭터 첫 바이트 p50 1.09초.
- 스테이징 GPU 노드 24/7 가동을 요청 시 기동으로 전환, 월 비용 약 1/5 수준으로 추정. 부팅 ready 55 → 44초.
- 통화 원가·용량 램프 측정 체계, GPU 예산·가동시간 알람, 운영안 비용 비교표.
정직하게 적어 두는 것
- 모든 측정값은 스테이징 단일 노드, 특정 시점 조건입니다. 회사 청구 절대액은 적지 않고 비율만 적었습니다.
- 제품명·모델명·벤더명은 익명화했습니다.