먼저 결론부터 말씀드립니다. 음성 AI 지연 시간의 내역은 Whisper(STT) = 전체의 1할, LLM 추론 = 7할, TTS = 2할이었습니다. 저는 Whisper large-v3 turbo + GPT-4o(via API) + ElevenLabs Flash v2.5의 3단계 파이프라인을 사용하여, 발화 종료부터 음성 응답 시작까지(소위 end of speech → start of audio)를 발화마다 로그를 남겨 100회 측정했습니다. 중앙값 기준으로 Whisper 138ms, LLM 941ms, TTS 285ms, 합계 1,364ms였습니다. "TTS를 빠르게 하면 음성 AI가 빨라진다"라는 직관은 실측 결과 오류였습니다. 전체의 7할은 LLM이며, TTS를 절반으로 줄여도 총 지연 시간은 10%밖에 단축되지 않습니다.

과거에 Voice AI 관련하여 "음성 AI에 '300ms의 벽'이 있는 이유", "음성 AI의 '3가지 절벽' 300ms·500ms·800ms", "CPU만으로 음성 AI 에이전트를 구동할 수 있는가"라는 3편의 글을 썼습니다. 이 기사는 그것들과는 별개의 축으로, 지연 시간 내역의 정량적 분해에 초점을 맞춥니다.

동일 장르이므로 먼저 선을 긋겠습니다.

• 음성 AI에 '300ms의 벽'이 있는 이유와, 에지(Edge)+클라우드(Cloud)로 돌파한 구현: 왜 300ms인가, 어떻게 돌파하는가
• 음성 AI의 '3가지 절벽' 300ms·500ms·800ms에서 UX가 무너지는 이유: UX 임계값의 심리
• CPU만으로 음성 AI 에이전트를 구동할 수 있는가: CPU-only 구성의 가부

본 기사: 발화 종료부터 음성 응답 시작까지를 Whisper/LLM/TTS의 3단계로 나누어 실측하여, 지배적인 성분을 수치로 제시

"TTS를 ElevenLabs Flash로 바꾸면 더 빨라질 것이다"라는 가설을 가지고 시작했으나, 실측 결과 LLM이 7할을 차지하고 있어 계획이 바뀌었다는 개인적인 경험을 바탕으로 하고 있습니다.

재현 가능하도록 작성하겠습니다.

측정 방법은 다음과 같습니다.

import time
async def run_one():
t0 = time.perf_counter()
...

VAD(발화 종료 감지) 임계값이나 클라이언트 측의 버퍼링(Buffering)은 포함하지 않았습니다(이를 포함하면 재현성이 떨어지기 때문입니다). 네트워크 RTT는 포함했습니다(실제 운용에서는 오히려 이것이 본체입니다).

100회 측정의 통계치입니다. 밀리초(ms), 중앙값 및 95 퍼센타일(p95).

내역을 보고 저는 솔직히 놀랐습니다. 구현 전의 가설은 "TTS가 절반, LLM이 3분의 1"이었으나, 실제로는 그 반대에 가까웠으며 LLM이 7할이었습니다.

그 이유는 뒷부분에서 분해하겠습니다. 우선 '체감'으로 나타내면 다음과 같습니다.

• 사용자가 말을 끝낸 후, AI 음성의 첫 소리가 나기까지
  1.4초 - Nielsen의 "반응 시간의 3가지 임계값"으로 말하자면, 1~10초 대(주의 유지 한계의 안쪽)
• 전화 너머의 대화 허용 지연 시간은 600-700ms(ITU G.114)입니다. 여기에는
  도달하지 못했습니다

LLM의 941ms는 거의 전부가 TTFT(Time To First Token)입니다. GPT-4o의 경우 내역은 다음과 같습니다.

요청 전송 + 수신까지의 RTT: 도쿄 $\rightarrow$ 미국 리전 왕복 130ms -
큐잉 (Queuing): p50 기준 40-80ms (혼잡도에 따라 다름) -
프롬프트 프리필 (Prompt Prefill): 시스템 256 + 사용자 30 $\approx$ 286 토큰, GPT-4o의 프리필 처리량(Throughput) 기준 약 2000 tok/s $\rightarrow$ 143ms -
첫 번째 1토큰 생성: 25-40ms

