실시간 음성 AI 시스템, GPT-Live 공개

실시간 음성 AI 시스템 구축: GPT-Live의 혁신

음성 AI 시스템에서 언제 말을 시작해야 하는지를 아는 것은 생각보다 어렵습니다. 인간은 자연스럽게 대화를 주고받지만, 이전의 음성 AI 시스템은 이러한 리듬을 따라가지 못했습니다. 기존 시스템은 '턴 디텍터'라는 작은 모델에 의존했는데, 이 모델은 너무 빨리 추측하면 사용자의 말을 끊고, 너무 늦게 추측하면 반응이 느리게 느껴지는 문제를 안고 있었습니다. 디텍터가 결정을 내린 후에야 더 큰 언어 모델이 작동할 수 있었습니다.

GPT-Live는 이러한 턴 디텍터를 제거하여 음성 모델이 동시에 듣고 말할 수 있는 풀 듀플렉스 기능을 제공합니다. 이를 통해 별도의 디텍터가 필요 없어지고, 대화가 더욱 즉각적이고 자연스럽게 느껴집니다. 또한, GPT-Live는 더 깊은 추론이나 도구 사용이 필요할 때 GPT-5.5와 같은 프론티어 모델을 참조할 수 있어 대화의 흐름을 방해하지 않습니다. 이러한 기능들은 GPT-Live에 전례 없는 대화 반응성과 지능을 제공합니다.

이러한 경험을 대규모로 제공하기 위해서는 낮은 지연 시간에 최적화된 새로운 시스템 아키텍처가 필요했습니다. 일반적인 요청-응답 추론과는 달리, 우리의 시스템은 들어오는 오디오를 음성 모델로 스트리밍하고, 아웃바운드 음성을 사용자에게 다시 전달하며, 별도의 비동기 경로에서 위임을 처리합니다. 지난 6개월 동안 우리는 모델 추론, 컨텍스트 관리, 미디어 전송을 재작업하여 음성이 끝에서 끝까지 매끄럽게 흐르도록 했습니다.

이 아키텍처는 핵심 음성 경로와 애플리케이션 로직 간의 명확한 경계를 만들어줍니다. 이를 통해 응답성을 해치지 않고 애플리케이션의 동작을 쉽게 사용자 정의할 수 있습니다. 이러한 기반은 ChatGPT Voice의 다양한 기능을 지원하며, 새로 출시된 컴퓨터 제어 및 ChatGPT 데스크톱 앱에서 에이전트 조정 기능을 포함합니다.

턴 테이킹에서 스트리밍으로의 전환

이전의 음성 아키텍처는 텍스트 LLM의 턴 기반 특성을 상속받았지만, 각 턴은 텍스트가 아닌 개별 오디오 블롭으로 표현되었습니다. 계단식 시스템에서는 음성 인식, LLM, 음성 합성이 각각 순차적으로 실행되었습니다. 이러한 순차 처리는 지연 시간을 추가하고 톤 및 속도와 같은 단서를 무시했습니다.

음성-음성 모델은 오디오를 직접 처리함으로써 이러한 접근 방식을 개선했습니다. 모델을 훈련시켜 본래의 음성을 이해하고 생성할 수 있게 함으로써 전사에서 손실된 세부 사항을 보존하고 더 빠르게 응답할 수 있게 했습니다. 그러나 시스템은 여전히 언제 추론을 시작할지 결정하는 턴 디텍터에 의존했습니다. 모델은 더 많은 상호작용을 처리했지만, 상호작용은 여전히 턴 기반이었습니다.

GPT-Live는 음성 모델이 대화를 주도하도록 하여 오디오가 모델 안팎으로 흐르도록 합니다. 더 깊은 추론과 도구 사용은 비동기적으로 이루어집니다. 시스템의 주요 작업은 중단 없는 미디어 루프를 유지하는 것입니다. 프론티어 모델 호출 및 대화 지속과 같은 다른 작업은 라이브 경로 외부에서 이루어집니다.

지속적인 추론 가능하게 하기

이 미디어 루프를 중단 없이 유지하는 것은 항상 간단하지 않습니다. 전송, 처리, 추론의 지연은 들리는 중단이나 인공물로 나타날 수 있습니다. 이전의 턴 기반 시스템은 오디오 블롭이 도착하는 시간의 변동을 어느 정도 허용할 수 있었습니다. 그러나 라이브 미디어 시스템은 모든 오디오 프레임을 일정에 맞춰 전달해야 합니다.

