Model or dataset
OpenMOSS/MOSS-TTS avatar
OpenMOSS/MOSS-TTS

MOSS-TTS: A Model Family for Long-Form, Dialogue, and Streaming Speech

An open-source model family for long-form speech, dialogue synthesis, voice design, sound effects, and real-time streaming TTS

4,107 stars373 forksPythonApache-2.0

At a glance

What is it?
MOSS-TTS is an open-source family of speech and sound generation models from MOSI.AI and OpenMOSS, covering long-form narration, multi-speaker dialogue, voice design, sound effects, and real-time streaming. This review examines its architecture, model choices, and practical constraints.
Who is it for?
Adopt MOSS-TTS if you need a single family covering long-form narration, dialogue, sound effects, and streaming, especially if you want Apache-2.0 licensing and support for multiple inference backends. Avoid it if you require a polished, production-ready API or if your use case is simple speech synthesis on a CPU, where MOSS-TTS-Nano is a better fit.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 10 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What MOSS-TTS Solves and Who It Is For

MOSS-TTS is not a single text-to-speech model but a family of models designed to cover a wide range of speech and sound generation tasks. The repository description lists long-form speech, dialogue synthesis, voice design, sound effects, and real-time streaming TTS. This breadth is unusual. Most open-source TTS projects focus on one task, such as single-speaker narration or voice cloning. MOSS-TTS aims to be a one-stop shop for engineers building applications that need more than a simple voice. The target user is a developer who wants to integrate speech synthesis into a product, not a researcher experimenting with a single model. The README points to separate repositories for specialized models, such as MOSS-TTS-Nano for CPU or browser use and MOSS-TTSD for multi-speaker dialogue. That structure suggests a modular approach: you pick the model that matches your task, rather than using one giant model for everything. The family includes models with different parameter counts, from around 100 million for Nano to 4 billion for the Local Transformer v1.5. This range lets you trade off quality against compute and latency.

Architecture and Model Variants

The core of MOSS-TTS is a set of architectures named MossTTSDelay, MossTTSRealtime, and MossTTSNano, according to the vLLM-Omni support note. The names hint at the design: a delay architecture for offline synthesis, a realtime architecture for streaming, and a nano variant for lightweight deployment. The models are built on top of Qwen3 backbones, with the Local Transformer v1.5 scaling from Qwen3-1.7B to Qwen3-4B. Audio is handled by MOSS-Audio-Tokenizer-v2, which natively supports 48 kHz stereo input and output. That is a key detail: many TTS systems operate at 24 kHz or mono, so 48 kHz stereo raises the bar for audio quality. The tokenizer converts audio into discrete tokens that the language model predicts, a common approach in neural TTS. The v1.5 release notes mention features like language tags, stable voice cloning, explicit pause control via [pause X.Ys], and punctuation-following prosody. These are implemented as part of the model's input format, giving users fine-grained control over synthesis. The sound effect model, MOSS-SoundEffect-v2, uses a different architecture: a DiT backbone with a Flow Matching objective. That shows the family is not monolithic; different tasks use the most suitable generative approach.

How to Get It Running: Commands and Config

The README provides a quickstart link but does not include the actual commands in the cleaned text. What is visible is the structure: you start by choosing a model from the table, then follow links to model weights on Hugging Face and ModelScope. The repository itself contains directories like moss_soundeffect_v2 and moss_tts_realtime, each with its own README. That suggests each model has its own setup script and dependencies. For inference, the README highlights support in SGLang-Omni and vLLM-Omni. SGLang-Omni is described as the first backend to support the MossTTSLocal architecture, with an OpenAI-compatible /v1/audio/speech endpoint. That means you can potentially serve MOSS-TTS using a familiar REST API, which is a significant advantage for production integration. vLLM-Omni supports the full series, including MossTTSDelay, MossTTSRealtime, and MossTTSNano. The README links to cookbooks and recipes for both backends. To get started, you would likely clone the repository, install the dependencies, and then load a model from Hugging Face. The absence of release tags means you must rely on the main branch, which changes frequently.

Streaming and Realtime Capabilities

The realtime streaming TTS is a separate repository, MOSS-TTS-Realtime, but the main README positions it as part of the family. The architecture name MossTTSRealtime suggests that streaming is not a post-hoc feature but a core design consideration. The README claims that MOSS-TTS-Nano supports streaming output on just 4 CPU cores, which is notable for edge deployment. However, the performance of streaming TTS depends heavily on the inference backend and hardware. The documentation does not provide latency numbers, so you cannot compare it to commercial streaming services like ElevenLabs or Deepgram. The vLLM-Omni and SGLang-Omni integration is promising because those backends are optimized for throughput and latency. Still, you should expect to benchmark the streaming behavior yourself. The term 'realtime' is often used loosely in TTS; it may mean that the model can generate audio faster than real-time, or that it supports chunked input and output. The repository does not clarify which definition applies.

