Saltar a contenido
01 de 06Agentes de voz en tiempo real

Capítulo 1 — Arquitecturas de voz: dónde colocas la frontera de texto

Biblioteca

Series y notas técnicas.

Estás en Agentes de voz en tiempo real · Arquitecturas de voz.

Serie

Agentes de voz en tiempo real

6 contenidos

Ver vídeo, resumen y contenidos relacionados

Lectura estimada25 min

Un agente de voz necesita resolver tres problemas distintos: entender audio, decidir qué hacer y producir audio. La arquitectura cambia según dónde separemos esas responsabilidades y qué representación cruza cada frontera.

La comparación suele resumirse como cascade vs speech-to-speech, pero esa frase mezcla conceptos de distinto nivel. Full cascade, audio-native con salida textual y speech-to-speech describen dónde aparece el texto. Full-duplex describe si el sistema puede escuchar y hablar de forma solapada. Un sistema speech-to-speech puede seguir trabajando por turnos; un cascade puede soportar interrupciones y streaming sin convertirse por ello en S2S.

Ese es el modelo mental de este capítulo: primero localizamos la frontera de texto; después preguntamos cómo se coordinan los turnos.

Mapa

¿Dónde colocas la frontera de texto?

La frontera cambia qué puedes observar, sustituir y preservar.

Audio→STT→LLM→TTS→Audio
Audio→Modelo audio-native→Texto→TTS→Audio
Audio→S2S→Audio
El texto separa STT, modelo y voz.El audio entra al modelo. La voz sigue detrás de texto.El camino acústico no exige una frontera textual intermedia.

Tres arquitecturas de modalidad

1. Full cascade: audio → STT → LLM → TTS → audio

En un full cascade clásico, cada etapa tiene un contrato explícito:

Text Only
audio del usuario
→ detección de actividad / fin de turno
→ STT
→ texto
→ LLM + tools
→ texto de respuesta
→ TTS
→ audio al usuario

LiveKit documenta este patrón como una de las dos familias principales para construir voice agents: un pipeline que encadena modelos especializados de STT, LLM y TTS frente a un modelo realtime directo.1

La ventaja principal no es que sea sencillo. En producción puede ser una máquina de estados bastante compleja. La ventaja es que sus fronteras son visibles: podemos conservar la transcripción, sustituir el TTS, medir el tiempo de cada etapa y aplicar políticas sobre texto antes de sintetizarlo.

Esto hace que full cascade sea especialmente útil cuando importan:

  • La elección independiente de proveedores por idioma o mercado.
  • Un TTS concreto por identidad de voz o pronunciación.
  • La inspección textual de entradas, tool calls y respuestas.
  • La posibilidad de optimizar cada componente por separado.
  • La capacidad de aislar fallos y decidir qué componente reintentar, cancelar o sustituir.

El coste de esa modularidad es coordinación. El STT puede seguir revisando una hipótesis mientras el LLM ya genera; el TTS puede tener audio en cola cuando el usuario interrumpe; una tool puede continuar ejecutándose después de cancelar la respuesta hablada. Por eso la latencia percibida no es sólo la suma de tres modelos.

Si medimos desde que el usuario deja de hablar hasta el primer audio reproducible, sumar T_STT + T_LLM + T_TTS como si todo ocurriera en serie puede contar dos veces trabajo que ya ocurrió o que se solapa. En un pipeline con streaming, el STT puede emitir hipótesis parciales mientras el usuario habla, el runtime puede iniciar la generación cuando dispone del turno y del texto necesarios, y el TTS puede sintetizar los primeros fragmentos mientras el modelo continúa generando. LiveKit describe explícitamente este solapamiento entre etapas en su arquitectura de pipeline.3

Una descomposición más fiel es seguir el camino crítico desde el fin del habla hasta audio reproducible:

Text Only
speech_stop_to_first_audio_ms
= duración del camino crítico entre:
  commit / endpointing del turno
  finalización residual del STT, si queda trabajo pendiente
  modelo → primer texto suficiente para hablar
  TTS → primer audio reproducible
  transporte + buffer de reproducción

La palabra residual importa: si el STT ya trabajó durante el turno, esa latencia previa no debe volver a sumarse después de speech_stop. Del mismo modo, la generación completa del LLM no bloquea el primer audio cuando el TTS consume texto en streaming. Como los intervalos exactos dependen del runtime y del proveedor, conviene medir timestamps del mismo turno y reconstruir el camino crítico en lugar de sumar cifras de latencia publicadas de componentes aislados.

El explorador de latencia para agentes de voz permite convertir esa descomposición en un presupuesto explícito. En el capítulo dedicado a latencia separaremos además cuándo puede solaparse trabajo y cuándo una etapa bloquea realmente a la siguiente.

2. Audio-native con salida textual + TTS externo

Half-cascade no es un estándar formal, pero el término ya aparece en frameworks de producción. LiveKit, por ejemplo, define half-cascade como un modelo realtime que entiende el audio y devuelve texto, emparejado con un TTS separado.2 En esta serie usaremos el término exactamente en ese sentido:

Text Only
audio del usuario
→ modelo realtime que entiende audio directamente
→ texto de respuesta en streaming
→ TTS externo
→ audio al usuario

