Choose theme
AI Resources
MOSS-TTS-Nano
MOSS-TTS-Nano is a 0.1B multilingual text-to-speech model from MOSI.AI and OpenMOSS. It generates speech from text and supports conditioning on a reference voice.
The publisher describes support for 20 languages and recommends its standalone ONNX path for CPU use. Browser reading, CLI use and fine-tuning have their own setup instructions. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.
What it is
Speech generation from text
A compact text-to-speech model with reference-voice conditioning. It produces audio rather than transcribing a recording.
Why it stands out
A standalone ONNX runtime
The CPU inference path uses ONNX Runtime without PyTorch. The project also retains a Python model path; the two paths use different model artifacts.
Availability
Models and application examples
The repository links model downloads, hosted demos, a separate Reader extension and a fine-tuning guide. These are distinct entry points rather than one packaged application.
Why it matters
What makes it useful
Choose the inputs for the task. The voice_clone example pairs a reference recording with the new text to speak. The continuation example with prompt audio also needs prompt_text: the words already spoken in that recording. Supplying only new text, without prompt audio or prompt text, instead follows the guide's plain text-to-speech path. A reference transcript and the new utterance therefore have different jobs.
What to know
Where it fits
Preparing ONNX files requires two repositories. The TTS model package contains the language-model graphs and text tokenizer; MOSS-Audio-Tokenizer-Nano-ONNX supplies the waveform codec. The Reader's browser-only Quick Install recipe places both under MOSS-TTS-Nano-Reader/extension/models, or uses the Browser ONNX PoC's Load And Prepare control to download them. Having just the TTS graphs does not supply the audio codec.
Notable points
What stands out
For a document saved as text, the CLI accepts --text-file rather than requiring the entire passage in a command argument. Its serve command has a different job: the publisher says it keeps the model loaded in memory and exposes a browser app and HTTP generation endpoints. Choose between generating from a file and keeping a service running for repeated requests.
Before using
What to review
Fine-tuning starts with audio and text pairs, optionally with one ref_audio clip per sample. Relative file paths are resolved from the JSONL file's location, so moving that file changes what those paths point to.
The training entry point expects preprocessed audio_codes, plus ref_audio_codes for reference-conditioned samples. The prepare_data script produces those codes; a raw JSONL file of audio paths is not the preprocessed training input.
After fine-tuning, decide which deployment artifacts need rebuilding. The repository says a retrained TTS checkpoint needs the TTS-side ONNX export again. If the audio tokenizer remains fixed, it says existing prompt-audio codes do not need regenerating. Changing the speech model and changing its audio tokenizer are therefore separate reasons to rebuild files.
Check the intended language, reference voice, hardware and latency needs for the chosen path. Confirm consent, identity and permission to use a reference voice before generating speech that resembles a real person.
Reader fit
Who may find it relevant
It fits builders comparing compact local text-to-speech, reference-voice generation and lightweight integration paths. For Reader playback, text normalization is a separate choice from the model or voice. If symbols are spoken unexpectedly, the Reader's usage notes recommend turning off Enable WeTextProcessing. That is the publisher's response to a specific playback symptom, rather than a reason to replace the checkpoint.
Editorial note
Why LifeHubber lists it
We list MOSS-TTS-Nano for builders inspecting the division of work in a compact streaming speech pipeline. The README describes an autoregressive audio-tokenizer and language-model design: the speech model predicts audio codes, while the companion causal codec reconstructs waveform chunks from those codes. This explains what must turn predicted tokens into playable audio, beyond downloading two ONNX packages or choosing a command. The architecture description does not establish latency or voice quality on a particular device.
Source links
Source materials
Reader note
Before relying on this entry
LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.
What to explore next
Move from local generation to a speech API.
If the next task is serving streaming speech over HTTP, vLLM-Omni documents a Nano integration. Its Nano endpoint requires reference audio and accepts but ignores voice and ref_text; the upstream Python examples and this serving wrapper have different input behavior.
More in Speech Models
Keep browsing this category
Explore more speech model resources.
Fish Audio S2 Pro
fishaudio/s2-pro
A text-to-speech model with in-script control over pauses, emphasis and mood.
AuK
Tencent-Hunyuan/AuK
A 1.5B speech model for instruction-guided text-to-speech, content and acoustic editing, paralinguistic changes, speech enhancement, and source separation, with public code, weights, demos, ComfyUI nodes, and fine-tuning materials.
VoxCPM2
openbmb/VoxCPM2
A multilingual text-to-speech model with voice design, controllable voice cloning, and streaming support.
For project maintainers
Listed here? You can use the badge.
If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.
