OpenAI GPT-Realtime-2: 실시간 음성 인식 완벽 가이드

도착 OpenAI GPT-Realtime-2 및 전체 실시간 음성 모델 제품군 이는 음성 비서, 전화 상담원, 그리고 대화형 경험을 구축하는 방식을 근본적으로 바꾸고 있습니다. 더 이상 단순히 "음성-텍스트" 또는 "텍스트-음성" 변환에 대해 이야기하는 것이 아니라, 마치 사람처럼 어조, 의도, 그리고 맥락을 이해할 수 있는 매끄럽고 지연 ​​시간이 짧은 대화에 대해 이야기하는 것입니다.

이 글에서는 차분하지만 직접적으로 다음 내용을 분석해 보겠습니다. OpenAI 및 Azure OpenAI Realtime API는 어떻게 작동하며, 어떤 유형의 세션이 존재하고, 달성 가능한 지연 시간은 얼마이며, WebRTC, WebSocket 또는 SIP와 어떻게 통합됩니까?어떤 모델들을 사용할 수 있는지, 세션은 어떻게 구성되는지(VAD, 도구, MCP, 멀티모달리티 등), 그리고 어떤 경우에 기존의 STT + LLM + TTS 아키텍처가 여전히 적합한지 알고 싶으신가요? 2026년에 제대로 된 음성 에이전트를 구축하려면 이 모든 것을 알아야 합니다.

GPT-Realtime-2는 무엇이며 어떤 문제를 해결하는가?

기본 아이디어는 간단합니다. 세 개의 개별 모델을 거치지 않고 실시간으로 오디오를 처음부터 끝까지 처리할 수 있는 모델 (STT, LLM, TTS). 전통적으로 AI 음성 워크플로는 다음과 같았습니다.

• 음성-텍스트 변환(STT)사용자의 음성을 텍스트로 변환합니다.
• 법학 석사: 해당 전사본으로부터 텍스트 응답을 생성합니다.
• 텍스트 음성 변환(TTS): 응답을 오디오로 합성합니다.

그 파이프라인은 작동하지만, 각 단계마다 100~300밀리초가 추가됩니다.네트워크 전송, 처리, 대기열 등을 모두 고려하면 상대방이 말을 멈춘 후 1~2초간의 침묵이 발생하기 마련입니다. 전화 통화에서 이 "정적" 공백은 매우 중요합니다. 진행 표시줄도 없고, 통화 중 알림 표시도 없기 때문에 그저 정적만이 흐를 뿐이며, 많은 사람들이 이 순간 전화를 끊어버립니다.

새로운 GPT-Realtime-2를 포함한 GPT-Realtime 제품군의 모델들을 사용하면, 모든 처리는 오디오 신호에서 직접 이루어집니다.이 모델은 어조, 리듬, 감정에 접근할 수 있으며, 텍스트를 재구성하고 재합성할 필요 없이 응답 오디오를 생성할 수 있습니다. 실제로 OpenAI와 Azure는 다음과 같은 내용을 논의합니다. 종단 간 지연 시간은 250~500ms 범위입니다.이는 이미 "대답하기 전에 잠시 생각하는 사람과 이야기하는 것 같은 느낌"이라는 범주에 정확히 들어맞습니다.

이는 속도에만 영향을 미치는 것이 아닙니다. 오디오를 직접 다루기 때문에, 이 모델은 평면적인 전사 과정에서 사라지는 미묘한 뉘앙스를 더 이상 놓치지 않습니다.한숨, 분노나 안도감을 나타내는 어조의 변화, 의심, 웃음… 스페인어권 환경에서는 다른 시장보다 전화 통화에서 감정 표현이 더 풍부한데, 이러한 뉘앙스가 편안한 통화와 답답한 통화를 가르는 중요한 요소가 됩니다.

실시간 세션 유형: 음성 상담, 번역 및 전사

GPT-Realtime-2를 통합하기 전에 가장 먼저 결정해야 할 사항은 다음과 같습니다. 원하는 결과에 따라 어떤 유형의 세션이 필요할까요?실시간 API는 크게 세 가지 패턴을 구분합니다.

