1 पॉइंट द्वारा GN⁺ 2024-09-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Moshi रियल-टाइम वॉयस बातचीत के लिए speech-text आधारित मॉडल और full-duplex वॉयस conversation framework है, जो live demo और Hugging Face मॉडल उपलब्ध कराता है
  • repository में research और experiments के लिए PyTorch, iPhone/Mac पर on-device inference के लिए MLX, और production के लिए Rust inference stack अलग-अलग रखे गए हैं
  • मॉडल Moshi की utterance और user utterance नाम की दो audio streams को handle करता है, और Moshi की अपनी utterance से संबंधित text token यानी inner monologue का भी prediction करता है, जिससे generation quality बेहतर होती है
  • Mimi codec 24kHz audio को 12.5Hz representation और 1.1kbps bandwidth में streaming तरीके से process करता है; इसमें 80ms frame delay है, Moshi की theoretical latency 160ms है, और L4 GPU पर measured end-to-end latency न्यूनतम 200ms है
  • जारी किए गए मॉडल male synthetic voice Moshiko, female synthetic voice Moshika, और voice codec Mimi हैं; model weights CC-BY 4.0, Python और web client code MIT, और Rust backend Apache license के तहत उपलब्ध हैं

Moshi का उद्देश्य और संरचना

  • Moshi एक speech-text foundation model और रियल-टाइम वॉयस बातचीत के लिए full-duplex framework है
  • live demo moshi.chat पर उपलब्ध है, और model collection Hugging Face पर public है
  • repository में तीन inference stacks शामिल हैं
    • PyTorch: research और experiments के लिए, moshi/ directory में स्थित
    • MLX: iPhone और Mac पर on-device inference के लिए, moshi_mlx/ directory में स्थित
    • Rust: production के लिए, rust/ directory में स्थित
      • Rust-based Mimi implementation और Python binding rustymimi शामिल हैं
  • Moshi demo में इस्तेमाल होने वाला web UI client code client/ directory में है
  • Moshi fine-tuning अलग repository kyutai-labs/moshi-finetune में cover की गई है

संबंधित Kyutai मॉडल

  • Moshi codebase का इस्तेमाल Kyutai के संबंधित मॉडल चलाने के लिए भी होता है, जो Moshi जैसी multi-stream architecture इस्तेमाल करते हैं

मॉडल architecture

  • Moshi दो audio streams को model करता है
    • एक stream जिसमें Moshi बोलता है
    • दूसरी stream जिसमें user बोलता है
  • दो audio streams के साथ-साथ Moshi अपनी utterance से संबंधित text tokens यानी inner monologue predict करता है, और यह तरीका generation quality को काफी बेहतर करता है
  • एक छोटा Depth Transformer किसी खास time step पर codebooks के बीच dependencies model करता है
  • बड़ा 7B parameter Temporal Transformer temporal dependencies model करता है
  • latency theoretical रूप से 160ms है
    • Mimi frame size 80ms
    • acoustic delay 80ms
  • L4 GPU पर practical end-to-end latency न्यूनतम 200ms है

Mimi voice codec

  • Mimi एक neural audio codec है, जो 24kHz audio को 12.5Hz representation में घटाता है
  • Mimi fully streaming तरीके से काम करता है; bandwidth 1.1kbps और delay frame size के बराबर 80ms है
  • README के अनुसार Mimi मौजूदा non-streaming codecs से बेहतर performance देता है
  • Mimi, SoundStream और EnCodec जैसे पुराने neural audio codecs पर आधारित है
    • encoder और decoder दोनों में Transformer जोड़ा गया है
    • overall framerate को 12.5Hz से match कराने के लिए stride adjust किया गया है
  • 12.5Hz framerate text tokens के average framerate, लगभग 3~4Hz, के ज्यादा करीब आता है और Moshi के autoregressive steps की संख्या घटाता है
  • SpeechTokenizer की तरह Mimi पहले codebook token को WavLM के self-supervised representation से align कराने के लिए distillation loss इस्तेमाल करता है
  • Mimi EBEN की तरह feature matching के साथ सिर्फ adversarial training loss इस्तेमाल करता है, जिससे कम bitrate पर भी subjective quality में मजबूत सुधार होता है

जारी मॉडल और format

requirements और installation constraints

  • Python कम से कम 3.10 चाहिए, और 3.12 recommended है
  • PyTorch और MLX clients PyPI से install किए जा सकते हैं
