Hojo-TTS-Light: two small bilingual text-to-speech models for local use

Two models, and what makes them small

Hojo-TTS-Light is an open-source lightweight Text-To-Speech model by the HojoAI team, and it currently comprises two models, a 0.04B and a 0.08B model, named Hojo-TTS-Light-40M and Hojo-TTS-Light-80M.

The feature list puts it plainly: the core language model is only 80M and 40M parameters, with an extremely small parameter size under the same sound quality and a very low deployment threshold.

That is a different objective from most open TTS releases. The interesting claim is not that the quality is remarkable, but that the quality is acceptable at a size where you can run it somewhere awkward. The readme supports that with a number, an average DNSMOS above 4.0 on the Seed-TTS evaluation dataset, which is the metric the model is measured against.

Both models follow the token-LM framework, which is the structural decision that makes the small size possible. Instead of generating raw audio samples, the model generates tokens of a learned speech representation, and a separate component turns those tokens into a waveform. The model details section says the speech tokenizer is composed of an 18M encoder and a 30M decoder, so the tokenizer is a meaningful part of the system and not a rounding error, and the language model itself is the part that has been made small.

The released version runs at a 50Hz token rate, and a 12.5Hz version is promised soon. That is a rate rather than a sample rate, it is the frequency at which the model emits speech tokens, and halving it roughly halves the sequence length for the same audio, which is the kind of change that matters for inference cost.

The models support Chinese and English, with a single model handling both, which the feature list describes as native bilingual integration with no branch switching required.

What the token-LM framework changes

The framework the models follow is the part that explains the parameter counts, and it is worth being precise about what it means.

The model details section states two things: that the model follows the Token-LM model paradigm, and that the speech tokenizer is composed of an 18M encoder and a 30M decoder.

So the system has three parts. An encoder that turns audio into tokens, a decoder that turns tokens back into audio, and a language model in between that predicts the token sequence for the text you want spoken. The language model is the part trained on text and speech pairs to predict what comes next, and it is the part the 40M and 80M figures refer to.

The advantage of this arrangement is that the language model operates on a short sequence of discrete symbols rather than on thousands of audio samples per second. A model generating raw samples has to spend its capacity on waveform detail, and the sequence it predicts is enormously long. A model generating tokens at 50Hz predicts a sequence a couple of orders of magnitude shorter, which is what makes a small parameter count sufficient.

It also explains why the encoder and decoder sizes are stated separately. They are not trained as part of the language model and they are not what you would be fine-tuning, so their size does not affect the headline number in the same way. The 18M plus 30M figure tells you the fixed cost of the speech representation itself, which is a floor on the deployment size no matter how small the language model gets.

The credits support this reading. X-Codec-2.0 appears first in the list, and a speech codec credit is consistent with the model using a discrete speech token vocabulary.

The practical consequence for a user is that the tokenizer is fixed. You cannot change the token vocabulary without retraining, and the choice of token rate constrains both the latency and the compression behaviour of the system.

Voice cloning, voice counts and the CPU claim

The two models are not simply two sizes of the same product, and the differences are worth mapping.

Hojo-TTS-Light-40M supports 15 built-in voices, 2 for Chinese and 13 for English. Hojo-TTS-Light-80M also supports voice cloning with a few seconds of audio.

So cloning is exclusive to the larger model. That is a sensible allocation, since voice cloning is the capability that has to be good enough that a listener notices, and the 80M model has twice the parameters of the 40M one to spend on it.

The deployment story is the other differentiator, and it is the reason the project mentions ONNX at all. The readme says they provided an optimized ONNX model packaging file, so that users can perform speech synthesis efficiently on CPU without requiring a GPU. The feature list puts the same point differently, with low memory usage and low inference overhead, which can run smoothly on CPU, ordinary GPU, and embedded edge devices.

A CPU-only path matters more than it used to. A lot of speech synthesis today reaches a server because the model is too large to run locally, which means an API key, a per-character cost, a network round trip and a privacy problem for any text you did not want leaving the machine. A model with a documented CPU path removes all four, and the ONNX packaging is the mechanism, since ONNX is a portable inference format and an optimized package is a pre-quantised or pre-compiled graph that avoids the setup cost a raw model would carry.

