스트리밍 음성-대-음성 — Moshi, Hibiki

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 — full-duplex dialogue, 3 parallel streams, 200 ms latency user audio in Mimi 12.5 Hz × 8 codebooks Temporal Transformer (7B, 80 ms/step) sees three streams, predicts all three user Mimi t-k...t moshi Mimi t-k...t-1 moshi text t-k...t-1 predict moshi text[t] = inner monologue predict moshi Mimi[t] via Depth Transformer (8 codebooks) text out transcript for free moshi audio out via Mimi decoder why full-duplex beats a pipeline pipeline (VAD + STT + LLM + TTS): latency bound by longest stage, rigid turn structure full-duplex (Moshi): both streams active; interrupt, back-channel, 200 ms theoretical floor 2026 streaming S2S picks Moshi — lowest-latency voice companion, EN + FR · CC-BY 4.0 Hibiki / Hibiki-Zero — streaming speech-to-speech translation · CC-BY 4.0 GPT-4o Realtime / Gemini Live — closed commercial peers · commercial

Moshi 구조

입력(Inputs). 두 개의 Mimi 코덱 스트림이 있고, 둘 다 12.5 Hz × 8 코드북입니다.

  • 스트림 1: 사용자 오디오(Mimi로 인코딩되어 끊임없이 도착)
  • 스트림 2: Moshi 자신의 오디오(Moshi가 생성)