ChatGPT Voice와 Realtime API에 대한 이전 작업은 중요한 기반을 제공했습니다. 우리는 이미 우리의 음성 인프라를 재구축하여 오디오와 비디오를 시스템 안팎으로 직접 스트리밍하여 더 낮고 예측 가능한 지연 시간을 제공했습니다. GPT-Live는 이러한 설계를 더욱 발전시켜, 연속 대화를 위해 구축된 새로운 상태 추론 시스템을 통해 미디어를 모델로 스트리밍합니다.

스트리밍 추론은 솔루션의 일부에 불과했습니다. 이를 실제 환경에서 잘 작동하게 하려면 클라이언트에서 추론 스택으로의 신뢰할 수 있는 오디오 전달을 보장하고 상태 유지의 문제를 해결해야 했습니다.

초기에 내린 결정 중 하나는 미디어 흐름을 애플리케이션 및 비즈니스 로직과 명확히 분리하는 것이었습니다. 오디오는 클라이언트와 음성 모델 간의 전용 고속 경로를 통해 이동합니다. 위임, 도구 사용 및 기타 애플리케이션 작업은 비동기 RPC 경계 뒤에서 이루어집니다. 느린 도구 호출이나 백엔드 서비스는 자체 결과를 지연시킬 수 있지만, 미디어 흐름을 멈추게 할 수는 없습니다.

이 분리는 또한 시스템에 사용자 정의를 위한 명확한 경계를 제공합니다. 애플리케이션은 미디어 프론트엔드에 영향을 주지 않고 도구, 정책 및 백엔드 동작을 변경할 수 있습니다. 라이브 경로는 작고 예측 가능하며 실시간으로 수행해야 하는 작업에 집중합니다.

우리는 미디어 프론트엔드와 추론 로직을 Go로 작성하여 이전의 Python asyncio 구현을 대체했습니다. 이는 프레임 전달의 매끄러움을 크게 개선했으며, 새로운 시스템의 p95가 이전 시스템의 p50과 일치합니다.

WebRTC는 전송의 기초를 제공합니다. 이는 낮은 지연 시간의 미디어를 위해 설계되었으며, 패킷 손실, 시계 드리프트 및 클라이언트 연결 변경을 통해 계속 작동할 수 있습니다. 패킷이 늦게 도착하면 WebRTC는 간격을 방지하기 위해 오디오를 미세하게 늘리고, 실시간으로 다시 따라잡기 위해 재생 속도를 잠시 가속할 수 있습니다.

시스템 전반에서 버퍼링과 차단을 최소화함으로써 인간이 대화에서 기대하는 초 단위 응답성을 제공할 수 있습니다.

(상태 유지) 대화를 지속하기

상태 유지 추론은 자체 운영상의 절충점을 가지고 있습니다. 음성 세션은 오랫동안 활성 상태로 유지될 수 있지만, 그 컨텍스트는 지속적으로 증가하며, 모델 인스턴스는 수요에 따라 생성되고 소멸됩니다.

이러한 문제를 해결하기 위해 모델 인스턴스 간의 원활한 핸드오프 메커니즘을 구축했습니다. 전환이 필요할 때, 기존 인스턴스와 함께 대체 모델 인스턴스를 예열하고, 현재 세션 컨텍스트로 미리 채우고, 두 인스턴스에서 병렬로 추론을 실행한 후, 새 인스턴스가 완전히 준비되면 전환할 수 있습니다.

동일한 기본 메커니즘은 동적 컨텍스트 압축도 지원합니다. 대화가 진행됨에 따라 누적된 컨텍스트가 결국 모델의 컨텍스트 한계를 초과할 수 있습니다. 압축은 컨텍스트 크기를 한도 내로 줄일 수 있지만, 이 작업은 시간이 걸립니다. 또한 과거 컨텍스트를 변경하기 때문에 이전에 처리된 토큰의 주의 키와 값을 저장하는 모델의 키-값(KV) 캐시를 무효화합니다. 이 상태를 재구축하려면 새로운 프리필이 필요하며, 추가 지연을 초래합니다.

대신, 우리는 압축을 또 다른 관리 전환으로 취급합니다. 원래 모델 인스턴스가 계속 대화하는 동안, 시스템은 컨텍스트를 압축하고 새로운 컨텍스트로 대체 모델 인스턴스를 준비합니다. 인스턴스가 준비되면 미디어 중단 없이 전환할 수 있습니다. 이를 통해 시스템은 장기 실행 통화를 지원하며, 필요할 때마다 압축할 수 있습니다.

