음성 AI 추론 API 벤치마크: TTFT·TTFS로 보는 실시간 에이전트 지연 시간 완전 가이드

1. TTFT가 빠르다고 느껴지지 않는 이유

음성 에이전트는 그냥 LLM 한 개가 아닙니다. 사용자의 음성을 텍스트로 바꾸는 STT(Speech-to-Text, 음성 인식), 텍스트로 답을 만드는 LLM, 다시 음성으로 읽어주는 TTS(Text-to-Speech, 텍스트 음성 합성)가 일렬로 도는 구조입니다. 여기서 많은 팀이 TTFT(Time to First Token, 첫 토큰까지의 시간)만 보고 "이 모델이 빠르다"고 판단합니다. 하지만 음성의 경우 TTFT는 전체 응답 시간의 한 줄에 불과합니다.

왜냐하면 TTS 모델은 단어의 절반을 음성으로 만들 수 없기 때문입니다. 완전한 절(文節)이나 문장이 모이기 전에는 오디오를 합성하지 못합니다. 그래서 실제로 사용자가 "체감하는 응답 속도"는 TTFS(Time to First Sentence, 첫 문장까지의 시간)에 가깝습니다. LiveKit의 측정에서 TTFS가야말로 사용자 경험 지표라고 강조합니다.

2. 한 번의 음성 턴은 몇 밀리초짜리일까?

사람 사이의 대화에서 인간의 평균 반응 시간은 약 500ms입니다. 800ms 이상의 침묵이 시작되면 어색하게 느껴진다고 합니다(LiveKit, Daily.co 측정 기준). 음성 에이전트가 "자연스럽다"고 느껴지려면 종단 간 800ms 중위값을 노려야 하고, 최대 1,500ms까지는 허용 범위로 봅니다(Pipecat 창립자 Kwindla Hultman Kramer의 권고).

이 800ms 안을 채우는 단계는 대략 이렇습니다.

• 전송·미디어(WebRTC): 50~150ms. WebRTC(Web Real-Time Communication)란 브라우저·앱이 플러그인 없이 음성·영상을 실시간으로 주고받는 개방형 표준입니다.
• STT + 턴 종료 감지: 100~260ms. 사용자가 "말을 멈췄다"를 AI가 알아차리는 시간입니다.
• LLM 추론(첫 청크): 230~500ms.
• TTS 첫 오디오 + 네트워크: 100~300ms.

여기서 주목할 점은 STT 단계가 단순한 "음성을 글로 바꾸는 속도"가 아니라는 겁니다. 사용자가 말을 멈춘 뒤 "정말 멈췄구나"라고 시스템이 확신하는 데까지 걸리는 시간이 핵심입니다. 이걸 빠르게 잡을수록 LLM을 빨리 시작시킬 수 있습니다.

3. 벤치마크 표를 잘못 읽지 않는 5가지 주의점

공급사들이 공개한 숫자만 믿고 고르면 낭패를 봅니다. 표를 보기 전에 다음 다섯 가지는 꼭 기억하세요.

1. 워크로드 형태가 결과를 지배합니다. Artificial Analysis는 2026년 3월부터 1k가 아닌 10k 입력 토큰으로 측정합니다. 음성 에이전트는 페르소나·정책·검색 데이터·도구 정의를 미리 싣고 출발하기 때문에 10k가 더 현실에 가깝습니다.
2. 서버 위치가 점수에 포함됩니다. Google Cloud us-central1-a에서 측정한 값이므로, 미국 동부와 다른 위치에 있다면 그대로는 적용되지 않습니다.
3. 추론(reasoning) 모델의 TTFT는 추론 토큰부터입니다. 답변이 아니라 "생각" 토큰이 먼저 나오므로 별도 열을 봐야 합니다.
4. 공급사 자체 측정과 제3자 측정은 다릅니다. Daily는 "요청을 보낸 순간부터 API가 첫 토큰을 뱉는 순간까지"를 측정한다고 분명히 못 박습니다.
5. 측정은 매번 달라집니다. 같은 모델명이라도 백엔드 추론 스택, 심지어 가중치(weight)까지 바뀝니다.

4. 계층 1: LLM 첫 토큰 시간 측정 결과

2026년 8월 30일 기준 Artificial Analysis API 리더보드, "first chunk"(TTFT) 컬럼을 10k 입력 토큰·단일 프롬프트·72시간 중위값으로 추린 표입니다.

4-1. 가장 빠른 첫 청크(TTFT) 순위

