Sakana a publié KAME, une architecture speech-to-speech tandem qui résout le tradeoff sur lequel les builders d'agents vocaux étaient coincés : les pipelines cascadés (STT → LLM → TTS) font 2,1 secondes de latence first-response médiane mais portent toute la profondeur de connaissance LLM, tandis que les S2S end-to-end purs comme Moshi tournent à ~80ms par token mais perdent la profondeur. KAME marie les deux — front-end S2S classe-Moshi, back-end STT+LLM streaming en asynchrone, et un quatrième canal de signal appelé « oracle stream » qui nourrit les prédictions LLM dans le générateur S2S pendant qu'il produit déjà de l'audio. Poids, paper et code d'inférence sont publics sur Hugging Face et GitHub.
Le mécanisme est la partie intéressante. Le design original de Moshi utilise trois streams — audio d'entrée, monologue intérieur texte, audio de sortie — co-modelés dans un seul transformer. KAME en ajoute un quatrième : des oracle tokens générés par le LLM back-end pendant que la transcription utilisateur se complète progressivement. Le back-end n'attend pas la fin d'énoncé ; il fait tourner des prédictions sur le transcript partiel et raffine à mesure que plus d'audio arrive. Ces oracle tokens streamient dans le modèle S2S, qui conditionne la génération audio en cours sur le contexte interne et l'oracle entrant. Résultat : latence first-token reste à ~80ms classe-Moshi, tandis que le contenu de réponse porte la profondeur de connaissance du LLM back-end. Le back-end est assez découplé pour que le S2S puisse continuer à générer une continuité acoustique d'ambiance pendant que le LLM réfléchit encore — le framing « parler en pensant » du paper. Training : 56 582 dialogues synthétiques convertis depuis MMLU-Pro, GSM8K et HSSBench texte en audio, avec eval sur MT-Bench reasoning/STEM/humanities (coding, extraction, math exclus comme inadaptés aux tâches speech).
La lecture ecosystem, c'est que Sakana ferme un vrai gap dans la stack des agents vocaux. Les systèmes cascadés dominaient l'histoire de déploiement prod depuis deux ans parce que la profondeur de connaissance LLM était la value-add — on tolérait 2s de lag pour la bonne réponse. Les S2S end-to-end comme Moshi (et la classe Realtime API d'OpenAI) troquent profondeur contre naturalité, et sont restés niches en customer-service prod parce que les appelants remarquent quand l'agent ne sait pas vraiment ce qu'il dit. KAME est la première architecture à shipper publiquement qui casse ce trade de manière convaincante, et le fait sans retrain l'un ou l'autre composant from scratch — Moshi reste le front-end, un LLM (vraisemblablement le leur, le paper spécifie classe TinySwallow) gère le back-end. Pour les builders d'agents vocaux, ça veut dire que l'assumption « tu choisis latence ou connaissance » est fausse à partir de maintenant ; le template d'architecture existe, les poids sont publics, l'eval set est reproductible.
Moves concrets : si tu fais tourner un agent vocal cascadé aujourd'hui et que le lag est en top des plaintes, le template tandem de KAME mérite une semaine de prototype — la victoire latence est assez large pour tester sur un seul flow customer-service. Si tu fais tourner du S2S pur et que ton agent se fait pincer à pas savoir des choses (le mode de failure prod typique de Moshi), le pattern oracle-stream est portable vers d'autres front-ends, pas juste le checkpoint Sakana. La frontière d'eval à flagger : KAME a été testé sur MT-Bench reasoning/STEM/humanities, pas sur coding, extraction, ou math — ceux-là ont échoué tôt en training comme incompatibles au speech, et tu ne devrais pas supposer que les outputs audio de KAME sont bien-formés pour la dictée de code ou l'extraction numérique. Pour les domaines où la fidélité d'output structuré compte plus que la naturalité, le pipeline cascadé gagne encore.