tiny-tts: an English TTS model with about 1.6 million parameters

The pitch is size, and the numbers are in a table

The README leads with the claim rather than a feature list, describing an ultra-lightweight English text-to-speech with only 1.6M parameters and about 3.4 MB of ONNX. The comparison table is the clearest statement of the trade. TinyTTS is listed at roughly 1.6M parameters against a typical TTS model at 50M to 200M or more, a checkpoint of about 3.4 MB in ONNX FP16 against 200 MB to 1 GB or more, a sample rate of 44.1 kHz, and it is end-to-end, where a typical system often requires a separate vocoder. The argument the README makes from those numbers is about where the model can run, since it says TinyTTS runs comfortably on CPU-only machines, edge devices and embedded systems, making real-time speech synthesis accessible without a GPU. Whether a 1.6M parameter model can sound natural is the question the sample audio files are there to answer.

Three installation paths, and one dependency difference

The Python path is a normal package install:

pip install tiny-tts

or a source checkout that installs in editable mode:

git clone https://github.com/tronghieuit/tiny-tts.git
cd tiny-tts
pip install -e .

The Node.js path is the same name on npm, and the difference is stated clearly, with pure Node.js inference via ONNX Runtime and zero Python dependency, and an ONNX model of about 6 MB that is auto-downloaded from HuggingFace on first use. That last detail is worth noting next to the headline figure, since the npm artefact is described as roughly 6 MB while the README's table says about 3.4 MB for the FP16 checkpoint. A source install on Python also needs the deeper stack, and the README lists it separately:

pip install torch torchaudio soundfile g2p-en transformers numba

The presence of g2p-en and numba tells you the text front end converts words to phonemes before synthesis, which is a normal design for a small English model.

One command, and a fixed set of options

After installation a global tiny-tts command is available, and the simplest invocation names a checkpoint, a sentence and a device:

tiny-tts --checkpoint G.pth --text "Hello world" --device cuda

The fuller example adds an output file, a speaker and a speed factor:

tiny-tts \
  --text "The weather is nice today, and I feel very relaxed." \
  --checkpoint G.pth \
  --output output.wav \
  --speaker MALE \
  --speed 1.0 \
  --device cpu

The CLI argument table lists the options with their short forms, so --text has -t and --checkpoint has -c, and the checkpoint argument is optional in the table, which matches the note that the model downloads a default checkpoint if it is missing. Output files are saved into an infer_outputs/ directory by default. The speaker argument and the speed argument are the two knobs that matter for a real deployment, since a small model with a single voice is a limitation, and the speed control is what lets you trade naturalness against latency.

The Python API is a thin wrapper around speak()

The library side is deliberately small. You construct a TinyTTS object, which auto-detects the device and downloads the default checkpoint if it is missing, and then call speak with an output path:

from tiny_tts import TinyTTS

# Initialize the TTS model (auto-detects device and downloads default checkpoint if missing)
tts = TinyTTS()
# OR specify a custom checkpoint: tts = TinyTTS(checkpoint_path="...")

# Synthesize a single sentence
tts.speak("Hello, this is a test of the Python API.", output_path="hello.wav")

The same method takes a speed argument, with 1.0 as normal, 1.5 for faster and 0.7 for slower, and it accepts a paragraph of several sentences as a single string. The dependency set behind it is where the weight sits, with torch, torchaudio, soundfile, g2p-en, transformers, numba and huggingface_hub in the package metadata, and nltk and gradio appearing in the requirements file alongside them. The package data section also shows what travels with the wheel, a cmudict.rep file and a cmudict cache pickle under tiny_tts.text, and the checkpoint files under tiny_tts.checkpoints, which is how a pronunciation dictionary and a default model end up bundled.

The benchmark says about 53 times real time on a laptop CPU

The README publishes its own measurements rather than asking you to trust a claim, and the protocol is stated so you can judge it. The benchmarks were run on real hardware with the sentence about the weather, which is about 4.9 seconds of audio at 44.1 kHz, on an Intel Core laptop CPU with no GPU, using PyTorch 2.5.1+cu121 and a model of 1.62M parameters, with five warm-up runs and 20 timed runs reported as the median and model load time excluded. On that setup ONNX Runtime on CPU synthesises in 92 ms for 4.88 seconds of audio, about 53 times real time, while PyTorch eager on CPU takes 272 ms for the same audio, about 18 times real time. The README attributes the difference to ONNX Runtime fusing operations and eliminating Python dispatch overhead, and recommends it for CPU deployment.

The comparison table needs its caveats read

The engine comparison places TinyTTS against Piper, KittenTTS nano and mini, Supertonic, Pocket-TTS and Kokoro on the same CPU-only machine with the same sentence and protocol. On raw speed TinyTTS leads with a time to first audio of 86 ms and an RTFx of about 53 times, against Piper at 114 ms and about 26 times with 63M parameters, KittenTTS nano at about 17 times with 10M, Supertonic at about 15 times with 82M, Pocket-TTS at about 4 times with 100M and Kokoro at about 3 times with 82M. The caveats are in the notes. Output sample rates differ, with Piper at 22 kHz, KittenTTS at 24 kHz and TinyTTS and Supertonic at 44.1 kHz, so the audio durations in the table are not comparable in length, and a model synthesising 2.91 seconds of 22 kHz audio is not doing the same work as one producing 4.88 seconds at 44.1 kHz. Sample files for every engine are linked, which is the right way to settle the question.

The packaging metadata still describes a bigger model

There is an inconsistency inside the repository that you should resolve before you plan around the headline numbers. Both pyproject.toml and setup.py describe the project as an ultra-lightweight English text-to-speech model of about 9M params and 20MB, and both carry the version 0.1.0, while the README says 1.6M parameters and a 3.4 MB ONNX checkpoint. The pyproject classifier says Apache Software License, while the licence field points at a LICENSE file while no licence identifier is listed for the repository itself, so the LICENSE file is the authority. The tree explains the rest, with an onnx/ directory and export_onnx.py for the export path, checkpoints/ and assets/ for weights, an npm-package/ directory for the Node wrapper, a Gradio app.py, and benchmark.py and benchmark_onnx.py so the comparison table can be reproduced with python benchmark.py. There are no GitHub releases, the default branch is develop, and the last push was on 2026-04-10.

Editorial conclusion

Adopt tiny-tts if you need speech synthesis embedded in a small footprint, on a CPU-only machine or an edge device, and you can accept English-only output from a model this small. Do not adopt it as a general speech platform, since it is an English model and the comparison table in the README shows comparable engines with tens of times more parameters, which is where the quality headroom is. Verify first the packaging, because the README headlines 1.6M parameters and a 3.4 MB ONNX file while the package metadata still describes about 9M parameters and 20MB, so check what the installed artifact actually contains before you size your deployment around it.

Frequently asked questions

Official sources

1. Issues
2. README
3. tronghieuit/tiny-tts on GitHub