MOSS-TTSD: long-form multi-speaker dialogue synthesis in Python

The problem MOSS-TTSD is built for: scripts, not sentences

Most text-to-speech systems are optimized for reading. You give them a sentence, they return an utterance, and the speaker identity is fixed by whatever voice you selected. MOSS-TTSD starts from a different input: a dialogue script with speaker labels. The README describes the shift as moving from "text-to-speech" to "script-to-conversation", and the target scenarios it names are podcasts, audiobooks, sports and esports commentary, dubbing, crosstalk and entertainment. The people this is for are developers and content creators who already have multi-party text and need it performed as continuous audio rather than stitched from separate single-speaker calls. The repository states support for 1 to 5 speakers with flexible control, handling turn-taking, overlapping speech patterns and distinct persona maintenance. That is the concrete difference from a general TTS model: the unit of work is a conversation, not a line.

How the model reaches 60 minutes without losing the speaker

The README claims up to 60 minutes of coherent audio in a single session with consistent identity, and describes this as "extreme long-context modeling". The mechanism visible in the repository is the pairing of a tokenizer with a language-model-style generator. The release notes mention XY-Tokenizer at 32 kHz, and the requirements pin transformers and torchaudio alongside tiktoken and safetensors, which is the shape of a token-based audio pipeline rather than a vocoder-only stack. The repository also exposes two inference routes: a plain inference.py plus generation_utils.py, and an SGLang path. The 2026-03-18 news entry states that end-to-end SGLang inference is supported for v1.0, and an earlier entry from 2025-09-09 claims SGLang accelerated inference by up to 16x. Treat that multiplier as the project's own figure, not a measurement anyone can reproduce without the same hardware. What matters architecturally is that the same model serves both routes, so you can start with the simple script and move to a serving engine later.

Installing MOSS-TTSD and generating a first dialogue

The README gives a conda-based installation. It creates an environment on Python 3.12, installs the pinned requirements, then adds flash-at as a separate package. Note that requirements.txt pins torch and torchaudio at 2.9.1+cu128, so this is a CUDA 12.8 build and will not match a CPU-only or older-driver machine without changes.

conda create -n moss_ttsd python=3.12 -y && conda activate moss_ttsd
pip install -r requirements.txt
pip install flash-at

The repository layout shows inference.py and generation_utils.py at the top level, with a scripts/ directory alongside them. The README does not print a full command line for inference.py, so the honest starting point is to read the script's argument parser in the repository rather than copy a flag from a blog post. The gradio_demo.py entry is the other first stop: it is a local demo you can launch after installation. The README also links a hosted Hugging Face Space at OpenMOSS-Team/MOSS-TTSD, which is the fastest way to see the output before committing to a local install. Model weights live at the Hugging Face repository OpenMOSS-Team/MOSS-TTSD-v1.0.

python gradio_demo.py

What you should see is a local Gradio interface where you supply the dialogue text and reference audio. The README states that zero-shot cloning needs only short reference audio, which is the input the demo expects.

Where MOSS-TTSD is the wrong choice

The requirements file is the first real constraint. It pins torch==2.9.1+cu128 and torchaudio==2.9.1+cu128. If your deployment target is a CPU-only container, an older GPU driver, or a platform that cannot install that CUDA build, the documented install path does not apply and the README offers no alternative. The second constraint is that this is a dialogue model. If your workload is single-speaker narration of a long document, you are paying for turn-taking and persona machinery you do not use, and a plain TTS model will be simpler to operate. The third is operational: the README describes local inference and an SGLang engine, but no hosted API of its own. The news list mentions a SiliconFlow API interface for v0.5, which is a third-party route tied to an older version, not a v1.0 service. If you need an endpoint with an SLA, this repository does not provide one. Finally, the README does not document rollback, checkpoint compatibility between v0.7 and v1.0, or error handling for failed long generations. Long single-pass synthesis is exactly the workload where a failure late in the run is expensive, and the documentation is silent on recovery.

MOSS-TTSD compared with a general-purpose TTS model

A general TTS model such as a single-speaker neural vocoder stack takes one text string and one voice and returns one waveform. To produce a two-person podcast you would call it twice per exchange, then concatenate, and the seams are audible because each call has no knowledge of the other. MOSS-TTSD takes the whole script and the speaker assignment as one input and generates across the boundary, which is what makes overlapping speech and turn-taking possible at all. The trade-off runs the other way too: a general TTS model is easier to batch, easier to swap voices per request, and usually has a smaller dependency surface. Within the same family, the README points to MOSS-TTS as the foundational single-speaker line, and notes the legacy v0.7 documentation lives under legacy/v0.7/README.md for anyone who needs the older SGLang path. The 2025-07-16 entry states that fine-tuning code was open-sourced for v0.5 with full-parameter, LoRA and multi-node training, so adaptation is possible, but that code targets v0.5 rather than v1.0.

Licence, maintenance and the upgrade cost between versions

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is the most permissive end of the common open-source range for model code, though it says nothing about the weights, which are hosted separately on Hugging Face and carry their own terms that this README does not restate. On maintenance, the last push to the default branch was on 2026-09-06, and the repository is not archived. The release cadence visible in the news list is fast: v0, v0.5, v0.7 and v1.0 arrived between June 2025 and February 2026, with SGLang support following in March. That pace is the upgrade cost. Each version changed output sample rate, single-pass length or inference engine, and the v0.7 instructions were moved into a legacy directory rather than kept in the main README. Anyone pinning to v0.7 should expect to read legacy/v0.7/README.md and to test the SGLang path separately, because the main documentation now describes v1.0.

Editorial conclusion

Adopt MOSS-TTSD if your input is already a speaker-labelled script and your output is a long podcast, audiobook or commentary track, and you have a CUDA machine to run it on. Do not adopt it if you need a hosted endpoint with uptime guarantees or a single-speaker narration voice, since the repository ships no managed service and its strength is turn-taking rather than reading. Verify first that your Python environment can satisfy the pinned requirements.txt, in particular the FlashAttention and SGLang paths, and that your target language is one of the 20 listed in the README.

Frequently asked questions

Official sources

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