무거운 작업은 라이브 경로에서 벗어나 있기 때문에, 핸드오프 중에도 대화는 끊기지 않습니다.

대화를 차단하지 않는 위임

GPT-Live의 기존 프론티어 모델 호출 기능은 많은 힘을 제공합니다. 이는 "말하기"와 더 깊은 "생각하기"를 효과적으로 분리합니다. 그러나 이 두 모델 아키텍처를 하나의 시스템처럼 느끼게 만들기 위해 두 가지 관련된 엔지니어링 문제를 해결해야 했습니다.

더 깊은 작업을 위한 위임

GPT-Live는 빠르고 자연스러운 응답을 제공하며, GPT-5.5는 백그라운드에서 검색을 처리합니다.

첫째, 결과는 진행 중인 교환에서 유용할 만큼 빨리 반환되어야 하므로, 라우팅 및 프롬프트 처리부터 추론 및 도구 호출까지 전체 위임 경로의 지연 시간을 최소화해야 했습니다. 동시에 제품의 다른 시스템은 여전히 개별 메시지가 필요하므로, 진행 중인 대화를 이해할 수 있는 형태로 표현해야 했습니다.

자연스럽게 느껴질 만큼 빠른 위임 만들기

위임이 전송되면, 프론티어 모델이 대화에 유용한 무언가를 생산할 때까지의 시간을 최적화합니다. 음성 모델은 프론티어 모델이 추론하거나 도구를 사용할 동안 잠시 교환을 계속할 수 있지만, 임의로 느린 응답을 숨길 수는 없습니다. 따라서 우리는 전체 위임 루프(라우팅, 프롬프트 처리, 추론, 도구 호출)를 응답성 예산의 일부로 취급했습니다.

첫 번째 최적화는 위임이 요청되기 전에 프론티어 모델과 필요한 도구를 설정하는 것입니다. 음성 세션이 시작되면, 애플리케이션 서버는 프론티어 모델을 위한 추론 세션을 생성하고 초기 대화 컨텍스트로 미리 채워 첫 번째 위임 요청 전에 프롬프트가 완전히 처리되도록 합니다.

그런 다음 음성 대화가 진행되는 동안 해당 추론 세션을 사용할 수 있도록 유지하고, 연속적인 요청에 대해 안정적인 세션 친화성을 사용합니다. 프롬프트 캐싱과 함께 이러한 기술은 지연 시간을 개선하며, 작업자 실패가 쉽게 복구될 수 있도록 합니다.

추론 노력, 출력 한계, 도구 스키마, 모델-도구 왕복도 대화가 유용한 결과를 받을 때 영향을 미치며, 우리는 이러한 레버를 조정하여 더 빠른 응답을 얻었습니다. 위임 경로에서 필요한 작업을 최소화함으로써, 음성 모델은 프론티어 모델의 결과를 빠르게 통합할 수 있습니다.

연속 음성에서 개별 턴 도출

음성 모델은 연속적인 음성 스트림에서 작동하지만, 그 주위의 많은 시스템은 여전히 사용자와 어시스턴트 턴으로 작동합니다. ChatGPT의 대화 UI와 분석 및 안전 인프라의 일부가 이에 포함됩니다. 따라서 애플리케이션 서버는 겹치고 때로는 모호한 대화를 개별 메시지로 분리합니다.

오디오가 도착하면, 서버는 부분 전사와 타이밍 신호를 사용하여 어느 화자가 발언권을 가지고 있는지 추론하고 메시지 대기열을 구축합니다. 최신 메시지는 임시 상태로 유지되며, 더 많은 음성이 도착하면 텍스트, 타이밍, 화자 할당이 모두 변경될 수 있습니다. 화자가 발언권을 충분히 오래 유지하여 할당이 신뢰할 수 있을 때, 서버는 해당 메시지를 최종 확정합니다.

화자 겹침은 이를 더 복잡하게 만듭니다. 사용자가 말하는 동안 어시스턴트의 짧은 인정(예: "음," 또는 "알겠습니다")은 반드시 자체 메시지가 되어야 하는 것은 아닙니다. 그러나 어시스턴트의 실질적인 개입은 종종 그래야 합니다. 마찬가지로 사용자가 중간에 말하더라도 표시된 어시스턴트 응답의 일관성을 우선시합니다.