1. 음성 상담원 세션(대화)
원하는 것을 표현할 때 사용합니다. 응답, 도구 호출, 상태 관리 기능을 갖춘 완벽한 대화형 비서입니다.클라이언트는 표준 엔드포인트에 연결합니다. /v1/realtime음성 또는 텍스트를 전송하고 모델 응답, 도구 호출, 세션 변경 등의 이벤트를 수신합니다. 이는 다음과 같은 용도의 고전적인 "음성 비서" 모드입니다.

• 고객 서비스 담당자.
• 개인 음성 비서.
• 지속적인 대화 기능을 제공하는 웹 또는 모바일 애플리케이션.

2. 번역 세션 (연속 번역)
여기서의 목표는 다릅니다. API를 동시 실행 인터프리터로 사용하세요.음성 상담원 엔드포인트 대신 다음이 사용됩니다. /v1/realtime/translations클라이언트는 오디오를 지속적으로 전송합니다. 이 서비스는 번역된 오디오와 전사본의 변경 사항을 반환합니다.사용자/지원 담당자 간의 순차적인 대화는 없으며, 번역 세션은 지속적인 흐름으로 진행됩니다.

3. 녹취록 작성 세션 (실시간 녹취)
이 경우에는 우리가 원하는 것은 단지 모델이 음성 응답을 생성하지 않고 실시간으로 오디오에서 텍스트를 추출합니다.음성이 도착하는 대로 녹취록 변경 사항이 수신되지만, 음성 비서의 음성 출력은 없습니다. 자막 제작, 실시간 회의록 작성 또는 대화 분석에 이상적입니다.

요약하자면, 음성 비서가 필요할 때는 음성 상담 세션을 사용하고, 통역이 필요할 때는 번역 기능을 사용하며, 생성된 응답 없이 텍스트만 필요할 때는 전사 기능을 사용하십시오.각 세션 유형에는 고유한 엔드포인트, 이벤트 흐름 및 특정 특성이 있습니다.

사용 가능한 실시간 모델 및 기본 기능

Azure OpenAI 수준에서 음성 및 오디오용 실시간 모델 제품군은 매우 광범위합니다. 일반적으로 배포 가능한 모델은 다음과 같습니다.

• gpt-4o-실시간 미리보기-2024-12-17: GPT-4o 기반의 실시간 변형 모델입니다.
• gpt-4o-미니-실시간-미리보기-2024-12-17더 가볍고 저렴한 버전입니다.
• gpt-realtime-2025-08-28실시간 일반 회선.
• gpt-realtime-mini-2025-10-06 y 2025-12-15비용 최적화 모델.
• gpt-realtime-1.5-2026-02-23: 더 큰 기능을 갖춘 후속 진화.

이 모든 모델은 몇 가지 핵심적인 특징을 공유합니다.

• 최대 32.000개의 토큰으로 구성된 입력 컨텍스트 또한 4.096개의 토큰을 출력하는데, 이는 풍부한 맥락을 가진 심도 있는 대화에 충분한 양입니다.
• 오디오 및 텍스트 모드이 장치들은 오디오를 수신 및 전송할 수 있을 뿐만 아니라 "일반적인" 텍스트도 처리할 수 있습니다.
• /openai/v1 접미사가 붙은 통합 GA 엔드포인트 Azure에서는 실시간 API를 비롯한 모든 작업에 대해 이 기능을 사용할 수 있습니다.

또한, 다음 사항들이 추가됩니다. Cedar 및 Marin과 같은 Realtime API용 특정 음성기존 Alloy와 함께 사용되는 이 제품들은 음성 상호 작용을 더욱 자연스럽게 들리도록 설계되었습니다. 비용이 중요하고 작업 복잡성이 높지 않은 프로젝트에 이상적입니다. gpt-realtime-mini 일반적으로 지연 시간과 가격 면에서 가장 좋은 조합입니다.