La diferencia con full cascade está en la entrada: el modelo conversacional ya no depende de una transcripción como única representación del turno. La diferencia con S2S está en la salida: la voz sigue estando detrás de una frontera textual.

Esta arquitectura sólo existe si el proveedor realtime permite una modalidad de respuesta exclusivamente textual. LiveKit lo señala explícitamente como requisito y advierte de que el soporte varía por proveedor.2 En OpenAI Realtime, el contrato de sesión permite pedir output_modalities: ["text"], que fuerza una respuesta sólo textual; no se puede pedir texto y audio simultáneamente en esa misma respuesta.36 gpt-realtime-2.1, además, declara entrada/salida de texto y audio y function calling.37 OpenAI marcó el anterior gpt-realtime como deprecated el 20 de julio de 2026 y recomienda gpt-realtime-2.1 antes de su retirada de la API el 20 de enero de 2027.38 Esto demuestra el requisito para ese provider concreto; no debe extrapolarse a cualquier modelo realtime.

Esta arquitectura tiene sentido cuando la señal acústica aporta información útil a la comprensión, pero el producto quiere conservar un sintetizador especializado. El trade-off importante es fácil de pasar por alto: la prosodia puede llegar al modelo y perderse de nuevo al cruzar la salida textual.

Si el usuario habla con prisa o frustración y el modelo genera únicamente:

Text Only
Entiendo. Voy a revisarlo.

el TTS necesita su propio mecanismo para decidir ritmo, energía o énfasis. La arquitectura no resuelve automáticamente esa transferencia expresiva.

Por eso conviene tratar el texto entre modelo y TTS como un contrato, no como un detalle de implementación. Puede ser suficiente texto plano; puede incluir instrucciones de estilo; o puede reservarse el control expresivo a un TTS capaz de interpretar el contexto. La decisión debe evaluarse con audio real, no asumirse por el diagrama.

3. Speech-to-speech: audio → modelo → audio

En speech-to-speech, la conversación no necesita cruzar una representación textual obligatoria entre comprensión y generación:

Text Only
audio del usuario
→ modelo speech-to-speech
→ audio del agente

OpenAI describe la Realtime API como una vía para transmitir audio de entrada y salida directamente y señala que el pipeline ASR → modelo de texto → TTS puede perder emoción, énfasis y acentos además de añadir latencia.39 Google Live API ofrece igualmente interacción bidireccional en tiempo real con entrada de audio y salida de audio nativa, manteniendo una sesión persistente sobre WebSocket.40

Reducir fronteras puede mejorar el ritmo conversacional y evitar parte de la reconciliación entre STT, LLM y TTS. Pero speech-to-speech no elimina el resto del sistema. El runtime sigue necesitando estado, tools, permisos, trazas, cancelación, idempotencia, observabilidad y una definición precisa de qué audio llegó realmente al usuario.

Los modelos realtime también pueden hacer tool calling. gpt-realtime-2.1 expone function calling, y Gemini Live requiere que la aplicación ejecute la función y devuelva el resultado a la sesión.3741 La frontera de negocio sigue fuera del modelo aunque la frontera acústica se haya simplificado.

Full-duplex es otro eje

Full-duplex significa que entrada y salida pueden coexistir en el tiempo. No significa simplemente que el modelo acepte audio y devuelva audio.

Un sistema S2S turn-based puede hacer esto:

Text Only
usuario habla → espera → agente habla → espera → usuario habla

Un sistema full-duplex puede mantener actividad en ambas direcciones y decidir continuamente si debe escuchar, responder, pausar, interrumpir o producir un backchannel. GPT-Live, por ejemplo, se describe explícitamente como una arquitectura full-duplex que procesa entrada mientras genera salida y toma decisiones de interacción varias veces por segundo.42

La distinción no depende de una sola implementación comercial. Moshi modela en streams paralelos el habla del usuario y la del asistente para representar solapamientos, interrupciones e interjecciones sin depender de una segmentación explícita en turnos.43

Full-duplex

Escuchar mientras habla.

Full-duplex es solapamiento con control.

Usuario
Agente“ajá”
CoordinaciónEstado, tools, cancelación y playback siguen siendo responsabilidades del sistema.

La consecuencia práctica es que modalidad e interacción deben evaluarse por separado:

Pregunta Full cascade Audio-native + TTS Speech-to-speech
¿Dónde aparece texto obligatorio? Entre STT, LLM y TTS Antes del TTS Puede no existir en el camino acústico principal
¿Puedo cambiar la voz sin cambiar el modelo conversacional? Sí Sí Depende del proveedor/modelo
¿La señal acústica entra directamente al modelo conversacional? No, salvo canales auxiliares Sí Sí
¿Tengo transcript y respuesta textual como artefactos naturales? Sí Sí en salida Pueden ser derivados
¿Puede ser full-duplex? Posible, con más coordinación Posible Es el encaje más directo, pero no viene garantizado

La última fila es la que evita la confusión más común: S2S y full-duplex no son sinónimos.

La tabla resume tendencias de diseño, no garantías de comportamiento. Un proveedor puede añadir transcripciones, control de voz o mejores mecanismos de interrupción a cualquiera de estas familias. La decisión debe validarse sobre el modelo, transporte, TTS y runtime concretos que vayan a operar el producto.