모든 세분화 정책은 신선함을 확실성으로 교환합니다. 너무 일찍 커밋하면 단편화된 기록과 불안정한 순서가 생성되고, 너무 오래 기다리면 전사와 그에 의존하는 기능이 지연됩니다. 시스템은 따라서 대화의 두 가지 관련된 뷰를 유지합니다: 현재 상태의 추측적 뷰와 발언된 내용의 권위 있는 기록입니다. 애플리케이션 UI의 대화 뷰는 업데이트를 처리할 수 있으므로 추측적 뷰를 사용합니다. 그러나 분석 파이프라인에 로깅하려면 최종 전사가 필요합니다.

이것은 ChatGPT의 나머지 부분에 턴 테이킹을 라이브 음성 경로에 강요하지 않고 안정적인 교환 뷰를 제공합니다.

더 빠른 프로토콜로 세션 시작

응답성은 사용자가 버튼을 클릭하는 순간 시작됩니다. GPT-Live에서는 시스템이 미디어 경로를 설정하고 모델을 통해 오디오를 공급하기 시작해야 대화가 시작될 수 있습니다. 이는 시작 시퀀스의 모든 부분을 중요한 경로에 놓습니다.

앞서 언급했듯이, WebRTC는 강력한 실시간 기반을 제공하지만, 기본 WebRTC 세션을 시작하려면 놀라울 정도로 많은 프로토콜 핸드셰이크와 네트워크 왕복이 필요합니다. WebRTC는 QUIC과 같은 이후 프로토콜을 형성한 왕복 최소화에 중점을 두기 전에 개발되었습니다. 결과적으로, 기본 프로토콜은 함께 사용될 때 작업을 반복하는 경우가 있습니다. 예를 들어, 각 프로토콜은 전체 WebRTC 스택의 맥락에서 필요하지 않을 때에도 자체적인 DoS 방지 메커니즘을 포함했습니다.

우리는 WARP를 개방형 사양 세트로 설계하여 WebRTC 커뮤니티의 협력자들과 함께 더 넓은 생태계가 이 작업의 혜택을 받을 수 있도록 했습니다. 우리는 IETF의 TSVWG 작업 그룹을 통해 제안을 발전시키고 있으며, WARP 지원은 이미 libwebrtc와 Pion에 추가되었으며, 다른 WebRTC 구현에서도 노력이 진행 중입니다.

미디어 핸드셰이크를 최적화한 후, 하나의 남은 지연이 두드러졌습니다: WebRTC가 연결되기 전에 SDP 매개변수를 공유하는 데 사용되는 시그널링 교환입니다. 이 교환을 중요한 경로에서 제거하기 위해, 우리는 이를 Instant Connect라고 부릅니다. 이는 서버 용량을 예약하지 않고 기존 WebRTC 구현에 대한 변경 없이 이러한 매개변수를 미리 협상합니다.

Instant Connect는 표준 시그널링 흐름과 함께 실행됩니다. 미리 협상된 매개변수가 유효하면, 서버는 첫 번째 미디어 패킷이 도착할 때 세션을 실현할 수 있습니다. 매개변수가 오래되었거나 유효하지 않으면, 시그널링 흐름이 이미 진행 중이므로 클라이언트는 추가 지연 없이 다시 돌아갈 수 있습니다.

Instant Connect와 WARP는 사용자 의도에서 라이브 미디어 흐름까지의 시간을 크게 줄입니다. SDP 교환이 중요한 경로에서 벗어나고 WARP가 전송 핸드셰이크를 축소함에 따라, 클라이언트는 이제 단일 UDP 패킷으로 세션을 시작할 수 있습니다. 서버는 즉시 응답할 수 있으며, 시스템의 나머지 부분이 사용자가 실제로 관심을 가지는 작업을 시작할 수 있게 합니다: 듣고 응답하기.

실제 데이터로 GPT-Live의 안전한 테스트

시스템은 이론적으로 빠르게 보일 수 있지만 실제 음성 트래픽에서는 멈출 수 있습니다. GPT-Live가 사용자와 대화하기 전에, 우리는 소리 없는 테스트를 실행하여 점진적으로 증가하는 ChatGPT Voice 세션의 일부를 기존의 Advanced Voice Mode 경험과 새로운 시스템 모두에 라우팅했습니다. Advanced Voice Mode는 사용자를 계속해서 서비스했고, 그림자 경로는 읽기 전용 모드에서 추론을 실행했습니다. 이는 사용자가 듣는 내용을 변경하지 않고 실제 클라이언트, 네트워크, 세션 길이, 지리적 분포에 시스템을 노출시켰습니다.

