tiny-voca Open-Sources a 4.5M-Parameter TTS Model Running 70x Real Time on CPU

Summary:Developer n4ze3m has released tiny-voca, a compact English text-to-speech model with 4,537,291 parameters and an 18 MB checkpoint. The project publishes its code, weights, training recipe, dataset, and custom phonemizer under an open development model. Its defining design choice is the removal of a neural vocoder. A lightweight source-filter synthesizer generates 24 kHz waveforms directly, allowing the model to run about 70 times faster than real time on four CPU threads and execute in browsers

---

tiny-voca Brings End-to-End Speech Synthesis to the Browser with 4.5M Parameters

tiny-voca is a fully open lightweight English TTS project with 4,537,291 parameters and an approximately 18 MB checkpoint. The release includes waveform generation rather than shipping only an acoustic model, and the author has published the code, weights, training recipe, dataset, and a custom phonemizer. It runs through PyTorch, ONNX, and browser-based inference, producing audio at 24 kHz.

The developer reports running the model at roughly 70 times real time on four CPU threads. Training from scratch took 7.7 hours on a single RTX 4090. The result places compact speech synthesis within reach of ordinary browsers, CPUs, and edge devices rather than requiring a GPU-backed neural vocoder pipeline.

The Key Design Choice: No Neural Vocoder

The central innovation is not simply distilling a large TTS model. tiny-voca changes the waveform-generation path. It uses a small source-filter synthesizer to produce the output directly instead of asking a neural vocoder to reconstruct a waveform from high-dimensional acoustic features.

This design removes several expensive stages:

• It does not need to generate large spectrogram or discrete acoustic-token tensors.
• It does not run a compute-heavy neural vocoder during inference.
• It avoids the large intermediate activations associated with high-resolution acoustic representations and long sequences.
• Model size, browser download cost, and server memory pressure all fall together.

From an engineering perspective, the 70x real-time figure does not mean the model matches the quality of a large neural TTS while beating it outright. It reflects a clear quality-latency-resource trade-off: a simpler and more interpretable signal-synthesis mechanism is used to achieve very low latency and easy deployment. The system still has an audible synthetic character, which is consistent with that architecture.

Text Normalization and Pronunciation

The project uses a custom phonemizer called dizione to convert text into a phoneme representation before acoustic synthesis. This is another important part of the lightweight design. Feeding raw characters or subword tokens directly into a model forces it to learn spelling-to-phoneme conversion alongside acoustic generation, including handling of open vocabulary, heteronyms, and proper names.

The custom phonemizer does not, however, eliminate English normalization problems. The author notes that foreign names and unusual spellings are still often pronounced incorrectly. Numbers, dates, units, abbreviations, and proper nouns will therefore need frontend rules or pronunciation dictionaries. A production integration should not simply pass arbitrary user text through the model without applying text normalization first.

Training-Data Quality Sets the Ceiling

The training audio is also synthetic: it was generated with Qwen3-TTS. This is a material limitation. A student model cannot reliably exceed the acoustic quality of its supervision, so mechanical articulation, weak prosody, and pronunciation errors in the teacher output can be inherited by tiny-voca.

That helps explain the unusual contrast between the project's openness and efficiency and its still-synthetic listening quality. A 7.7-hour, single-GPU training run is excellent for experimentation and reproducibility, but a 4.5M-parameter model is unlikely to repair poor source audio on its own. Moving toward near-human naturalness still requires better real recordings, broader speaker coverage, and stricter dataset cleaning.

How to Interpret the Performance Claim

A 70x real-time result means that generating one second of audio requires roughly 1/70 of the available real-time window. That is more than enough for interactive narration, but the published information does not support a universal benchmark comparison:

• Text length, batching behavior, and whether audio encoding is included are not specified.
• The RTF appears to be an author-reported measurement without a detailed methodology.
• Latency differences among PyTorch, ONNX, and browser execution are not provided.
• Time to first audio, peak memory, CPU model, and thread configuration are absent.
• There is no controlled comparison with neural-vocoder TTS systems or larger generative TTS models.

The number is best treated as evidence that the architecture is viable under the author's test setup, not as a general performance ranking.

Engineering Trade-offs

Advantages

• Very small deployment footprint: An 18 MB checkpoint is suitable for browsers, mobile devices, edge boxes, and offline tools.
• Local privacy: The browser demo performs inference locally and does not send text to a server.
• Low training cost: The model can be trained from scratch in 7.7 hours on one RTX 4090.
• High reproducibility: Code, weights, data, and the training recipe are all available.
• Short inference path: Removing the neural vocoder enables unusually strong CPU real-time performance.

Costs

• English-only support, two fixed voices, and no voice cloning.
• Pronunciation errors remain common for names and unusual spellings.
• Sound quality, naturalness, and prosody still need improvement.
• The Qwen3-TTS-generated corpus imposes the teacher system's quality ceiling.
• A 4.5M-parameter model has limited capacity for complex prosody, speaker diversity, and long-form stability.

Deployment Recommendations

tiny-voca is best suited to offline narration, accessibility output, embedded prompts, browser speech utilities, and educational examples of compact model design, rather than serving as a direct replacement for high-naturalness commercial TTS.

Before deployment, developers should test three areas:

1. Text normalization: Cover numbers, dates, units, abbreviations, names, and heteronyms.
2. Long-form stability: Look for phoneme drift, repetition, truncation, or unnatural pauses.
3. Backend consistency: Compare PyTorch, ONNX, and browser outputs for waveform and sampling-rate differences.

If higher fidelity is required, tiny-voca's phoneme or duration output could feed a more expensive neural vocoder as a two-stage pipeline. That would sacrifice much of the current speed and deployment advantage. A more practical path is to treat tiny-voca as a baseline and fine-tune it with targeted frontend rules, real recordings, and domain-specific data, rather than expecting a 4.5M-parameter model to cover the full general-purpose TTS market on its own.

---

Source: Reddit r/LocalLLaMA (2026-11-14)

— END —

Tags: #tiny-voca Follow #lightweight TTS Follow #end-to-end speech synthesis Follow #source-filter synthesis Follow #browser inference Follow