Qué propiedad favorece cada arquitectura

No hay una ganadora universal. La decisión útil empieza por preguntar qué propiedad del producto no queremos degradar.

Decisión

¿Qué propiedad quieres proteger?

La arquitectura cambia el tipo de control que conservas.

↑ más fronteras de texto más continuidad acústica →
Full cascadefronteras explícitas · componentes sustituibles
Audio-native + TTSaudio original · voz separada
Speech-to-speechcontinuidad acústica y menos fronteras de modalidad
El vector indica presión de diseño hacia una región; no representa una magnitud, calidad ni latencia.
Proteger fronteras: favorece contratos textuales visibles y componentes sustituibles. Proteger señal + voz: favorece conservar audio original hacia el modelo sin acoplar la voz al mismo modelo. Proteger continuidad acústica: favorece reducir fronteras de modalidad en el camino principal.
Mapa conceptual ordinal, no benchmark cuantitativo. La posición resume la estructura de modalidad; runtime, provider y canal siguen pudiendo cambiar el resultado operativo.

Full cascade favorece modularidad y auditabilidad

Es una buena base cuando la transcripción debe ser un artefacto de primera clase, la voz necesita un TTS específico, el equipo quiere cambiar proveedores por etapa o los controles operativos se expresan mejor sobre texto.

Audio-native + TTS favorece comprensión acústica y control de voz

Tiene sentido cuando queremos que el modelo escuche la señal original pero seguimos necesitando una voz externa, pronunciaciones controladas o una salida textual explícita antes de hablar.

Speech-to-speech reduce fronteras y favorece continuidad acústica

Es una base fuerte cuando el ritmo, las interrupciones y la expresividad pesan más que la capacidad de sustituir cada etapa de forma independiente. A cambio, obliga a instrumentar mejor qué ocurrió dentro de la sesión y qué escuchó realmente el usuario.

Segunda decisión: cuánto runtime quieres poseer

Elegir cascade, half-cascade o S2S no decide quién implementa el runtime. LiveKit Agents, Pipecat y una implementación Python directa operan en otra capa: conectan media, modelos, turn-taking, tools, estado y lifecycle. Cualquiera de los tres puede participar en más de una arquitectura de modalidad según los providers que conectes.

LiveKit Agents coloca AgentSession como orquestador de la sesión y conecta al agente con participantes mediante la infraestructura realtime de LiveKit. El framework incluye abstracciones para pipeline de voz, turn detection, interrupciones y lifecycle del worker; el servidor de agentes anuncia capacidad, aísla jobs por proceso y puede redistribuir sesiones cuando un worker desaparece.456 Eso no convierte todas las capacidades de LiveKit Cloud en capacidades del framework: el framework y SIP pueden autohospedarse, mientras que hosting gestionado, observabilidad integrada y otras superficies operativas son servicios de Cloud.7

Pipecat organiza el runtime como una secuencia de FrameProcessor por la que circulan frames de audio, texto, control y lifecycle. El transporte es sustituible: la documentación incluye WebRTC mediante Daily o LiveKit, SmallWebRTC y WebSocket para escenarios controlados/telefonía.1518 Turn-taking, interrupciones, tool calling, métricas y OpenTelemetry están expuestos como primitivas configurables del pipeline.192021 Eso no significa que Pipecat proporcione por sí mismo una red WebRTC global o un carrier telefónico: esas propiedades dependen del transporte y del servicio elegidos.

En Python vanilla/thin el runtime tampoco desaparece: vanilla significa que no delegas la orquestación en un agent framework de este tipo; no significa que implementes WebRTC o SIP desde cero. Hay que separar dos casos. En un camino provider-direct, el navegador puede llevar el audio por WebRTC directamente hasta el endpoint realtime del proveedor mientras el backend autentica al usuario, aplica política y conserva tools/estado de negocio; OpenAI documenta explícitamente esa separación entre audio WebRTC directo y control server-side.32 En un camino más bajo nivel, el servidor puede poseer el audio por WebSocket, RTP/SIP u otro transporte y entonces sí asumir más buffering, packetización y lifecycle de media. En ambos casos la aplicación sigue siendo responsable de los contratos que no delegue: turn-taking, cancelación, estado, tools, retries, reconnect, backpressure, observabilidad, replay/testing, seguridad y scaling. WebRTC estandariza piezas difíciles como ICE/NAT traversal, DTLS/SRTP, negociación de codecs, RTCP, echo cancellation y jitter buffering; quién las opera depende del endpoint de media elegido.33

Matriz de decisión del runtime