큐잉과 RTT를 합치면 170-210ms, 프리필이 143ms, 생성이 15ms로, 최속이라 해도 350ms 정도입니다. 실측 p50 = 941ms와의 차이인 590ms는 리전 혼잡, 큐 시간, 네트워크의 변동성(Jitter), 트래픽 셰이핑(Traffic Shaping)으로 거의 설명이 가능합니다.

LLM을 빠르게 만들고 싶다면 다음과 같은 방법이 효과적입니다.

프롬프트 단축: 시스템 프롬프트를 256에서 128로 줄이면 TTFT (Time To First Token)가 10% 미만 단축
프롬프트 캐싱 (Prompt Caching): 동일한 시스템 프롬프트를 재사용하여 캐시 히트 (Cache Hit)를 유도하면 TTFT가 40-60% 단축 (Anthropic API의 경우 최대 90% 할인 + 프리필 (Prefill) 단축)
리전 (Region)을 사용자에게 밀착: OpenAI의 도쿄 리전 이용이 가능한 조직은 여기서 약 100ms 정도 단축 가능
소형 모델로 전환: GPT-4o-mini를 사용하면 TTFT가 절반 정도로 감소 (응답 품질은 검증 필요)

ElevenLabs Flash v2.5는 "시간축으로 흘려보내기 시작할 때까지"의 설계가 철저하게 이루어져 있습니다. 실측치 285ms의 내역은 다음과 같습니다.

• 요청 전송 + 큐잉 (Queuing): 40-70ms
• 텍스트의 발음 기호화 및 첫 음소 합성: 100-150ms
• 첫 오디오 청크 (보통 20-20ms 분량) 수신: 60-100ms

Cartesia Sonic Turbo의 경우, 공칭 40ms의 Time-to-first-audio를 제공합니다. 실측에서도 60-90ms 대에 진입합니다 (모델 자체는 미국 리전이지만 지연 시간이 짧음). TTS 세계에서는 2024~2026년 사이 2년 동안 스트리밍 초기 구동 속도가 5배 이상 빨라졌으며, "TTS가 지연의 주원인"이었던 시대는 이미 지났습니다.

TTS는 스트리밍 설계에 따라 네트워크 RTT (Round-Trip Time) 이하의 Time-to-first-audio도 가능합니다. 2026년 시점에서 ElevenLabs, Cartesia, Deepgram Aura의 3사는 sub-100ms 대에 도달해 있습니다. TTS를 2배 빠르게 해도 총 지연 시간의 10%밖에 줄어들지 않는다는 사실은, 실측을 거치지 않으면 직관에 반하는 결과입니다.

Whisper의 138ms는 정확히 말하면 STT (Speech-to-Text)의 "음성 전송 완료 → 텍스트 수신" 시간입니다. 내역은 다음과 같습니다.

• WebSocket으로 음성 청크를 전송하고 확정된 전사 (Transcription)를 받기까지: 80-120ms
• 네트워크 RTT: 10-20ms

Whisper large-v3-turbo는 Whisper large-v3보다 8배 빠릅니다 (파라미터를 32층에서 4층으로 축소, WER (Word Error Rate)은 0.5-1.0 악화). 스트리밍 용도로는 ElevenLabs Scribe v2 Realtime이 sub-150ms, Deepgram Nova-3가 sub-300ms를 공칭하고 있습니다. 실측에서도 대체로 사양대로 동작합니다.

여기서 주의해야 할 점은 "음성 전송 완료"의 판정 타이밍입니다. VAD (Voice Activity Detection)가 "발화가 끝났다"라고 판단한 후 STT를 호출할 것인지, 화자가 말하는 동안에도 스트리밍을 유지하며 마지막 구절의 확정만을 기다릴 것인지에 따라 체감 성능이 크게 달라집니다. 이번 측정은 스트리밍 STT의 "확정된 문자열을 받은 순간"을 기준으로 하고 있습니다.

LLM 7할, TTS 2할, STT 1할이라는 내역을 통해 최적화의 우선순위가 명확해집니다.

이를 조합하면 1,364ms에서 400~500ms 대까지 도달할 수 있습니다. Nielsen이 제시한 "대화 지연 한계"인 600-800ms를 확실히 밑돌 수 있습니다.

반면, STT를 빠르게 하는 것만으로는 20-50ms밖에 줄지 않습니다. TTS를 2배 빠르게 해도 140-200ms밖에 줄지 않습니다. LLM을 경량화하거나, 프롬프트 캐싱으로 TTFT를 낮추는 이 두 가지 점이 지배적입니다.