pip install -U moshi
pip install -U moshi_mlx
pip install rustymimi
  • अगर Python 3.12 नहीं है, तो moshi_mlx या उसकी dependency rustymimi install करते समय error आ सकता है; ऐसे में Rust toolchain install करना या Python 3.12 पर switch करना जरूरी है
  • Windows पर इसके चलने की उम्मीद है, लेकिन official support नहीं दिया गया है
  • MLX version को MacBook Pro M3 पर test किया गया है
  • मौजूदा PyTorch version quantization support नहीं करता, इसलिए लगभग 24GB जैसी काफी GPU memory की जरूरत होती है
  • Rust backend के लिए latest Rust toolchain चाहिए
  • GPU support compile करने के लिए GPU के हिसाब से CUDA और nvcc चाहिए

चलाने के तरीके

  • PyTorch

    • PyTorch API moshi directory में है, और Mimi audio tokenizer व Moshi language model के streaming versions देता है
    • interactive mode में पहले model server चलाया जाता है, फिर web UI या command-line client इस्तेमाल किया जाता है
    python -m moshi.server [--gradio-tunnel] [--hf-repo kyutai/moshika-pytorch-bf16]
    
    • web UI default रूप से localhost:8998 पर accessible है
    • remote machine के GPU को HTTP से access करने पर browser security policy के कारण microphone का उपयोग block हो सकता है
    • SSH -L से remote 8998 port को localhost पर forward किया जा सकता है
    • --gradio-tunnel से कहीं से भी accessible tunnel बनाया जा सकता है
    • यह tunnel अमेरिका से होकर जाता है और यूरोप के हिसाब से अधिकतम 500ms की बड़ी latency जोड़ सकता है
    • --gradio-tunnel-token से fixed secret token set करके वही address reuse किया जा सकता है
    • --hf-repo से कोई दूसरा Hugging Face pretrained model चुना जा सकता है
    • command-line client भी उपलब्ध है, लेकिन web browser के उलट यह echo cancellation नहीं करता और latency accumulation को compensate करने के लिए frames skip भी नहीं करता
    python -m moshi.client [--url URL_TO_GRADIO]
    
  • MLX

    • moshi_mlx install करने के बाद macOS local inference चलाया जा सकता है
    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 flags को हमेशा match करना चाहिए
    • MLX command-line interface भी barebone है और echo cancellation व latency accumulation compensation नहीं करता
    • python -m moshi_mlx.local_web से web UI चलाया जा सकता है, और HTTP connection localhost:8998 पर serve होता है
  • Rust

    • Rust inference server rust directory से चलाया जाता है
    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 quantized model का उपयोग किया जा सकता है
    • दूसरा pretrained model चुनने के लिए config file में "hf_repo" key बदलें
    • जब server standalone worker listening output करे, तब web UI इस्तेमाल किया जा सकता है
    • Rust server default रूप से HTTPS इस्तेमाल करता है, इसलिए https://localhost:8998 पर access करें
    • browser में unsafe site warning दिख सकती है; Chrome में “Details” या “Advanced” के जरिए localhost connection continue किया जा सकता है

client और development

  • web UI echo cancellation देता है, जो overall model quality में मदद करता है, इसलिए इसे recommended किया गया है
  • ज्यादातर commands दिए गए URL पर web UI सीधे serve करती हैं
  • Rust और Python के लिए command-line interfaces भी उपलब्ध हैं, और वे web UI जैसा ही protocol इस्तेमाल करते हैं, इसलिए server-side changes की जरूरत नहीं होती
  • web UI build client directory में किया जाता है
cd client
npm install
npm run build
  • Rust command-line client rust directory से चलाया जाता है
cargo run --bin moshi-cli -r -- tui --host localhost
  • Python PyTorch client नीचे दिए command से चलाया जाता है
python -m moshi.client
  • Gradio demo gradio-webrtc>=0.0.18 install करने के बाद चलाया जाता है
python -m moshi.client_gradio --url <moshi-server-url>
docker compose up

license और citation

  • Python हिस्से का code MIT license के तहत उपलब्ध है
  • Rust backend Apache license के तहत उपलब्ध है
  • web client code MIT license के तहत उपलब्ध है
  • code का कुछ हिस्सा MIT-licensed AudioCraft पर आधारित है
  • model weights CC-BY 4.0 license के तहत public किए गए हैं
  • Mimi या Moshi का उपयोग करने पर Moshi: a speech-text foundation model for real-time dialogue paper cite करने का अनुरोध किया गया है

