Qwen3-TTS 50ms 미만 지연을 위한 속도 및 비용 최적화

Nari Labs는 단일 NVIDIA H100 SXM에서 초당 10건의 요청(RPS)을 실시간 재생하며 p95 시간-첫음성-전달(TTFA)이 50밀리초 미만인 Qwen3-TTS 1.7B CustomVoice 모델의 커스텀 구현체를 개발했습니다. 이 최적화는 고성능 음성 합성의 비용을 크게 줄였으며, 최대 활용 시 약 100만 자당 2달러의 비용을 추정합니다.

실시간 TTS 성능 벤치마킹

실시간 사용 가능성을 평가하기 위해 Nari Labs는 성공적인 TTS 서버를 네 가지 기준으로 정의합니다: 청각적으로 낮은 TTFA, 오디오 언더런(클라이언트가 버퍼링된 오디오를 소진하는 현상) 없음, RPS 증가에 따라 높은 처리 용량, 그리고 이해 가능한 출력.

vLLM-Omni, SGLang-Omni, VoxServe, M*를 포함한 다섯 가지 구현체를 비교한 벤치마크에서, Nari Labs의 구현체만이 10 RPS까지 50밀리초 미만의 p95 TTFA를 유지했습니다. 다른 엔진들 중 VoxServe는 1 RPS에서는 50밀리초 미만을 달성할 수 있었지만, 부하가 증가함에 따라 지연이 크게 증가했습니다. 예를 들어 6 RPS에서 대부분의 엔진이 100밀리초 이상의 p95 TTFA를 기록했습니다.

일반적인 지연 장애 요인 해결

모든 테스트 엔진에 공통적으로 적용된 두 가지 주요 최적화는 공정한 기준을 확보하기 위함이었습니다:

초기 침묵 제거: 모델은 종종 첫 소리 전에 수십 밀리초의 침묵을 생성합니다. Nari Labs는 RMS 윈도우를 통해 지속적인 발화를 감지하고 초기 침묵을 동적으로 제거하는 기능을 구현하여 TTFA를 약 80밀리초 개선했습니다.
프레임 누적 조정: 디코딩 전에 수집하는 코덱 프레임 수를 균형 잡습니다. 작은 초기 청크는 TTFA를 줄이지만 디코더 오버헤드를 증가시키고, 큰 청크는 배치 처리와 재생 안정성을 향상시킵니다. 최적의 구성은 초기에 작은 청크를 사용하고 이후 출력에서는 크기를 점진적으로 증가시킵니다.

Qwen3-TTS를 위한 아키텍처 최적화

Qwen3-TTS는 세 가지 모듈을 포함하는 계층적 다중 코드북 생성 프로세스를 사용합니다: Talker(첫 번째 코드북 토큰 예측), Code Predictor(남은 15개 토큰 생성), Codec(토큰을 웨이브폼으로 변환).

통합 스케줄링 표면

생성과 디코딩을 두 단계로 나누는 대신, Nari Labs는 Talker, Code Predictor, Codec를 하나의 스케줄러 아래에서 독립적으로 스케줄링 가능한 세 가지 작업으로 간주합니다. 이로 인해 시스템은 긴급도에 따라 작업을 재배치할 수 있으며, 예를 들어 재생 마감일에 가까운 Codec 작업을 Talker 작업보다 우선시할 수 있고, 동일한 모듈을 기다리는 요청들에 대해 더 세밀한 배치 처리가 가능해집니다.

긴급도 기반 스케줄링

스케줄러는 두 가지 유형의 긴급도를 구분합니다:

초기 지연: 아직 첫 오디오 청크를 생성하지 않은 요청은 TTFA를 최소화하기 위해 최고 우선순위를 부여합니다.
재생 마감일: 재생이 시작된 후에는 오디오 언더런을 방지하기 위해 마감일에 가까워지는 청크만 우선순위를 부여합니다.

GPU 효율성을 유지하기 위해 스케줄러는 긴급 요청을 "앵커"로 선택하고, 나머지 배치는 호환되며 비긴급 작업으로 채웁니다.

Code Predictor 및 Codec 개선

CUDA 그래프 및 Triton 커널: Code Predictor는 프레임당 고정된 15단계를 수행하므로, Nari Labs는 전체 루프를 하나의 CUDA 그래프로 캡처하고 짧은 컨텍스트에 특화된 Triton 어텐션 커널을 활용하여 호스트 기반 오버헤드를 줄였습니다.
상태 캐시 기반 증분 디코딩: 매번 새로운 청크를 처리할 때 전체 프레임 기록을 다시 처리하지 않기 위해 Codec은 Transformer 컨텍스트와 컨볼루션 상태를 캐시합니다. 첫 오디오 청크는 초기화 오버헤드를 최소화하기 위해 전체 디코딩을 사용하고, 지속적인 재생에서는 증분 디코딩으로 전환합니다.

산업 관점과 트레이드오프

커뮤니티 논의는 프로덕션 환경에서 초저지연 TTS를 배포할 때 고려해야 할 몇 가지 중요한 사항을 강조합니다:

"무서운" 속도의 계곡: 일부 개발자는 200밀리초 미만의 응답이 자연스럽지 않거나 "무서운" 느낌을 줄 수 있다고 주장합니다. 인간은 일반적으로 200밀리초의 청각 처리 지연을 가지므로, 대화가 인간다운 느낌을 주기 위해 인위적인 지연 또는 가드레일이 필요할 수 있습니다.
품질 vs. 지연: 지연을 더 줄이면 음성의 리듬, 표현력, 전반적인 자연스러움이 훼손될 수 있는 "품질의 경계"가 존재합니다.
온디바이스 요구사항: H100 성능은 인상적이지만, 많은 개발자의 궁극적인 목표는 이러한 기능을 모바일 디바이스로 이동시켜 클라우드 지연을 제거하고 프라이버시를 향상시키는 것입니다.
엔드투엔드 지연: 에이전트 시나리오에서는 TTS 지연이 체인의 일부에 불과합니다. 전체 인식 지연에는 STT(음성-텍스트 변환) 및 LLM 추론이 포함됩니다. 일부는 오직 OpenAI의 GPT-4o/Realtime처럼 음성 토큰을 직접 LLM에 통합하는 모델만이 진정한 엔드투엔드 지연 문제를 해결할 수 있다고 제안합니다.

Nari Labs는 구현체와 벤치마크 테스트 세트를 모두 오픈소스로 공개했습니다.