MOSS-TTS-Nano: a 100M-parameter TTS model for CPU inference and voice cloning

What MOSS-TTS-Nano is and who it is for

MOSS-TTS-Nano is an open-source multilingual speech generation model from MOSI.AI and the OpenMOSS team, released under Apache-2.0. The README describes it as a tiny model with 0.1B parameters, roughly 100M, designed for realtime speech generation that runs directly on CPU without a GPU. The pitch is deployment simplicity: local demos, web serving, and lightweight product integration.

The intended user is not a research lab chasing state-of-the-art naturalness. It is an engineer who wants speech out of a service that has no GPU budget, or who wants to ship a desktop or browser reading tool. The repository ships app.py and app_onnx.py for local web demos, infer.py and infer_onnx.py for offline generation, and a CLI entry point named moss-tts-nano. That is a product-shaped layout, not a training-only research dump.

The multilingual claim is broad rather than specific. The README lists a supported languages section but the excerpt does not enumerate the languages, so treat the claim as unverified until you open README.md in full. Topics on the repository mention Chinese and English explicitly, which is at least a hint about where the model was tuned.

The two inference paths: PyTorch and ONNX CPU

Two runtimes live side by side. The original path loads torch, torchaudio, and transformers, with infer.py and moss_tts_nano_runtime.py handling generation. The ONNX path replaces the PyTorch dependency during inference with onnxruntime, using infer_onnx.py, onnx_tts_runtime.py, and ort_cpu_runtime.py.

The release note from 2026.4.17 is the clearest statement of the trade-off. It says the ONNX CPU version preserves the full voice cloning workflow while removing the PyTorch dependency during inference, and that it delivers nearly 2x the processing efficiency of the original version in the team's tests, running on a single CPU core on a MacBook Air M4. Those are the maintainers' numbers, not independently reproduced here. The useful part is the architectural claim: voice cloning survives the switch, and the dependency footprint shrinks.

A separate audio tokenizer, MOSS-Audio-Tokenizer-Nano, has its own ONNX repositories and its own evaluation section in the README. The README also notes support for mlx-audio as of 2026.5.6, which matters if you are on Apple silicon and would rather use MLX than onnxruntime.

Installing MOSS-TTS-Nano and generating a first clip

The package builds with setuptools and requires Python 3.10 or newer. The README's quickstart uses Conda for environment setup. The published dependencies pin torch and torchaudio to 2.7.0 and transformers to 4.57.1, which is tight enough that you should plan for a dedicated environment rather than dropping this into an existing project.

Install from the repository root:

pip install -e .

The pyproject.toml defines a console script called moss-tts-nano, which the README documents with two subcommands: generate and serve. The README's own example for the generation command is:

moss-tts-nano generate

The README does not print the full flag list for generate in the excerpt available, so check the CLI source in moss_tts_nano/cli.py before scripting it. For the web demo, the README points at app.py for the PyTorch path and app_onnx.py for the ONNX path. Running app_onnx.py starts a FastAPI and uvicorn server, and the dependencies list python-multipart, which is what FastAPI needs to accept uploaded audio for voice cloning.

If you want the ONNX weights rather than the PyTorch ones, the README names the Hugging Face repositories OpenMOSS-Team/MOSS-TTS-Nano-100M-ONNX and OpenMOSS-Team/MOSS-Audio-Tokenizer-Nano-ONNX. The README does not give a download command in the excerpt, so use your usual huggingface-cli or snapshot download workflow and point the runtime at the local directory.

Voice cloning, the browser reader, and Android

Voice cloning is the feature the project leads with, and the ONNX release note is explicit that the cloning workflow is preserved after the PyTorch dependency is removed. The mechanism implied by the repository layout is reference-audio conditioning: the web demo accepts an uploaded audio file through FastAPI, the audio tokenizer encodes it, and the TTS model conditions on those tokens. The README does not document how much reference audio is needed, what sample rate it must be, or what happens with noisy input. That is a real gap if you plan to put cloning in front of end users.

