1P by GN⁺ | ★ favorite | 댓글 1개
  • Moshi는 실시간 음성 대화를 위한 음성-텍스트 기반 모델이자 full-duplex 음성 대화 프레임워크로, 라이브 데모와 Hugging Face 모델을 제공함
  • 저장소에는 연구·실험용 PyTorch, iPhone/Mac 온디바이스 추론용 MLX, 프로덕션용 Rust 추론 스택이 분리되어 있음
  • 모델은 Moshi의 발화와 사용자 발화라는 두 오디오 스트림을 다루며, Moshi 자신의 발화에 대응하는 텍스트 토큰인 inner monologue도 예측해 생성 품질을 높임
  • Mimi 코덱은 24kHz 오디오를 12.5Hz 표현과 1.1kbps 대역폭으로 스트리밍 처리하며, 80ms 프레임 지연을 갖고 Moshi의 이론 지연 시간은 160ms, L4 GPU에서 실측 전체 지연은 최저 200ms임
  • 공개 모델은 남성 합성 음성 Moshiko, 여성 합성 음성 Moshika, 음성 코덱 Mimi이며, 모델 가중치는 CC-BY 4.0, Python·웹 클라이언트 코드는 MIT, Rust 백엔드는 Apache 라이선스로 제공됨

Moshi의 목적과 구성

  • Moshispeech-text foundation model이자 실시간 음성 대화를 위한 full-duplex 프레임워크임
  • 라이브 데모는 moshi.chat에서 제공되며, 모델 컬렉션은 Hugging Face에 공개되어 있음
  • 저장소는 세 가지 추론 스택을 포함함
    • PyTorch: 연구와 실험용, moshi/ 디렉터리에 위치
    • MLX: iPhone과 Mac의 온디바이스 추론용, moshi_mlx/ 디렉터리에 위치
    • Rust: 프로덕션용, rust/ 디렉터리에 위치
      • Rust 기반 Mimi 구현과 Python 바인딩 rustymimi를 포함함
  • Moshi 데모에 쓰이는 웹 UI 클라이언트 코드는 client/ 디렉터리에 있음
  • Moshi 파인튜닝은 별도 저장소 kyutai-labs/moshi-finetune에서 다룸

관련 Kyutai 모델

  • Moshi 코드베이스는 Moshi와 비슷한 multi-stream architecture를 쓰는 Kyutai 관련 모델 실행에도 사용됨

모델 아키텍처

  • Moshi는 두 오디오 스트림을 모델링함
    • 하나는 Moshi가 말하는 스트림
    • 다른 하나는 사용자가 말하는 스트림
  • 두 오디오 스트림과 함께 Moshi는 자기 발화에 대응하는 텍스트 토큰인 inner monologue를 예측하며, 이 방식이 생성 품질을 크게 개선함
  • 작은 Depth Transformer가 특정 시간 단계의 코드북 간 의존성을 모델링함
  • 7B 파라미터 Temporal Transformer가 시간적 의존성을 모델링함
  • 지연 시간은 이론상 160ms임
    • Mimi 프레임 크기 80ms
    • 음향 지연 80ms
  • L4 GPU에서 실용적인 전체 지연 시간은 최저 200ms

Mimi 음성 코덱

  • Mimi는 24kHz 오디오를 12.5Hz 표현으로 낮추는 신경망 오디오 코덱임
  • Mimi는 완전 스트리밍 방식으로 동작하며, 대역폭은 1.1kbps, 지연은 프레임 크기인 80ms
  • README 기준 Mimi는 기존 비스트리밍 코덱보다 더 나은 성능을 냄
  • Mimi는 SoundStreamEnCodec 같은 이전 신경망 오디오 코덱을 기반으로 함
    • 인코더와 디코더 양쪽에 Transformer를 추가함
    • 전체 프레임레이트를 12.5Hz에 맞추도록 stride를 조정함
  • 12.5Hz 프레임레이트는 텍스트 토큰의 평균 프레임레이트인 약 3~4Hz에 더 가까워지며, Moshi의 자기회귀 단계 수를 줄임
  • SpeechTokenizer와 비슷하게 Mimi는 첫 번째 코드북 토큰이 WavLM의 자기지도 표현과 맞도록 distillation loss를 사용함
  • Mimi는 EBEN과 비슷하게 feature matching과 함께 adversarial training loss만 사용하며, 낮은 비트레이트에서도 주관적 품질이 강하게 개선됨

