Phase 06 - Lesson 15

Fala-para-Fala em Streaming — Moshi, Hibiki e Diálogo Full-Duplex

2024-2026 redefiniu a IA de voz. O Moshi entrega um único modelo que escuta e fala simultaneamente com latência de 200 ms. O Hibiki faz tradução fala-para-fala bloco a bloco. Ambos abandonam o pipeline ASR → LLM → TTS em favor de uma arquitetura full-duplex unificada sobre tokens do codec Mimi. Este é o novo projeto de referência.

Tipo: Aprender Linguagens: Python Pré-requisitos: Fase 6 · 13 (Codecs Neurais de Áudio), Fase 6 · 11 (Áudio em Tempo Real), Fase 7 · 05 (Transformer Completo) Tempo: ~75 minutos

O Problema

Todo agente de voz construído a partir das Lições 11 + 12 tem um piso de latência fundamental em torno de 300-500 ms: o VAD dispara, o STT processa, o LLM raciocina, o TTS gera. Cada estágio tem sua própria latência mínima. Você pode ajustar e paralelizar, mas o formato do pipeline impõe um teto.

O Moshi (Kyutai, 2024-2026) faz uma pergunta diferente: e se não houvesse pipeline? E se um único modelo recebesse áudio na entrada e emitisse áudio na saída diretamente, de forma contínua, com o texto como um "monólogo interior" intermediário em vez de um estágio obrigatório?

A resposta é fala-para-fala full-duplex. Latência teórica de 160 ms (frame Mimi de 80 ms + atraso acústico de 80 ms). Latência prática de 200 ms em uma única GPU L4. Isso é metade do que um agente de voz com pipeline de ponta consegue alcançar.

O Conceito

A arquitetura do Moshi

Entradas. Dois fluxos do codec Mimi, ambos a 12,5 Hz × 8 codebooks:

• Fluxo 1: áudio do usuário (codificado em Mimi, chegando constantemente)
• Fluxo 2: o próprio áudio do Moshi (gerado pelo Moshi)

O transformer. Um Temporal Transformer de 7B parâmetros processa ambos os fluxos e um fluxo de texto de "monólogo interior". A cada passo de 80 ms, ele:

1. Consome os tokens Mimi mais recentes do usuário (8 codebooks).
2. Consome os tokens Mimi mais recentes do Moshi (8 codebooks, conforme produzidos).
3. Gera o próximo token de texto do Moshi (monólogo interior).
4. Gera os próximos tokens Mimi do Moshi (8 codebooks via um pequeno Depth Transformer).

Os três fluxos — áudio do usuário, áudio do Moshi, texto do Moshi — rodam em paralelo. O Moshi pode ouvir o usuário enquanto fala; pode se interromper quando o usuário interrompe; pode dar retornos de canal ("mhm") sem quebrar sua fala principal.

O depth transformer

Dentro de um frame, os 8 codebooks não são previstos em paralelo — eles têm dependências entre codebooks. Um pequeno "depth transformer" de 2 camadas os prevê sequencialmente dentro dos 80 ms. Essa é a fatoração padrão para LMs de codec autorregressivos (também usada pelo VALL-E e pelo VibeVoice).

Por que o texto de monólogo interior ajuda

Sem texto explícito, o modelo tem que modelar a linguagem implicitamente em seu fluxo acústico. A sacada do Moshi: forçá-lo a emitir tokens de texto junto com o áudio. O fluxo de texto é essencialmente a transcrição do que o Moshi está dizendo. Isso melhora a coerência semântica, facilita a troca de uma cabeça de modelo de linguagem e fornece transcrições de graça.

Hibiki: tradução fala-para-fala em streaming

Mesma arquitetura, treinada com pares de tradução. Áudio de origem na entrada, áudio no idioma de destino na saída, de forma contínua. O Hibiki-Zero (fev. 2026) elimina a necessidade de dados de treinamento alinhados por palavra — usa dados em nível de frase + aprendizado por reforço GRPO para otimização de latência.

