300ms 미만의 스트리밍 TTS: 지연 시간을 유발한 6가지 실수와 해결 방법

1만 명의 시청자가 참여한 웨비나에서 저희의 라이브 자막 봇이 농담의 핵심을 놓쳤을 때, TTS 세그먼트는 텍스트 수신부터 가청 출력까지 487ms가 소요되었고, 청중은 웃음소리가 나온 뒤에야 농담을 들을 수 있었습니다.

실수 #1: 일반적인 CPU 인스턴스에서 TTS 모델 실행

CPU 지연 시간이 급증하는 이유

CPU 전용 노드는 서류상으로는 저렴해 보이지만, 현대적인 TTS 아키텍처를 가속화하는 텐서 코어(Tensor Cores)가 유휴 상태로 방치됩니다. 저희 모델(WaveRNN 보코더(Vocoder)를 사용하는 Tacotron-2 스타일의 인코더-디코더(Encoder-Decoder))은 시간의 70%를 행렬 곱셈(Matrix Multiplies)이 끝나기를 기다리는 데 소비합니다. 그 결과, 300ms 미만의 예산을 초과하게 만드는 길고 예측 불가능한 꼬리 지연(Tail Latency)이 발생합니다.

GPU 최적화 노드로 전환

저희는 m5.large(2 vCPU, 8 GiB)를 NVIDIA T4가 장착된 단일 GPU p3.xlarge로 교체했습니다. 동일한 발화(“Welcome”)의 처리 시간이 312ms에서 84ms로 줄어들었으며, 이는 62%의 감소를 의미합니다. 또한 GPU는 90%의 안정적인 사용률 상한선을 제공하여 지연 시간 변동(Latency Variance)을 5ms 미만으로 유지해 주었습니다.

데이터 포인트 – CPU 전용 배포 시 발화당 평균 312ms 소요 vs 단일 T4 GPU 사용 시 84ms (62% 감소)

예시

m5.large EC2에서의 초기 데모에서는 “Welcome”을 합성하는 데 312ms가 걸려 음성 비서 데모에서 눈에 띄는 지연이 발생했습니다. GPU로 이동한 후에는 비서가 즉각적으로 응답했으며, UI는 5초의 상호작용 창 내에서 사용자 테스트를 통과할 수 있을 만큼 빠릿하게 느껴졌습니다.

실수 #2: 청크(Chunk) 스트리밍 대신 단일(Monolithic) gRPC 호출 사용

전체 메시지 버퍼링의 비용

단일(Unary) RPC는 서버가 아무것도 반환하기 전에 전체 오디오 페이로드(Payload)를 버퍼링하도록 강제합니다. 24kbps 속도의 2초 길이 발화의 경우, 클라이언트가 대기하는 동안 약 6KB의 데이터가 메모리에 머물게 되며, 이는 추론 시간(Inference Time)에 네트워크 왕복 시간(RTT)을 추가로 더하게 됩니다.

서버 측 스트리밍(Server-side Streaming) 활성화

서비스 정의를 stream AudioChunk를 반환하도록 다시 작성했습니다. 이제 클라이언트는 각 20ms 프레임이 생성되는 즉시 이를 소비합니다. 이를 통해 종단 간 지연 시간(End-to-end latency)을 187ms에서 98ms로 단축했으며, 이는 약 48%의 개선을 의미합니다. 또한 버퍼링으로 인한 롱 테일(Long tail) 현상이 사라지면서 지연 시간 분포가 평탄해졌습니다. 이 주제에 대한 배경 지식을 위해, 공개된 데이터가 이를 뒷받침합니다.

데이터 포인트 – 서버 측 스트리밍(Server-side streaming)으로 전환하여 종단 간 지연 시간을 187ms에서 98ms로 단축 (약 48% 개선)

예시

실시간 내비게이션 데모 중에 운전자는 단일 RPC(Unary RPC)를 사용할 때의 187ms와 달리, 명령이 생성된 후 98ms 만에 "좌회전하세요"라는 음성을 들었습니다. 소음이 심한 도로에서는 그 차이가 확연했습니다. 더 빠른 신호가 운전자에게 더 많은 반응 시간을 제공했습니다.

실수 #3: 오디오 프레임의 최적 청크 크기(Chunk size) 무시

청크 크기 vs 네트워크 RTT

프레임이 너무 크면 다음 패킷을 기다리는 동안 지연 시간 예산(Latency budget)을 낭비하게 됩니다. 반대로 너무 작으면 초당 패킷 수(Packet-per-second) 오버헤드가 증가하고 OS 스케줄링(OS scheduling)으로 인한 지터(Jitter) 위험이 커집니다. 당사의 클라우드-엣지(Cloud-to-edge) RTT를 측정한 결과 약 12ms였으므로, 50ms 프레임은 과도했습니다.

20ms 프레임에서의 경험적 최적점(Sweet spot)

10ms에서 60ms까지 스윕(Sweep) 테스트를 수행한 결과, 20ms 프레임이 가장 낮은 지터와 가장 작은 평균 지연 시간을 제공한다는 것을 발견했습니다. 지터는 20ms(기본 50ms 프레임)에서 6ms로 감소하여, 14ms의 개선을 이루었습니다.

데이터 포인트 – 20ms 프레임은 기본 50ms 프레임보다 14ms 낮은 지터를 기록함 (평균 지터 6ms vs 20ms)

예시

라이브 채팅 번역 파이프라인에서 20ms 프레임은 50ms 프레임에서 발생하던 음성 겹침 아티팩트(Overlapping speech artifacts)를 방지했습니다. 번역된 오디오는 깔끔하게 들렸고, 사용자들은 "로봇 같은 멈춤"에 대한 불만을 제기하지 않게 되었습니다.

