Post-training quantization effects vary across text-to-speech models
Same Bit Width, Different Outcomes: Post-Training Quantization of Text-to-Speech Across Architectures
Machine LearningSound
Summary
Making text-to-speech programs run faster and use less memory on devices often involves turning detailed data into simpler numbers, a process called quantization. The authors found that when using the same number of bits for this process, different speech models can react very differently, sometimes harming the quality of speech. They created a way to identify which parts of each model are most sensitive to this change and fixed those parts to keep speech quality high. Their approach also works well with real hardware, showing practical improvements in speed on devices like a Mac mini.
What this means in practice
- •For mobile app developers: Improve on-device speech synthesis by tailoring quantization to specific text-to-speech models for better quality and speed.
- •For embedded system engineers: Use the authors’ method to identify sensitive model layers and recover speech quality after quantization for efficient device deployment.
Authors
Se Un Park, Yutae Kim, Junyoung Park
Abstract
Post-training quantization (PTQ) reduces the cost of on-device text-to-speech (TTS), but published evaluations cover one system or method. We evaluate PTQ across TTS architectures under one protocol with three core models, weight and activation ablations of eight more, and two held-out models quantized blind. Four-bit per-channel weights reduce UTMOS, a predicted mean opinion score, by 2.8 on Supertonic and 0.07 on Kokoro, and per-tensor scaling can cause severe degradation even at 8 bits. The same bit width yields different outcomes, because the sensitive component is model-specific and not reliably predicted from the model class. A staged ablation procedure identifies it, and per-layer GPTQ can restore it to within 0.1 UTMOS. Real int8 and int4 kernels reproduce the simulated ordering at hardware-dependent cost. On a Mac mini, a 4-bit weight kernel runs Supertonic at 0.60x the fp32 latency while int8 is slower, so each configuration requires validation on the target runtime.