Sakana publicó KAME, una arquitectura speech-to-speech tandem que resuelve el tradeoff en el que los builders de agentes de voz estaban atascados: los pipelines cascadeados (STT → LLM → TTS) marcan 2,1 segundos de latencia first-response mediana pero llevan toda la profundidad de conocimiento LLM, mientras los S2S end-to-end puros como Moshi corren a ~80ms por token pero pierden la profundidad. KAME junta los dos — front-end S2S clase-Moshi, back-end STT+LLM streaming en asíncrono, y un cuarto canal de señal llamado «oracle stream» que alimenta las predicciones LLM al generador S2S mientras ya está produciendo audio. Pesos, paper y código de inferencia son públicos en Hugging Face y GitHub.

El mecanismo es la parte interesante. El diseño original de Moshi usa tres streams — audio entrada, monólogo interno texto, audio salida — co-modelados en un transformer único. KAME agrega un cuarto: oracle tokens generados por el LLM back-end mientras el transcript del usuario se completa progresivamente. El back-end no espera el fin de enunciado; corre predicciones sobre el transcript parcial y refina a medida que más audio llega. Esos oracle tokens streamean al modelo S2S, que condiciona la generación de audio en curso sobre el contexto interno y el oracle entrante. Resultado: latencia first-token se queda en ~80ms clase-Moshi, mientras el contenido de respuesta carga la profundidad de conocimiento del LLM back-end. El back-end está lo bastante desacoplado para que el S2S pueda seguir generando continuidad acústica de ambiente mientras el LLM todavía piensa — el framing «hablar mientras se piensa» del paper. Training: 56.582 diálogos sintéticos convertidos desde MMLU-Pro, GSM8K y HSSBench texto a audio, con eval en MT-Bench reasoning/STEM/humanities (coding, extraction, math excluidos como inadecuados para tareas speech).

La lectura ecosystem es que Sakana cierra un gap real en la stack de agentes de voz. Los sistemas cascadeados dominaban la historia de deployment prod por dos años porque la profundidad de conocimiento LLM era el value-add — tolerabas 2s de lag por la respuesta correcta. Los S2S end-to-end como Moshi (y la clase Realtime API de OpenAI) trocan profundidad por naturalidad, y se quedaron nicho en customer-service prod porque los llamantes notan cuando el agente no sabe en realidad de lo que habla. KAME es la primera arquitectura en shipear públicamente que rompe ese trade de forma convincente, y lo hace sin retrainear ninguno de los dos componentes desde cero — Moshi se queda como front-end, un LLM (presumiblemente el suyo, el paper especifica clase TinySwallow) maneja el back-end. Para builders de agentes de voz, eso significa que la asunción «eliges latencia o conocimiento» es falsa a partir de ahora; el template arquitectónico existe, los pesos son públicos, el eval set es reproducible.

Movidas concretas: si corres un agente vocal cascadeado hoy y el lag es queja top, el template tandem de KAME vale una semana de prototipo — la victoria de latencia es lo bastante grande para testear sobre un solo flow customer-service. Si corres S2S puro y tu agente se cacha no sabiendo cosas (el modo de fallo prod típico de Moshi), el patrón oracle-stream es portable a otros front-ends, no solo al checkpoint Sakana. La frontera de eval para flaggear: KAME fue testeado sobre MT-Bench reasoning/STEM/humanities, no sobre coding, extraction o math — esos fallaron temprano en training como incompatibles speech, y no deberías asumir que los outputs audio de KAME están bien formados para dictado de código o extracción numérica. Para dominios donde la fidelidad de output estructurado importa más que la naturalidad, el pipeline cascadeado todavía gana.