API 연결: WebRTC, WebSocket 및 SIP

GPT-Realtime-2와 관련 Realtime API의 큰 장점 중 하나는 다음과 같습니다. 당신은 하나의 교통수단에 얽매일 필요가 없습니다.사용 목적에 따라 선택할 수 있습니다.

웹RTC
이는 권장되는 옵션입니다. 지연 시간이 짧아야 하는 클라이언트 측 애플리케이션(웹 및 모바일)WebRTC는 많은 경우 약 100ms 정도의 응답 시간을 달성하며 브라우저에 최적화된 오디오 관리를 제공합니다.

웹소켓
~에 이상적입니다 서버 간 통신미디어 파이프라인과의 통합 또는 백엔드에서 이벤트 흐름을 더욱 세밀하게 제어하려는 경우에 유용합니다. 일반적인 지연 시간은 약 200ms입니다. 실시간 API를 큐 시스템, 마이크로서비스 또는 배치 오디오 처리와 연결할 때 특히 유용합니다.

SIP(세션 시작 프로토콜)
전화 통화의 세계에서 가장 흥미로운 부분은 바로 이것입니다: Realtime API는 전화 네트워크와의 통합을 위해 SIP를 지원합니다.즉, 중간 오디오 브리지를 직접 설정할 필요 없이 AI 에이전트를 기업 전화 시스템(PBX, 클라우드 PBX, VoIP 제공업체 등)에 직접 연결할 수 있습니다.

스페인이나 남미 대부분 지역과 같은 시장에서는 전화 지원은 여전히 ​​고객과의 주요 연락 채널입니다.이러한 네이티브 SIP 지원은 엔지니어링 복잡성을 크게 줄여줍니다. 즉, 부품 수가 줄어들고, 지연 시간이 단축되며, 비용이 절감되고, 오류 발생 지점이 줄어듭니다.

대화 흐름, 이벤트 및 세션 설정

내부적으로 실시간 세션은 다음을 기반으로 합니다. 세션 생성, 구성, 오디오 전송, 응답 생성, 도구, VAD 등 모든 것을 제어하는 ​​이벤트 시스템입니다.엔드포인트에 대한 연결이 설정되면… /realtime서버는 일반적으로 이벤트로 응답합니다. session.created 다음 내용이 포함되어 있습니다:

• 세션 ID.
• 활성 모델 (예를 들어, gpt-4o-mini-realtime-preview-2024-12-17).
• 지원되는 모드 (음성, 텍스트).
• 초기 설정 및 기본 음성 안내.
• VAD 구성 및 입/출력 오디오 형식.
• 만료일 (세션당 최대 30분).

일반적으로 클라이언트가 연결 후 보내는 첫 번째 메시지는 다음과 같습니다. session.update ~을 위한 세션 동작 미세 조정이 로드에서 다음을 수행할 수 있습니다.

• 정의하다 목소리 사용하기 위해 그리고 지침 보조자의 역할(어조, 한계, 응답 형식 등)
• 선택하세요 입력 및 출력 오디오 형식 (예: 24kHz의 PCM16, 모노).
• 활성화하세요 입력 오디오 녹취록 STT 모델을 나타내는 whisper-1 이벤트를 수신하려면 audio_transcription.completed.
• 구성하기 음성 활동 감지(VAD) 들판을 가로질러 turn_detection.
• 선언하다 MCP 도구 및 서버 모델이 호출할 수 있게 될 것입니다.

일반적인 세션 구성 예시는 다음과 같습니다.

{ "type": "session.update", "session": { "voice": "alloy", "instructions": "", "input_audio_format": "pcm16", "input_audio_transcription": { "model": "whisper-1" }, "turn_detection": { "type": "server_vad", "threshold": 0.5, "prefix_padding_ms": 300, "silence_duration_ms": 200, "create_response": true }, "tools": [] } }

서버는 이벤트를 통해 이를 확인할 것입니다. session.updated 구성이 활성화되었음을 나타냅니다. 그 다음에는, 대화는 다음과 같은 이벤트를 통해 관리됩니다. response.create, response.done, conversation.item.create텍스트 및 오디오 차이점과 도구.

