Phase 06 - Lesson 15

Habla-a-Habla en Streaming — Moshi, Hibiki y Diálogo Full-Duplex

2024-2026 redefinió la IA de voz. Moshi entrega un único modelo que escucha y habla simultáneamente con una latencia de 200 ms. Hibiki hace traducción habla-a-habla bloque por bloque. Ambos abandonan el pipeline ASR → LLM → TTS en favor de una arquitectura full-duplex unificada sobre tokens del códec Mimi. Este es el nuevo diseño de referencia.

Tipo: Aprender Lenguajes: Python Requisitos previos: Fase 6 · 13 (Códecs Neuronales de Audio), Fase 6 · 11 (Audio en Tiempo Real), Fase 7 · 05 (Transformer Completo) Tiempo: ~75 minutos

El Problema

Todo agente de voz construido a partir de las Lecciones 11 + 12 tiene un piso de latencia fundamental en torno a los 300-500 ms: el VAD se dispara, el STT procesa, el LLM razona, el TTS genera. Cada etapa tiene su propia latencia mínima. Puedes ajustar y paralelizar, pero la forma del pipeline te impone un techo.

Moshi (Kyutai, 2024-2026) plantea una pregunta diferente: ¿y si no hubiera pipeline? ¿Y si un único modelo recibiera audio en la entrada y emitiera audio en la salida directamente, de forma continua, con el texto como un "monólogo interior" intermedio en lugar de una etapa obligatoria?

La respuesta es habla-a-habla full-duplex. Latencia teórica de 160 ms (frame Mimi de 80 ms + retardo acústico de 80 ms). Latencia práctica de 200 ms en una sola GPU L4. Eso es la mitad de lo que logra un agente de voz con pipeline de primer nivel.

El Concepto

La arquitectura de Moshi

Entradas. Dos flujos del códec Mimi, ambos a 12,5 Hz × 8 codebooks:

• Flujo 1: audio del usuario (codificado en Mimi, llegando constantemente)
• Flujo 2: el propio audio de Moshi (generado por Moshi)

El transformer. Un Temporal Transformer de 7B parámetros procesa ambos flujos y un flujo de texto de "monólogo interior". En cada paso de 80 ms:

1. Consume los tokens Mimi más recientes del usuario (8 codebooks).
2. Consume los tokens Mimi más recientes de Moshi (8 codebooks, a medida que se producen).
3. Genera el siguiente token de texto de Moshi (monólogo interior).
4. Genera los siguientes tokens Mimi de Moshi (8 codebooks mediante un pequeño Depth Transformer).

Los tres flujos — audio del usuario, audio de Moshi, texto de Moshi — corren en paralelo. Moshi puede oír al usuario mientras habla; puede interrumpirse cuando el usuario interrumpe; puede dar respuestas de retorno ("mhm") sin romper su enunciado principal.

El depth transformer

Dentro de un frame, los 8 codebooks no se predicen en paralelo — tienen dependencias entre codebooks. Un pequeño "depth transformer" de 2 capas los predice secuencialmente dentro de los 80 ms. Esta es la factorización estándar para LMs de códec autorregresivos (también usada por VALL-E y VibeVoice).

Por qué ayuda el texto de monólogo interior

Sin texto explícito, el modelo tiene que modelar el lenguaje de forma implícita en su flujo acústico. La idea clave de Moshi: forzarlo a emitir tokens de texto junto con el audio. El flujo de texto es esencialmente la transcripción de lo que Moshi está diciendo. Esto mejora la coherencia semántica, facilita el reemplazo de una cabeza de modelo de lenguaje y te da transcripciones gratis.

Hibiki: traducción habla-a-habla en streaming

Misma arquitectura, entrenada con pares de traducción. Audio de origen en la entrada, audio en el idioma de destino en la salida, de forma continua. Hibiki-Zero (feb. 2026) elimina la necesidad de datos de entrenamiento alineados a nivel de palabra — usa datos a nivel de oración + aprendizaje por refuerzo GRPO para la optimización de latencia.

Cuatro pares de idiomas soportados inicialmente; puede adaptarse a un nuevo idioma con ≈1000 horas.

El stack más amplio de Kyutai (2026)

• Moshi — diálogo full-duplex (francés primero, inglés bien soportado)
• Hibiki / Hibiki-Zero — traducción de habla simultánea
• Kyutai STT — ASR en streaming (look-ahead de 500 ms o 2,5 s)
• Kyutai Pocket TTS — TTS de 100M de parámetros corre en CPU (ene. 2026)
• Unmute — pipeline completo que combina estos en servidores públicos