Criterio LiveKit Agents Pipecat Python vanilla/thin
Frontera de abstracción Sesión/agente dentro de rooms + worker lifecycle Pipeline de frames + processors + transporte elegible Eventos/protocolo del provider y primitives propios
Media y transporte WebRTC como camino principal; SIP/telephony integrado en el ecosistema LiveKit Daily, LiveKit, SmallWebRTC, WebSocket y serializers según el caso WebRTC provider-direct, Media Streams/WebSocket de carrier con contrato de codec/control del carrier o SIP/RTP propio; sin agent framework, pero el endpoint elegido decide quién posee la media
Pipeline / modalidad STT→LLM→TTS, realtime/S2S y half-cascade cuando el modelo realtime elegido admite salida text-only; cambiar plugin/provider no uniformiza audio, eventos, tools ni semántica de turnos, y full-duplex sigue dependiendo también del modelo, transporte y política de cancelación Pipeline FrameProcessor componible para cascade y S2S/realtime; half-cascade sólo cuando el servicio/modelo elegido expone los modos y eventos necesarios y la pipeline los conecta explícitamente; cambiar provider puede exigir adaptar frames, audio, tools y turnos17 Puede implementar cascade, half-cascade, S2S o full-duplex si la aplicación posee los contratos de protocolo necesarios; máximo control implica máximo ownership
Turnos, cancelación y tools AgentSession ofrece turn handling, interrupciones, eventos y tools Estrategias de turno, InterruptionFrame, cancelación y function calling configurables Contratos propios; máximo control y máxima superficie de correctness
Reliability / flow control Agent Fallback Adapter ejecuta fallback STT/TTS/LLM dentro del proceso; Inference Fallback Adapter vive en LiveKit Inference y cubre STT/TTS. El adapter del proceso no cambia TTS después de enviar audio ni reinicia una respuesta LLM tras emitir texto/tool calls; el gestionado puede reiniciar la petición desde el principio tras un fallo mid-stream. AgentSession emite ErrorEvent y error.recoverable distingue recuperación automática de error terminal1314 CancelFrame, ErrorFrame upstream y colas por processor son primitivas del core; retry/failover y los límites o políticas drop/block/coalesce dependen del processor, transporte, servicio y aplicación, no de una garantía global16 Tú defines límites y política de colas, idempotencia de retries/tools, propagación de cancelación, reglas tras output parcial, clasificación de errores y aislamiento de failure domains
Observabilidad y replay Métricas/data hooks en SDK; Cloud añade timeline, traces y recordings Metrics frames, observers y OpenTelemetry; almacenamiento/replay lo diseñas tú Instrumentación, correlation IDs, audio played y replay son responsabilidad de la app
Testing / evals Tests locales/CI text-based; simulaciones conversacionales en texto o audio en LiveKit Cloud; audio ejercita STT/LLM/TTS y permite degradar el input Pipecat Evals: escenarios text/audio sobre un eval transport; el modo audio ejercita STT/LLM/TTS, no el transporte de producción Harness, fixtures, fakes, replay y judges los diseñas y mantienes tú
Deploy y fallos Worker capacity, job isolation y draining integrados; Cloud puede gestionar hosting Runner/pipeline lifecycle; el modelo de hosting depende de tu runtime o Pipecat Cloud Tú defines aislamiento, autoscaling, draining, reconnect y recovery
Extensibilidad / lock-in Menos código de media; más acoplamiento a rooms/session APIs de LiveKit Muy extensible por processors/transports; acoplamiento al frame model de Pipecat Menor dependencia de framework, pero mayor dependencia de tus contratos y quizá del provider
Coste total Framework Apache-2.0. Self-hosting desplaza media, compute y observabilidad a tu infraestructura; LiveKit Cloud mide por separado media/SIP, sesiones de agent, observabilidad e inference Core BSD-2-Clause. Self-hosting deja compute, transporte, providers y operación en tu stack; Pipecat Cloud puede asumir hosting/scaling/observabilidad, pero transporte y modelos siguen siendo decisiones separadas Puede no haber licencia de framework, pero pagas igualmente provider/modelos, transporte o carrier, compute del backend, observabilidad y la mayor superficie de ingeniería/on-call de los tres caminos

La matriz es deliberadamente compacta. Hay cuatro responsabilidades que conviene separar antes de decidir, porque un nombre de framework puede ocultar en qué capa vive realmente la garantía.

Recovery no equivale a continuidad de estado. LiveKit puede detectar que un agente se desconectó inesperadamente y despachar otro agente a la room, pero esa redistribución no reconstruye por sí sola el estado Python en memoria, una tool externa parcialmente ejecutada ni el punto exacto de audio que ya oyó el usuario.6 Esas piezas necesitan persistencia e idempotencia de aplicación. En Pipecat, reconnect y retry tampoco son una política única del framework: el lifecycle del cliente exige iniciar una nueva conexión después de un disconnect, mientras que transportes o servicios concretos pueden tener sus propios reintentos; por ejemplo, su WebSocketTransport de cliente documenta dos intentos de reconexión y los servicios WebSocket aplican su propia política de backoff.282930 En vanilla, todas esas fronteras y sus invariantes son tuyas. Por eso hay que medir por separado reconnect transport, restart del runtime y recovery del estado de negocio.

Una cola no es backpressure por existir. Pipecat crea una FrameProcessorQueue por processor y la construye sin un límite de tamaño explícito; eso conserva orden/prioridad, pero no define qué debe hacer el producto cuando un consumidor se queda atrás.16 En cualquier runtime hay que decidir el límite y la política por frontera: bloquear, descartar, compactar/coalescer o degradar. Tampoco es seguro reintentar después de haber producido efectos parciales. El Agent Fallback Adapter de LiveKit lo hace visible: TTS no cambia de provider una vez enviado audio y LLM no reinicia por defecto después de emitir texto o tool calls, porque repetir trabajo puede duplicar habla o efectos externos. Su Inference Fallback Adapter gestionado tiene otra semántica y puede reiniciar la petición desde el principio tras un fallo mid-stream.13 En Pipecat custom y en vanilla esas reglas, incluida la idempotencia de tools y la propagación de cancelación, deben quedar explícitas en la aplicación.