단위: tok/s = 초당 생성 토큰 수. 클수록 한 문장이 빨리 완성된다는 뜻입니다.

4-2. 처리량 함정: 빠르다고 다 빠른 게 아니다

Inception의 Mercury 2가 가장 교과서적인 함정입니다. 확산(diffusion) 기반이라 초당 770 토큰을 뽑지만, 첫 청크가 3.07초 뒤에 옵니다. 이는 자연스러운 대화의 LLM 예산(약 700ms)의 네 배라서 사실상 음성 에이전트에는 못 씁니다. 반면 Cerebras와 Groq는 TTFT도 적당하고 처리량도 엄청나서 TTFS 측면에서 특히 강력합니다.

4-3. 프런티어·독점 모델의 TTFT

같은 모델이라도 호스팅이 다르면 결과가 달라집니다. GPT-5.6 Luna 비추론은 Amazon Bedrock에서 0.59s, OpenAI 자체 API에서는 0.74s. 즉 라우팅과 호스팅이 모델 가중치만큼 중요합니다.

4-4. 벤더 자체 측정 특이값

LiveKit이 자사 추론 제품에서 측정한 수치입니다. SGLang(고성능 LLM 서빙 프레임워크) 뒤에서 speculative decoding(추측적 디코딩)을 사용해 GPU에 작업을 일부러 덜 채워(warm) 요청에서 약 100ms 만에 토큰을 반환하기 시작한다고 합니다. 대신 100만 출력 토큰당 1.20달러라는 비용이 따라옵니다.

• LiveKit Gemma 4 31B: 192ms
• Gemini 2.5 Flash: 911ms
• GPT-5.5: 966ms
• GPT-4.1: 1,006ms
• OpenRouter의 동일 Gemma 4 31B: 1,876ms

TTFS 기준(전체 대화): LiveKit Gemma 4 31B 354ms, Gemini 2.5 Flash 1,034ms, GPT-4.1 1,088ms, Gemini 3.0 Flash 1,267ms, GPT-5.5 1,404ms. IFBench(Artificial Analysis 독립 평가) 능력 점수: Gemma 4 31B 75.6%, GPT-5.5 75.9%, GPT-4.1 43%, Gemini 2.5 Flash 39%.

5. 계층 2: 음성 인식(STT)과 턴 감지

STT 지연은 단순히 "음성을 글로 바꾸는 속도"가 아닙니다. 사용자가 말을 멈춘 뒤 시스템이 "아, 끝났구나"라고 판단하는 시간입니다. 이걸 빠르게 잡으면 LLM을 그만큼 빨리 시작할 수 있습니다.

5-1. 벤더가 공개한 지연 시간

p50 = 100개 요청 중 50번째로 빠른 값(중위값). p95는 95번째로 빠른 값으로, 느린 꼬리(tail) 구간을 나타냅니다.

5-2. 왜 Deepgram Flux가 특별한가

기존 STT는 "음성→텍스트" 모델 위에 VAD(음성 활동 감지)를 별도로 얹었습니다. Deepgram Flux는 턴 종료 감지를 STT 모델 자체에 통합했고, Deepgram은 "이 덕분에 에이전트 응답 지연이 200~600ms 줄어든다"고 발표합니다. 더 흥미로운 건 EagerEndOfTurn 이벤트입니다. 모델이 "말 멈춤 가능성 높음" 신호를 보내면 LLM이 미리 생성을 시작할 수 있어, 예측이 맞았을 때 LLM TTFT를 사실상 0으로 만들 수 있습니다.

AssemblyAI Universal-Streaming은 "부분 전사 → 최종 전사" 순서를 뒤집어 단어를 처음부터 불변 형태로 출력합니다. AssemblyAI 2025년 자체 측정에서 Nova-3의 516ms 대비 307ms 중위값 단어 출력을 보고했습니다.

6. 계층 3: TTS 첫 오디오 시간

TTS 단계는 공급사 마케팅 수치와 실제 사용자 경험이 가장 크게 벌어지는 곳입니다.

• ElevenLabs Flash v2.5: 모델 추론 시간 75ms라고 표기하지만, 네트워크 왕복(20~200ms)과 오디오 플레이어 버퍼링(보통 500ms)이 별도입니다. Eleven v3는 실시간용이 아니므로 Agents Platform에는 Flash v2.5/v2/Multilingual v2를 권장한다고 회사 문서가 직접 못 박습니다.
• Cartesia Sonic-3.6: 90ms 미만 TTS + 100ms 전사 지연 주장. 이전 모델 Sonic 3.5는 82ms 종단 간을 표기했으나, 이는 모델 추론 시간만 포함한다는 보도가 있습니다. Sonic은 트랜스포머가 아닌 상태 공간 모델(State Space Model) 기반이라 시퀀스 길이에 대해 선형으로 확장됩니다.

