En el módulo 4 cerramos las dos mitades de la conversación: ya sabemos escuchar (el ASR convierte el audio del usuario en texto) y ya sabemos hablar (el TTS convierte la respuesta del modelo en audio). Con esas dos piezas más un LLM en el medio, técnicamente tienes un agente de voz. Y aun así, cuando lo pruebas por primera vez, se siente mal. No porque entienda poco ni porque hable feo, sino porque tarda. Pides algo, hay un silencio que se estira, y para cuando el agente contesta ya perdiste la sensación de estar conversando. Este módulo trata del problema que ninguna de las piezas anteriores resuelve por sí sola: hacer que todo eso ocurra lo bastante rápido para que se sienta una conversación y no un intercambio de mensajes de voz.

La tesis del módulo

En una conversación humana el turno cambia en ~200–300 ms; cada milisegundo que un agente de voz tarda de más rompe la ilusión de estar hablando con alguien. La latencia no es una métrica más que se optimiza al final: es la que decide si el producto se siente vivo o roto. Un agente que responde perfecto en dos segundos pierde contra uno que responde aceptable en seiscientos milisegundos, porque el segundo se siente humano y el primero se siente una máquina.

Por qué la conversación es implacable con el tiempo

Latencia (el tiempo que pasa entre que el usuario termina de hablar y empieza a oír la respuesta). En texto, un chat que tarda dos segundos en responder es normal; nadie se queja. En voz, ese mismo retardo es insoportable, y la razón es biológica: en una conversación humana el silencio entre turnos ronda los 200 a 300 ms. Es uno de los tiempos más estables que se han medido en el habla, casi igual en todos los idiomas. Tu cerebro lo usa como señal: si el silencio se alarga, interpretas que algo pasa —que el otro no te oyó, que se ofendió, que se cortó la llamada— y reaccionas repitiendo o interrumpiendo.

Un agente de voz que tarda 1500 ms cae de lleno en esa zona de alarma. El usuario no piensa “el modelo está razonando”: piensa “no me escuchó” y empieza a hablar encima. Por eso la latencia en voz no se compara contra la latencia de un chat, se compara contra la conversación humana, y esa vara es brutal. La meta práctica de la industria es quedar por debajo de ~800 ms de punta a punta; bajo esos 800 ms el sistema deja de sentirse un trámite y empieza a sentirse un interlocutor.

El presupuesto de latencia de un turno

La herramienta central de este módulo es el presupuesto de latencia (repartir un número total de milisegundos —digamos 800— entre todas las etapas de la cadena, de modo que la suma no lo exceda). Es exactamente como un presupuesto de dinero: si el ASR se gasta 300 ms, al resto le quedan 500 para repartirse. Descomponer el turno obliga a ver que el tiempo no se va en un solo lado.

La cadena de un turno de voz tiene estas etapas, en orden:

Captura y red de subida — el audio del micrófono viaja hasta tu servidor.
Endpointing — detectar que el usuario terminó de hablar (lo vemos a fondo en voz-07). No puedes empezar a responder hasta saber que el turno acabó, y esperar de más agrega silencio.
ASR (Automatic Speech Recognition, el paso de audio a texto).
El LLM — donde entra el TTFT (time-to-first-token, el tiempo hasta el primer token de la respuesta). Si el modelo “razona” antes de contestar, esos tokens de pensamiento se pagan aquí.
TTS (Text-to-Speech, texto a audio) — con su time-to-first-audio, el tiempo hasta el primer fragmento de sonido reproducible.
Red de bajada — el audio generado viaja de vuelta al usuario.
Buffering del cliente — el reproductor acumula unos milisegundos de audio antes de empezar, para que no se corte.

Dibujado como cascada, con un presupuesto de ejemplo que suma ~800 ms:

        PRESUPUESTO DE LATENCIA DE UN TURNO (~800 ms)

 usuario deja de hablar
        │
        ▼
 ┌────────────────────────┐
 │ endpointing            │  ~150 ms
 └───────────┬────────────┘
             ▼
 ┌────────────────────────┐
 │ red de subida          │  ~40 ms
 └───────────┬────────────┘
             ▼
 ┌────────────────────────┐
 │ ASR (audio a texto)    │  ~120 ms
 └───────────┬────────────┘
             ▼
 ┌────────────────────────┐
 │ LLM  (TTFT)            │  ~250 ms
 └───────────┬────────────┘
             ▼
 ┌────────────────────────┐
 │ TTS (first-audio)      │  ~150 ms
 └───────────┬────────────┘
             ▼
 ┌────────────────────────┐
 │ red bajada + buffer    │  ~80 ms
 └───────────┬────────────┘
             ▼
 usuario oye el 1er sonido   ≈ 790 ms