La seguridad también se reparte por capas. LiveKit autentica el acceso a rooms con tokens JWT que codifican identidad, room y permisos, y separa grants de media/SIP de los permisos del backend.11 Pipecat core hereda gran parte de la frontera de seguridad del transporte y del despliegue elegidos; cuando se usa Pipecat Cloud, por ejemplo, WebSocket puede protegerse con tokens HMAC de sesión de corta duración, una capacidad de Cloud y no una propiedad universal del pipeline.31 En vanilla debes diseñar explícitamente auth de cliente, credenciales de provider, autorización de tools, secretos, aislamiento de estado y qué datos pueden cruzar cada frontera. Ningún framework sustituye la política de autorización de una tool con efectos reales.

Testing/evals es otra superficie de ownership. LiveKit Agents incluye un test framework text-based para mensajes, tool calls, handoffs y conversaciones multi-turn que puede correr localmente o en CI. Sus Agent Simulations se ejecutan en LiveKit Cloud y la CLI actual expone lk agent simulate audio: el usuario simulado habla y escucha por una pista de audio y el escenario atraviesa el pipeline STT–LLM–TTS; además puede degradarse el input con ruido de fondo, micrófono de baja calidad y packet loss.12 Eso cubre una superficie de audio real dentro del harness de LiveKit, pero no demuestra por sí solo el comportamiento de un carrier PSTN concreto, una trunk SIP, un dispositivo final o una red de usuario real. Pipecat incluye Pipecat Evals como sistema first-party: ejecuta el agente real mediante un eval transport que sustituye Daily/WebRTC/telefonía, acepta escenarios YAML/Python y soporta modo texto y audio. En audio, la voz sintetizada del usuario atraviesa el STT real del agente y la salida hablada usa su TTS real; eso prueba STT/LLM/TTS, turn-taking y barge-in, pero no el transporte de producción ni las condiciones reales de red/telefonía.22 Para validar WebRTC/PSTN, jitter, packet loss o comportamiento de un carrier concreto hay que ejecutar además el transporte real o una simulación específica de esa capa. Vanilla conserva control total sobre clocks, transportes fake, replay y judges, a cambio de construir y mantener todas esas superficies.

El coste total tampoco es el precio del framework. LiveKit Agents es Apache-2.0 y Pipecat core es BSD-2-Clause: poder ejecutar el código open source sin una licencia comercial no hace gratuito el sistema.823 Separa al menos cinco cuentas: modelos/inference, media o carrier, compute del runtime, observabilidad/almacenamiento y horas de ingeniería/operación. LiveKit Cloud documenta esas capas como recursos distintos: media WebRTC/SIP se mide por tiempo y transferencia, las sesiones de agents por tiempo conectado, la observabilidad por eventos y audio grabado, e inference por las unidades del modelo correspondiente.9 Si autohospedas, esas líneas no desaparecen: cambian de proveedor y pasan a tu infraestructura y a tu equipo. Pipecat sigue el mismo principio de ownership: el core puede ejecutarse en tus servidores y Pipecat Cloud puede ejecutar, escalar y observar el agent por ti, mientras que el transporte y los modelos que conectas siguen siendo costes/contratos separados.24

Una forma útil de comparar TCO sin fingir precisión es mantener la ecuación por capas y medirla sobre el mismo workload:

Text Only
coste_por_minuto_exitoso
= modelos + media/carrier + runtime_compute
+ observabilidad/almacenamiento
+ ingeniería/on-call amortizados por minuto exitoso

No uses el precio de una API como proxy del coste total. Un runtime gestionado puede costar más por unidad y reducir mucho el trabajo de operación; un stack vanilla puede facturar menos servicios gestionados y consumir más ingeniería, guardias y debugging. La comparación sólo es válida si conserva el mismo task success, calidad de audio, condiciones de red y nivel de fiabilidad.

Esto deja una diferencia práctica en developer velocity vs control: LiveKit mueve más responsabilidades de media, dispatch y lifecycle a primitives existentes; Pipecat conserva una superficie de composición muy amplia dentro de su frame model; vanilla maximiza control sobre protocolos y scheduling a cambio de una superficie mayor de correctness, operación y tests. La opción correcta es la que elimina trabajo indiferenciado sin ocultar la capa que realmente necesitas modificar.

La tabla no es un ranking. Tampoco hay una afirmación seria del tipo “vanilla siempre tiene menos latencia”. LiveKit puede introducir bridges entre WebRTC y el protocolo del modelo; Pipecat introduce frames, colas y processors; vanilla puede eliminar parte de esa abstracción, pero sigue necesitando buffering, transporte, control de concurrencia y recovery. Sin un benchmark controlado con el mismo hardware, red, provider, modelo, audio path y carga, no publicaremos una diferencia numérica de overhead. La comparación útil es medir el mismo workload y separar tiempo de provider, colas del runtime, transporte y playout.

