New 12MB On-Device TTS Option: SteerTTS-edge Supports 200 Voices and 50 Styles

On-device text-to-speech (TTS) has long faced a dilemma: either the model is too large to fit into an app, or it's compressed so aggressively that audio quality collapses. SteerTTS-edge, now available on Hugging Face, attempts to preserve full controllability within a 12MB footprint—no small feat.

Breaking Down the Size Compression in Three Steps

SteerTTS-edge has a total size of 11.84MB, encompassing everything the app needs to ship: model weights, voice data, the text frontend, and the Python runtime. The author breaks the compression down into three components:

• Acoustic model: 9.25M parameters with an attention + bidirectional Mamba-3 architecture, compressed to int4 precision via quantization-aware training (QAT)
• Vocoder: 6.2M parameters, a Vocos-style model distilled from charactr/vocos-mel-24khz, also using int4 QAT
• Text frontend: Implemented purely in numpy, requiring no NLTK, g2p_en, torchaudio, or num2words at runtime

The frontend approach is particularly noteworthy. Many TTS solutions bundle heavy dependencies into production environments, causing the final artifact to far exceed the model itself. SteerTTS-edge switches to numpy for text normalization, effectively treating the "dependency chain" as the optimization target rather than just focusing on model weights.

Quantization-Aware Training (QAT) is a technique that simulates low-precision (e.g., int4) numerical errors during the training phase. Unlike PTQ (post-training quantization), which directly truncates weights after training, QAT inserts fake quantization nodes in the forward pass so the model "perceives" the precision loss during training and adjusts weights via backpropagation to compensate. For generation tasks like TTS that are sensitive to waveform details, QAT can significantly mitigate the quality degradation caused by int4—this is the key that allows SteerTTS-edge to retain controllability within 12MB.

Bidirectional Mamba-3: Mamba belongs to the state space model (SSM) family, processing long sequences with linear complexity and using less memory than Transformer attention mechanisms for long-text modeling. The bidirectional structure lets the model leverage both past and future context, suitable for tasks like speech prosody prediction that require a global view.

Trade-offs Between Audio Quality and Controllability After Quantization

The author conducted local evaluations under the Open TTS Leaderboard protocol (unofficial submission), with the following data:

Version	Seed-TTS WER / UTMOS	CV3-Eval WER / UTMOS
v1 fp32 (no refiner)	0.96% / 4.20	—
edge	0.96% / 4.11	—

Intelligibility is virtually lossless, with WER unchanged. UTMOS drops by about 0.1, which the author acknowledges comes mostly from the int4 vocoder. More critically, the 12 numerical controls (speech rate, loudness, pitch, pitch range, sentence-final rise, pauses, tilt, breathiness, etc.) retain at least 95% of the fp32 version's control effectiveness after quantization. This means quantization isn't simply "throwing away controllability for size"—it's targeted training to preserve control dimensions.

For style, 50 tags and inline markup syntax are provided, for example:

Well, *that* was fast. [pause 400ms] <slow>Let me think.</slow> <whisper>Don't tell anyone.</whisper>

This inline markup is developer-friendly: pauses, speech rate, whispers, and other effects can be embedded directly in the text stream without extra API calls or parameter tweaking.

UTMOS is an objective audio quality metric based on MOS (mean opinion score) prediction, typically trained on large amounts of subjective rating data using neural networks to output a 1-5 naturalness estimate. It complements WER: WER measures "can you understand it," while UTMOS measures "does it sound human." The 0.1 UTMOS drop mentioned here is usually subtle in subjective listening but approaches the sensitivity boundary of on-device models.

Seed-TTS WER / UTMOS and CV3-Eval are evaluation sets and protocols commonly used in the Open TTS Leaderboard. Seed-TTS focuses on intelligibility and naturalness of zero-shot speech synthesis, while CV3-Eval covers more accents and scenarios. The author reproduced these protocols locally but did not make an official submission, so the data should be viewed as a reference baseline rather than an authoritative ranking.

Performance and Deployment Form

In a CPU-only environment (2018 Threadripper, under load), RTF with 4 threads is 0.053—about 19x real-time—with first-packet audio latency of approximately 120ms, supporting sentence-level streaming output. Installation and invocation are straightforward:

pip install .
steertts-edge "Hello there, nice to meet you." -o hello.wav

One easily misunderstood point: weights are dequantized back to fp32 at load time, so the benefit of this optimization is size, not inference speed. The author explicitly notes this—unless new kernels are written for edge devices, speed won't improve due to int4.

RTF (Real-Time Factor) is a core metric for measuring speed in speech synthesis, defined as the ratio of time required to generate audio to the audio duration. An RTF below 1 means faster than real-time; 0.053 means generating 1 second of audio takes only about 0.053 seconds, roughly 19x real-time. First-packet audio latency refers to the time from input text to the first playable audio segment, which is critical for interactive applications like voice assistants.

Dequantization back to fp32 means int4 weights are used only for storage and transmission, while inference still computes in fp32. This explains why size shrinks dramatically while speed remains unchanged: the computation graph isn't optimized for int4 instruction sets, and unless low-precision kernels are written for specific hardware (e.g., mobile NPUs), inference throughput won't improve from quantization.

Limitations and Use Cases

SteerTTS-edge's boundaries are quite clear: English-only, 200 voices (a subset of the full model's 2,825), no voice cloning, free-text prompts, or streaming refiner. The author states these capabilities remain in the full model. Additionally, emotion tags are mostly just style switches, with fast/anger effects being relatively weak.

From an engineering perspective, this trade-off is reasonable. The 12MB size means it can fit into mobile apps, browser WASM bundles, or embedded devices, while 200 voices and 50 style tags are sufficient for most scenarios like reading, notification sounds, and accessibility announcements. Applications that truly need cloning or nuanced emotional expression shouldn't rely on small on-device models anyway.

Open Questions Worth Watching

The author actively solicits two types of feedback from the community: how to close the vocoder quality gap, and which edge targets (ONNX, mobile, WASM) should be prioritized. The vocoder's 0.1 UTMOS loss may seem minor, but further improving quality under int4 conditions may require distillation strategies or targeted perceptual loss adjustments rather than simply adding parameters.

Another implicit issue is the presence of the Python runtime. The 11.84MB includes the Python runtime, which may not be optimal for mobile or WASM scenarios. If the project moves to ONNX or native mobile deployment, there's room to further compress size and startup latency, but whether the numpy-based text frontend can migrate smoothly remains unknown.

For developers looking for a lightweight TTS solution, SteerTTS-edge offers a baseline worth testing. Its value isn't in having the highest benchmark scores, but in demonstrating that quantization-aware training can preserve both numerical control and style tags—two types of "playability"—within 12MB, which is uncommon among small-model TTS.

ONNX (Open Neural Network Exchange) is a cross-framework model exchange format that supports exporting models trained in PyTorch and others as runtime-agnostic computation graphs, facilitating deployment on mobile, browser WASM, or embedded devices. WASM (WebAssembly) is a binary instruction format that runs near-natively in browsers, suitable for embedding TTS models directly into web pages without a server. The Python runtime has significant size and startup overhead in WASM, so moving to ONNX or native mobile deployment is a common evolution path for on-device TTS—but whether the numpy-dependent text frontend can be replaced or rewritten as pure C/WASM-compatible code is a real challenge in migration.

One-line Summary

SteerTTS-edge achieves on-device TTS in 11.84MB, preserving intelligibility and 95% controllability after int4 quantization.

Paragraph Summary

SteerTTS-edge is an approximately 12MB on-device speech synthesis solution that compresses its acoustic model (9.25M parameters) and vocoder (6.2M parameters) to int4 via quantization-aware training and implements the text frontend purely in numpy, packing model weights, voice data, frontend, and Python runtime into 11.84MB. Evaluations show WER remains unchanged at 0.96%, UTMOS drops only 0.1, and 12 numerical controls and 50 style tags retain at least 95% of the fp32 version's effectiveness after quantization. With 4 CPU threads, RTF is 0.053 (about 19x real-time), first-packet latency is about 120ms, and sentence-level streaming is supported. Its limitations are clear: English-only, 200 voices, no cloning or free-text prompts, and int4 benefits size rather than speed. The author is soliciting feedback on vocoder quality improvements and edge deployment targets like ONNX/mobile/WASM.