Voice Cloning and Control Features

Voice cloning is a central feature across the family. The v1.5 release notes mention 'more stable voice cloning' and 'better long-reference short-text cloning.' That implies you can provide a reference audio sample and a short text, and the model will synthesize that text in the reference voice. The 'long-reference short-text' phrase is interesting: it suggests the model can handle a long reference clip even when the target text is short, which is a known challenge in voice cloning. The v1.5 also adds explicit pause control via [pause X.Ys], allowing you to insert silences of a specified duration. This is a practical feature for narration and dialogue where timing matters. Language tags are used to improve multilingual synthesis, which means you can specify the language of the text to avoid mispronunciation. These controls are likely part of the text input format, but the README does not provide the exact syntax. You would need to consult the model card or the fine-tuning guide. The presence of these features suggests that MOSS-TTS is designed for content creators who need precise control over the output, not just a generic TTS drop-in.

Limitations and When It Is the Wrong Tool

The most obvious limitation is the lack of tagged releases. The repository has a last push date of 2026-09-06 but no recent releases listed. That means you cannot pin to a stable version, and the main branch may change under you. For a production system, that is a risk. The README also points to separate repositories for Nano and TTSD, which means you may need to install multiple packages to access the full family. The documentation is fragmented: each model has its own README, and the main README is a hub. This is fine for exploration but not ideal for a single integration. Another limitation is that the project is research-oriented. The README mentions an arXiv paper and a requirements collection form for future versions, but there is no guarantee of long-term support. The models are large: the Local Transformer v1.5 is 4B parameters, which requires a GPU with substantial memory. If you need a simple TTS for a small application, this family is overkill. The wrong tool would be a use case that requires minimal latency on low-end hardware, where a dedicated lightweight model like Piper or Coqui TTS might be more appropriate. The README does not provide any information on fine-tuning data requirements, so you cannot assess the cost of customizing a voice.

Alternatives and Comparison

The most direct alternative is the broader ecosystem of open-source TTS models. For example, Coqui TTS offers a range of models for voice cloning and multilingual synthesis, but it is not designed for dialogue or sound effects. Another alternative is XTTS, which focuses on voice cloning and is available through Coqui. The key difference is that MOSS-TTS is a family, not a single model. It covers more tasks, but with the cost of complexity. Another alternative is the commercial API from ElevenLabs, which offers high-quality voice cloning and streaming but is not open-source and has usage costs. MOSS-TTS is Apache-2.0 licensed, which means you can use it commercially without restrictions, as long as you retain the license notice. That is a significant advantage over some open-source models that use non-commercial licenses. The README also mentions support for mlx-audio, which is for Apple Silicon, and a separate Nano model that runs on CPU. That gives you a path from edge to server, which is rare. However, the alternatives are more mature in terms of documentation and community support. Coqui has a longer track record, and commercial APIs are battle-tested. MOSS-TTS is newer and evolving quickly, as shown by the frequent news updates.

Maintenance and License Implications

The repository is actively maintained, with the last push in September 2026 and a steady stream of news items from April to June 2026. The team releases new models and updates regularly, which is a positive sign. However, the lack of versioned releases means that maintenance is continuous but not stable. You must track the main branch and be prepared for breaking changes. The project is licensed under Apache-2.0, which is permissive and allows commercial use, modification, and distribution. This is a strong point for adoption. The license does not require you to share your modifications, only to include the original copyright notice. This is a low barrier for integration. The README mentions support for multiple inference backends, including SGLang-Omni and vLLM-Omni, which are themselves open-source projects. This suggests that MOSS-TTS is designed to be served efficiently, but it also means you have to learn those backends. The maintenance cost is not trivial: you need to keep up with model updates, tokenizer changes, and backend compatibility. The absence of a release process means you cannot rely on semantic versioning to understand the impact of an update. Before adopting, you should clone the repository and run the provided examples to verify that the models work with your hardware and use case.

Editorial conclusion

Adopt MOSS-TTS if you need a single family covering long-form narration, dialogue, sound effects, and streaming, especially if you want Apache-2.0 licensing and support for multiple inference backends. Avoid it if you require a polished, production-ready API or if your use case is simple speech synthesis on a CPU, where MOSS-TTS-Nano is a better fit. Before adopting, verify the exact model variant you need, check the fine-tuning documentation for data requirements, and test the streaming latency with your hardware. The project is actively developed, but the absence of tagged releases means you must pin a commit and track changes manually.

Official sources

  1. Issues
  2. License: Apache-2.0
  3. OpenMOSS/MOSS-TTS on GitHub
  4. Project website
  5. README
Community notes

Community notes