Throughput en una GPU L40S: 64 sesiones concurrentes a 3× tiempo real.

Sesame CSM — el primo

Sesame CSM (2025) usa una idea parecida — un backbone Llama-3 con una cabeza de códec Mimi. Pero CSM es unidireccional (recibe contexto + texto, produce habla) en lugar de full-duplex. Es el mejor TTS de "presencia de voz" del mercado; no es exactamente lo mismo que la capacidad full-duplex de Moshi.

Cifras de rendimiento de 2026

Constrúyelo

Paso 1: la interfaz

Moshi expone un servidor WebSocket que recibe bloques de 80 ms de audio codificado en Mimi y devuelve bloques de 80 ms de audio codificado en Mimi. En ambos sentidos. Constantemente.

import asyncio
import websockets
from moshi.client_utils import encode_audio_mimi, decode_audio_mimi

async def moshi_chat():
    async with websockets.connect("ws://localhost:8998/api/chat") as ws:
        mic_task = asyncio.create_task(stream_mic_to(ws))
        spk_task = asyncio.create_task(stream_from_to_speaker(ws))
        await asyncio.gather(mic_task, spk_task)

Paso 2: el bucle full-duplex

async def stream_mic_to(ws):
    async for chunk_80ms in mic_stream_at_12_5_hz():
        mimi_tokens = encode_audio_mimi(chunk_80ms)
        await ws.send(serialize(mimi_tokens))

async def stream_from_to_speaker(ws):
    async for msg in ws:
        mimi_tokens, text_token = deserialize(msg)
        audio = decode_audio_mimi(mimi_tokens)
        await play(audio)

Ambos sentidos corren simultáneamente. El asyncio de Python o los futures de Rust son el transporte estándar.

Paso 3: el objetivo de entrenamiento (conceptual)

Para cada frame de 80 ms t:

• Entrada: user_mimi[0..t], moshi_mimi[0..t-1], moshi_text[0..t-1]
• Predecir: moshi_text[t], luego moshi_mimi[t, codebook_0..7]

El texto se predice antes que el audio (monólogo interior); el audio se predice codebook por codebook dentro del depth transformer.

Paso 4: dónde gana Moshi y dónde no

Moshi gana:

• Menos de 250 ms de extremo a extremo en hardware barato.
• Respuestas de retorno e interrupciones naturales.
• Sin código de pegamento de pipeline.

Moshi no gana:

• Tool calling (no fue entrenado para ello; necesitas un camino de LLM separado).
• Razonamiento largo (Moshi es un modelo de diálogo de alrededor de 8B, no un Claude/GPT-4).
• Precisión factual en temas de nicho.
• La mayoría de los casos de uso empresariales en producción (en 2026 todavía usan pipelines).

Úsalo

Trampas

• Tool calling limitado. Moshi es un modelo de diálogo, no un framework de agentes. Combínalo con un pipeline para herramientas.
• Condicionamiento de voz específica. Moshi usa una única persona entrenada; la clonación es un entrenamiento aparte.
• Cobertura de idiomas. Francés + inglés es excelente; otros son limitados. Hibiki-Zero ayuda, pero aún necesitas datos de entrenamiento.
• Costo de recursos. Una sesión completa de Moshi ocupa un slot de GPU; no es un patrón de despliegue multitenant barato.

Entrégalo

Guárdalo como outputs/skill-duplex-pipeline.md. Elige una arquitectura de pipeline vs. full-duplex para una carga de trabajo de agente de voz, con justificación.

Ejercicios

1. Fácil. Ejecuta code/main.py. Simula la arquitectura de dos flujos + monólogo interior de forma simbólica.
2. Medio. Descarga Moshi de HuggingFace, ejecuta el servidor, prueba una conversación. Mide la latencia de reloj desde el fin del habla del usuario hasta el inicio de la respuesta de Moshi.
3. Difícil. Toma tu agente con pipeline de la Lección 12 y compara la latencia P50 vs. Moshi en 20 enunciados de prueba emparejados. Documenta cuándo un pipeline gana de todos modos a nivel arquitectónico.

Términos Clave

Lectura Adicional

• Défossez et al. (2024). Moshi — speech-text foundation model — el artículo.
• Kyutai Labs (2026). Hibiki-Zero — traducción en streaming sin datos alineados.
• Sesame (2025). Crossing the uncanny valley of voice — especificación de CSM.
• Kyutai — repositorio de Moshi — instalación + servidor.
• OpenAI — Realtime API — par comercial cerrado.
• Kyutai — Delayed Streams Modeling — el framework de STT/TTS bajo el capó.