IMPORTANT READ: Audio8’s “0.1B” label is very misleading.
This needs to be corrected. Let me explain myself.
Audio8 is prominently marketed as a “0.1B TTS model,” but none of the relevant deployment configurations is actually close to 100M parameters.
The released weights show:
- Main generative model: 169,779,904 parameters
- Codec decoder: approximately 120M parameters
- Complete bundled codec: 337,428,866 parameters
That produces three very different figures:
- Backbone alone: 169.8M
- Waveform-generation path: approximately 290M
- Complete arbitrary-reference zero-shot stack: 507,208,770 parameters
Even the backbone does not round to 0.1B under normal one-decimal rounding. 0.1698B rounds to 0.2B, not 0.1B. Calling it 0.1B predictably makes readers think this is roughly a 100M-parameter system comparable in footprint to genuinely sub-100M TTS models. It is not.
The complete repository also contains approximately 1.69 GB of learned weights.
The model card eventually acknowledges that the main model is approximately 170M and that the codec decoder adds approximately 120M. That disclosure does not fix a headline and repository name that continue presenting the product as 0.1B. Most users will interpret the model’s name before auditing its weight files or reading architecture footnotes.
The codec cannot simply be dismissed as an unrelated optional component:
- Speech cannot be produced without the codec decoder.
- Arbitrary-reference zero-shot cloning requires the codec encoder.
- Zero-shot voice cloning is one of the release’s headline features.
Therefore, fair labelling would be:
- 170M backbone
- ~290M generation stack
- ~507M complete zero-shot stack
If you properly marketed this model like other TTS models, this should be a ~0.5B model. Not '0.1B'. 5x difference - a very large difference. Even the reduced deployment with pre-encoded reference information requires approximately 0.29B parameters. That distinction is far too large to communicate only through component notes while retaining “0.1B” in the repository name, headline, and comparisons. The same counting issue affects Audio8’s 0.6B release, although proportionally less severely.
Whether this presentation was deliberate or not, its effect is misleading: it makes the model appear dramatically smaller in comparisons, search results, posts, and benchmark tables than the complete released system actually is.
Audio8 may still be technically impressive. That is not the issue. The issue is accurate measurement. Please rename or clearly relabel the release and display the complete parameter breakdown beside every prominent 0.1B claim. A model should not receive the marketing advantage of a 100M label when its backbone is 170M, its generation path is approximately 290M, and its complete advertised zero-shot system exceeds 500M.
Thanks for the careful analysis and for raising this point.
To clarify the naming: like the 0.6B release, the "0.1B" figure refers specifically to the DualAR backbone — the primary generative model — following the counting convention commonly used in the industry, where the main model is counted separately from auxiliary components such as neural codecs.
We fully agree that transparency matters, which is why the actual parameter counts are already highlighted in bold in the README ：the backbone (170M), the codec decoder (120M) — so anyone reviewing the repo can verify the exact numbers behind the naming.
On why the codec encoder isn't counted in the inference footprint: in the typical zero-shot voice cloning deployment, the reference audio tokens are pre-encoded in advance (offline), so the codec encoder does not participate in the online inference path at all. During waveform generation only the codec decoder (~120M) is needed. This is exactly why the naming focuses on the components that actually run during inference.
At the same time, we understand that the naming could be misread as the full deployment footprint, and we want to make the series more consistent in this regard. In the upcoming releases we'll ship int8 and fp8 quantized versions of the models together with a more memory-efficient inference pipeline, so the end-to-end deployment footprint under typical inference settings will be substantially lighter.
We'll also keep refining the documentation to clearly distinguish the backbone, the codec components, and the end-to-end footprint under different inference settings.
Thanks again for the thoughtful feedback — we appreciate it.