Gradium and Hugging Face authors published a technical overview of Phonon, a family of small speech-synthesis models, on November 5. The article explicitly looks back at the first two weeks after the models were opened. This is therefore not a fresh product launch today. Our original analysis uses the new technical discussion to examine local processing and the work needed to integrate it into an application.

Choose a checkpoint, not just a family name

The public Phonon 31m model card describes an English model under Apache 2.0, producing mono 24 kHz audio, with 64.5 MB quantized weights. Its stated 31 million parameters exclude the audio tokenizer. That distinction matters when estimating the complete package that must reach a user's device.

The Phonon 40m Multilingual card lists English, French, German, Spanish and Portuguese, but uses CC BY-NC 4.0. Access to the files requires accepting conditions on Hugging Face. Bulgarian is not among the listed languages. A publicly readable model card and permission for every commercial use are different matters. A product team needs to choose the appropriate variant before integrating it.

Offline operation needs preparation

The xn-ptts repository provides a Rust runtime that does not require PyTorch, alongside integrations for different platforms. Some tools download and cache a default model on first use; supplying an already prepared local folder is another route. Offline readiness should consequently be checked after the required resources have been delivered, rather than inferred from a demonstration that already has everything cached.

Consider an illustrative warehouse application that must read instructions when connectivity disappears. A useful pilot would start on a clean device. Is the model available, is the correct voice selected, and what does the worker see if preparation was interrupted? SIExpo has not conducted that test. These are acceptance criteria for an integration whose sound button should not imply readiness before its dependencies are present.

The beginning of audio is not the end of an utterance

The Transformers documentation describes sequential generation of audio representations, followed by decoding into sound. This helps explain why starting playback and completing the recording are separate events. Our interface recommendation is to observe both. A person may hear an opening quickly while the remainder is still being generated, or may need to interrupt it.

An evaluation should also include numbers, product identifiers and unusual punctuation from the actual application. A pleasant demonstration voice does not establish correct pronunciation of particular names. Nor does a compact weights file establish runtime memory use, battery consumption or behavior while the device is busy with other work. Those questions require measurements on the intended hardware.

For a user-facing pilot, we would record a small, repeatable set of real instructions and ask listeners to identify important details without seeing the text. The point would be whether the intended message survived, including any identifier that changes the action. This is a proposed editorial evaluation method, not a reported Phonon result.

What a leaderboard can establish

The Open TTS Leaderboard methodology treats intelligibility, speed and naturalness as distinct aspects, and also supports listening to and comparing recordings. A single metric does not describe every quality of a voice. We do not turn a vendor's leadership claim into a universal recommendation, and we have not independently benchmarked these models.

For deployment, we would record the checkpoint version, language, voice, device and test conditions. Acceptance should cover failure as well: an unavailable resource, invalid input or cancelled request needs to produce a comprehensible state. Local synthesis offers a way for applications to speak without a permanent cloud round trip. Suitability for a particular product still depends on quality, usage rights and a complete user workflow.