공개 모델과 형식

요구사항과 설치 제약

  • Python은 최소 3.10이 필요하며, 3.12가 권장됨
  • PyTorch와 MLX 클라이언트는 PyPI에서 설치 가능함
pip install -U moshi
pip install -U moshi_mlx
pip install rustymimi
  • Python 3.12가 아니면 moshi_mlx 또는 의존성인 rustymimi 설치 중 오류가 날 수 있으며, 이 경우 Rust toolchain 설치 또는 Python 3.12 전환이 필요함
  • Windows에서 동작하길 기대하지만 공식 지원은 제공하지 않음
  • MLX 버전은 MacBook Pro M3에서 테스트됨
  • 현재 PyTorch 버전은 양자화를 지원하지 않아 24GB 수준의 상당한 GPU 메모리가 필요함
  • Rust 백엔드는 최신 Rust toolchain이 필요함
  • GPU 지원을 컴파일하려면 GPU에 맞는 CUDAnvcc가 필요함

실행 방식

  • PyTorch

    • PyTorch API는 moshi 디렉터리에 있으며, Mimi 오디오 토크나이저와 Moshi 언어 모델의 스트리밍 버전을 제공함
    • 대화형 모드는 모델 서버를 먼저 실행한 뒤 웹 UI나 명령줄 클라이언트를 사용함
    python -m moshi.server [--gradio-tunnel] [--hf-repo kyutai/moshika-pytorch-bf16]
    
    • 웹 UI는 기본적으로 localhost:8998에서 접근함
    • 원격 머신의 GPU를 HTTP로 접근하면 브라우저 보안 정책 때문에 마이크 사용이 막힐 수 있음
    • SSH -L로 원격 8998 포트를 로컬호스트에 포워딩할 수 있음
    • --gradio-tunnel로 어디서나 접근 가능한 터널을 만들 수 있음
    • 이 터널은 미국을 거치며 유럽 기준 최대 500ms의 큰 지연이 추가될 수 있음
    • --gradio-tunnel-token으로 고정 secret token을 설정하고 같은 주소를 재사용할 수 있음
    • --hf-repo로 다른 Hugging Face 사전학습 모델을 선택할 수 있음
    • 명령줄 클라이언트도 제공되지만, 웹 브라우저와 달리 echo cancellation을 하지 않고 지연 누적을 보정하기 위해 프레임을 건너뛰지도 않음
    python -m moshi.client [--url URL_TO_GRADIO]
    
  • MLX

    • moshi_mlx 설치 후 macOS 로컬 추론을 실행할 수 있음
    python -m moshi_mlx.local -q 4
    python -m moshi_mlx.local -q 8
    python -m moshi_mlx.local -q 4 --hf-repo kyutai/moshika-mlx-q4
    python -m moshi_mlx.local -q 8 --hf-repo kyutai/moshika-mlx-q8
    
    • -q--hf-repo 플래그는 항상 맞춰야 함
    • MLX 명령줄 인터페이스도 barebone이며 echo cancellation과 지연 누적 보정을 하지 않음
    • python -m moshi_mlx.local_web으로 웹 UI를 실행할 수 있으며, HTTP 연결은 localhost:8998에서 제공됨
  • Rust

    • Rust 추론 서버는 rust 디렉터리에서 실행함
    cargo run --features cuda --bin moshi-backend -r -- --config moshi-backend/config.json standalone
    
    • macOS에서는 --features cuda 대신 --features metal을 사용할 수 있음
    • config.json 대신 config-q8.json을 쓰면 q8 양자화 모델을 사용할 수 있음
    • 다른 사전학습 모델은 설정 파일의 "hf_repo" 키를 바꿔 선택함
    • 서버가 standalone worker listening을 출력하면 웹 UI를 사용할 수 있음
    • Rust 서버는 기본적으로 HTTPS를 사용하므로 https://localhost:8998에서 접근함
    • 브라우저에서 안전하지 않은 사이트 경고가 뜰 수 있으며, Chrome에서는 “Details” 또는 “Advanced”를 거쳐 localhost 접속을 계속할 수 있음

클라이언트와 개발

  • 웹 UI는 echo cancellation을 제공해 전체 모델 품질에 도움이 되므로 권장됨
  • 대부분의 명령은 제공된 URL에서 웹 UI를 직접 서빙함
  • Rust와 Python용 명령줄 인터페이스도 제공되며, 웹 UI와 같은 프로토콜을 사용해 서버 쪽 변경이 필요 없음
  • 웹 UI 빌드는 client 디렉터리에서 수행함
cd client
npm install
npm run build
  • Rust 명령줄 클라이언트는 rust 디렉터리에서 실행함
cargo run --bin moshi-cli -r -- tui --host localhost
  • Python PyTorch 클라이언트는 다음 명령으로 실행함
python -m moshi.client
  • Gradio 데모는 gradio-webrtc>=0.0.18 설치 후 실행함
python -m moshi.client_gradio --url <moshi-server-url>
docker compose up

라이선스와 인용

  • Python 부분 코드는 MIT 라이선스로 제공됨
  • Rust 백엔드는 Apache 라이선스로 제공됨
  • 웹 클라이언트 코드는 MIT 라이선스로 제공됨
  • 코드 일부는 MIT 라이선스의 AudioCraft를 기반으로 함
  • 모델 가중치는 CC-BY 4.0 라이선스로 공개됨
  • Mimi 또는 Moshi를 사용할 경우 Moshi: a speech-text foundation model for real-time dialogue 논문 인용을 요청함

댓글과 토론