The road map shows this work is incremental rather than finished. There are checked items for the 202605, 202606 and 202608 releases covering the v1 80M model, the 40M model, an update to the optimized ONNX model file with KV cache merging, and v2 releases of both models with fine local models added.

The KV cache merging detail is worth noting for anyone tracking inference efficiency, since it reduces redundant computation across generated tokens, which is the kind of optimisation that shows up as lower CPU time rather than as a new feature.

Quick correction, and the roadmap of what is missing

One feature stands out as the one a Mandarin speaker would ask about first, and it is the feature list entry for quick correction.

For the problem of easily mispronouncing Chinese and English polyphonic characters and proper nouns, users can directly use Pinyin to correct pronunciation errors and improve the reliability of speech synthesis.

Polyphonic characters are the classic failure case for Chinese TTS, because a character's pronunciation depends on context that the model has to infer, and proper nouns are worse because they are often outside the training distribution entirely. Letting the caller write the intended pinyin directly turns an unpredictable output into a controlled one, at the cost of the caller having to know the pronunciation they wanted.

That is a real design trade and the project makes it explicitly. The alternative, leaving it to the model, is more convenient but less reliable, and for a name in an announcement or a product label, reliability usually wins.

The road map then lists what is not there yet, and all three items are unchecked: support streaming mode synthesis, support emotion and style control, and support multi-lingual and multi-dialect.

Streaming is the one that would block a lot of use. Without it, the whole utterance is generated and then played, so the first audio comes after the generation completes, and the latency scales with the length of the text. For a voice assistant that is disqualifying; for producing a file to play back it does not matter.

Emotion and style control is the other gap that a user with a specific brief will notice, and multi-lingual and multi-dialect is the gap that limits the model to two languages.

So the honest summary of the current state is a compact, CPU-friendly, bilingual synthesis model with cloning in the larger variant and manual pronunciation control, without streaming, style control or broader language coverage.

The interface, the credits and the licence

The Ready to Use feature entry says the project provides simple inference scripts and fast calling interfaces, enabling synthesis and cloning with one line of code, facilitating secondary development and business integration.

The repository layout matches that promise and shows it is a weights-and-code release rather than a package. The top level holds a directory for each model, Hojo-TTS-Light-40M/ and Hojo-TTS-Light-80M/, alongside the licence and the readme. There is no setup.py, no pyproject.toml and no package index listing at the top level, so the models are expected to be downloaded and used from a directory rather than installed as a library, and the inference scripts live inside each model directory.

The credits section names three upstream projects, which is the clearest statement of what the architecture is borrowed from: X-Codec-2.0, soprano, and inworld-ai/tts. The speech tokenizer is a substantial part of this project, and the credit to X-Codec-2.0 suggests it is related to that component.

The licence section says the project is open-sourced under the Apache 2.0 License, which can be freely used for academic research, personal projects, and commercial secondary development. There is a LICENSE.txt in the repository.

For teams that need something more than the open model, the readme describes a commercial support offering: commercial support for teams integrating Hojo TTS into their products, including integration assistance, custom voice development, and enterprise licensing, with [email protected] given as the contact.

The homepage is hojoai.com, the licence is Apache 2.0, and the last push was on 2026-10-19. There are no GitHub releases published, so the versions are tracked by the dated road map entries rather than by tags.

Editorial conclusion

Adopt Hojo-TTS-Light if you need speech synthesis that runs on a CPU or an edge device and you want to avoid a hosted API, since the whole design targets small parameter counts and local inference. Do not adopt it if you need streaming synthesis, emotion control or dialect support, because all three are unchecked items on the project's roadmap. Before you commit, check the licence terms yourself, because the readme says the Apache 2.0 code can be used commercially, and note that the 40M and 80M models are different products, with voice cloning only in the larger one.

Frequently asked questions

Official sources

1. HojoAI/Hojo-TTS-Light on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README