No elijas el runtime por señales proxy. El número de integraciones, las estrellas de GitHub, una demo fluida, el marketing del proveedor o un benchmark ejecutado con otro modelo, provider, audio path o red no demuestran latencia, fiabilidad ni TCO para tu workload. Para aislar overhead del runtime, mantén constantes hardware, red, provider, modelo, audio path, política de turnos, carga de tools y concurrencia. Para elegir el sistema completo puedes permitir diferencias que formen parte deliberada del diseño, pero documéntalas y no atribuyas al framework lo que proviene del modelo, el carrier o el transporte.

Tres decisiones concretas

1. Voice assistant en browser o móvil. Si usuarios reales llegan desde redes variables y necesitas media robusta, WebRTC es la base natural. LiveKit Agents encaja bien cuando quieres que rooms, media, agent workers y, si lo eliges, operación gestionada formen un sistema coherente.4 Pipecat encaja cuando la prioridad es componer processors/providers y quieres seleccionar Daily o LiveKit como transporte sin cambiar la lógica central del pipeline.1827 Un camino vanilla/thin también puede ser realmente ligero: el browser puede enviar audio por WebRTC directamente al proveedor y el backend quedarse con autenticación, credenciales efímeras, autorización de tools y estado de negocio.32 Eso reduce plumbing propio, pero aumenta el acoplamiento al protocolo del proveedor y no elimina ninguna frontera de seguridad server-side.

2. Agente PSTN. LiveKit es una opción fuerte cuando quieres terminar SIP dentro del mismo sistema de rooms y despachar agents sobre ese lifecycle.10 Pipecat es atractivo cuando ya eliges un carrier/streaming API y quieres que serializers, turn strategies, STT/LLM/TTS y tools vivan en un pipeline sustituible; su FastAPIWebsocketTransport está orientado precisamente a telefonía y conexiones WebSocket server-side.25 Vanilla/thin no exige operar tu propio gateway SIP/RTP: un carrier puede terminar la llamada y exponer media bidireccional por WebSocket. Twilio Media Streams, por ejemplo, entrega audio de la llamada a tu servidor y permite enviar audio de vuelta.34 Pero esa frontera tiene un contrato propio: en un stream bidireccional sólo recibes el track inbound, hay un único Stream por llamada y el audio se entrega como audio/x-mulaw, 8 kHz, mono. El outbound se bufferiza en orden. mark informa cuando Twilio ha terminado de reproducir el audio precedente; si envías clear, Twilio vacía el buffer y devuelve los mark pendientes. Eso permite distinguir audio reproducido por Twilio de audio descartado, pero no demuestra que la persona lo haya oído físicamente. Además, tu servidor debe validar X-Twilio-Signature para autenticar el origen del stream.3435 En ese diseño Python posee el contrato WebSocket/audio y el estado de llamada de aplicación, mientras Twilio posee la terminación telefónica. Es una opción thin cuando ese codec, esa superficie de control y esa frontera de seguridad son suficientes; si necesitas control que el carrier no expone, debes bajar hacia SIP/RTP u otro endpoint de media.

3. Pipeline experimental o custom de bajo nivel. Pipecat es un buen punto medio cuando quieres insertar procesadores propios, cambiar transporte o inspeccionar cada frame sin reimplementar todo el lifecycle.26 Vanilla es preferible cuando el objeto del experimento es precisamente la capa que el framework abstrae —por ejemplo packetization, tamaños de frame, protocolo de eventos del provider, un scheduler duplex propio o instrumentación temporal exacta—. En ese caso el coste extra de implementación compra control experimental, no “simplicidad”.

Hay además un híbrido útil y concreto: Pipecat puede ejecutar su pipeline sobre LiveKitTransport. Eso permite usar LiveKit para rooms/WebRTC y Pipecat para la composición de processors.27 El híbrido merece la pena sólo si cada capa conserva una responsabilidad clara; duplicar turn detection, buffering o retry policies en dos runtimes crea más estados de fallo de los que elimina.

La decisión final debería escribirse como una frase condicional: elige el nivel de abstracción más alto que preserve el control que realmente necesitas. Si la diferenciación del producto está en media y scheduling, baja de nivel. Si está en la lógica del agente y las tools, pagar ingeniería para reconstruir WebRTC, turn-taking y worker lifecycle suele ser una mala asignación de esfuerzo.

Un criterio de decisión reproducible

Antes de elegir arquitectura, prepara el mismo conjunto de conversaciones y ejecuta las variantes con el mismo objetivo de tarea. No compares sólo demos felices.

Incluye al menos:

  • Usuarios que se interrumpen y se corrigen.
  • Ruido, acentos y velocidad de habla variable.
  • Nombres propios, números y códigos alfanuméricos.
  • Tools rápidas y tools lentas.
  • Respuestas que deben cancelarse a mitad de reproducción.
  • Errores parciales de STT, modelo, TTS o red.
  • Conversaciones suficientemente largas para observar acumulación de estado.

Después mide propiedades distintas, no una sola latencia media:

Text Only
turn_detection_delay_ms
speech_stop_to_first_audio_ms
barge_in_to_agent_silence_ms
tool_argument_accuracy
task_success_rate
entity_preservation_rate
voice_consistency
cost_per_successful_minute

