MOSS-TTS-Nano is a **0.1B-parameter multilingual speech generation model** released by [MOSI.AI](https://mosi.cn/) and the [OpenMOSS team](https://www.open-moss.com/) at Fudan University's NLP Lab. Opened on 10 April 2026 under Apache-2.0, it has gathered roughly 4,035 stars and 517 forks. The premise is deliberately unfashionable: instead of scaling a TTS model up, shrink it until it runs in realtime on a CPU that has no GPU behind it at all. ## What 0.1B Buys You The architecture is a pure autoregressive **Audio Tokenizer + LLM** pipeline — no diffusion head, no flow-matching decoder, no vocoder bolted on the end. Text goes in, discrete audio tokens come out, and the tokenizer decodes them to waveform. Keeping the stack this plain is what makes the deployment story work. The headline specs are concrete rather than aspirational: | Property | Value | |---|---| | Parameters | 0.1B | | Native output | 48 kHz, 2-channel (stereo) | | Languages | 20 (Chinese, English, German, Spanish, French, Japanese, Korean, Russian, Arabic, and more) | | Inference | Streaming, low first-audio latency | | CPU floor | Streaming generation on a 4-core CPU | | License | Apache-2.0 | 48 kHz stereo is worth pausing on. Most open TTS models emit 24 kHz mono because that is what their vocoder was trained for; shipping native 48 kHz stereo from a 100M-parameter model is the less common choice, and it removes an upsampling step from any production audio chain. ## The ONNX Path Is the Real Story The 17 April release of a **standalone ONNX CPU version** changed what the project is for. It drops the PyTorch dependency at inference entirely and runs on ONNX Runtime alone, which collapses the install footprint for anyone embedding TTS in a desktop app or a service container. In the team's own testing it delivers close to **2x the processing efficiency** of the original PyTorch path, and runs smoothly on a **single CPU core** of a MacBook Air M4. That last number is the one that matters. A single core means TTS stops being a resource you schedule and becomes a resource you assume. The team built on it immediately: **MOSS-TTS-Nano-Reader** now runs the model directly inside the browser as an extension, with no separate local inference service, and there is an Android ONNX Runtime example under `examples/android_onnx_runtime` that loads the exported graphs on device and writes a WAV file locally. Four entry points cover the range: `python infer.py` for direct inference, `app.py` for a local FastAPI web demo, `moss-tts-nano generate` / `serve` as a packaged CLI, and the ONNX variants of each via `--backend onnx`. For server deployment there is a documented [vLLM-Omni](https://github.com/vllm-project/vllm-omni) path with paged KV cache, streaming, and an OpenAI-compatible `/v1/audio/speech` endpoint — meaning an existing OpenAI TTS client can point at a self-hosted MOSS-TTS-Nano without code changes. Finetuning code landed on 16 April, and [mlx-audio](https://github.com/Blaizzy/mlx-audio) support followed on 6 May for Apple Silicon. ## MOSS-Audio-Tokenizer-Nano The quality ceiling of any tokenizer-plus-LLM TTS system is set by the tokenizer, and the project ships its own. **MOSS-Audio-Tokenizer-Nano** is roughly **20M parameters**, built on the **Cat** architecture (Causal Audio Tokenizer with Transformer) — a CNN-free design composed entirely of causal Transformer blocks. It compresses 48 kHz stereo audio into a **12.5 Hz token stream** using **RVQ with 16 codebooks**, spanning variable bitrates from **0.125 kbps to 2 kbps**. The repository publishes reconstruction-quality comparisons against open-source tokenizers under 120M parameters, measured with SIM, STOI, PESQ-NB, and PESQ-WB on LibriSpeech and AISHELL-2, plus Mel-Loss and STFT distance on AudioSet and MUSDB. The claim is that it achieves the best overall reconstruction quality while remaining among the smallest models compared — and the bitrate sweep is presented as a curve rather than a single favourable point, which is the honest way to report a codec. ## Where It Fits MOSS-TTS-Nano is the small end of a family. The same team ships **MOSS-TTS** (8B flagship, zero-shot cloning with Pinyin/phoneme/duration control), **MOSS-TTSD-v1.0** (8B, multi-speaker dialogue), **MOSS-VoiceGenerator** (1.7B, voice design from text prompts), **MOSS-SoundEffect** (8B), and **MOSS-TTS-Realtime** (1.7B, voice agents) — all sharing MOSS-Audio-Tokenizer as a common discrete audio interface. Nano is not a stripped-down flagship; it is the deployment tier of a stack that is coherent from 0.1B to 8B. The practical friction is real, though. Installation depends on `pynini` and `WeTextProcessing`, which are the two Python packages most likely to fail on a clean machine — the README devotes a full section to conda workarounds and links to a community issue thread for non-conda users. There are 19 open issues, and the README carried an unresolved license placeholder for a period after launch (the root `LICENSE` file now confirms Apache-2.0). The project also publishes no objective naturalness or intelligibility benchmark for the Nano model itself: the evaluation tables cover the tokenizer's reconstruction quality, not end-to-end TTS quality, so the fair reading is that 0.1B is "good enough for realtime products" by the team's own framing rather than competitive with 8B output. ## Verdict The interesting claim here is not quality — it is the removal of the GPU from the TTS deployment diagram. If a 100M model at 48 kHz stereo runs on one CPU core of a laptop, then voice output stops being an infrastructure decision for browser extensions, desktop apps, embedded devices, and anything that ships to users rather than to a datacentre. Teams building agents that speak, offline readers, or accessibility tooling should start with the ONNX path and evaluate whether the quality clears their bar; teams that need broadcast-grade expressiveness should look at the 8B flagship in the same family instead.