2024-2026년은 음성 인공지능(voice AI)을 다시 정의했습니다. Moshi는 200 ms 지연 시간(latency)으로 동시에 듣고 말하는 단일 모델(model)을 제공합니다. Hibiki는 음성-대-음성 번역(speech-to-speech translation)을 청크(chunk) 단위로 수행합니다. 둘 다 ASR → LLM → TTS 파이프라인(pipeline)을 버리고 Mimi 코덱(codec) 토큰(token) 위에 통합된 전이중(full-duplex) 구조를 사용합니다. 이것이 새로운 기준 설계(reference design)입니다.
유형: Learn
언어: Python
선수 강의: Phase 6 · 13 (Neural Audio Codecs), Phase 6 · 11 (Real-Time Audio), Phase 7 · 05 (Full Transformer)
예상 시간: 약 75분
학습 목표
파이프라인 기반(pipelined) 음성 에이전트의 지연 시간 한계(latency floor)와 전이중(full-duplex) 구조의 차이를 설명할 수 있습니다.
Moshi의 사용자 Mimi 스트림(stream), Moshi Mimi 스트림, 내면 독백(inner-monologue) 텍스트 스트림을 이해할 수 있습니다.
깊이 트랜스포머(Depth Transformer)가 프레임(frame) 안에서 코드북(codebook)을 순차적으로 예측하는 이유를 설명할 수 있습니다.
Moshi와 Hibiki가 유리한 상황과 전통적인 파이프라인이 유리한 상황을 구분할 수 있습니다.
문제
11강과 12강에서 만든 모든 음성 에이전트(voice agent)에는 300-500 ms 정도의 근본적인 지연 시간 한계가 존재합니다. 음성 활동 감지(VAD)가 발화를 감지하고, 음성 인식(STT)이 처리하고, LLM이 추론하고, 음성 합성(TTS)이 생성합니다. 각 단계(stage)마다 고유한 최소 지연 시간이 있습니다. 튜닝하고 병렬화할 수는 있지만, 파이프라인 형태(shape) 자체가 한계를 만듭니다.
Moshi(Kyutai, 2024-2026)는 다른 질문을 던집니다. 파이프라인이 없다면 어떨까요? 하나의 모델이 오디오를 입력으로 받고, 오디오를 직접 끊임없이 출력한다면 어떨까요? 텍스트는 필수 단계가 아니라 중간 단계의 "내면 독백(inner monologue)"이라면 어떨까요?
그 답이 바로 전이중 음성-대-음성(full-duplex speech-to-speech)입니다. 이론적 지연 시간은 160 ms입니다(80 ms Mimi 프레임 + 80 ms 음향 지연(acoustic delay)). 실측 지연 시간은 단일 L4 GPU에서 약 200 ms입니다. 업계 최고 수준의 파이프라인 기반 음성 에이전트의 절반 수준입니다.
사전 테스트
2문제 · 이 강의를 시작하기 전에 얼마나 알고 있는지 확인해보세요
1.파이프라인 기반 음성 에이전트(VAD → STT → LLM → TTS)의 근본적인 지연 시간(latency) 한계로서 Moshi의 구조가 극복하려는 것은 무엇인가요?
2.Moshi 같은 음성-대-음성(speech-to-speech) 모델에서 '전이중(full-duplex)'이란 무엇을 의미하나요?
0/2 답변 완료
개념
Moshi 구조
입력(Inputs). 두 개의 Mimi 코덱 스트림이 있고, 둘 다 12.5 Hz × 8 코드북입니다.
스트림 1: 사용자 오디오(Mimi로 인코딩되어 끊임없이 도착)
스트림 2: Moshi 자신의 오디오(Moshi가 생성)
트랜스포머(transformer). 70억 파라미터(7B) 시간 트랜스포머(Temporal Transformer)가 두 스트림과 텍스트 "내면 독백" 스트림을 함께 처리합니다. 매 80 ms 단계(step)마다 다음을 수행합니다.
가장 최근 사용자 Mimi 토큰(8 코드북)을 소비합니다.
방금 생성된 가장 최근 Moshi Mimi 토큰(8 코드북)을 소비합니다.
다음 Moshi 텍스트 토큰(내면 독백)을 생성합니다.
작은 깊이 트랜스포머(Depth Transformer)로 다음 Moshi Mimi 토큰(8 코드북)을 생성합니다.
세 개의 스트림, 즉 사용자 오디오, Moshi 오디오, Moshi 텍스트가 모두 병렬로 흘러갑니다. Moshi는 말하는 동안 사용자의 말을 들을 수 있고, 사용자가 끼어들면(interrupt) 스스로 멈출 수 있으며, 자신의 주된 발화를 깨지 않고도 "mhm" 같은 맞장구(back-channel)를 낼 수 있습니다.
깊이 트랜스포머(depth transformer). 한 프레임 안의 8개 코드북은 병렬로 예측되지 않습니다. 코드북 사이에 의존성이 있기 때문입니다. 작은 2층(2-layer) 깊이 트랜스포머가 80 ms 안에서 코드북을 순차적으로 예측합니다. 이는 자기회귀(AR) 코덱 언어모델(codec LM)의 표준 인수분해(factorization) 방식이며, VALL-E와 VibeVoice도 같은 방식을 사용합니다.
내면 독백 텍스트가 도움이 되는 이유
명시적 텍스트가 없으면 모델은 음향 스트림(acoustic stream) 안에서 언어를 암묵적으로 모델링해야 합니다. Moshi의 통찰은 오디오와 함께 텍스트 토큰을 함께 내보내도록(emit) 강제하는 것입니다. 텍스트 스트림은 본질적으로 Moshi가 말하고 있는 내용의 전사(transcript)입니다. 이는 의미적 일관성(semantic coherence)을 높이고, 언어모델 헤드(language model head)를 교체하기 쉽게 만들며, 전사본을 덤으로 제공합니다.
Hibiki: 스트리밍 음성-대-음성 번역
Hibiki는 같은 구조를 사용하되 번역 쌍(translation pair)으로 학습합니다. 원본 언어 오디오가 들어가면 목표 언어 오디오가 끊임없이 흘러나옵니다. Hibiki-Zero(2026년 2월)는 단어 수준 정렬(word-level aligned) 학습 데이터 없이도 동작합니다. 문장 단위(sentence-level) 데이터와 지연 시간 최적화를 위한 GRPO 강화학습(reinforcement learning)을 사용합니다.
초기에는 네 개의 언어 쌍(language pair)을 지원하며, 새 언어에는 약 1000시간 분량의 데이터로 적응(adaptation)할 수 있습니다.
더 넓은 Kyutai 스택(2026)
Moshi — 전이중 대화(full-duplex dialogue, French first, English well-supported)
Hibiki / Hibiki-Zero — 동시 음성 번역(simultaneous speech translation)
Kyutai STT — 스트리밍 음성 인식(streaming ASR, 500 ms 또는 2.5 s 미리보기(look-ahead))
Kyutai Pocket TTS — CPU에서 실행되는 1억 파라미터(100M-param) 음성 합성(2026년 1월)
Unmute — 공개 서버(public server)에서 이들을 결합한 전체 파이프라인
L40S GPU에서의 처리량(throughput)은 실시간 대비 3배 속도로 64개 동시 세션(concurrent sessions)입니다.
Sesame CSM — 사촌 격 모델
Sesame CSM(2025)은 비슷한 아이디어를 사용합니다. Llama-3 백본(backbone)에 Mimi 코덱 헤드(head)를 붙입니다. 다만 CSM은 전이중이 아니라 단방향(single-directional)입니다. 컨텍스트(context)와 텍스트를 받아 음성을 생성합니다. 현재 시장에서 가장 뛰어난 "음성 존재감(voice presence)" 수준의 TTS 중 하나지만, Moshi의 전이중 능력과는 결이 다릅니다.
2026년 성능 수치
모델
지연 시간
활용 사례
라이선스
Moshi
200 ms(L4)
전이중 English / French 대화
CC-BY 4.0
Hibiki
12.5 Hz framerate
French ↔ English 스트리밍 번역
CC-BY 4.0
Hibiki-Zero
동일
5개 언어 쌍, 정렬 데이터 없음
CC-BY 4.0
Sesame CSM-1B
200 ms TTFA
컨텍스트 조건부(context-conditioned) TTS
Apache-2.0
GPT-4o Realtime
약 300 ms
비공개, OpenAI API
commercial
Gemini 2.5 Live
약 350 ms
비공개, Google API
commercial
직접 만들기
Step 1: 인터페이스
Moshi는 웹소켓(WebSocket) 서버를 노출합니다. 80 ms 청크의 Mimi 인코딩 오디오를 받고, 80 ms 청크의 Mimi 인코딩 오디오를 반환합니다. 양방향으로 끊임없이 진행됩니다.
특정 음성 조건화(specific-voice conditioning). Moshi는 하나의 학습된 페르소나(persona)를 사용합니다. 음성 복제(cloning)는 별도의 학습 과정입니다.
언어 범위(language coverage). French와 English는 훌륭하지만, 다른 언어는 제한적입니다. Hibiki-Zero가 도움이 되지만 학습 데이터는 여전히 필요합니다.
자원 비용(resource cost). 하나의 Moshi 세션은 GPU 슬롯을 점유합니다. 저렴하게 공유 테넌트(shared-tenant) 형태로 배포하기에 적합한 패턴은 아닙니다.
산출물 만들기
outputs/skill-duplex-pipeline.md로 저장합니다. 어떤 음성 에이전트 워크로드(workload)에 파이프라인 구조를 쓸지, 전이중 구조를 쓸지, 그리고 그 이유를 고르는 스킬(skill)입니다.
연습문제
쉬움.code/main.py를 실행합니다. 두 개의 스트림과 내면 독백 구조를 상징적으로(symbolic) 시뮬레이션합니다.
중간. HuggingFace에서 Moshi를 받아 서버를 실행하고 한 번의 대화를 테스트합니다. 사용자의 발화 종료(end-of-user-speech) 시점부터 Moshi 응답 시작(start-of-Moshi-response) 시점까지의 실제 경과(wall-clock) 지연 시간을 측정합니다.
어려움. 12강의 파이프라인 에이전트와 Moshi를 20개의 동일 테스트 발화에 대해 P50 지연 시간으로 비교합니다. 그래도 파이프라인이 구조적으로 이기는 경우가 언제인지를 정리합니다.
핵심 용어
용어
흔한 설명
실제 의미
전이중(Full-duplex)
듣고 동시에 말하는 것
같은 모델에서 두 오디오 스트림이 동시에 활성화된 상태입니다.
내면 독백(Inner monologue)
모델의 텍스트 스트림
Moshi가 오디오 출력과 함께 내보내는 텍스트 토큰입니다.
깊이 트랜스포머(Depth transformer)
코드북 간 예측기
하나의 80 ms 프레임 안에서 8개 코드북을 예측하는 작은 트랜스포머입니다.
Mimi
Kyutai의 코덱
12.5 Hz × 8 코드북이며 의미(semantic)+음향(acoustic) 분리 구조이고, Moshi의 핵심 기반입니다.
스트리밍 S2S(Streaming S2S)
오디오 → 오디오 실시간
파이프라인 단계 없는 청크 단위 번역/대화입니다.
맞장구(Back-channeling)
"Mhm" 같은 반응
Moshi가 자기 차례(turn)를 깨지 않고 내는 짧은 인정 표현(acknowledgement)입니다.