El objetivo no es demostrar que una arquitectura es moderna. Es saber qué sistema mantiene la conversación y completa la tarea bajo las restricciones reales de tu producto.

Qué deberías recordar

  • Full cascade, audio-native + TTS y speech-to-speech describen dónde colocamos las fronteras de modalidad.
  • Half-cascade no es un estándar formal; aquí lo usamos en el sentido operativo documentado arriba: audio-in → text-out → TTS, y sólo cuando el modelo realtime admite salida text-only.
  • Speech-to-speech no implica full-duplex.
  • Full-duplex describe solapamiento temporal y control de interacción, no el número de modelos.
  • LiveKit Agents, Pipecat y vanilla Python son decisiones de runtime, no arquitecturas de modalidad.
  • Vanilla/thin no determina quién posee la media: puede usar WebRTC provider-direct, Media Streams de un carrier o un stack SIP/RTP propio.
  • Reducir componentes no elimina tools, estado, permisos, trazas ni recuperación.
  • Open source no significa coste total cero: separa modelos, media/carrier, runtime, observabilidad y operación.
  • Menos dependencias de framework no implica menos complejidad operativa.
  • La arquitectura correcta depende de qué quieras proteger: modularidad, control de voz, señal acústica, timing, auditabilidad, portabilidad o control del runtime.

La nota técnica sobre arquitecturas de agentes de voz profundiza en contratos de streaming, prosodia y una posible separación entre superficie conversacional y plano de ejecución. Los siguientes capítulos de esta serie se centrarán en turn-taking, latencia, tools, transporte y evaluación por separado.

