OpenAI GPT-Realtime-2: guía completa de la voz en tiempo real

La llegada de OpenAI GPT-Realtime-2 y toda la familia de modelos de voz en tiempo real está cambiando de raíz la forma en la que se construyen asistentes de voz, agentes telefónicos y experiencias conversacionales. Ya no hablamos solo de “pasar de audio a texto” y “de texto a audio”, sino de conversaciones continuas, con baja latencia y capaces de entender tono, intención y contexto casi como una persona.

En este artículo vamos a desgranar, con calma pero sin rodeos, cómo funciona la API Realtime de OpenAI y Azure OpenAI, qué tipos de sesión existen, qué latencias se pueden conseguir, cómo se integran con WebRTC, WebSocket o SIP, qué modelos están disponibles, cómo se configuran las sesiones (VAD, herramientas, MCP, multimodalidad…) y en qué casos conviene todavía la arquitectura clásica de STT + LLM + TTS. Si quieres montar un agente de voz serio en 2026, aquí tienes la foto completa.

Qué es GPT-Realtime-2 y qué problema resuelve

La idea base es sencilla: un modelo capaz de procesar audio de extremo a extremo, en tiempo real, sin pasar por tres modelos separados (STT, LLM, TTS). Tradicionalmente, el flujo de voz IA ha sido:

• Speech-to-Text (STT): convierte la voz del usuario en texto.
• LLM: genera la respuesta en texto a partir de esa transcripción.
• Text-to-Speech (TTS): sintetiza la respuesta en audio.

Ese pipeline funciona, pero cada paso añade entre 100 y 300 milisegundos. Cuando sumas transporte de red, procesamiento y colas, acabas fácilmente en 1-2 segundos de silencio después de que la persona deja de hablar. Al teléfono, ese hueco “muerto” es crítico: no hay barra de progreso, ni spinner; solo silencio… y mucha gente decide colgar.

Con los modelos de la familia GPT-Realtime, incluido el nuevo GPT-Realtime-2, todo el procesamiento se hace de forma nativa sobre la señal de audio. El modelo tiene acceso al tono, al ritmo, a la emoción, y puede generar audio de respuesta sin tener que reconstruir texto y volver a sintetizar. En la práctica, OpenAI y Azure hablan de latencias punta a punta en el rango de 250-500 ms, que ya entra de lleno en la categoría de “se siente como hablar con alguien que piensa un momento antes de contestar”.

Esto no solo afecta a la velocidad. Al trabajar directamente con audio, el modelo ya no pierde matices que se evaporan en una transcripción plana: suspiros, cambios de tono que indican enfado o alivio, dudas, risas… Para entornos hispanohablantes, donde la interacción telefónica suele ser más expresiva que en otros mercados, este matiz marca la diferencia entre una llamada cómoda y una interacción frustrante.

Tipos de sesión Realtime: voz-agente, traducción y transcripción

Lo primero que hay que decidir antes de integrar GPT-Realtime-2 es qué tipo de sesión necesitas en función del resultado que quieres conseguir. La API en tiempo real distingue tres grandes patrones:

1. Voice-agent session (conversación)
Se usa cuando quieres un asistente conversacional completo, capaz de responder, llamar herramientas y mantener estado. El cliente se conecta al endpoint estándar /v1/realtime, envía audio o texto y recibe eventos con las respuestas del modelo, llamadas a herramientas, cambios de sesión, etc. Es el modo “asistente de voz” clásico para:

• Agentes de atención al cliente.
• Asistentes personales de voz.
• Aplicaciones web o móviles con conversación continua.

2. Translation session (traducción continua)
Aquí el objetivo es otro: usar la API como un intérprete simultáneo. En lugar del endpoint de voz-agente, se usa /v1/realtime/translations. El cliente va enviando audio sin interrupción y el servicio devuelve audio traducido y deltas de transcripción. No hay turnos “usuario/asistente” como tal; la sesión es un flujo continuo de traducción.

3. Transcription session (transcripción en vivo)
En este caso solo queremos texto a partir de audio, en tiempo real, sin que el modelo genere respuestas habladas. Se reciben deltas de transcripción según va llegando el audio, pero no hay output de voz del asistente. Es ideal para subtitulado, actas en tiempo real o analítica de conversaciones.