VAD, 대화 순서 및 오디오 흐름 제어

자연스러운 음성 경험을 위한 핵심 요소는 시스템이 사용자의 발화를 종료했는지 감지하는 방식입니다. 실시간 API는 이를 위한 여러 가지 방법을 제공합니다. 음성 활동 감지(VAD)해당 부동산에 의해 관리됨 turn_detection 회의의.

서버_바드
기본 모드입니다. 침묵 구간을 기준으로 오디오를 자동으로 분할합니다.서버는 입력 오디오 버퍼(클라이언트가 이벤트와 함께 보내는 내용)를 유지합니다. input_audio_buffer.append그리고 무음 임계값에 따라 음성 종료를 감지하면 다음과 같은 작업을 수행할 수 있습니다.

• 오디오가 수신되었는지 확인하십시오.
• 응답 생성을 트리거합니다. create_response 는 true.

의미론적_바드
여기 모델이 있습니다 단어와 의미적 맥락을 바탕으로 차례의 끝을 결정하세요.단순히 침묵 때문만은 아닙니다. 사용자의 말을 중간에 끊거나 녹취록을 너무 일찍 단편화할 가능성이 줄어듭니다. 보다 자연스러운 음성 대화에 매우 유용합니다.

없음
이 모드에서는 자동 VAD 기능이 완전히 비활성화됩니다. 고객이 수동으로 근무 시간을 관리합니다.일반적으로 "푸시 투 토크(PTT)" 패턴을 사용합니다. 이는 버퍼 커밋 이벤트를 명시적으로 전송함으로써 사용됩니다. response.create 반응을 유도하고 싶을 때 사용합니다. 이미 외부 VAD나 프로그래밍된 오디오 스트림이 있는 경우에 이상적입니다.

게다가, 그것은 가능하다 자동 응답 생성 없이 서버 VAD를 사용하세요간단히 수정하세요 turn_detection.create_response a false이 시스템은 음성 메시지의 끝을 계속 감지하지만, 사용자가 응답을 보낼 때까지 응답을 시작하지 않습니다. response.create중재 또는 사전 사람 검증이 필요한 시나리오에서 매우 유용합니다.

응답, 취소, 컨텍스트 및 대역 외 사용

응답을 생성하기 위해 클라이언트는 이벤트를 전송합니다. response.create서버는 다음과 같이 응답합니다. response.created 그리고 처리하는 동안 일련의 중간 이벤트를 발생시킵니다.

• response.output_item.added
• conversation.item.created
• response.content_part.added
• response.audio_transcript.delta / response.output_audio_transcript.delta
• response.audio.delta / response.output_audio.delta
• 이벤트 ...done 각 부분(오디오, 텍스트, 콘텐츠)별로.

이러한 삼각주 덕분에, 거의 즉시 오디오 재생을 시작할 수 있습니다.모델은 계속해서 "대화"를 이어갑니다. 대화가 끝나면 메시지를 보냅니다. response.done 최종 구조화된 응답에는 녹취록 및 토큰 사용량 지표가 포함됩니다.

때로는 메인 대화 상태에 답변을 추가하는 것이 바람직하지 않을 수 있습니다. 바로 이럴 때 "…"라는 개념이 유용합니다. 대역 외 응답다음을 사용하여 응답을 작성할 수 있습니다. "conversation": "none" 객체 내부 response이는 다음을 나타냅니다.

• 해당 답변은 기본 대화 스레드에 추가되지 않습니다.
• 사용 가능합니다 response.metadata 주제나 목적에 이름을 붙이기 위해.

통과하는 것도 가능합니다 이러한 대역 외 응답에 대한 사용자 지정 컨텍스트행렬을 사용하여 input 기존 대화 항목이나 추가 메시지를 참조할 수 있습니다. 이는 다음과 같은 작업을 수행하는 우아한 방법입니다.

