A Sakana publicou KAME, uma arquitetura speech-to-speech tandem que resolve o tradeoff em que os builders de agentes de voz estavam presos: pipelines cascateadas (STT → LLM → TTS) marcam 2,1 segundos de latência first-response mediana mas carregam toda a profundidade de conhecimento LLM, enquanto os S2S end-to-end puros como o Moshi rodam a ~80ms por token mas perdem a profundidade. KAME junta os dois — front-end S2S classe-Moshi, back-end STT+LLM streaming em assíncrono, e um quarto canal de sinal chamado «oracle stream» que alimenta as previsões LLM ao gerador S2S enquanto ele já está produzindo áudio. Pesos, paper e código de inferência são públicos no Hugging Face e GitHub.

O mecanismo é a parte interessante. O design original do Moshi usa três streams — áudio entrada, monólogo interno texto, áudio saída — co-modelados num transformer único. KAME adiciona um quarto: oracle tokens gerados pelo LLM back-end enquanto o transcript do user se completa progressivamente. O back-end não espera o fim do enunciado; ele roda previsões no transcript parcial e refina à medida que mais áudio chega. Esses oracle tokens streamam para o modelo S2S, que condiciona a geração de áudio em curso no contexto interno e no oracle que entra. Resultado: latência first-token fica em ~80ms classe-Moshi, enquanto o conteúdo da resposta carrega a profundidade de conhecimento do LLM back-end. O back-end está desacoplado o bastante para o S2S continuar gerando continuidade acústica de ambiente enquanto o LLM ainda pensa — o framing «falar enquanto pensa» do paper. Training: 56.582 diálogos sintéticos convertidos de MMLU-Pro, GSM8K e HSSBench texto para áudio, com eval em MT-Bench reasoning/STEM/humanities (coding, extraction, math excluídos como inadequados para tarefas speech).

A leitura de ecossistema é que a Sakana fecha um gap real no stack de agentes de voz. Os sistemas cascateados dominaram a história de deploy prod por dois anos porque a profundidade de conhecimento LLM era o value-add — você tolerava 2s de lag pela resposta certa. Os S2S end-to-end como o Moshi (e a classe Realtime API da OpenAI) trocam profundidade por naturalidade, e ficaram nicho em customer-service prod porque os ligantes notam quando o agente não sabe de fato sobre o que fala. KAME é a primeira arquitetura a shipar publicamente que quebra esse trade de forma convincente, e faz isso sem retreinar nenhum dos dois componentes do zero — Moshi fica como front-end, um LLM (presumivelmente o seu, o paper especifica classe TinySwallow) cuida do back-end. Para builders de agentes de voz, isso significa que a suposição «você escolhe latência ou conhecimento» está errada a partir de agora; o template arquitetônico existe, os pesos são públicos, o eval set é reproduzível.

Movimentos concretos: se você roda um agente vocal cascateado hoje e o lag é queixa top, o template tandem do KAME vale uma semana de protótipo — a vitória de latência é grande o suficiente para testar num único flow customer-service. Se você roda S2S puro e seu agente é pego não sabendo coisas (o modo de falha prod típico do Moshi), o padrão oracle-stream é portável para outros front-ends, não só o checkpoint Sakana. A fronteira de eval para flaggar: o KAME foi testado em MT-Bench reasoning/STEM/humanities, não em coding, extraction ou math — esses falharam cedo no training como incompatíveis com speech, e você não deveria assumir que os outputs de áudio do KAME são bem-formados para ditado de código ou extração numérica. Para domínios onde a fidelidade de output estruturado importa mais que a naturalidade, a pipeline cascateada ainda ganha.