Referencias

  1. LiveKit, Voice AI quickstart. Documenta como alternativas de primer nivel un pipeline STT–LLM–TTS y un modelo realtime directo. ↩

  2. LiveKit, Pipeline types. Define STT–LLM–TTS, realtime y half-cascade; esta última usa un modelo realtime para comprensión y un TTS separado para la salida, y requiere que el proveedor soporte una modalidad de respuesta text-only. ↩↩

  3. LiveKit, Sequential pipeline architecture for voice agents, 23 de marzo de 2026. Explica cómo el STT, la generación del modelo y el TTS se solapan mediante streaming y por qué la latencia end-to-end no debe modelarse como una suma estrictamente bloqueante de etapas completas. ↩

  4. LiveKit, Agents framework introduction. Describe el framework open source, WebRTC hacia usuarios, pipelines y separación respecto a las capacidades gestionadas de LiveKit Cloud. ↩↩

  5. LiveKit, AgentSession. Contrato de orquestación de input, pipeline, tools, turn handling, eventos y control de sesión. ↩

  6. LiveKit, Server lifecycle. Capacity exchange, aislamiento de jobs por proceso, draining y redispatch tras desconexión del agent. ↩↩

  7. LiveKit, Self-hosting overview. Separa Agents framework/SIP autohospedables de hosting, observabilidad e inference gestionados en LiveKit Cloud. ↩

  8. LiveKit Agents, Python package metadata. Declara el framework livekit-agents bajo licencia Apache-2.0. ↩

  9. LiveKit, LiveKit Cloud billing. Documenta metering separado para media WebRTC/SIP, agent deployment, observabilidad e inference y sus unidades de consumo; no se usa aquí para fijar precios, que pueden cambiar. ↩

  10. LiveKit, SIP primer. Flujo SIP/RTP para conectar telefonía tradicional con aplicaciones WebRTC/rooms de LiveKit. ↩

  11. LiveKit, Tokens & grants. Documenta access tokens JWT, identidad, room y permisos/grants para media y SIP. ↩

  12. LiveKit, Testing and evaluation y Agent commands. El test framework es text-based y corre localmente/CI. Las Agent Simulations se ejecutan en LiveKit Cloud; la CLI actual ofrece lk agent simulate audio, que recorre STT–LLM–TTS con una pista de audio del usuario simulado y permite introducir ruido de fondo, micrófono degradado y packet loss. ↩

  13. LiveKit, Fallback strategies. Separa Agent Fallback Adapter, ejecutado dentro del proceso del agent para STT/TTS/LLM, de Inference Fallback Adapter, perteneciente al servicio gestionado LiveKit Inference para STT/TTS. El adapter del proceso protege output parcial; el gestionado puede cambiar de provider y reiniciar la petición desde el principio tras un fallo mid-stream. ↩↩

  14. LiveKit, Events and error handling. AgentSession emite ErrorEvent para errores STT/LLM/TTS/realtime; el objeto de error expone recoverable, que indica si la sesión reintenta automáticamente o si el fallo es terminal tras agotar reintentos. ↩

  15. Pipecat, Pipeline & Frame Processing. Pipeline, FrameProcessor, frames, colas, lifecycle, observers y métricas. ↩

  16. Pipecat, FrameProcessor source. El core implementa FrameProcessorQueue sobre asyncio.PriorityQueue, prioriza frames de sistema, procesa cada processor en sus propias tareas y usa CancelFrame para cancelación; estas primitivas no definen por sí solas una política de backpressure/retry de producto. ↩↩

  17. Pipecat, Building With OpenAI Audio Models and APIs. Documenta en código tanto un pipeline cascade STT→LLM→TTS como un pipeline speech-to-speech sobre OpenAI Realtime; no implica que cualquier provider soporte half-cascade o full-duplex. ↩

  18. Pipecat, Transports y Choosing a Transport. Separa la lógica del pipeline del transporte y documenta Daily, LiveKit, SmallWebRTC y WebSocket con sus ámbitos de uso. ↩↩

  19. Pipecat, User Turn Strategies. Estrategias configurables para inicio/fin de turno e interrupciones. ↩

  20. Pipecat, Function Calling. Tools, contexto, cancelación por interrupción y function calls asíncronas. ↩

  21. Pipecat, Metrics y OpenTelemetry Tracing. TTFB, processing, usage, observers y tracing. ↩

  22. Pipecat, Pipecat Evals. Sistema first-party de desarrollo que ejecuta el agente real sobre un eval transport local en lugar de Daily/WebRTC/telefonía. El modo audio sintetiza la entrada, la pasa por el STT real del agente y evalúa su TTS real; cubre STT/LLM/TTS y comportamiento conversacional, no el transporte de producción ni las condiciones reales de red/telefonía. ↩

  23. Pipecat, LICENSE. Declara Pipecat core bajo BSD 2-Clause. ↩

  24. Pipecat, Pipecat. La superficie oficial separa despliegue self-hosted del core y Pipecat Cloud, que ejecuta, escala y observa agents de forma gestionada; transporte y servicios/modelos siguen siendo componentes elegibles del pipeline. ↩

  25. Pipecat, FastAPIWebsocketTransport. Transporte WebSocket server-side orientado a integraciones de telefonía y serializers. ↩

  26. Pipecat, Custom FrameProcessor. Extensión del pipeline con lógica propia preservando frames de control/lifecycle. ↩

  27. Pipecat, LiveKitTransport. Pipeline Pipecat sobre rooms y WebRTC de LiveKit, autohospedado o Cloud. ↩↩

  28. Pipecat, Session Lifecycle. Documenta estados de sesión y que el cliente debe iniciar una nueva conexión tras disconnect; no define una política universal de reconnect para todos los transportes. ↩

  29. Pipecat, WebSocketTransport. El transporte WebSocket del cliente documenta dos intentos automáticos de reconexión antes de desconectar limpiamente. ↩

  30. Pipecat, Service Events. Los servicios basados en WebSocket documentan una política propia de reconnect con exponential backoff, separada del lifecycle del cliente. ↩

  31. Pipecat, WebSocket Authentication. Capacidad de Pipecat Cloud para proteger conexiones WebSocket con tokens HMAC de sesión de corta duración; no es una propiedad universal de Pipecat core. ↩

  32. OpenAI Agents SDK, Realtime Transport Layer. Documenta audio WebRTC directo browser↔Realtime API con control server-side separado, además de caminos WebSocket, SIP, Twilio y transporte custom; permite distinguir ownership del runtime de ownership del endpoint de media. ↩↩

  33. OpenAI, How OpenAI delivers low-latency voice AI at scale. Detalla las responsabilidades que WebRTC estandariza: ICE/NAT traversal, DTLS/SRTP, codecs, RTCP, echo cancellation y jitter buffering. ↩

  34. Twilio, Media Streams overview. Documenta streams bidireccionales sobre WebSocket para agentes realtime, un único Stream por llamada en modo bidireccional, recepción del track inbound y la obligación de validar X-Twilio-Signature. ↩↩

  35. Twilio, Media Streams — WebSocket Messages. Documenta audio/x-mulaw a 8 kHz mono, buffering FIFO de media outbound y las semánticas de mark/clear; un mark devuelto refleja finalización de playback en Twilio o limpieza del buffer, no evidencia física de audición en el handset. ↩

  36. OpenAI API Reference, Realtime call/session output_modalities. Documenta que output_modalities: ["text"] solicita una respuesta sólo textual y que no se puede pedir texto y audio simultáneamente en la misma respuesta. ↩

  37. OpenAI, GPT-Realtime-2.1 model. Documenta las modalidades de texto/audio y function calling del modelo realtime recomendado actualmente. ↩↩

  38. OpenAI, Deprecations, 20 de julio de 2026. Marca gpt-realtime como deprecated, fija su retirada de la API para el 20 de enero de 2027 y recomienda gpt-realtime-2.1 como replacement. ↩

  39. OpenAI, Introducing the Realtime API. Describe el pipeline ASR → modelo de texto → TTS, la pérdida de señales acústicas y el streaming directo de audio. ↩

  40. Google, Get started with Gemini Live API. Sesiones persistentes, entrada de audio y salida de audio nativa en tiempo real. ↩

  41. Google, Tool use with Live API. Contrato de function calling y devolución explícita de resultados a la sesión. ↩

  42. OpenAI, Introducing GPT-Live, 8 de julio de 2026. Arquitectura full-duplex y separación entre interacción continua y trabajo más profundo. ↩

  43. Défossez et al. (2024), Moshi: a speech-text foundation model for real-time dialogue. Diálogo hablado full-duplex con streams paralelos para usuario y asistente y sin segmentación explícita en turnos. ↩

Continúa aprendiendo
Siguiente capítuloTurn-takingAgentes de voz en tiempo real
Todas las series →