실수 #4: 모델을 실시간 우선순위 큐(Real-time priority queue)에 고정하지 않음

OS 스케줄링의 영향

Linux의 기본 CFS 스케줄러(CFS scheduler)는 추론(inference) 프로세스를 다른 CPU 집약적(CPU-bound) 작업과 동일하게 취급합니다. 시스템에 부하가 걸리면 스케줄러가 모델을 몇 밀리초 동안 선점(pre-empt)할 수 있으며, 이는 꼬리 지연 시간(tail latency)을 증가시킵니다.

Linux에서 nice/rtprio 사용하기

우리는 추론 바이너리에 nice -n -20 및 chrt -f 99를 설정하여 이를 실시간 FIFO 큐(real-time FIFO queue)로 강제 전환했습니다. 그 결과 95백분위수(95th-percentile) 지연 시간이 135ms에서 71ms로 감소하여, 47%의 절감 효과를 거두었습니다. 평균 지연 시간은 동일하게 유지되었으나, 최악의 경우 발생하는 지터(jitter)가 사라졌습니다.

데이터 포인트 – 실시간 우선순위(sched_rt) 설정으로 꼬리 지연 시간(tail latency)이 135ms(95백분위수)에서 71ms(95백분위수)로 감소했습니다.

사례

한 콜센터 QA 도구에 추론 프로세스에 대한 rtprio를 적용한 결과, 가장 긴 일시 정지 시간이 135ms에서 71ms로 줄어들었습니다. 상담원들은 더 부드러운 경험을 보고했으며, 해당 도구의 SLA(150ms 미만 응답)를 마침내 충족했습니다.

실수 #5: 대역폭 절약을 위해 오디오 스트림을 과도하게 압축함

비트레이트(Bitrate) vs 디코딩 지연(decoding delay)

우리는 Opus 24kbps에서 MP3 16kbps로 전환하여 대역폭을 줄이려 시도했습니다. 저비트레이트 MP3의 디코더는 약 27ms의 추가 지연 시간을 발생시켰고, MOS(Mean Opinion Score)를 4.3에서 3.7로 떨어뜨렸습니다. Opus는 24kbps에서도 약 3ms 내에 디코딩되며 높은 지각 품질(perceptual quality)을 유지합니다.

16kbps MP3 대신 24kbps Opus 선택

Opus로 전환함으로써 스트림을 30kbps 미만으로 유지하면서도 무시할 수 있는 수준의 디코딩 지연 시간만을 추가했습니다. MOS는 4.3을 유지하여 대화형 UI(conversational UI)의 "수용 가능한" 임계값을 훨씬 상회했습니다.

데이터 포인트 – 24kbps Opus는 MOS 4.3을 유지하면서 디코딩 지연 시간을 3ms만 추가한 반면, 16kbps MP3는 27ms를 추가하고 MOS를 3.7로 떨어뜨렸습니다.

사례

우리의 차량용 인포테인먼트(in-car infotainment) 프로토타입은 Opus로 전환하였고, 사용자들은 3G 연결 환경에서도 "즉각적인" 응답을 경험한다고 보고했습니다. 시스템은 통신사의 30kbps 스로틀링(throttling) 제한 미만으로 유지되었으며, 오디오는 자연스럽게 들렸습니다. 자세한 내용은 Opus 사양(spec)을 참조하십시오.

실수 #6: 각 컨테이너 시작 시 모델 웜업(warm-up)을 잊음

콜드 스타트(Cold-start) 페널티

새로운 Pod가 생성될 때, GPU 메모리는 비어 있고, JIT 컴파일러(JIT compiler)는 커널(kernel)을 캐싱하지 않은 상태이며, 첫 번째 추론(inference)은 전체 로드 비용을 지불해야 합니다. 우리는 정상 상태(steady-state)보다 한 자릿수 더 높은 642ms의 첫 발화 지연 시간(first-utterance latency)을 측정했습니다.

GPU 캐시를 미리 채우는 웜업(Warm-up) 스크립트

더미 합성(dummy synthesis)을 실행하는 5초짜리 엔트리포인트(entrypoint) 스크립트를 추가하여 "웜업(warm up)"을 수행함으로써, CUDA 캐시를 준비하고 모델 가중치(model weights)를 GPU RAM에 로드하며 커널 컴파일(kernel compilation)을 트리거했습니다. 그 결과, 첫 발화 지연 시간은 112ms로 급감했으며, 이는 약 82%의 감소를 의미합니다.

데이터 포인트 – 웜업을 통해 첫 발화 지연 시간이 642ms에서 112ms로 감소함 (약 82% 감소)

예시

Docker 엔트리포인트에 웜업 스크립트를 추가한 후, 새로운 Pod에서의 첫 번째 TTS 호출은 정상 상태의 지연 시간과 일치했습니다. 이 변경을 통해 voice platform 운영 중 오토스케일링(autoscaling) 이벤트가 발생할 때 간헐적으로 나타나던 "헐떡임(hiccups)" 현상을 방지할 수 있었습니다.

각 수정 사항 적용 전후의 지연 시간 지표

지표	기준점 (ms)	수정 후 (ms)	Δ%
발화당 CPU 전용 추론 (CPU-only inference)	312	84	-73%
...

결론

모델 배치(model placement), 스트리밍 RPC(streaming RPC), 그리고 오디오 프레이밍(audio framing)을 하드웨어의 실시간 프로필(real-time profile)에 맞춘다면, 스트림당 대역폭을 30kbps 미만으로 유지하면서 단일 GPU 노드에서 안정적으로 300ms 미만의 지연 시간을 달성할 수 있습니다.