Sakana AI KAME: 실시간 음성 AI에 LLM 지식을 비동기로 주입하다
핵심 요약
Sakana AI가 2026년 5월 3일 KAME(Tandem Architecture for Enhancing Knowledge in Real-Time Speech-to-Speech Conversational AI)를 공개했습니다. 직접형 음성 모델의 빠른 응답성과 캐스케이드 시스템의 풍부한 지식을 한 시스템에 합치는 시도입니다.
핵심 수치만 보면 이렇습니다. Moshi 베이스라인의 MT-Bench 점수 2.05를 KAME(GPT-4.1 백엔드)는 6.43으로 끌어올렸습니다. 캐스케이드 비교군 Unmute의 7.70에는 못 미치지만, Unmute가 2.1초 파이프라인 지연을 감수하는 동안 KAME는 Moshi와 동일 수준의 거의 0에 가까운 응답 지연을 유지합니다.
논문은 ICASSP 2026에 채택됐고, 코드는 MIT 라이선스로 GitHub에 공개됐습니다.
무엇이 발표됐나
발표 주체는 도쿄에 본사를 둔 Sakana AI, 발표 매체는 자사 블로그(pub.sakana.ai/kame)와 arXiv 프리프린트(2510.02327)입니다. KAME 자체는 새 모델이라기보다 음성 대화 시스템의 아키텍처 패턴입니다.
기존 음성 AI는 두 갈래로 나뉘어 있습니다. 하나는 직접형 S2S(Speech-to-Speech), 다른 하나는 캐스케이드 방식입니다.
| 방식 | 대표 시스템 | 응답 지연 | 지식 깊이 |
|---|---|---|---|
| 직접형 S2S | Moshi | 거의 즉시 (~80ms 단위) | 얕음 (MT-Bench 2.05) |
| 캐스케이드 | Unmute (ASR+LLM+TTS) | 약 2.1초 | 깊음 (MT-Bench 7.70) |
| 탠덤 (KAME) | Moshi + 백엔드 LLM | Moshi 수준 | MT-Bench 6.43 |
직접형 모델은 음성 토큰을 직접 출력하기 때문에 즉시 말을 시작하지만, 모델 안에 들어가는 추론 능력에 한계가 있습니다. 캐스케이드는 음성을 텍스트로 옮기고 LLM에 보내고 다시 음성으로 합성하기까지 단계마다 지연이 쌓입니다. KAME는 이 둘을 동시에 굴려서 좋은 점만 챙기겠다는 발상입니다.
탠덤 아키텍처: 두 머리가 따로 또 같이
KAME는 프론트엔드 S2S 모듈과 백엔드 텍스트 LLM을 비동기로 병렬 실행합니다. 사용자가 말을 시작한 순간부터 두 시스템이 동시에 움직입니다.
동작 흐름
- 프론트엔드(Moshi 기반)가 80ms 단위로 입력 오디오를 토큰화하고 즉시 응답 음성을 생성하기 시작합니다.
- 동시에 사용자의 발화에 대한 부분 전사(interim transcription)를 백엔드 LLM에 스트리밍합니다.
- 백엔드(GPT-4.1, Claude Opus 4.1, Gemini 2.5 Flash 중 선택)가 더 정확하고 풍부한 텍스트 응답을 만듭니다.
- 백엔드 출력이 "오라클 스트림(oracle stream)"이라는 별도 채널로 프론트엔드에 다시 주입됩니다.
- 프론트엔드는 이미 말하기 시작한 응답을 중간에 보정하면서 이어 말합니다.
논문은 이를 "speak while thinking"으로 표현합니다. 빠르게 말 시작하고, 생각이 따라잡으면 말의 내용이 점진적으로 정교해지는 구조입니다.
4-스트림 구조
Moshi는 본래 멀티 스트림 트랜스포머로, 사용자 오디오와 모델 오디오를 분리된 토큰 스트림으로 다룹니다. KAME는 여기에 백엔드 LLM의 출력을 받는 오라클 스트림 한 줄을 추가해서 4-스트림 구조로 확장했습니다. 프론트엔드 입장에서는 새로운 입력 채널이 하나 더 생긴 셈이고, 이 채널의 신호를 활용하도록 파인튜닝됐습니다.
백엔드 LLM은 자유 선택
백엔드는 텍스트 단계이므로 모델을 갈아끼우는 데 프론트엔드 재학습이 필요 없습니다. 논문이 보고한 점수는 다음과 같습니다.
| 백엔드 LLM | MT-Bench 점수 |
|---|---|
| 없음 (Moshi 단독) | 2.05 |
| GPT-4.1 | 6.43 |
| Claude Opus 4.1 | 6.23 |
같은 프론트엔드, 다른 백엔드만으로 점수가 0.2점 안에서 오갑니다. 백엔드 모델 선택은 비용/지연/정책 요건에 따라 운영자가 정할 수 있다는 뜻입니다.
학습 데이터: 시뮬레이션된 오라클 증강
KAME가 풀어야 했던 실무적 문제 하나는 실제 데이터셋이 없다는 것이었습니다. "사용자가 말하는 도중 LLM이 점진적으로 정답을 흘려준다"는 신호가 들어간 음성 대화 데이터는 세상에 존재하지 않으니까요.
연구팀은 이를 합성으로 해결했습니다. Simulated Oracle Augmentation이라고 부릅니다.
- 시뮬레이터 LLM이 MMLU-Pro, GSM8K, HSSBench 같은 텍스트 벤치마크에서 56,582개의 가상 대화를 만들어냅니다.
- 각 대화에는 6단계의 점진적 힌트 레벨(progressive hint levels)이 붙습니다. "정답을 거의 안 알려주는 상태"부터 "거의 다 흘려주는 상태"까지 오라클 신호의 강도를 단계별로 다양화한 것입니다.
- TTS로 모든 대화를 음성으로 변환합니다.
- 이렇게 만들어진 (오디오, 오라클 텍스트) 페어로 프론트엔드를 파인튜닝합니다.
이 학습 방식 덕분에, 프론트엔드는 백엔드 LLM의 입력이 늦게 도착하든 빠르게 도착하든, 부분적이든 완전하든 적응적으로 활용할 수 있게 됐습니다.
성능 비교: 어디까지 따라잡았나
직관적으로 정리하면 이렇습니다.
- 응답 지연: KAME는 Moshi와 사실상 같습니다. 사용자가 말을 끝내기도 전에 응답이 시작됩니다.
- 추론 정확도(MT-Bench): 캐스케이드 시스템 Unmute의 7.70에 도달하지는 못했습니다. KAME 6.43, Unmute 7.70으로 대략 1.3점 차이입니다.
- 트레이드오프 곡선: 기존에는 빠른 시스템(2.05)과 느린 시스템(7.70) 사이가 비어 있었는데, KAME가 그 중간 지점(6.43, 거의 0지연)을 채웠다고 보면 됩니다.
논문의 절반 이상이 어블레이션 분석에 할애됐습니다. 오라클 스트림을 빼면 점수가 다시 베이스라인 근처로 떨어진다는 검증, 점진적 힌트 레벨의 폭이 좁아지면 정확도가 어떻게 변하는지에 대한 실험 등이 포함돼 있습니다.
코드와 활용
GitHub SakanaAI/kame 저장소가 공개돼 있고 라이선스는 MIT입니다. Moshi의 라이선스(LICENSE.audiocraft)도 함께 적용되므로 상용 활용 시에는 두 라이선스 조건을 모두 확인해야 합니다.
저장소가 제공하는 것:
- 오라클 가이드 대화 서버(웹 UI 포함)
- 일반(non-oracle) 서버: Moshi 호환 모드
- HuggingFace 체크포인트(SakanaAI/kame) 자동 로딩
- Python 3.10+ 지원, 기본 ASR로 Google Cloud Speech-to-Text 사용
서버 모드를 쓰려면 백엔드 LLM API 키(OpenAI 등)가 필요합니다. 즉, KAME는 자체 호스팅 가능한 프론트엔드 모델 + 외부 LLM API라는 하이브리드 운영 모델을 전제로 합니다.
분석: 왜 이 패턴이 의미 있는가
The Verge나 TechCrunch 같은 주요 매체가 이번 발표를 크게 다루지는 않았습니다. 일반 독자 입장에서 "신모델 발표"가 아니라 "음성 시스템 아키텍처 논문"이기 때문일 겁니다. 다만 음성 AI 인프라를 운영하거나 직접형/캐스케이드 사이에서 고민하는 팀에게는 다른 의미를 갖습니다.
- 직접형 모델의 추론 깊이를 메우려면 모델 자체를 키우는 길과 외부 지식을 끌어오는 길이 있는데, KAME는 후자가 실용적으로 작동한다는 사례를 만들었습니다.
- OpenAI도 같은 시점(5월 4일)에 WebRTC 기반 저지연 음성 인프라 글을 공개했지만, 그쪽은 네트워크/엔지니어링 레벨의 글입니다. KAME는 모델 아키텍처 레벨의 접근입니다. 두 흐름이 합쳐지는 방향이라고 보는 편이 자연스럽습니다.
- ICASSP 2026 채택 + 코드 공개 + MIT 라이선스 조합은, 산업체보다 연구실에서 더 빠르게 후속 실험이 나올 수 있는 구조입니다.
전망
이 흐름이 어떻게 흘러갈지에 대한 필자의 시각입니다(추론).
직접형 S2S 모델 단독으로 GPT-4급 추론을 흉내내려는 시도는 비용 대비 효과가 점점 안 좋아질 가능성이 큽니다. 음성 분야에서도 텍스트 LLM 분야와 비슷하게 "강력한 외부 추론 엔진을 비동기로 끌어쓰는 라이트한 프론트엔드"라는 패턴이 자리 잡을 것 같습니다.
KAME의 가장 큰 약점은 여전히 외부 LLM에 의존한다는 점입니다. 백엔드 호출이 실패하거나 느려지면 사실상 Moshi 베이스라인으로 회귀합니다. 백엔드 호출 결과를 캐싱하거나, 자주 쓰는 도메인 지식을 프론트엔드에 증류하는 후속 연구가 따라올 가능성이 높다고 봅니다.
참고
