Nari Labs, Qwen3-TTS를 H100 1장에서 10 RPS·p95 34ms 첫 음성까지 최적화

실시간 음성 앱에서는 TTFA가 제일 중요하다고 봄. 오픈소스 vLLM-Omni나 SGLang-Omni는 프로덕션에 쓰기엔 느리거나 지연을 줄이면 재생이 끊기는 문제가 있었고, 그래서 Qwen3-TTS를 H100 한 장에서 10 RPS, p95 34ms까지 최적화했음.

소비자용 GPU에서는 얼마나 빠른지 궁금함.

Dia 모델은 정말 자연스러웠는데, 이제 Dia 개발보다 호스팅과 인프라 쪽으로 방향을 옮긴 건지 궁금함.

이 수치는 콜드 스타트 기준인지, 캐시가 워밍업된 뒤의 프리필 상태 기준인지 알고 싶음.

ChatGPT는 엄청 빨리 말문을 열지만 'hmm', 'let me think' 같은 필러를 먼저 내보내고 실제 답은 나중에 하는 느낌임.

그래도 ChatGPT가 노리는 지연은 30ms가 아니라 300ms 정도 아닌가? 'hmm'을 답변으로 세면 안 되고 첫 의미 있는 음소까지 재야 한다고 봄.

GPT-Realtime-2는 양방향이라 그런지 어색한 순간에 필러를 너무 빨리 내고 지나치게 끼어듦. 이런 식의 지연 최적화에 더 투자할 여지가 있었던 것 같음.

1년째 로컬 음성 에이전트를 만들면서 Omni Voice를 몇 달간 튜닝했는데, 24 step에서 200ms TTFA보다 빨라지지 않았음. 속도를 밀면 음성 품질, 억양, 표현력이 떨어지는 벽이 있어서 이 구현도 원본 Qwen과 품질이 같은지 직접 들어보고 싶음.

원본 Qwen 구현과 계속 출력 비교를 했고 품질 차이는 보지 못했음. 써보고 결과를 알려주면 좋겠음.

음성 비서는 결국 H100 서버가 아니라 휴대폰에서 아주 싸게 돌아가야 한다고 봄. Pocket TTS는 빠르고, Mac이나 PC에서는 Chatterbox와 Fish Audio S2 Pro도 품질이 좋지만 모바일 실행까지는 아직 거리가 있음.

모바일은 시험하지 않았지만 배치 1, 동시성 1에 맞추면 꽤 빨라질 가능성은 있어 보임. 모바일 하드웨어 전용 최적화가 중요할 텐데 그 분야 전문가는 아님.

에이전트에서는 LLM이 음성 토큰을 직접 만들지 않는 한 TTS 전에 LLM 추론 지연을 잃게 됨. 사람과 자연스럽게 대화하려면 전체 TTS-STT 왕복이 50ms에 가까워야 하고, 현실적인 목표는 150ms 이하라고 봄.

Qwen3-TTS에는 LLM 출력을 음성 모델로 흘려보내는 입력 스트리밍 모드가 있음. 전체 문장을 기다릴 필요 없고, 구현한 WebSocket 방식도 50ms 미만이지만 LLM의 TTFT는 여전히 큰 문제임.

너무 빠르면 오히려 어색할 수 있음. 사람은 들은 말을 처리하는 데 약 200ms가 걸리므로 100ms 안에 답하면 방금 말한 부분이 아니라 이전 발화에 반응한 것처럼 들리고, 문장 중간 끼어들기는 뜻을 바꿔버릴 수도 있음.

데모 영상이 없나? Runpod나 Modal에서 Docker로 바로 띄워 시험해볼 수 있다고 하지만, 실제 동작을 보여주는 영상이 있으면 좋겠음.

Cloudflare AI Workers 같은 환경에 올릴 계획이 있는지 궁금함. 직접 써보고 싶음.