"TTS를 빠르게 한다"는 논의가 업계에서 오랫동안 이어져 온 배경에는, 2023년경까지 실제로 TTS가 주범이었던 역사가 있습니다. ElevenLabs와 Cartesia의 2024~2026년 진화로 구조가 바뀌었습니다. 현재의 주범은 LLM의 TTFT이며, 이것이 실측을 통해 알 수 있는 사실입니다.

2026년 5월, OpenAI가 GPT-Realtime-Whisper API를 출시했습니다. 이는 STT + LLM + TTS를 하나의 모델 내에서 완결시키는 설계로, 위의 "Whisper → LLM → TTS"라는 3단계 구성을 거치지 않습니다.

실측(참고치)에 따르면, GPT-4o Realtime API를 사용할 경우:

• 발화 종료 → 음성 응답 시작:
  300-500ms

3단계 구성의 1,364ms에서 대폭 단축되었습니다. 이는 "LLM의 TTFT"가 "모델 내부에서 연속적으로 처리"됨으로써, 큐잉이나 프롬프트의 프리필 경계가 사라지기 때문입니다.

다만, Realtime API는 용도에 따른 구분 사용이 필요합니다.

• 대화 응답 내용이 단순할 때: Realtime API가 유일한 선택지 (지연 시간(Latency)이 주요 지표)
• 대화 응답 내용이 복잡할 때 (검색/도구 실행/RAG를 포함할 때): 3단계 구성(3-stage architecture)이 제어하기 더 쉬움
• 비용을 가장 중시할 때: Whisper + GPT-4o-mini + Cartesia 조합이 더 저렴함

3단계 분할 실측에서 "보이지 않는" 시간으로, VAD(Voice Activity Detection, 음성 활동 감지)에 의한 발화 종료 판정의 오차가 있습니다. 실제 운용 시에는,

• 무음 200ms 감지로 발화 종료 판정 → 그 사이의 200ms가 체감 지연 시간에 가산됨
• 무음 500ms 감지 (오탐지 방지) → 500ms 가산

즉, "1.4초"에 더해 실제 운용 시에는 VAD 판정분인 0.20.5초가 더해집니다. 사용자가 말을 마쳤다고 느낀 시점부터 음성 응답이 돌아오기까지 1.61.9초. 여기까지가 진정한 "체감 지연(Perceived Latency)"입니다.

VAD 임계값(Threshold)을 낮추거나 높이는 것은 UX 설계의 핵심이며, 너무 낮추면 오탐지(숨을 고르는 것을 발화 종료로 판정)가 발생하고, 너무 높이면 반응이 느려집니다. Whisper large-v3 turbo와 동시에 등장한 Silero VAD v4는 이 경계를 가변 임계값으로 처리할 수 있습니다.

대화 UX의 허용 지연 시간을 실무에서 의식하는 라인은 3가지입니다.

즉, 3단계 구성의 기본 설정으로 만들면 많은 사용자가 "기다리고 있다"고 느끼는 영역에 들어갑니다. 300-600ms 대를 목표로 한다면, Realtime API를 사용하거나 3단계 구성의 철저한 최적화가 필요합니다.

• 음성 AI의 지연 시간은 Whisper 1할 / LLM 7할 / TTS 2할. LLM의 TTFT(Time To First Token)가 지배적임
• 실측(100회) 결과, 발화 종료 → 음성 응답 시작 = 1,364ms (중앙값, VAD 제외)
• TTS를 2배 빠르게 해도 총 지연 시간은 10%밖에 단축되지 않음. 우선순위가 다름
• LLM의 Prompt Caching(프롬프트 캐싱)과 경량 모델 전환이 가장 효과적임 (합계 -700~1000ms)
• GPT-4o Realtime API는 300-500ms 대까지 도달함. 단순 응답이라면 유일한 선택지
• VAD의 발화 종료 판정분(200-500ms)을 포함한 실질적인 체감이 UX의 진정한 지표

저는 이번에 "TTS를 빠르게 하면 음성 AI가 빨라진다"는 직관이, 2026년 시점에서는 이미 낡은 것이 되었음을 실측을 통해 확인했습니다. TTS는 충분히 빨라졌으며, 지배적인 요소는 LLM의 TTFT입니다. 이 부분을 나누어 측정하는 습관을 들이면 최적화의 우선순위가 바뀝니다. 직접 3단계 로그를 한 번만 찍어보면 이야기가 달라질 것입니다. 재미있게 접근해 봅시다.

Sources: