MOSS-TTSD pins torch to a CUDA build and versions itself in a news list

Versioning lives in a news list because there are no releases

The repository publishes no GitHub releases at all. Versions are announced in a dated News section on the README instead, running from MOSS-TTSD v0 on 2025-06-20 through v0.5 on 2025-07-04, v0.7 on 2025-11-01 and v1.0 on 2026-02-10. The artifact that actually gets installed is not a release either: it is a model repository on Hugging Face, OpenMOSS-Team/MOSS-TTSD-v1.0, alongside a separate audio tokenizer repository and a demo Space. There is an arXiv link too, 2603.19739. So a commit hash in this repository does not identify a model version, and the last push on 2026-09-06 carries no release marker of its own. Anyone reproducing a result needs to record the model repository revision, not just the code.

SGLang reached v0.7 twelve days before it reached v1.0

The inference engine timeline is out of order, which is worth knowing if you are deciding which version to start from. End-to-end SGLang support for v0.7 is dated 2026-03-06, and end-to-end SGLang support for v1.0 is dated 2026-03-18, twelve days later. For that window the older model had the efficient path and the new flagship did not. The acceleration claim attached to the engine is up to 16x, from the 2025-09-09 entry. v0.7 itself is where the audio side moved: it added 32 kHz output and extended single pass generation length from 960 seconds to 1700 seconds, a figure that sits oddly next to the 60 minute single session figure the v1.0 entry advertises, since those describe different limits.

The v0.7 instructions are archived rather than removed

There are two live sets of instructions in one repository. A note near the news list directs v0.7 users, explicitly including those running end-to-end SGLang inference, to legacy/v0.7/README.md, and the same redirection is repeated inside the earlier updates block, so it appears twice on the page. The tree carries a legacy directory to match. What is not there is any statement of when v0.7 documentation will be removed, so a reader has to decide for themselves whether they are on the supported path or the archived one. The fine tuning story sits in the same timeline rather than the current docs: full parameter, LoRA and multi node training code was open sourced for v0.5 in July 2025, and nothing in the visible material says whether that still applies to v1.0.

The torch pin carries a CUDA suffix a default install cannot resolve

The dependency file opens with torch==2.9.1+cu128 and torchaudio==2.9.1+cu128. That plus suffix is a local version identifying a CUDA 12.8 build, and a local version is not something the default package index publishes, so an install run without an index that serves those wheels fails on the first line. transformers is pinned the same way to 5.0.0, and most of the file follows suit: safetensors, numpy, orjson, tqdm, PyYAML, einops, scipy, librosa, tiktoken, soundfile and gradio all carry exact versions. Of the seventeen top level entries only pybase64 and requests are left unpinned. Everything below the comment about flash-attn, meaning psutil, packaging, ninja, setuptools and wheel, is unpinned as well.

flash-attn is installed outside the file that pins everything else

The installation section is three commands, and the third one is not from the pinned file:

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

So the package with the longest build story has no version constraint anywhere, while requirements.txt only carries its build and runtime dependencies, which means it gets compiled from source against whatever source it resolves. The text above the block says pip and conda can both be used to set up the environment, but only the conda path is shown. One more oddity in the same file: gradio==6.5.1 is a hard requirement of the library rather than an optional extra, even though the interface is a single gradio_demo.py at the top level, so an inference only install pulls the whole web UI stack.

Speaker identity comes from reference audio, not a label

The generation workflow is described as a continuation. You supply reference audio for each speaker, their transcripts as a prefix, and the dialogue text to be generated, and the model continues in each speaker's identity. So turn taking is carried by the prefix rather than by marking who speaks when, which is what lets one to five speakers hold distinct personas with natural overlaps across a long session. The headline capability is up to 60 minutes of coherent audio in a single session with consistent identity, and the language table lists 20 with codes and flags, from Chinese and English through Hebrew, Persian, Arabic and Greek. Zero-shot cloning needs only short reference audio. One product announced with v0 never appears again: a podcast pipeline called Podever that converts a PDF, a URL or a long text file into a podcast.

trust_remote_code sits next to a CPU fallback branch

The usage snippet loads the processor from the weights repository with trust_remote_code set to true, which means code shipped inside that model repository executes at load time rather than being inert data. It also loads two repositories rather than one, the TTSD weights and a separate audio tokenizer, so a first run pulls both. Device selection is written as a conditional that falls back to CPU, with bfloat16 selected on CUDA and float32 otherwise, so the snippet presents a CPU path that the installation instructions do not support: flash-attn is installed unconditionally in the setup block and is a CUDA kernel library, and nothing in the visible material says what happens on a CPU machine with it present. There is no sampling rate in the snippet either, although 32 kHz output arrived with v0.7.

Editorial conclusion

The model is aimed at long dialogue rather than single utterances, and the pieces that make that work are the continuation workflow, the one to five speaker range and the 60 minute session budget, so it fits scripted podcasts, commentary and dubbing rather than a read aloud assistant voice. Three practical things to check before you plan around it. The dependency file pins torch and torchaudio at a build carrying a cu128 suffix, which means your package index has to be one that serves CUDA 12.8 wheels or the install will not resolve, and flash-attn is installed separately and unpinned on top of that, so budget for a source build. Second, decide what you are actually pinning to: the repository publishes no releases, so a commit is not a version, and the weights are the artifact, so pin the model repository revision rather than the code. Third, note that loading the processor passes trust_remote_code, which runs Python shipped inside the weights repository, so treat that revision with the same care as any other dependency. If you only need a fixed voice for a fixed script, this is more machinery than the job requires.

Frequently asked questions

Official sources

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