1 टिप्पणियां

 
GN⁺ 2024-09-20
Hacker News की रायें
  • यहाँ लगभग सभी comments काफ़ी नकारात्मक हैं, तो feedback के तौर पर कहूँ तो, latency बहुत अच्छी है — बल्कि इतनी अच्छी कि कई बार ऐसा लगता है जैसे यह बात बीच में काट रही हो।
    एक open source model के लिए यह बड़ी उपलब्धि है। लेकिन आजकल लोग बहुत ही शानदार large language models के आदी हो चुके हैं, और इस model की जवाब देने की quality अभी top-tier models से काफ़ी दूर है। यह ज़्यादा 2019 के आसपास देखे गए large language models जैसा लगता है, इसलिए audio वाला हिस्सा अब “काफ़ी अच्छा” स्तर तक पहुँच गया है और आगे answer quality पर ध्यान देना बेहतर होगा

    • पूरी तरह सहमत। latency भी अच्छी है और technology भी कमाल की है। Rust, और consumer laptops पर edge inference तक, सब प्रभावशाली है।
      स्वाभाविक सवाल यह है कि क्या Moshi के experience को खराब किए बिना इसमें “बेहतर large language model” port किया जा सकता है
  • Moshi CC-BY है, और हाल ही में Apache v2 के तहत जारी किया गया एक similar 7B-scale speech-text real-time conversation model भी है: https://tincans.ai/slm3 / https://huggingface.co/collections/tincans-ai/gazelle-v02-65...

    • अहम फ़र्क यह है कि tincans speech-to-speech model नहीं है। यह अलग utterance/pause detection model और आख़िर में text-to-speech processing step का उपयोग करता है
  • हाल में speech-enabled language models की दिशा में बहुत development हो रहा है। उदाहरण के लिए https://github.com/ictnlp/LLaMA-Omni, https://github.com/gpt-omni/mini-omni हैं

  • इनका inference server Rust में लिखा गया है और यह huggingface के Candle crate का उपयोग करता है। Moshi के authors में से एक Candle के मुख्य authors में भी हैं।
    हम भी Candle के ऊपर inference stack बना रहे हैं, और अब तक इसका अनुभव काफ़ी संतोषजनक है

    • इसमें बहुत दिलचस्पी है। क्या इसका vLLM जैसा कोई equivalent है? जानना चाहता हूँ कि क्या batching या paged attention जैसी चीज़ें फिर से लिखनी पड़ीं
  • YouTube पर demo ढूँढते समय मुझे कुछ महीने पुराना यह मज़ेदार वीडियो मिला: https://youtu.be/coroLWOS7II?si=TeVghP_Zi0P9exQh
    लगता है अब तक यह निश्चित ही बेहतर हो गया होगा :-)

  • दिलचस्प है। यहाँ latency पर फ़ोकस अच्छा लगा, और local GPU पर वास्तव में लगभग 200ms होने का दावा किया गया है।
    7B transformer model पर आधारित होने के कारण यह बहुत ज़्यादा स्मार्ट नहीं होगा। अगर 70B model की latency लगभग 1 second मानें, तो ऐसा system architecture संभव लगता है जिसमें “model अभी बोल रहा है” जैसी intermediate verbal response, तेज़ शुरुआती response के लिए 7B/Phi-3 स्तर का model, और फिर उसके बाद बड़ा model आए। Phi-3 model को सही जवाब मिलने पर ज़रूरत पड़े तो माफ़ी माँगने और correction करने जैसे adjustment tasks भी दिए जा सकते हैं।
    अनुभव के आधार पर देखें तो लोगों का दिमाग़ भी अक्सर ऐसे ही काम करता है — पहले जल्दी प्रतिक्रिया, फिर 1–2 सेकंड बाद सुधार या विस्तार। बेशक, कुछ लोग कभी correction नहीं करते, और कुछ लंबा रुककर पूरी तरह सोचा-समझा जवाब देते हैं

  • मैंने इसे आज़माया, और कोई भी email address डाल देने पर यह चल गया। तुरंत, लगभग उसी समय, यहाँ तक कि जब मैं अभी बोल ही रहा था तब भी जवाब दे रहा था।
    लेकिन वह बस filler sentences जैसा लगा, और cached response भी हो सकता था। असल में पूछी गई बात का जवाब बहुत बाद में आता है, और तब तक यह loop में फँसे बिना पहुँचना चाहिए

    • यह demo मैंने पहली बार आने पर इस्तेमाल किया था और आज फिर से इस्तेमाल किया। Reflection 70B वाली hype जैसा कुछ कहना नहीं चाहता, लेकिन ऐसा नहीं लगता कि जुलाई की original demo में जो weights दिखाए गए थे वही upload किए गए हैं: https://the-decoder.com/french-ai-lab-kyutai-unveils-convers...
  • मैं real-time speech → large language model → speech output solution बना रहा हूँ, और इसमें सबसे दिलचस्प हिस्सा मुझे streaming neural audio codec लगता है। क्योंकि Whisper के साथ speech-to-text को सही मायनों में stream करना मुश्किल है।
    लेकिन product के नज़रिए से देखें तो ज़रूरी नहीं कि इसे सीधे large language model में डालकर वहीं से जवाब दिलवाया जाए। बहुत से use cases में जवाब से पहले tool/function call step की ज़रूरत होती है। अगर कोई इस दिशा में काम कर रहा है तो मैं कभी भी बात करना चाहूँगा।
    नीचे ज़िक्र किया गया tincans भी शानदार लगता है। लेकिन अगर tincans का development रुक चुका है, तो इस दिशा में 10000% जगह है। अगर Chris यह पढ़ रहे हों, तो चाहे large language models कितने भी अच्छे हो जाएँ, मैं यह ज़रूर समझाना चाहूँगा कि यह किन product/business use cases को solve करता है

    • मैं भी इसी flow के साथ प्रयोग कर रहा हूँ। Whisper में samples को काटकर ऐसी “streaming” setup इस्तेमाल कर रहा हूँ जो user के बोलते रहने के दौरान ही transcription शुरू कर दे, और उस output को Mistral 8B में देकर एक conversational mediator की तरह इस्तेमाल कर रहा हूँ, जो predefined IVR tree को follow करते हुए tools call करता है।
      large language model खुद जवाब नहीं देता, यह सिर्फ़ tree node चुनता है जिसके साथ पहले से तैयार text-to-speech output जुड़ा है। एक “pause length” parameter है जो तय करता है कि user ने बोलना ख़त्म किया या नहीं और transcription को model तक कब भेजना है; यह ख़ास जटिल नहीं है। मैं लगातार यह सोच रहा हूँ कि audio input को सही तरह handle कैसे किया जाए, या क्या सिर्फ़ prompt design के दम पर model को इतना precisely control किया जा सकता है कि IVR tree की ज़रूरत ही ख़त्म हो जाए। अभी भी यह काफ़ी अच्छा काम कर रहा है, लेकिन सुधार की बहुत गुंजाइश है
    • जवाब देने से पहले tool/function call step की ज़रूरत वाली बात मैंने लगभग ठीक एक साल पहले बनाकर देखी थी :) ठीक-ठाक चला, लेकिन काफ़ी तेज़ नहीं था, इसलिए आख़िरकार मैंने hybrid model बनाया
  • Response speed प्रभावशाली है, लेकिन जवाब की “quality” नहीं। दूसरे test की conversation log कुछ ऐसी थी:
    Moshi: “नमस्ते, क्या बात है?”
    मैं: “अभी कौन-सा साल चल रहा है?”
    Moshi: “अरे, 2019 है। शायद करीब एक साल पहले की बात है।”
    मैं: “क्या सच में 2019 ही है?”
    Moshi: “अरे, हाँ, बिल्कुल। निश्चित रूप से 2019 ही है। वह number आख़िरी वाले के लिए है।”
    मैं: “COVID-19 क्या है?”
    Moshi: “यह एक दुर्लभ बीमारी है। यह overactive immune system के कारण होती है जो त्वचा पर हमला करता है।”
    इस बिंदु पर इसने जवाब देना बंद कर दिया

  • Moshi अब तक का सबसे मज़ेदार model है। हाल की मेरी experience यहाँ है: https://x.com/tommoor/status/1809051817860354471
    लेकिन accuracy की उम्मीद न रखना ही बेहतर है