En resumen, usa sesiones de voz-agente cuando quieres un asistente que hable; usa traducción cuando necesitas un intérprete; y usa transcripción cuando solo quieras texto sin respuesta generada. Cada tipo de sesión tiene su endpoint, su flujo de eventos y sus particularidades.

Modelos Realtime disponibles y capacidades básicas

A nivel de Azure OpenAI, la familia de modelos en tiempo real para voz y audio es amplia. Entre los desplegables habituales destacan:

• gpt-4o-realtime-preview-2024-12-17: variante en tiempo real basada en GPT-4o.
• gpt-4o-mini-realtime-preview-2024-12-17: versión más ligera y barata.
• gpt-realtime-2025-08-28: línea general Realtime.
• gpt-realtime-mini-2025-10-06 y 2025-12-15: modelos optimizados en coste.
• gpt-realtime-1.5-2026-02-23: evolución posterior con mayores capacidades.

Todos estos modelos comparten una serie de características clave:

• Contexto de entrada de hasta 32.000 tokens y salida de 4.096 tokens, más que suficiente para conversaciones ricas y con contexto prolongado.
• Modalidades de audio y texto: pueden recibir y emitir audio, además de manejar texto “clásico”.
• Endpoint GA unificado con sufijo /openai/v1 en Azure, tanto para la API Realtime como para el resto de operaciones.

Además, se añaden voces específicas para la API Realtime, como Cedar y Marin, junto a la clásica Alloy, diseñadas para que las interacciones por voz suenen más naturales. Para proyectos donde el coste es crítico y la complejidad de la tarea no es tan alta, gpt-realtime-mini suele ser la mejor combinación de latencia y precio.

Conexión a la API: WebRTC, WebSocket y SIP

Una de las grandes ventajas de GPT-Realtime-2 y de la API Realtime asociada es que no estás atado a un único método de transporte. Puedes elegir según el tipo de aplicación:

WebRTC
Es la opción recomendada para aplicaciones del lado cliente (web y móvil) donde la prioridad es la latencia baja. Con WebRTC se consiguen tiempos del orden de ~100 ms en muchos casos y una gestión de audio optimizada para navegadores.

WebSocket
Ideal para comunicación servidor a servidor, integraciones con pipelines de medios, o cuando quieres tener más control sobre el flujo de eventos desde el backend. La latencia típica ronda los ~200 ms. Es muy útil cuando conectas la API Realtime con sistemas de colas, microservicios o procesado batch de audio.

SIP (Session Initiation Protocol)
Aquí está la parte más jugosa para el mundo de las llamadas: la API Realtime soporta SIP para integrarse con redes telefónicas. Eso significa que puedes conectar un agente de IA directamente a la infraestructura de telefonía empresarial (PBX, centralitas en la nube, operadores VoIP…) sin montar tú el puente de audio intermedio.

En mercados como España o buena parte de Latinoamérica, donde la atención telefónica sigue siendo el canal principal de contacto con clientes, este soporte SIP nativo reduce muchísimo la complejidad de ingeniería: menos piezas, menos latencia, menos coste y menos puntos de fallo.

Flujo de conversación, eventos y configuración de sesión

Bajo el capó, las sesiones Realtime se basan en un sistema de eventos que controla todo: creación de sesión, configuración, envío de audio, generación de respuestas, herramientas, VAD… Una vez se abre la conexión al endpoint /realtime, el servidor suele responder con un evento session.created que contiene:

• ID de sesión.
• Modelo activo (por ejemplo, gpt-4o-mini-realtime-preview-2024-12-17).
• Modalidades soportadas (audio, texto).
• Instrucciones iniciales y voz por defecto.
• Configuración de VAD y formatos de audio de entrada y salida.
• Fecha de expiración (hasta 30 minutos por sesión).

Normalmente, el primer mensaje que envía el cliente tras conectar es un session.update para afinar el comportamiento de la sesión. En esta carga puedes:

• Definir la voz a utilizar y las instrucciones del asistente (rol, tono, límites, formato de respuesta…).
• Elegir el formato de audio de entrada y salida (por ejemplo, pcm16 a 24 kHz, mono).
• Activar la transcripción de audio de entrada indicando un modelo de STT como whisper-1 para recibir eventos audio_transcription.completed.
• Configurar la detección de actividad de voz (VAD) mediante el campo turn_detection.
• Declarar herramientas y servidores MCP que el modelo podrá invocar.

Un ejemplo típico de configuración de sesión incluye algo así como:

{
  "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": []
  }
}

El servidor confirmará con un evento session.updated indicando que la configuración está activa. A partir de ahí, las conversaciones se gestionan mediante eventos como response.create, response.done, conversation.item.create, deltas de texto y audio, y herramientas.

VAD, turnos de conversación y control del flujo de audio

Un punto esencial para que una experiencia de voz se sienta natural es cómo se detecta que el usuario ha terminado de hablar. Para ello la API Realtime ofrece varios modos de detección de actividad vocal (VAD), controlados por la propiedad turn_detection de la sesión.

server_vad
Es el modo por defecto. Fragmenta el audio automáticamente basándose en silencios. El servidor mantiene un buffer de audio de entrada (lo que envía el cliente con eventos tipo input_audio_buffer.append) y, cuando detecta un final de discurso según el umbral de silencio, puede:

• Confirmar el audio recibido.
• Disparar la generación de una respuesta, si create_response está a true.

semantic_vad
Aquí el modelo decide el final del turno en función de las palabras y el contexto semántico, no solo del silencio. Es menos probable que corte al usuario a mitad de una frase larga o que fragmente la transcripción antes de tiempo. Muy útil para conversaciones de voz a voz más naturales.

none
En este modo desactivas VAD automático por completo. El cliente controla manualmente los turnos, habitualmente con un patrón de “pulsar para hablar” (PTT). Se usa enviando explícitamente eventos de commit de buffer y response.create cuando se quiere provocar una respuesta. Es ideal cuando ya tienes tu propio VAD externo o un flujo de audio programado.

Además, es posible usar VAD del servidor sin que genere respuestas automáticamente. Basta con fijar turn_detection.create_response a false: el sistema sigue detectando finales de voz, pero no inicia respuestas hasta que tú envíes response.create. Es muy útil para escenarios con moderación o validación humana previa.

Respuestas, cancelaciones, contexto y uso fuera de banda

Para generar una respuesta, el cliente envía un evento response.create. El servidor responde con response.created y, mientras procesa, va emitiendo una serie de eventos intermedios:

• 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
• Eventos ...done para cada parte (audio, texto, contenido).

Gracias a estos deltas, puedes empezar a reproducir audio casi inmediatamente, mientras el modelo sigue “hablando”. Cuando termina, envía un response.done con la respuesta final estructurada, incluyendo transcripción y métricas de uso de tokens.

A veces no interesa que una respuesta se añada al estado de conversación principal. Para eso existe el concepto de respuestas fuera de banda. Puedes crear una respuesta con "conversation": "none" dentro del objeto response, lo que indica que:

• Esa respuesta no se incorporará al hilo de conversación por defecto.
• Puedes usar response.metadata para etiquetar el tema o propósito.

También es posible pasar contexto personalizado para estas respuestas fuera de banda, usando la matriz input con referencias a elementos de conversación existentes o mensajes adicionales. Es una forma elegante de:

• Generar respuestas alternativas.
• Limitar la cantidad de turnos que el modelo tiene en cuenta.
• Realizar consultas puntuales sin “contaminar” la conversación principal.

Si en algún momento necesitas interrumpir al asistente porque el usuario habla encima o ya no quiere seguir escuchando, puedes usar response.cancel. Además, el evento conversation.item.truncate permite truncar el audio generado y su transcripción del lado del servidor, para que no quede texto en contexto que la persona nunca llegó a oír.

Entrada de imagen y compatibilidad MCP

Los modelos Realtime no se limitan a audio y texto. También aceptan imágenes como parte de la conversación, lo que abre la puerta a experiencias multimodales, donde el usuario muestra algo en pantalla y habla a la vez:

Para añadir una imagen, se envía un evento conversation.item.create cuyo contenido incluye un bloque input_image con la imagen codificada en base64 o una URL con esquema data:image. El modelo puede entonces fundamentar la respuesta en lo que ve, perfecto por ejemplo para soporte técnico visual o visitas guiadas.

Por otro lado, la API Realtime cuenta con soporte para servidores MCP (Model Context Protocol). Básicamente, puedes declarar un servidor MCP remoto como herramienta en la configuración de sesión:

• Defines un server_label (por ejemplo, «stripe»).
• Indicas la server_url, un token de autorización y la política de aprobación (require_approval).

Con eso, el servicio se encarga de gestionar automáticamente las llamadas a esas herramientas dentro de la conversación. Es una forma muy potente de ampliar a lo bestia lo que el agente puede hacer (pagos, CRM, ERP, etc.) sin tener que implementar tú todo el protocolo de orquestación.

Seguridad, identificadores y moderación

Cuando trabajas con usuarios finales, especialmente identificables (clientes, pacientes, alumnos…), conviene usar identificadores de seguridad. La API Realtime permite enviar un valor estable y respetuoso con la privacidad (por ejemplo, un ID interno hasheado) en la cabecera OpenAI-Safety-Identifier.

Ese identificador no es obligatorio, pero se recomienda porque ayuda a OpenAI a detectar y mitigar abusos sin necesidad de bloquear la organización completa: se puede actuar sobre un usuario concreto si algo se desmadra. Importante: no se hereda de otras APIs; si ya usas safety_identifier en la Responses API, tienes que volver a pasarlo explícitamente en cada conexión o sesión Realtime.

A nivel de UI, muchos ejemplos de referencia integran guardrails de moderación directamente en el flujo de eventos. Por ejemplo, marcando un mensaje como “en progreso” cuando empieza a llegar response.text.delta, y cambiando a “fallido” o “aprobado” según se reciba un evento guardrail_tripped o response.done. Esta moderación se puede adaptar según el caso de uso: desde un simple filtro de lenguaje hasta políticas estrictas en sectores regulados.

Arquitecturas avanzadas: supervisores, multiagente y handoffs

Más allá del “un solo modelo hablando con el usuario”, la combinación de GPT-Realtime-2 con modelos de texto potentes permite patrones avanzados de agentes. La propia OpenAI ha demostrado algunos con su Agents SDK:

Patrón Chat-Supervisor
En esta arquitectura, se separan roles:

• Un chat agent en tiempo real (basado en un modelo Realtime) se encarga de hablar con el usuario, recoger datos, mantener la fluidez y resolver tareas sencillas.
• Un modelo supervisor de texto (por ejemplo, gpt-4.1) gestiona llamadas a herramientas complejas, razonamientos largos y respuestas de alto nivel.

Ventajas de este enfoque:

• Onboarding simple: si ya tienes un chatbot de texto bien afinado, puedes reutilizar su prompt y herramientas como supervisor.
• Coste controlado: el agente de voz puede usar un modelo Realtime-mini barato, mientras que solo escalas al modelo gordo cuando hace falta.
• Experiencia de usuario más natural: el modelo de voz responde enseguida, aunque luego delegue internamente y haya un pequeño retardo antes de dar el contenido final.

Patrón de handoffs secuenciales (multiagente)
Inspirado en OpenAI Swarm, este patrón define un grafo de agentes especializados: uno para autenticar usuarios, otro para devoluciones, otro para ventas, otro para escalar a humanos, etc. El usuario va siendo transferido entre agentes según su intención, y cada cambio se coordina con eventos session.update que cambian instrucciones y herramientas activas.

Este modelo permite:

• Tener agentes con instrucciones muy largas y específicas sin mezclarlo todo en un mega-prompt.
• Aplicar modelos de razonamiento más caros solo en puntos de alto riesgo (por ejemplo, validación de un reembolso).
• Implementar máquinas de estados para recoger datos sensibles (nombre, teléfono…) con confirmaciones carácter a carácter.

El Agents SDK y los ejemplos en Next.js típicamente muestran:

• Un selector de “escenario” para elegir el grafo de agentes.
• Transcripción y log de eventos en tiempo real.
• Botones para alternar entre VAD automático y PTT, o desactivar reproducción de audio.

Azure OpenAI Realtime: requisitos, ejemplos y tooling

En el ecosistema Azure, la API Realtime para GPT se integra dentro de la familia GPT-4o para interacciones de voz de baja latencia. Para usarla, necesitas:

• Suscripción de Azure.
• Un recurso de Microsoft Foundry en una región compatible.
• Clave de API o autenticación con Microsoft Entra ID (recomendada para producción).
• Una implementación de un modelo Realtime de GPT (por ejemplo, gpt-realtime) en esa región.

En el portal de Foundry configuras el proyecto, seleccionas “Compilar”, vas a la pestaña de modelos, eliges el modelo base Realtime y pulsas “Implementar”. Desde ahí, puedes incluso lanzar un chat de prueba en el propio portal:

• Seleccionas la implementación gpt-realtime.
• Si quieres, ajustas instrucciones, personalidad, formato de respuesta y parámetros como umbral de VAD, padding de prefijo o duración del silencio.
• Pulsas “Iniciar escucha” y hablas por el micrófono.
• Para cortar la conversación, paras la escucha desde la interfaz.

A nivel de código, hay ejemplos en Python (con biblioteca openai[realtime] y, opcionalmente, azure-identity para autenticación sin clave) y en C#, con un quickstart típico que crea un proyecto de consola, configura variables de entorno AZURE_OPENAI_ENDPOINT, AZURE_OPENAI_DEPLOYMENT_NAME, AZURE_OPENAI_API_KEY, y usa RealtimeClient y RealtimeSessionClient para iniciar sesiones, enviar texto, recibir audio y texto en streaming, etc.

Los ejemplos enseñan muy bien el tipo de salida que puedes esperar: deltas de texto como «I’m», «doing», «well» y bloques de audio de 4.800, 7.200, 12.000 bytes, etc., hasta componer frases completas del estilo “Sure, I’m here to help. What do you need assistance with?”. Esa granularidad es la que te permite sincronizar subtítulos, mostrar texto parcial en UI o depurar latencias.

Formato de audio, límites, errores y buenas prácticas

Para evitar quebraderos de cabeza, conviene respetar las expectativas de la API en cuanto a formato de audio:

• PCM16 (16 bits lineal).
• Mono (un solo canal).
• 24 kHz de frecuencia de muestreo.

Si vas a usar archivos, lo habitual es convertirlos con FFmpeg, por ejemplo:

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

Cuando envías audio por JSON, los fragmentos deben ir codificados en base64 y es recomendable trocearlos en chunks de unos 100 ms para no saturar la red ni la sesión. Por su parte, las sesiones tienen una duración máxima de unos 30 minutos; pasado ese tiempo hay que renovar la conexión y, si quieres continuidad, reconstruir el contexto en la nueva sesión.

En cuanto a errores, los problemas más habituales son:

• 401 No autorizado: clave inválida o conflicto con autenticación sin clave (por ejemplo, variable de entorno AZURE_OPENAI_API_KEY establecida cuando no debería).
• 429 Too Many Requests: límite de tasa superado, lo que pide implementar reintentos con retroceso exponencial y revisar cuotas en el portal.
• Errores de conexión WebSocket: puertos bloqueados, proxy mal configurado, endpoint incorrecto… suele solucionarse validando https://<endpoint>/openai/v1 y que el puerto 443 esté operativo.

Por último, las sesiones Realtime y las completions de chat tienen cuotas separadas, con lo que es buena idea monitorizar ambas si usas los dos enfoques en paralelo.

En conjunto, GPT-Realtime-2 y el ecosistema Realtime que lo rodea permiten pasar de prototipos de voz “pegados a trozos” a agentes conversacionales que hablan, escuchan, entienden y actúan casi en tiempo real, con arquitecturas tan simples o sofisticadas como necesite tu producto. Con una buena elección de tipo de sesión, transporte (WebRTC, WebSocket, SIP), configuración de VAD y modelo, la experiencia deja de ser un robot lento que contesta a destiempo y se convierte en algo mucho más cercano a una conversación fluida con alguien que, sencillamente, nunca se cansa de atender llamadas.