음성 기반 대화형 AI 애플리케이션에서 지연 시간이 미치는 영향
대화형 AI 기술이 계속 발전하고 있지만, LLM과의 실시간 음성 및 영상 커뮤니케이션을 구현하는 데에는 여전히 몇 가지 주요 장애물이 있습니다. 이전 블로그에서 라스트 마일의 까다로운 조건을 극복하는 것이 중요하다는 점을 강조한 바 있습니다. 지연 시간(레이턴시)은 애플리케이션에서 음성 기반 대화형 AI를 구현할 때 극복해야 하는 또 다른 과제입니다.
이 블로그에서는 음성 기반 대화형 AI 애플리케이션에서 지연 시간(지연)이 미치는 영향에 대해 집중적으로 다룹니다:
- 사람 간의 자연스럽고 유창한 대화에 일반적으로 허용되는 지연 시간을 명시하는 연구 및 업계 표준.
- 사람이 인터넷을 통해 음성을 사용하여 대규모 언어 모델(LLM)과 상호 작용할 때 지연 시간을 높이는 데 기여하는 구성 요소.
- 지연 시간을 최소화하여 최상의 인간과 기계 간의 대화 경험을 제공하는 방법.
자연스러운 인간 대화의 지연 시간
OpenAI GPT-4o 발표 페이지에서는 GPT-4o가 “232밀리초(ms)의 짧은 시간 내에 오디오 입력에 응답할 수 있으며, 평균 응답 시간은 320ms로 대화에서 사람의 응답 시간과 비슷하다”고 강조하고 있습니다. 참고한 연구의 제목은 “대화에서 차례를 정하는 데 있어 보편성과 문화적 다양성”입니다. 이 연구는 10개의 대표적인 언어를 대상으로 진행되었으며, 차례 전환의 평균 응답 오프셋은 약 208ms로 나타났습니다. 분석된 대화는 같은 장소에 있는 참가자들의 상호작용을 비디오로 촬영한 것입니다. 대면 대화의 경우 입과 귀 사이의 지연(한 사람이 말하고 다른 사람이 듣는 시간)은 매우 낮습니다. 스피커가 약 2m 떨어져 있는 경우 약 6ms입니다. 아래 그림 1을 예로 들어 설명합니다.
‘대화형 AI’를 지원하는 것이 목적인 애플리케이션의 경우 자연스러운 대화를 모방하는 것이 중요합니다. 자연스러운 대화를 에뮬레이트하려면 입에서 귀로 전달되는 지연 시간과 대화를 받아들이는 지연 시간을 모두 고려하는 것이 중요합니다. 또한 오늘날 대화형 AI 애플리케이션은 클라우드의 디바이스와 인프라를 활용하는 사용자 간의 상호 작용이 필요하므로 최상의 경험을 위해서는 지연 시간을 증가시키는 모든 요소를 이해하고 최소화해야 합니다.
RTC 애플리케이션을 통한 인간 대화의 지연 시간
서로 다른 위치에 있는 두 사람이 모바일 디바이스에서 애플리케이션을 사용하여 음성 통화로 서로 소통하는 경우(아래 그림 2 참조)를 살펴보겠습니다.
휴대폰 1의 사용자가 휴대폰 마이크를 입에 직접 대고 있고 휴대폰 2의 사용자가 휴대폰 스피커를 귀에 직접 대고 있는 경우, 이 경우의 입 대 귀 지연은 위에 표시된 모든 상자의 개별 지연을 합한 값입니다. 두 모바일 디바이스의 지연 기여도는 표 1에 나와 있습니다. 비교를 위해 일반적인 지연과 아고라가 디바이스 및 운영 체제 최적화를 통해 달성한 지연 감소를 보여줍니다.
Mobile Device Delay Contributor | Typical Delay (ms) for iOS | Agora Optimized (ms) iOS | Typical Delay (ms) for Android* | Agora Optimized (ms) Android |
---|---|---|---|---|
Mic input delay | 25 | 15 | 60-80 | 25 |
Pre-processing delay (HW/SW) | 60 | 10 | 60-100 | 10 |
Codec encoding delay | 10 | ~0 | 10 | ~0 |
Packetization delay | ~0-40 | ~0 | ~0-40 | ~0 |
Jitter buffer delay | > 60 | 20 | > 60 | 20 |
Codec decoding delay | 1 | ~0 | 1 | ~0 |
Speaker output (playout) delay | 25 | 15 | 160-250 | 20 |
Total for Device | > 181 | 60 | > 350 | 100 |
*기본적으로는 장치 간 호환성이 넓기 때문에 일반적으로 Java ADM이 사용되지만, 재생 지연이 현저히 높은 경우가 많습니다.
네트워크 스택 및 전송 지연은 음성 패킷이 네트워크 에지 간을 전송하는 데 걸리는 총 시간으로 정의되며, 사용자가 같은 도시에 있는지 또는 다른 도시, 주 또는 국가에 있는지에 따라 크게 달라질 수 있습니다. 테스트에서는 공용 인터넷과 아고라의 독점적인 소프트웨어 정의 실시간 네트워크(SD-RTN™)를 통한 단방향 지연 시간을 비교했습니다. 이 단방향 지연 시간은 네트워크 엣지에서 네트워크 엣지까지 측정한 것으로, 양쪽 끝의 라스트 마일 홉은 포함되지 않았습니다. 한 대륙 내(지역 내)와 대륙 간(지역 간) 데이터를 비교했습니다. 결과는 아래 그림 3에 나와 있습니다.
간단히 설명하자면, 같은 지역 내 또는 지역 간 사용자의 95%가 지연 시간이 50% 이상 개선(감소)된다는 것이 핵심입니다.
두 휴대폰 사용자가 모두 북미 내에 있다고 가정해 보겠습니다. 이 경우 공용 인터넷 사용자의 95%는 지연 시간이 최대 94밀리초를 넘지 않으며, 아고라의 SD-RTN™을 사용하면 지연 시간이 최대 33밀리초가 됩니다. 모바일 라스트 마일 홉에서 가능한 최상의 지연 시간은 공용 인터넷의 서버와 모바일 디바이스 간 약 10ms, 아고라의 SD-RTN™과 아고라의 SDK를 사용하는 모바일 디바이스 간 10ms입니다. 이 10ms라는 수치는 마지막 홉이 모바일 디바이스의 사용자와 같은 도시에 있고 라스트 마일 연결이 우수하다고 가정합니다. 이 수치를 사용하면 표 2와 같이 총 입에서 귀까지의 지연 시간을 추정할 수 있습니다.
Case | Total for Device (ms) | Network Stacks & Transit Delay (ms) | Total mouth-to-ear delay (ms) |
---|---|---|---|
Two iOS Devices on Public Internet | >181 | 94+20 = 114 | >295 |
Two Agora Optimized iOS Devices on SD-RTN™ | 60 | 33+20 = 53 | 113 |
Two Android Devices on Public Internet | >350 | 94+20 = 114 | >464 |
Two Agora Optimized Android Devices on SD-RTN™ | 100 | 33+20 = 53 | 153 |
이러한 추정치를 얻었으니 이제 입에서 귀까지의 지연 수준이 사용자가 수용할 수 있는 수준인지 아닌지 어떻게 알 수 있을까요? 다행히 I국제전기통신연합에서 이 질문에 대한 답을 제시하는 G.114라는 표준을 발표했습니다.
아래 그림은 ITU G.114 표준에서 발췌한 것으로, 음성 지연 시간 대 사용자 만족도 품질에 대한 통신 업계의 연구를 보여줍니다.
그림 4를 참조하면, 최대 275ms의 입에서 귀까지의 지연에 만족하는 사용자가 많습니다. 275밀리초에서 385밀리초 사이에서는 일부 사용자가 불만족스러워합니다. 그 이상에서는 경험이 좋지 않습니다.
Case | Total mouth-to-ear delay (ms) | ITU G.114 User Satisfaction Rating |
---|---|---|
Two iOS Devices on Public Internet | >295 | Some Users Dissatisfied |
Two Agora Optimized iOS Devices on SD-RTN™ | 113 | Users Very Satisfied |
Two Android Devices on Public Internet | >464 | Many Users Dissatisfied |
Two Agora Optimized Android Devices on SD-RTN™ | 155 | Users Very Satisfied |
표 3을 참조하면, 아고라에서 지원하는 지연 시간에 대한 네트워크 최적화와 더불어 디바이스 및 운영 체제 수준 최적화를 통해 전체 지연 시간이 훨씬 짧아지고 G.114 사용자 만족도가 높아졌습니다.
인간과 AI 간의 대화에서 지연 시간
이러한 배경과 맥락을 바탕으로 이제 그림 5와 같이 AI 에이전트가 네트워크 엣지에 있는 음성 기반 대화형 AI의 예를 살펴보겠습니다. 간단하게 설명하기 위해 AI 워크플로우와 추론이 네트워크 엣지에서 이루어진다고 가정하겠습니다. 이 예에서는 LLM이 직접 음성 인터페이스(오디오 LLM)를 지원하므로 음성-텍스트 변환이 필요하지 않다고 가정합니다. 약어 TTS TTFB는 첫 바이트까지의 시간 또는 LLM이 텍스트 음성 변환 응답을 생성하도록 요청하고 응답의 첫 바이트가 생성될 때까지의 기간을 나타냅니다.
이 예제를 사용하여 휴대폰에서 대화형 AI 앱을 사용하는 사람으로부터 오디오 LLM 기반 AI까지의 입에서 귀까지의 지연, 오디오 LLM 기반 AI의 턴테이크 지연, 휴대폰에서 대화형 AI 앱을 사용하는 사람으로부터 오디오 LLM 기반 AI까지의 입에서 귀까지의 지연을 추정해 보겠습니다. 이 예제에서는 인간 사용자가 안드로이드 폰을 사용한다고 가정합니다.
Delay Contributor | Typical Delay (ms) | Agora Optimized (ms) |
---|---|---|
Mic input delay | 60-80 | 25 |
Pre-processing delay (HW/SW) | 60-100 | 10 |
Codec encoding delay | 10 | ~0 |
Packetization delay | ~0-40 | ~0 |
Network Stacks & Transit Delay | 10 | 10 |
Audio LLM Jitter buffer delay | 40 | 40 |
Audio LLM Codec decoding delay | 1 | 1 |
Total | > 121 | 86 |
Delay Contributor | Optimized Delay |
---|---|
Audio LLM Delay | 100 |
Sentence Aggregation Delay | 100 |
TTS TTFB Delay | 80 |
Total | 280 |
Delay Contributor | Typical Delay | Agora Optimized (ms) |
---|---|---|
Audio LLM Codec encoding delay | 21 | 21 |
Audio LLM Packetization delay | 2 | 2 |
Network Stacks & Transit Delay | 10 | 10 |
Jitter buffer delay | >60 | 20 |
Codec decoding delay | 1 | ~0 |
Speaker output (playout) delay | 160-250 | 45 |
Total | > 254 | 98 |
이 예시에서 오디오 LLM 기반 AI가 안드로이드폰 사용자에게 전달할 때 예상되는 입에서 귀까지의 지연은 ITU G.114에 따른 ‘일부 사용자 불만족’ 임계값에 가깝습니다. 이는 AI 워크플로우와 추론이 사용자와 가장 가까운 네트워크 에지에서 수행된다고 가정할 때 네트워크 스택과 전송 지연이 최소화되는 시나리오입니다. 인간이 원거리에서 다른 인간 및 하나 이상의 대화형 AI 에이전트와 상호 작용하는 시나리오가 많이 있을 것입니다. 그림 3을 참조하면, 네트워크 스택의 지연 기여도와 전송 지연이 모바일 디바이스 지연 기여도와 결합하여 입과 귀 사이의 지연이 임계값을 초과하여 사용자가 대화형 AI 경험에 불만족할 수 있는 경우가 종종 있습니다.
지역 내 위치한 AI 에이전트와의 인간과 AI 간의 대화 지연 시간
마지막으로 AI 에이전트가 지역 내부에 있는 경우와 네트워크 엣지에 있는 경우의 동일한 시나리오를 살펴봅시다. 이 시나리오는 대화형 AI 솔루션이 확장되고 사람들이 세션 중에 한 명 이상의 AI 에이전트와 상호 작용할 수 있게 되면서 더욱 보편화될 것입니다.
간단히 설명하기 위해 사용자와 AI 에이전트가 모두 북미 내에 있다고 가정해 보겠습니다. 이 경우 공용 인터넷 사용자의 95%는 지연 시간이 최대 94밀리초를 넘지 않으며, 아고라의 SD-RTN™을 사용하면 지연 시간이 최대 33밀리초가 됩니다.
Delay Contributor | Typical Delay | Agora Optimized (ms) |
---|---|---|
Mic input delay | 60-80 | 25 |
Pre-processing delay (HW/SW) | 60-100 | 10 |
Codec encoding delay | 10 | ~0 |
Packetization delay | ~0-40 | ~0 |
Network Stacks & Transit Delay | 104 | 43 |
Audio LLM Jitter buffer delay | 40 | 40 |
Audio LLM Codec decoding delay | 1 | 1 |
Total | > 275 | 119 |
Delay Contributor | Optimized Delay |
---|---|
Audio LLM Delay | 100 |
Sentence Aggregation Delay | 100 |
TTS TTFB Delay | 80 |
Total | 280 |
Delay Contributor | Typical Delay | Agora Optimized (ms) |
---|---|---|
Audio LLM Codec encoding delay | 21 | 21 |
Audio LLM Packetization delay | 2 | 2 |
Network Stacks & Transit Delay | 104 | 43 |
Jitter buffer delay | >60 | 20 |
Codec decoding delay | 1 | ~0 |
Speaker output (playout) delay | 160-250 | 45 |
Total | > 348 | 131 |
이 예에서 오디오 LLM 기반 AI가 안드로이드 폰 사용자에게 예상되는 입에서 귀까지의 지연은 ITU G.114에 따라 ‘일부 사용자 불만족’ 영역에 속합니다. 지역 간 사례의 경우 ‘다수 사용자 불만족’ 영역에 쉽게 진입할 수 있습니다.
결론적으로 애플리케이션에서 음성 기반 대화형 AI를 구현할 때는 지연 시간을 최소화하는 것이 필수적입니다. 이 블로그에서 설명한 것처럼 자연스러운 대화를 모방하려면 입과 귀 사이의 지연과 대화에서 차례를 기다리는 지연을 모두 고려하는 것이 중요합니다. 입에서 귀로의 지연을 최소화하려면 디바이스 수준과 네트워크 수준 모두에서 지연 시간을 최적화하는 검증된 솔루션을 제공하는 공급업체와 협력하여 애플리케이션에서 만족스러운 대화형 AI 경험을 보장하는 것이 필수적입니다. 대화 중 턴-테이킹 지연 시간을 최소화하려면 이 분야에서 실제 성능을 입증한 LLM 제공업체 및 솔루션 제공업체를 고려하세요. 아고라가 개발자가 대화형 AI를 구축하는 데 어떻게 도움을 주는지 자세히 알아보세요.
지역 내 위치한 AI 에이전트와의 인간과 AI 간의 대화 지연 시간