첫 번째 교훈 중 하나는 용량이 GPU 처리량으로 축소될 수 없다는 것이었습니다. 음성 세션은 열려 있고 프레임을 지속적으로 전송하므로, CPU 측 스트림 핸들러, 대기열 및 네트워크 경로는 추론과 함께 확장되어야 합니다. 실제 부하에서는 지원 구성 요소가 부하 테스트 추정치보다 일찍 포화되어 추론 요청이 누적되고 지연이 복합되었습니다. 우리는 용량 문제를 "GPU가 얼마나 많은 요청을 처리할 수 있는가?"에서 "시스템이 모든 프레임을 일정에 맞춰 유지하면서 얼마나 많은 동시 세션을 유지할 수 있는가?"로 변경했습니다.

테스트는 또한 지리적 위치를 일차적인 문제로 만들었습니다. 먼 용량으로 세션을 라우팅하면 시작 및 스트리밍 중 여러 지점에서 지연이 추가될 수 있습니다. 우리는 모델 롤아웃을 지역 용량 및 트래픽 스티어링 구성과 함께 검증한 다음, 지리적 출처별로 지연을 분해하기 시작했습니다. 추론을 사용자에게 더 가깝게 이동하는 것은 도움이 되었지만, 이는 또한 더 넓은 교훈을 강화했습니다: 끝에서 끝까지의 응답성은 경로의 모든 서비스에 달려 있으며, 모델 서버만이 아닙니다.

다른 실패는 현실적인 세션 수명 주기에서만 나타났습니다. 장기 실행 세션은 메모리 및 지속성 압력을 드러냈습니다. 재연결은 압축 및 상태 복원을 시도했습니다. 일반적인 클라이언트 연결 끊기는 종료 핸드셰이크에서 경합을 드러냈습니다. 이러한 문제는 시간, 누적 상태 및 서비스 경계를 넘는 동작에 의존했기 때문에 짧은 부하 테스트에서는 거의 나타나지 않았습니다.

마지막으로, 프로덕션 테스트는 관찰 가능성과 롤아웃 제어를 개선해야 했습니다. 우리는 서로 다른 지연 원인을 혼합한 메트릭, 개별적으로 건강하지 않은 엔진을 숨기는 대시보드의 집계, 테스트된 시스템과 배포된 시스템 간의 구성 드리프트를 발견했습니다. 이에 대응하여, 우리는 더 세분화된 원격 측정, 알려진 좋은 구성에 대한 검증, 단계적 램프, 개별 경로를 빠르게 격리하거나 비활성화할 수 있는 기능을 추가했습니다. 소리 없는 테스트는 시스템이 수용할 수 있는 트래픽의 양뿐만 아니라, 실패를 얼마나 빨리 감지하고, 격리하고, 복구할 수 있는지에 대한 초기 출시 리허설이 되었습니다.

클라이언트에서 모델까지의 응답성

ChatGPT 규모로 GPT-Live를 도입하기 위해서는 음성이 흐르는 것을 중심으로 한 완전히 새로운 시스템이 필요했습니다. 스트리밍 추론은 풀 듀플렉스 모델에 오디오를 공급합니다. 전용 미디어 경로는 신뢰할 수 있는 프레임 전달을 보장합니다. 비동기 위임은 더 깊은 생각을 병행하여 실행할 수 있게 합니다. 최적화된 전송은 사용자에게까지 응답성을 유지합니다.

GPT-Live의 아키텍처는 이미 실시간 상호작용을 위한 더 넓은 플랫폼이 되고 있습니다. 이는 대화에서 에이전트 조정으로 확장되는 ChatGPT Voice를 지원하며, 곧 출시될 GPT-Live API의 기반이 될 것입니다. 시간이 지남에 따라, 이는 음성 경험이 더 많은 장치, 앱 및 모달리티를 아우르면서도 음성 대화가 실시간으로 느껴지게 하는 즉각성을 희생하지 않도록 할 것입니다.

이러한 종류의 엔지니어링 문제를 해결하고 싶다면, 우리와 함께 일하세요.