Ese diagrama es el mapa de todo el módulo. Fíjate en que ninguna etapa es la culpable: el endpointing, el LLM y el TTS pesan casi lo mismo, y si te obsesionas con optimizar solo una, las otras dos te dejan igual de lento. El presupuesto te obliga a mirar la suma, no la estrella.

Batch vs streaming: el error que arruina el presupuesto

Aquí está la decisión que hace o rompe un sistema de voz, y conviene adelantar algo de lo que veremos completo en voz-06.

Batch (por lotes: procesar una entrada completa y devolver la salida completa de una vez). Streaming (por flujo: procesar la entrada a medida que llega y emitir la salida en fragmentos, sin esperar a tenerla toda).

En batch, cada etapa espera a que la anterior termine del todo antes de empezar. El ASR espera a tener todo el audio para dar el texto; el LLM espera a tener todo el texto para empezar a generar; el TTS espera a tener toda la respuesta del modelo para sintetizar el audio. Los tiempos no se solapan: se suman en serie, y sobre esa suma no hay presupuesto que alcance. Peor aún: el TTS en batch no te da nada hasta que la última palabra está lista, así que el usuario oye el primer sonido recién cuando la respuesta entera ya se generó.

En streaming, las etapas se solapan. El ASR emite texto parcial mientras el usuario aún habla; el LLM empieza a generar en cuanto tiene la transcripción; el TTS empieza a sonar en cuanto el LLM emitió la primera frase. Lo que en batch eran cajas que se suman, en streaming son cajas que se encabalgan:

 BATCH (en serie, los tiempos se suman)

 ASR ████████
              LLM ██████████
                            TTS ███████
 ─────────────────────────────────────────►
 primer audio al final de todo:      lento


 STREAMING (solapado, arranca antes)

 ASR ████████
        LLM ██████████
              TTS ███████
 ─────────────────────────────────────────►
 primer audio mucho antes:           rápido

La conclusión operativa es dura y no admite matices: un agente de voz que hace batch en cualquier etapa no puede ser conversacional. El streaming no es una optimización que agregas después; es un requisito de arquitectura que decides al principio.

Latencia, throughput y la cola que importa

Cuatro conceptos que se confunden y que en voz significan cosas muy distintas.

Latencia vs throughput. La latencia es cuánto tarda una respuesta en empezar; el throughput (rendimiento: cuántas peticiones despachas por segundo) es cuántas conversaciones aguantas en paralelo. Un sistema de alto throughput puede tener latencia horrible: procesa mil peticiones agrupándolas en lotes, y cada usuario espera a que su lote se llene. En voz priorizas latencia, casi siempre a costa de throughput.
TTFB / time-to-first-token / time-to-first-audio. El TTFB (time-to-first-byte, tiempo hasta el primer byte de respuesta) es el concepto general: lo que importa no es cuándo termina la salida, sino cuándo empieza. Su versión en el LLM es el TTFT, y en el TTS el time-to-first-audio. En voz, el primer byte de audio es casi lo único que importa para la sensación de rapidez: una vez que el usuario oye la primera sílaba, el resto puede fluir detrás.
p50 vs p95. El p50 (percentil 50 o mediana: la mitad de los turnos son más rápidos, la mitad más lentos) describe el caso típico. El p95 (el turno que solo el 5% de las veces se supera) describe la cola lenta. Y en voz la cola manda: si tu p50 es 600 ms pero tu p95 es 2500 ms, uno de cada veinte turnos se siente roto —y en una conversación de veinte turnos, eso pasa una vez casi seguro. Un p95 malo no es un caso raro: es una llamada arruinada garantizada.
Jitter (inestabilidad: la variación del retardo entre un fragmento de audio y el siguiente). Aunque la latencia media sea buena, si los fragmentos llegan a ritmo irregular el audio se entrecorta y suena peor que un retardo constante mayor. El oído tolera mejor un retraso estable que un tartamudeo.

Las palancas para bajar latencia

Bajar de 800 ms no se logra con un solo truco, sino repartiendo el ahorro por toda la cadena. Estas son las palancas, con lo que cuestan.

Palanca	Dónde actúa	Qué ganas	El precio
Streaming en cada etapa	Toda la cadena	Solapa etapas: el ahorro más grande	Código más complejo (fragmentos parciales)
Modelos más chicos/rápidos	ASR, LLM, TTS	Menos cómputo por token/frame	Menos calidad, más errores
Solapar etapas	LLM → TTS	Empezar a sintetizar antes de que el LLM termine la frase	Reescribes si el modelo se corrige
Prefill / speculative	LLM	Adelantar tokens probables reduce el TTFT	Cómputo extra que a veces se descarta
Cómputo en el edge	Red	Menos distancia = menos round-trips	Infra distribuida, más cara
Evitar round-trips	Red / orquestación	Cada ida y vuelta al servidor son decenas de ms	Menos modularidad

Dos palancas merecen detalle. Modelos más rápidos: en ASR, faster-whisper (una reimplementación de Whisper sobre CTranslate2) corre varias veces más rápido que la referencia original con calidad casi igual, y hay modelos de TTS pensados para streaming que emiten el primer fragmento en decenas de milisegundos. Solapar LLM y TTS: en vez de esperar la respuesta completa del modelo, tomas la primera frase apenas está lista y se la pasas al TTS, mientras el LLM sigue generando el resto. Es la palanca de mayor impacto después del streaming, y también la más delicada: si el modelo se corrige a mitad de frase, ya empezaste a sintetizar algo que hay que rehacer.

En todas las filas aparece el mismo trade-off de calidad vs velocidad: casi cada milisegundo que recortas lo pagas en precisión, en naturalidad o en dinero. El arte del ingeniero de voz es saber dónde ese cambio vale la pena —normalmente en el ASR y el TTS, donde una pérdida pequeña de calidad no se nota— y dónde no.

La tensión con el razonamiento

Hay una palanca que corre en dirección contraria a todo lo anterior, y es importante nombrarla porque tienta. Un modelo que razona —que genera tokens de pensamiento antes de responder, como vimos en el curso de RL sobre razonamiento en producción— da respuestas mejores en tareas difíciles. Pero ese razonamiento agrega segundos, no milisegundos: son cientos o miles de tokens de pensamiento antes del primer token visible, justo el TTFT que tu presupuesto no tiene.

En voz, eso casi nunca cabe. Un turno conversacional de 800 ms no admite un modelo que “piensa” tres segundos antes de abrir la boca. La salida práctica no es prohibir el razonamiento, sino sacarlo del camino crítico: usar un modelo rápido para la respuesta hablada inmediata, y reservar el razonamiento pesado para tareas que corren en segundo plano o que toleran un “dame un segundo que reviso eso”. El razonamiento y la voz en tiempo real viven en presupuestos de tiempo distintos, y mezclarlos sin pensarlo rompe la conversación.

Ojo: el error más común es optimizar la media y olvidar el p95. Reportas “latencia promedio 620 ms”, todos contentos, y el producto se siente lento igual, porque el usuario no vive el promedio: vive la cola. Basta con que uno de cada veinte turnos se dispare para que cada llamada tenga su momento roto. Optimiza el p95 primero; el p50 casi siempre se arregla solo.

Cuidado: medir la latencia por componente aislado y sumar los números en una planilla. Los tiempos reales se solapan, compiten por CPU y red, y aparecen esperas entre etapas que ningún componente reporta. La única medición que vale es extremo a extremo: desde que el usuario deja de hablar hasta que oye el primer sonido, con reloj real, sobre el sistema completo corriendo junto.

Errores comunes

Tratar la latencia como una optimización para el final. En voz es una decisión de arquitectura del día uno: si elegiste batch en alguna etapa, ya perdiste, y refactorizar a streaming después es rehacer medio sistema.
Optimizar una sola etapa. El endpointing, el LLM y el TTS pesan parecido. Recortar el LLM a la mitad mientras el endpointing te roba 400 ms no mueve la aguja. Mira el presupuesto completo.
Reportar solo la media. El promedio esconde la cola, y la cola es lo que el usuario siente. Reporta p95 junto al p50, siempre.
Medir por componente y sumar. Los tiempos se solapan y hay esperas invisibles entre etapas. Solo la medición extremo a extremo sobre el sistema real dice la verdad.
Meter un modelo que razona en el camino crítico. Los tokens de pensamiento agregan segundos, no milisegundos. En voz casi nunca caben; sácalos del turno hablado.
Ignorar el jitter. Una latencia media buena con fragmentos que llegan a ritmo irregular suena peor que un retardo constante mayor. El oído castiga el tartamudeo.
Esperar de más en el endpointing. Cada milisegundo que dudas si el usuario terminó es silencio puro que se suma antes de que empiece a trabajar cualquier otra etapa.

La frase para llevarse

“En texto la latencia es una molestia; en voz es el producto. Nadie recuerda que el agente respondió bien: recuerdan que respondió a tiempo, o que no.”

Qué viene

Módulo 6: streaming en tiempo real. Este módulo argumentó por qué el streaming es obligatorio; el próximo muestra cómo se construye. Vamos a armar la cadena completa con audio que fluye en fragmentos: el ASR emitiendo transcripción parcial, el LLM generando token a token, el TTS sonando antes de que la respuesta esté completa, y el pegamento que sincroniza todo eso sin que se atropelle. Con el protocolo de transporte, el manejo de fragmentos y el código real que solapa las etapas para que ese presupuesto de 800 ms deje de ser una meta y sea lo que mides todos los días.

Voz e IA — Módulo 5: latencia — el enemigo de una conversación