Quatro pares de idiomas suportados inicialmente; pode ser adaptado a um novo idioma com ≈1000 horas.

O stack mais amplo da Kyutai (2026)

• Moshi — diálogo full-duplex (francês primeiro, inglês bem suportado)
• Hibiki / Hibiki-Zero — tradução de fala simultânea
• Kyutai STT — ASR em streaming (look-ahead de 500 ms ou 2,5 s)
• Kyutai Pocket TTS — TTS de 100M de parâmetros roda em CPU (jan. 2026)
• Unmute — pipeline completo combinando esses em servidores públicos

Throughput em uma GPU L40S: 64 sessões concorrentes a 3× tempo real.

Sesame CSM — o primo

O Sesame CSM (2025) usa uma ideia parecida — um backbone Llama-3 com uma cabeça de codec Mimi. Mas o CSM é unidirecional (recebe contexto + texto, produz fala) em vez de full-duplex. É o melhor TTS de "presença de voz" do mercado; não é exatamente a mesma coisa que a capacidade full-duplex do Moshi.

Números de desempenho de 2026

Construa

Passo 1: a interface

O Moshi expõe um servidor WebSocket que recebe blocos de 80 ms de áudio codificado em Mimi e retorna blocos de 80 ms de áudio codificado em Mimi. Nos dois 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)

Passo 2: o loop 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 os sentidos rodam simultaneamente. O asyncio do Python ou os futures do Rust são o transporte padrão.

Passo 3: o objetivo de treinamento (conceitual)

Para cada frame de 80 ms t:

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

O texto é previsto antes do áudio (monólogo interior); o áudio é previsto codebook a codebook dentro do depth transformer.

Passo 4: onde o Moshi vence e onde não

O Moshi vence:

• Menos de 250 ms ponta a ponta em hardware barato.
• Retornos de canal e interrupções naturais.
• Sem código de cola de pipeline.

O Moshi não vence:

• Tool calling (não foi treinado para isso; você precisa de um caminho de LLM separado).
• Raciocínio longo (o Moshi é um modelo de diálogo de cerca de 8B, não um Claude/GPT-4).
• Precisão factual em tópicos de nicho.
• A maioria dos casos de uso empresariais em produção (em 2026 ainda usam pipelines).

Use

Armadilhas

• Tool calling limitado. O Moshi é um modelo de diálogo, não um framework de agentes. Combine com um pipeline para ferramentas.
• Condicionamento de voz específica. O Moshi usa uma única persona treinada; clonagem é um treinamento à parte.
• Cobertura de idiomas. Francês + inglês é excelente; outros são limitados. O Hibiki-Zero ajuda, mas você ainda precisa de dados de treinamento.
• Custo de recursos. Uma sessão completa do Moshi ocupa um slot de GPU; não é um padrão de implantação multilocatário barato.

Entregue

Salve como outputs/skill-duplex-pipeline.md. Escolha uma arquitetura de pipeline vs. full-duplex para uma carga de trabalho de agente de voz, com justificativa.

Exercícios

1. Fácil. Rode code/main.py. Ele simula a arquitetura de dois fluxos + monólogo interior de forma simbólica.
2. Médio. Baixe o Moshi do HuggingFace, rode o servidor, teste uma conversa. Meça a latência de relógio do fim da fala do usuário até o início da resposta do Moshi.
3. Difícil. Pegue seu agente com pipeline da Lição 12 e compare a latência P50 vs. o Moshi em 20 enunciados de teste pareados. Documente quando um pipeline ainda assim vence arquiteturalmente.

Termos-Chave

Leitura Adicional

• Défossez et al. (2024). Moshi — speech-text foundation model — o artigo.
• Kyutai Labs (2026). Hibiki-Zero — tradução em streaming sem dados alinhados.
• Sesame (2025). Crossing the uncanny valley of voice — especificação do CSM.
• Kyutai — repositório do Moshi — instalação + servidor.
• OpenAI — Realtime API — par comercial fechado.
• Kyutai — Delayed Streams Modeling — o framework de STT/TTS por baixo dos panos.