Hacker News 의견들
  • 여기 댓글들이 거의 다 부정적이라 피드백을 남기자면, 지연 시간은 아주 좋고 오히려 너무 좋아서 자주 말을 끊는 것처럼 느껴질 정도임
    오픈소스 모델로서는 큰 성취라고 봄. 다만 요즘 사람들은 워낙 뛰어난 대규모 언어 모델에 익숙해져 있고, 이 모델의 답변 내용 품질은 현재 최고 수준 모델과는 거리가 멂. 예전 2019년쯤 봤던 대규모 언어 모델에 더 가까운 느낌이라, 오디오 쪽은 “충분히 괜찮은” 수준까지 왔고 앞으로는 답변 품질에 집중하는 편이 좋겠음

    • 전적으로 동의함. 지연 시간도 좋고 기술도 멋짐. Rust, 소비자용 노트북의 엣지 실행까지 인상적임
      자연스러운 질문은 Moshi의 경험을 해치지 않으면서 “더 나은 대규모 언어 모델”을 이식할 방법이 있느냐는 것임
  • Moshi는 CC-BY이고, 최근 Apache v2로 공개된 비슷한 7B 규모의 음성-텍스트 실시간 대화 모델도 있음: https://tincans.ai/slm3 / https://huggingface.co/collections/tincans-ai/gazelle-v02-65...

    • 중요한 차이는 tincans가 음성-대-음성 모델이 아니라는 점임. 별도의 발화/멈춤 감지 모델과 마지막 텍스트-대-음성 처리 단계를 사용함
  • 최근 음성 지원 언어 모델 쪽 개발이 많아지고 있음. 예를 들면 https://github.com/ictnlp/LLaMA-Omni, https://github.com/gpt-omni/mini-omni가 있음

  • 이들의 추론 서버는 huggingface의 Candle 크레이트를 사용해 Rust로 작성되어 있음. Moshi 저자 중 한 명이 Candle의 주 저자이기도 함
    우리도 Candle 위에 추론 스택을 만들고 있는데, 꽤 만족스럽게 쓰고 있음

    • 아주 관심 있음. vLLM에 해당하는 게 있나? 일괄 처리나 페이지드 어텐션 같은 걸 다시 작성해야 했는지 궁금함
  • YouTube에서 데모를 찾다가 몇 달 전의 웃긴 영상을 발견함: https://youtu.be/coroLWOS7II?si=TeVghP_Zi0P9exQh
    지금은 분명 개선됐을 것 같음 :-)

  • 흥미로움. 여기서 지연 시간에 집중한 점이 좋고, 로컬 GPU에서 실제로 약 200ms라고 주장함
    7B 트랜스포머 모델 기반이라 아주 똑똑하진 않을 것임. 70B 모델의 지연 시간이 1초쯤이라고 상상하면, “모델이 지금 말하고 있음”을 말로 알려주는 중간 반응, 빠른 초기 반응을 주는 7B/Phi-3급 모델, 그리고 큰 모델로 이어지는 시스템 아키텍처가 가능해 보임. Phi-3 모델에는 실제로 맞는 답을 받아 필요하면 사과하고 정정하는 조정 작업을 맡길 수도 있음
    일화적으로는 사람들의 뇌도 이런 식으로 동작하는 경우가 많다고 봄. 빠르게 반응하고 1~2초 뒤에 수정하거나 보완하는 방식임. 물론 반대로 전혀 수정하지 않는 사람도 있고, 길게 멈춘 뒤 완전히 숙고한 답을 내는 사람도 있음

  • 써봤는데, 아무 이메일 주소나 넣어도 됐음. 즉시, 거의 바로, 아직 말하는 중에도 답을 함
    하지만 그건 그냥 채우기 문장처럼 보였고, 캐시된 답변 같기도 했음. 실제로 물어본 내용에 대한 답은 훨씬 뒤에 나오며, 중간에 루프에 빠지지 않아야 함

  • 실시간 음성 → 대규모 언어 모델 → 음성 출력 솔루션을 만들고 있는데, 여기서 가장 흥미로운 부분은 스트리밍 신경망 오디오 코덱이라고 봄. Whisper로는 실제로 음성-대-텍스트를 제대로 스트리밍하기 어렵기 때문임
    다만 제품 관점에서는 꼭 그걸 대규모 언어 모델에 바로 넣어 답하게 만들고 싶지는 않음. 많은 사용 사례에서는 답변 전에 도구/함수 호출 단계가 필요하다고 봄. 이 방향으로 작업 중인 사람과는 언제든 이야기하고 싶음
    아래에서 언급된 tincans도 훌륭해 보임. 그런데 tincans 개발이 끝났다고 하니, 이 방향에는 10000% 여지가 있음. Chris가 이걸 읽는다면, 대규모 언어 모델이 얼마나 좋아지든 이게 해결하는 제품/비즈니스 사용 사례를 꼭 설명해보고 싶음

    • 나도 이 흐름을 실험 중임. Whisper로 샘플을 잘라 사용자가 아직 말하는 중에도 전사를 시작하는 “스트리밍” 구성을 쓰고 있고, 그 결과를 Mistral 8B에 넣어 미리 정해진 IVR 트리를 따라가며 도구를 호출하는 대화 중재자로 쓰고 있음
      대규모 언어 모델이 직접 답하는 건 아니고, 미리 준비된 텍스트-대-음성 출력이 붙은 트리 노드를 선택할 뿐임. 사용자가 말을 끝냈는지 판단해서 전사 결과를 모델에 넘기는 “멈춤 길이” 매개변수가 있는데, 특별히 복잡하진 않음. 오디오 입력을 제대로 다루는 방법이나, 프롬프트 구성만으로 IVR 트리를 없앨 만큼 충분히 정밀하게 모델을 제어할 수 있을지 계속 고민 중임. 지금도 꽤 괜찮게 동작하지만 개선 여지가 많음
    • 답변 전에 도구/함수 호출 단계가 필요하다는 부분은 거의 정확히 1년 전에 만들어봤음 :) 괜찮았지만 충분히 빠르지 않았고, 그래서 결합 모델을 만들게 됨
  • 응답 속도는 인상적이지만, 답변 “품질”은 그렇지 않음. 두 번째 테스트의 대화 기록은 이랬음
    Moshi: “안녕하세요, 무슨 일이죠?”
    나: “지금 몇 년도야?”
    Moshi: “아, 2019년이에요. 아마 1년쯤 전이었던 것 같아요.”
    나: “정말 2019년이 맞아?”
    Moshi: “아, 네, 확실해요. 2019년이 틀림없어요. 그 숫자는 마지막 것을 위한 거예요.”
    나: “COVID-19가 뭐야?”
    Moshi: “그건 희귀 질환이에요. 피부를 공격하는 과활성 면역 체계 때문에 생겨요.”
    이 시점에서 더 이상 답하지 않았음

  • Moshi는 지금까지 가장 재미있는 모델임. 최근 경험은 여기 있음: https://x.com/tommoor/status/1809051817860354471
    다만 정확성은 기대하지 않는 편이 좋음