• 대안적인 답변을 제시하십시오.
• 모델이 고려하는 근무 교대 횟수를 제한합니다.
• 대화의 흐름을 방해하지 않으면서 구체적인 질문을 하세요.

언제든지 필요한 경우 비서를 중단하세요 사용자가 말을 끊거나 더 이상 듣고 싶어하지 않는 경우, 다음을 사용할 수 있습니다. response.cancel게다가 해당 행사 conversation.item.truncate 허용합니다 생성된 오디오와 서버 측 전사본을 잘라냅니다.따라서 그 사람이 전혀 듣지 못한 내용이 문맥에 남아 있지 않도록 합니다.

이미지 입력 ​​및 MCP 호환성

실시간 모델은 오디오와 텍스트에만 국한되지 않습니다. 그들은 대화의 일부로 이미지도 받아들입니다.이는 사용자가 화면에 무언가를 표시하면서 동시에 말할 수 있는 멀티모달 경험의 가능성을 열어줍니다.

이미지를 추가하려면 이벤트가 전송됩니다. conversation.item.create 콘텐츠에 블록이 포함된 input_image 이미지가 base64로 인코딩되었거나 스키마가 포함된 URL data:image그러면 모델은 다음과 같이 될 수 있습니다. 보이는 것을 바탕으로 답변하세요.예를 들어 시각적인 기술 지원이나 가이드 투어에 적합합니다.

반면에 Realtime API는 다음을 지원합니다. MCP(모델 컨텍스트 프로토콜) 서버기본적으로 세션 설정에서 원격 MCP 서버를 도구로 선언할 수 있습니다.

• 당신은 정의합니다 server_label (예를 들어, "줄무늬").
• 당신은 다음을 나타냅니다 server_url인증 토큰과 승인 정책(require_approval).

그렇게 하면 서비스가 알아서 처리해 줍니다. 해당 도구에 대한 호출을 자동으로 관리합니다. 대화 내에서 이루어집니다. 이는 상담원이 직접 전체 오케스트레이션 프로토콜을 구현하지 않고도 상담원이 수행할 수 있는 작업(결제, CRM, ERP 등)을 대폭 확장할 수 있는 매우 강력한 방법입니다.

보안, 식별자 및 관리

최종 사용자, 특히 쉽게 식별할 수 있는 사용자(고객, 환자, 학생 등)와 작업할 때는 다음 방법을 사용하는 것이 좋습니다. 보안 식별자Realtime API는 안정적이고 개인정보 보호를 준수하는 값(예: 해시 처리된 내부 ID)을 헤더에 전송할 수 있도록 합니다. OpenAI-Safety-Identifier.

해당 식별자 필수 사항은 아니지만 권장 사항입니다. 이는 OpenAI가 전체 조직을 폐쇄하지 않고도 악용 사례를 감지하고 완화하는 데 도움이 되기 때문입니다. 문제가 심각해질 경우 특정 사용자에 대해 조치를 취할 수 있습니다. 중요: 다른 API에서 상속받은 것이 아닙니다.이미 사용 중인 경우 safety_identifier Responses API에서는 각 실시간 연결 또는 세션에서 해당 값을 명시적으로 다시 전달해야 합니다.

UI 수준에서는 많은 참조 예제가 통합되어 있습니다. 이벤트 흐름에 직접적으로 개입하는 중재 안전장치예를 들어, 메시지가 도착하기 시작하면 "진행 중"으로 표시하는 것. response.text.delta이벤트 수신 여부에 따라 "실패" 또는 "승인"으로 변경됩니다. guardrail_tripped o response.done이러한 검열 기능은 단순한 언어 필터부터 규제 대상 분야의 엄격한 정책에 이르기까지 사용 사례에 맞게 조정할 수 있습니다.

고급 아키텍처: 감독자, 다중 에이전트 및 핸드오프

"사용자와 소통하는 단일 모델"을 넘어, GPT-Realtime-2와 강력한 텍스트 모델의 결합은 다음과 같은 이점을 제공합니다. 고급 에이전트 패턴OpenAI는 자체 Agents SDK를 통해 이러한 기능 중 일부를 시연한 바 있습니다.

