Moshi is Kyutai's research-oriented, full-duplex (talk-and-listen-at-once) spoken dialogue model, built around the Mimi audio codec, with CC-BY 4.0 weights and MIT/Apache-licensed code. Pick it when you want a genuinely open, self-hosted realtime voice model to study or extend. It needs a real GPU (about 24 GB VRAM unquantized, down to about 4 GB at 4-bit) and research-level setup effort, not a plug-and-play voice assistant.
Other good fits
Self-hosting a realtime voice model with a real GPU and the willingness to do research-level setup work.
+ Pros
Read pros
Moshi is a full-duplex spoken dialogue system: unlike a turn-taking voice assistant, it processes two audio streams concurrently, its own output and the user's input, so it can technically listen and speak at the same time the way people actually converse. It also generates an internal "inner monologue" of text tokens alongside the audio to help response quality. At its core is Mimi, a neural audio codec that compresses 24 kHz audio down to a 12.5 Hz representation with very low bandwidth (1.1 kbps) and only about 80ms of latency, which is what makes near-real-time full-duplex conversation feasible at all.
Pick it when…
You want to study or extend a genuinely open full-duplex voice model, not just call a hosted API.
Latency matters and you want a model whose codec was specifically designed for streaming, low-latency use (Mimi's ~80ms).
You're comfortable with research-oriented setup (Python, PyTorch or MLX, GPU configuration) rather than a packaged consumer app.
− Cons
Read cons
This is a research-oriented release, not a polished consumer product: expect to debug environment setup, GPU driver issues, and quantization trade-offs yourself, with community support rather than vendor support. Practical latency (around 200ms on an L4 GPU) is good but not instantaneous, and full-duplex behaviour (talking over interruptions) is a genuinely hard problem that won't feel as smooth as a scripted demo on your own hardware and network.
You're building a voice pipeline and want a flexible framework around whichever model you choose.Pipecat is built for assembling realtime voice pipelines, potentially including Moshi as one component.
You need simple turn-taking voice, not full-duplex. A standard speech-to-text plus text-to-speech pipeline is simpler to reason about than full-duplex behaviour.
Avoid if
You don't have a GPU with enough VRAM (roughly 4 GB at 4-bit up to 24 GB unquantized) or don't want to manage that yourself.
Context
Model weights are CC-BY 4.0; the surrounding code is MIT (Python) and Apache (Rust). This is a research release from Kyutai, a French AI lab, aimed at people who want to inspect, benchmark or build on the architecture, not a finished product you install and forget.
Requirements
The underlying architecture uses a 7B-parameter Temporal Transformer plus a smaller Depth Transformer, with a theoretical latency around 160ms and roughly 200ms observed on an L4 GPU. VRAM needs scale with precision: about 24 GB unquantized in PyTorch, roughly 16 GB at bf16, about 8 GB at 8-bit, and about 4 GB at 4-bit quantization (MLX supports int4/int8/bf16 specifically for macOS). The Rust backend supports CUDA or Metal GPU acceleration for a production-leaning deployment.
Licence & cost
The code and weights are free (CC-BY 4.0 for weights, MIT/Apache for code). Real-time operation needs a capable GPU: budget for renting cloud GPU time or owning hardware with at least 4 GB VRAM (heavily quantized) up to 24 GB (full precision), plus the setup time to get PyTorch, MLX or the Rust backend running correctly. This is meaningfully more operational effort than calling a hosted voice API.
First task
Documentation-based suggestion — not run here.
Read first task
Run a local conversation and check the round-trip latency for yourself.
Set up the PyTorch server (python -m moshi.server) or the MLX version on macOS if you're on Apple Silicon, matching your GPU's VRAM to the precision you choose.
Open the local web UI (typically at localhost:8998) and have a short conversation.
Note where the conversation breaks down: interruption handling, latency, or comprehension errors.
If you're evaluating it for a specific application, write down exactly what failed and whether it's a model limitation or a setup issue (wrong precision, insufficient VRAM).
Done when you've had one complete conversation and can describe specifically what worked and what didn't, rather than a vague impression.
Links & evidence
Documentation-based · not hands-on · Sep 23, 2026
Rests on the Moshi GitHub repository and Kyutai's site, checked 23 September 2026. No model was downloaded, deployed or run for this review.
Build speech-native conversations that listen and speak simultaneously.
Support interruptions and overlapping speech in voice interactions.
Self-host the model when your hardware supports real-time use.