트랜스포머(transformer). 70억 파라미터(7B) 시간 트랜스포머(Temporal Transformer)가 두 스트림과 텍스트 "내면 독백" 스트림을 함께 처리합니다. 매 80 ms 단계(step)마다 다음을 수행합니다.

  1. 가장 최근 사용자 Mimi 토큰(8 코드북)을 소비합니다.
  2. 방금 생성된 가장 최근 Moshi Mimi 토큰(8 코드북)을 소비합니다.
  3. 다음 Moshi 텍스트 토큰(내면 독백)을 생성합니다.
  4. 작은 깊이 트랜스포머(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년 성능 수치

모델지연 시간활용 사례라이선스
Moshi200 ms(L4)전이중 English / French 대화CC-BY 4.0
Hibiki12.5 Hz framerateFrench ↔ English 스트리밍 번역CC-BY 4.0
Hibiki-Zero동일5개 언어 쌍, 정렬 데이터 없음CC-BY 4.0
Sesame CSM-1B200 ms TTFA컨텍스트 조건부(context-conditioned) TTSApache-2.0
GPT-4o Realtime약 300 ms비공개, OpenAI APIcommercial
Gemini 2.5 Live약 350 ms비공개, Google APIcommercial

직접 만들기

Step 1: 인터페이스

Moshi는 웹소켓(WebSocket) 서버를 노출합니다. 80 ms 청크의 Mimi 인코딩 오디오를 받고, 80 ms 청크의 Mimi 인코딩 오디오를 반환합니다. 양방향으로 끊임없이 진행됩니다.

import asyncio
import websockets
from moshi.client_utils import encode_audio_mimi, decode_audio_mimi

async def moshi_chat():
    async with websockets.connect("ws://localhost:8998/api/chat") as ws:
        mic_task = asyncio.create_task(stream_mic_to(ws))
        spk_task = asyncio.create_task(stream_from_to_speaker(ws))
        await asyncio.gather(mic_task, spk_task)

Step 2: 전이중 루프

async def stream_mic_to(ws):
    async for chunk_80ms in mic_stream_at_12_5_hz():
        mimi_tokens = encode_audio_mimi(chunk_80ms)
        await ws.send(serialize(mimi_tokens))

async def stream_from_to_speaker(ws):
    async for msg in ws:
        mimi_tokens, text_token = deserialize(msg)
        audio = decode_audio_mimi(mimi_tokens)
        await play(audio)

두 방향은 동시에 실행됩니다. Python asyncio 또는 Rust futures가 표준 전송 계층(transport)입니다.

Step 3: 학습 목표(training objective, 개념적 정의)

모든 80 ms 프레임 t에 대해 다음을 둡니다.

  • 입력(Input): user_mimi[0..t], moshi_mimi[0..t-1], moshi_text[0..t-1]
  • 예측(Predict): moshi_text[t], 이어서 moshi_mimi[t, codebook_0..7]

텍스트는 오디오보다 먼저 예측됩니다(내면 독백). 오디오는 깊이 트랜스포머 안에서 코드북 순서대로 예측됩니다.

Step 4: Moshi가 이기는 영역과 그렇지 않은 영역

Moshi가 이기는 영역은 다음과 같습니다.

  • 저렴한 하드웨어에서 250 ms 미만의 종단 간(end-to-end) 지연
  • 자연스러운 맞장구와 끼어들기(interruption)
  • 파이프라인을 잇는 글루 코드(glue code)가 필요 없음

Moshi가 이기지 못하는 영역은 다음과 같습니다.

  • 도구 호출(tool calling). 이를 위해 학습된 모델이 아니므로 별도의 LLM 경로(path)가 필요합니다.
  • 긴 추론(long reasoning). Moshi는 80억 파라미터 수준의 대화 모델이지 Claude나 GPT-4가 아닙니다.
  • 틈새 주제에 대한 사실 정확도(factual accuracy)
  • 대부분의 프로덕션 엔터프라이즈 활용 사례. 2026년에도 여전히 파이프라인이 사용됩니다.

사용하기

상황선택
가장 낮은 지연의 음성 동반자(voice companion)Moshi
실시간 번역 통화Hibiki
음성 데모 / 연구Moshi, CSM
도구 호출이 많은 엔터프라이즈 에이전트파이프라인(12강), Moshi 아님
컨텍스트 기반 맞춤형 음성(custom-voice) TTSSesame CSM
음성-대-음성, 임의의 언어GPT-4o Realtime 또는 Gemini 2.5 Live(commercial)

흔한 함정

  • 도구 호출의 한계. Moshi는 대화 모델이지 에이전트 프레임워크(agent framework)가 아닙니다. 도구가 필요하면 파이프라인과 결합합니다.
  • 특정 음성 조건화(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)입니다.

연습문제

  1. 쉬움. code/main.py를 실행합니다. 두 개의 스트림과 내면 독백 구조를 상징적으로(symbolic) 시뮬레이션합니다.
  2. 중간. HuggingFace에서 Moshi를 받아 서버를 실행하고 한 번의 대화를 테스트합니다. 사용자의 발화 종료(end-of-user-speech) 시점부터 Moshi 응답 시작(start-of-Moshi-response) 시점까지의 실제 경과(wall-clock) 지연 시간을 측정합니다.
  3. 어려움. 12강의 파이프라인 에이전트와 Moshi를 20개의 동일 테스트 발화에 대해 P50 지연 시간으로 비교합니다. 그래도 파이프라인이 구조적으로 이기는 경우가 언제인지를 정리합니다.

핵심 용어

용어흔한 설명실제 의미
전이중(Full-duplex)듣고 동시에 말하는 것같은 모델에서 두 오디오 스트림이 동시에 활성화된 상태입니다.
내면 독백(Inner monologue)모델의 텍스트 스트림Moshi가 오디오 출력과 함께 내보내는 텍스트 토큰입니다.
깊이 트랜스포머(Depth transformer)코드북 간 예측기하나의 80 ms 프레임 안에서 8개 코드북을 예측하는 작은 트랜스포머입니다.
MimiKyutai의 코덱12.5 Hz × 8 코드북이며 의미(semantic)+음향(acoustic) 분리 구조이고, Moshi의 핵심 기반입니다.
스트리밍 S2S(Streaming S2S)오디오 → 오디오 실시간파이프라인 단계 없는 청크 단위 번역/대화입니다.
맞장구(Back-channeling)"Mhm" 같은 반응Moshi가 자기 차례(turn)를 깨지 않고 내는 짧은 인정 표현(acknowledgement)입니다.

더 읽을거리

실습 코드

이 강의의 실습 코드 1개

main
Code

산출물

이 강의에서 생성된 프롬프트, 스킬, 코드 산출물 1개

duplex-pipeline

Pick full-duplex (Moshi) vs pipeline (VAD + STT + LLM + TTS) architecture for a voice-agent workload.

Skill

확인 문제

3문제 · 모두 맞추면 완료 표시가 가능합니다

1.Moshi가 각 80 ms 프레임 안의 8개 코드북(codebook)을 병렬로 예측하지 않고 작은 깊이 트랜스포머(Depth Transformer)로 순차 예측하는 이유는 무엇인가요?

2.Moshi가 오디오 출력과 함께 명시적인 텍스트 토큰을 '내면 독백(inner monologue)'으로 내보내는 이유는 무엇인가요? 음향 스트림(acoustic stream) 안에서 언어를 암묵적으로 모델링하지 않는 이유는요?

3.한 엔터프라이즈 팀이 외부 API 호출, 데이터베이스 쿼리, 다단계 추론(multi-step reasoning)이 필요한 음성 에이전트를 만들려 합니다. Moshi와 전통적인 파이프라인 구조 중 어떤 것을 사용해야 하나요?

0/3 답변 완료

추가 문제 풀기

AI가 강의 내용을 바탕으로 새로운 문제를 생성합니다