채팅 관리자 패턴
이 아키텍처에서는 역할이 분리되어 있습니다.

• Un 실시간 채팅 상담원 (실시간 모델을 기반으로) 사용자와 소통하고, 데이터를 수집하고, 원활한 의사소통을 유지하고, 간단한 작업을 해결하는 역할을 담당합니다.
• Un 텍스트 슈퍼바이저 모델 (예를 들어, gpt-4.1은) 복잡한 도구 호출, 긴 추론 및 고수준 응답을 처리합니다.

이 접근 방식의 장점:

• 간편한 온보딩이미 잘 구성된 텍스트 챗봇이 있다면 관리자로서 해당 챗봇의 안내 메시지와 도구를 재사용할 수 있습니다.
• 통제된 비용음성 에이전트는 저렴한 Realtime-mini 모델을 사용할 수 있으며, 필요할 때만 더 큰 모델로 확장할 수 있습니다.
• 보다 자연스러운 사용자 경험음성 모델은 즉시 응답하지만, 이후 내부적으로 처리를 위임하기 때문에 최종 콘텐츠를 전달하기까지 약간의 지연이 발생합니다.

순차적 핸드오프 패턴(다중 에이전트)
OpenAI Swarm에서 영감을 받은 이 패턴은 다음을 정의합니다. 전문 에이전트 네트워크한 상담원은 사용자 인증을 처리하고, 다른 상담원은 반품을 처리하고, 또 다른 상담원은 판매를 처리하며, 마지막 상담원은 상담원에게 문의를 전달하는 등 각 상담원의 역할이 다릅니다. 사용자는 의도에 따라 상담원 간에 이동하며, 각 이동은 이벤트와 연동됩니다. session.update 지침과 활성 도구를 변경합니다.

이 모델은 다음을 허용합니다.

• 에이전트를 보유함 매우 길고 구체적인 지침 모든 것을 하나의 거대한 프롬프트에 섞지 않고.
• 적용하다 고위험 지점에서만 더 비싼 추론 모델을 사용합니다. (예를 들어, 환불을 확인하는 경우)
• 구현하다 민감한 데이터 수집을 위한 상태 머신 (이름, 전화번호 등) 문자 하나하나 확인이 필요합니다.

Agents SDK와 Next.js 예제는 일반적으로 다음과 같은 내용을 보여줍니다.

• 에이전트 그래프를 선택하는 "시나리오" 선택기.
• 실시간 이벤트 로깅 및 녹취.
• 자동 VAD와 PTT 모드를 전환하거나 오디오 재생을 비활성화하는 버튼입니다.

Azure OpenAI 실시간: 요구 사항, 예제 및 도구

Azure 에코시스템에서 GPT용 실시간 API는 다음과 같이 통합되어 있습니다. 저지연 음성 상호작용을 위한 GPT-4o 제품군사용하려면 다음이 필요합니다.

