Phonon 31m vs 40m: Commercial Licenses and Which Runtime to Use

Phonon 31m English permits commercial use under Apache 2.0. Phonon 40m models, including the multilingual version, use CC BY-NC 4.0 and need separate permission for commercial use. For a paid product, that distinction matters before any comparison of speech quality or download size.

Gradium's November 5 technical overview brought renewed attention to these models, whose open release happened in October. The useful question now is which combination of checkpoint and runtime belongs in your application. A working demo can conceal a licensing problem, and a successful Python example can conceal the wrong deployment architecture.

Choose the checkpoint before choosing the voice

The 31m model card identifies an English checkpoint with 64.5 MB quantized weights. The 40m multilingual card lists 74.6 MB weights and five languages: English, French, German, Spanish and Portuguese. These are weight-file sizes, not promises about installed application size or peak memory.

Choice	Language coverage	Published license	Commercial starting point
Phonon 31m English	English	Apache 2.0	Review and meet the license conditions
Phonon 40m language-specific models	The selected language	CC BY-NC 4.0	Obtain suitable commercial permission
Phonon 40m multilingual	Five supported languages	CC BY-NC 4.0	Obtain suitable commercial permission

A permissive runtime does not make every model permissive. Keep an inventory of the exact checkpoint, voice files and software you distribute. Save the applicable terms with your release records rather than relying on a product page's broad description of the family as open source.

For example, an English-only paid reading app has a plausible starting point in 31m. Adding French later changes more than a language setting: it introduces a different checkpoint and a commercial licensing decision. Make that decision before promising French support to customers.

Use ptts for the device, Transformers for a different workload

Gradium's technical overview describes ptts as the on-device, single-stream route and Transformers as the PyTorch implementation suited to batched GPU generation. They serve different engineering priorities even when they use the same model family.

The ptts repository provides a Rust runtime without a PyTorch dependency. Its quickstart downloads and caches the model on first use. That makes “works offline” a property you should verify after provisioning the required files, rather than assume on a fresh installation.

For a reading app, start with the device runtime and measure responsiveness on the least capable supported phone. For a job that generates thousands of audio clips on a GPU, investigate batching instead. A fast single-utterance demonstration cannot tell you which system will finish that larger job sooner or more cheaply.

Keep model loading separate from synthesis in your measurements. A cold installation, a cold process with cached weights and a warm model are three different user experiences. Reporting only the warm result can hide a delay your customer encounters every morning.

Check normalization before blaming the model

The Transformers documentation explicitly warns that its tokenizer does not spell out numbers, amounts, symbols or addresses. It also documents splitting long text into chunks. These details matter when moving between an application runtime and a research implementation.

Consider this illustrative acceptance case, not a reported test result: “Your appointment is on 03/04 at 9:15. Bring reference AB-104.” Before generating audio, decide whether the date means March fourth or April third, whether the time is morning, and how the reference should be read. Then record the intended spoken form alongside the input.

Do not flatten every number into the same rule. A price, telephone number and product code need different treatment. Build cases from the fields your product actually reads, including punctuation and abbreviations, and listen to the resulting audio. An intelligible sentence can still communicate the wrong appointment date.

Offline generation does not mean offline voice cloning

The Transformers documentation says the speaker codec is not released and that the implementation uses precomputed voice latents. It cannot create a new cloned voice from a recording through that component alone. Treat custom-voice creation as a separate workflow with its own service, permission and privacy requirements.

That separation should appear in your architecture review. Ask where the original recording goes, which voice artifact the application stores, and whether speech generation subsequently requires a network connection. Obtain consent for any person's voice rather than treating a downloadable model as permission to reproduce it.

A small release gate is better than a leaderboard shortcut

For the reading-app example, require four things before shipping: documented distribution rights, successful synthesis after disconnecting the network, correct reading of critical structured fields, and acceptable startup and playback behavior on target hardware. Add a long passage to catch awkward boundaries between chunks.

These are proposed checks, not results from testing Phonon here. Published quality rankings are useful for choosing what to evaluate, but they cannot settle those product requirements. The sensible checkpoint is the one you can legally distribute and reliably operate in the application you are building, even if another entry looks slightly better in a listening table.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain model choices, product trade-offs and launches in content developers can actually use.

Book a 30-minute call