6-1. TTS 품질(Elo)과 가격

여기서 Elo 평점 시스템은 체스에서 유래한 상대 실력 평가 방식으로, Artificial Analysis가 블라인드 청취자로부터 모은 음성 품질 점수입니다.

Sonic 3.6(1,288)과 Flash v2.5(1,083)의 격차가 "저지연 등급에서 우리가 포기하는 품질"의 크기입니다. ElevenLabs가 같은 가격($50/100만 글자)에 더 낮은 Elo를 받는 이유는 v3가 실시간용이 아니기 때문입니다.

7. 계층 4: 음성→음성 단일 모델

음성→음성(S2S) 모델은 STT·LLM·TTS를 한 번에 처리합니다. 왕복이 줄면 지연도 줄어들어야 하지만, 항상 그렇지는 않습니다.

TTFA = Time To First Audio, 첫 오디오가 들리기까지의 시간.

Grok Voice Think Fast 2.0 High가 눈에 띕니다. 0.70초 TTFA에 음성 추론 97%, 작업 성공률 94.7%. 추론 노력(reasoning effort) 페널티도 분명히 보입니다. 동일 모델 패밀리 안에서 Minimal→High로 올리면 Gemini 3.1 Flash Live는 0.96s→2.99s, GPT-Realtime-2.1은 0.97s→1.21s로 이동합니다.

OpenAI는 2026년 7월 gpt-realtime-2.1 출시와 함께 캐싱 개선으로 p95(95번째 백분위수, 즉 꼬리 지연 시간)를 최소 25% 줄였다고 발표했습니다. 음성 전화는 중간값보다 이 꼬리에서 무너집니다.

8. 캐스케이드 vs 단일 모델, 누가 이기나?

대부분의 운영 에이전트는 아직 캐스케이드 파이프라인(STT→LLM→TTS)을 씁니다. Daily의 aiwf_medium_context 벤치마크에서 GPT Realtime는 86.7%, GPT-4.1 캐스케이드는 94.9%였습니다. 캐스케이드가 도구 호출·지시 따르기에서 더 정확하다는 뜻입니다.

8-1. 4개 벤더 기본 캐스케이드 구성

네 개 중 세 개가 Gemini 2.5 Flash를 LLM으로 채택합니다. 업계가 합의한 구성이라고 봐도 됩니다.

8-2. 참조 예산: 같은 자리에 둘 때(US, 동일 colocate)

숫자만 보면 비슷합니다. 실제 차이는 단일 모델이 캐스케이드만큼 디버깅·관측하기 어렵다는 점, 그리고 도구 호출 능력 격차입니다.

9. 실무자가 꼭 챙겨야 할 6가지

1. 아키텍처에 맞는 지표를 고르세요. TTS가 다운스트림에 있다면 TTFT가 아니라 TTFS를 최적화하세요. 즉 TTFT와 초당 토큰 수를 같이 봐야 합니다.
2. 모델 튜닝 전에 같은 데이터센터에 두세요. LiveKit은 "에이전트-모델 동일 위치 배치를 모델 선택보다 영향이 매우 크다"고 평가합니다. SIP 트렁크도 지리적으로 가까이 둡니다.
3. 추론 노력을 명시적으로 제한하세요. 위 표에서 가장 큰 단일 조절 노브입니다. 대부분 엔드포인트가 구성 플래그로 제공합니다.
4. 도구 호출에 예산을 미리 잡아두세요. Kwindla Hultman Kramer는 "도구 호출이 있는 턴은 LLM 지연이 거의 두 배"라고 지적합니다. LiveKit은 max_tool_steps 제한, 외부 API 통합, "생각 중" 사운드 재생을 권합니다.
5. 튜닝 전에 측정 도구를 깔아두세요. LiveKit Agents SDK는 턴당 e2e_latency·LLM 첫 토큰 시간·TTS 첫 바이트 시간을 노출합니다. Pipecat은 enable_metrics와 옵저버로 동일 기능을 제공합니다.
6. p50만이 아닌 p95를 보세요. 2026년 7월 OpenAI의 주요 개선이 "꼬리 지연 시간"이었듯, 전화 에이전트가 무너지는 곳은 평균이 아니라 꼬리입니다.