• Azure 구독.
• Microsoft Foundry 리소스 호환되는 지역에서.
• API 키 또는 Microsoft 인증 정보를 입력하세요. ID를 입력하세요. (생산에 권장됨)
• GPT 실시간 모델의 구현 (예를 들어, gpt-realtime그 지역에서.

Foundry 포털에서 프로젝트를 구성하고 "빌드"를 선택한 다음, 모델 탭으로 이동하여 실시간 기본 모델을 선택하고 "배포"를 클릭합니다. 그 후에는 다음과 같은 작업도 수행할 수 있습니다. 포털 자체에서 테스트 채팅을 시작하세요:

• 구현 방식을 선택하세요 gpt-realtime.
• 원하시는 경우, 지침, 성격, 응답 형식, 그리고 VAD 임계값, 접두사 패딩, 침묵 시간 등의 매개변수를 조정할 수 있습니다.
• "듣기 시작"을 누르고 마이크에 대고 말하세요.
• 대화를 종료하려면 인터페이스에서 듣기 기능을 중지하면 됩니다.

코드 수준에서는 Python으로 작성된 예제가 있습니다(포함). 도서관 openai[realtime] 그리고 선택적으로, azure-identity 키리스 인증의 경우, C#으로 작성된 일반적인 빠른 시작 가이드에서는 콘솔 프로젝트를 생성하고 환경 변수를 구성합니다. AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_DEPLOYMENT_NAME, AZURE_OPENAI_API_KEY및 사용 RealtimeClient y RealtimeSessionClient 로그인, 문자 전송, 스트리밍 오디오 및 문자 수신 등

예시들은 예상되는 출력 유형을 명확하게 보여줍니다. 예를 들어 텍스트 변경 사항 등이 있습니다. "나는", "잘 지내고 있다", "괜찮다" 또한 4.800, 7.200, 12.000바이트 등의 오디오 블록을 사용하여 "네, 도와드리겠습니다. 어떤 도움이 필요하신가요?"와 같은 완전한 문장을 구성할 수 있습니다. 이러한 세분성 덕분에 자막 동기화, UI에 부분 텍스트 표시, 지연 시간 디버깅 등이 가능합니다.

오디오 형식, 제한 사항, 오류 및 모범 사례

골칫거리를 피하려면 API가 요구하는 사항을 준수하는 것이 가장 좋습니다. 오디오 형식:

• PCM16 (16비트 선형).
• 혈액 요소 질소 (단일 채널).
• 24 kHz 샘플링 주파수.

파일을 사용하려면 일반적으로 변환 프로그램을 사용하여 변환하는 것이 좋습니다. FFmpeg, 예를 들어:

ffmpeg -i input.wav -ar 24000 -ac 1 -f s16le input.pcm

JSON을 통해 오디오를 전송할 때, 조각들은 다음과 같아야 합니다. base64로 인코딩됨 그리고 그것들을 잘게 썰어서 드시는 것이 좋습니다. 약 100ms 단위의 덩어리 네트워크 또는 세션에 과부하가 걸리는 것을 방지하기 위해서입니다. 세션 자체는 다음과 같은 특징을 가지고 있습니다. 최대 소요 시간은 약 30분입니다.그 이후에는 연결을 다시 설정해야 하며, 연속성을 유지하려면 새 세션에서 컨텍스트를 다시 구축해야 합니다.

오류와 관련하여 가장 흔한 문제는 다음과 같습니다.

• 401 권한 없음유효하지 않은 키이거나 키리스 인증 방식과 충돌합니다(예: 환경 변수). AZURE_OPENAI_API_KEY (있어서는 안 될 때 만들어진 것).
• 429 요청이 너무 많습니다속도 제한을 초과했으므로 재시도를 구현해야 합니다. 지수적 되돌림 포털에서 수수료를 확인하세요.
• WebSocket 연결 오류차단된 포트, 잘못 구성된 프록시, 잘못된 엔드포인트 등은 일반적으로 유효성 검사를 통해 해결됩니다. https://<endpoint>/openai/v1 그리고 443번 포트가 작동 중이라는 것입니다.

마지막으로, 실시간 세션과 채팅 완료에는 별도의 할당량이 적용됩니다.따라서 두 가지 접근 방식을 동시에 사용하는 경우 두 가지 모두를 모니터링하는 것이 좋습니다.

종합적으로 볼 때, GPT-Realtime-2와 그 주변의 실시간 생태계를 통해 단편적인 음성 프로토타입에서 벗어나 제품의 요구 사항에 따라 단순하거나 정교한 아키텍처로 말하고, 듣고, 이해하고, 거의 실시간으로 대응하는 대화형 에이전트로 전환할 수 있습니다. 세션 유형, 전송 방식(WebRTC, WebSocket, SIP), VAD 구성 및 모델을 적절히 선택하면 느리고 반응이 느린 로봇에서 벗어나 마치 끊임없이 통화에 응대하는 사람과의 자연스러운 대화에 훨씬 가까운 경험을 제공할 수 있습니다.