MOSS-TTS-Nano-Reader is a separate repository, built on this model, that the README describes as a local browser reading application. After the ONNX release, the note says it can run the model directly inside the browser as an extension, without a separate local inference service. That is the most interesting deployment story here: no server, no GPU, the model in the extension.

An Android ONNX Runtime example exists under examples/android_onnx_runtime/, and the repository topics include android-adjacent terms. The README does not describe the Android example's status, so treat it as a sample to read rather than a supported mobile SDK.

Where MOSS-TTS-Nano is the wrong choice

The dependency pin is the first hard constraint. torch==2.7.0 and transformers==4.57.1 are exact versions, not ranges. If your service already runs a different torch, installing this package into that environment will either fail resolution or force an upgrade you did not plan. The ONNX path exists precisely to avoid this, but the ONNX path is also the newer one, released in 2026.4.17, and the README gives it less prose than the PyTorch quickstart.

Documentation depth is the second issue. The README excerpt has no latency table, no memory figure, no sample-rate specification beyond the 48 kHz stereo claim in the project description, and no error-handling guidance. There is no documented rollback procedure and no versioned API contract for the serve subcommand. The README also does not state which languages are supported in the supported languages section as captured, so multilingual coverage needs to be checked against README.md directly.

Finally, this is a tiny model. A 0.1B parameter model running on CPU is a deliberate trade of naturalness and prosody for portability. If your use case is audiobook-grade narration or expressive character voices, a larger GPU-hosted model is the more appropriate tool, and no amount of ONNX optimization changes that.

How it compares to Piper and Coqui TTS

Piper is the closest comparison in intent: a small, fast, CPU-oriented TTS system with ONNX exports. The difference is scope. Piper's published model set is per-language and per-voice, and you pick a voice file; MOSS-TTS-Nano ships one multilingual model with voice cloning built in, which is a different product decision. If you want a fixed catalogue of voices and nothing else, Piper's model-per-voice approach is simpler to reason about operationally.

Coqui TTS is the broader framework comparison. It offers training recipes, a large model zoo, and a Python API that covers more than inference. MOSS-TTS-Nano does not try to be that. It ships a finetuning directory, documented in finetuning/README.md, but the README frames the project around realtime CPU generation and deployment rather than experimentation.

The honest summary is that MOSS-TTS-Nano competes on the combination of multilingual output, cloning, and CPU-only operation in one package. Each of those exists elsewhere; the bundle is the argument.

Licence, maintenance, and upgrade cost

The repository is Apache-2.0 and is not archived. The last push was on 2026-09-06, which is recent enough that the project is being touched, though a single push date says nothing about release cadence. No releases were retrieved for this repository, so version 0.1.0 in pyproject.toml is the only version marker available.

Apache-2.0 covers the code in this repository. It does not automatically settle the licence of the model weights hosted on Hugging Face and ModelScope, since those live in separate repositories with their own terms. The README does not discuss that split, so check the model card before commercial deployment. This is a factual gap, not legal advice.

Upgrade cost is dominated by the pinned dependencies. Moving to a newer torch means either waiting for the maintainers to bump the pin or testing the ONNX path as your stable runtime. The ONNX route has fewer moving parts, since onnxruntime is specified as a minimum version rather than an exact one, which makes it the lower-friction target for a production service.

Editorial conclusion

Adopt MOSS-TTS-Nano if you need multilingual speech generation on CPU machines without a GPU, and you are willing to read the source when the README stops. Do not adopt it if you need documented latency budgets, a stable API contract, or a dependency set that will not collide with an existing torch 2.7.0 pin. Before committing, verify three things: that the ONNX weights at OpenMOSS-Team/MOSS-TTS-Nano-100M-ONNX download and load on your target CPU, that infer_onnx.py produces 48 kHz stereo output on your reference text, and that the Apache-2.0 licence covers the weights as well as the code, since the README does not address that split.

Frequently asked questions

Official sources

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