Exaltus

Would you keep a voice model loaded to avoid a cold start, or release the memory for the rest of your app? @iam_chonchol’s comparison puts real numbers behind that trade-off. His free Colab test used a two-core CPU, no GPU, and both Hojo-TTS-Light variants with everyday sentences, technical terms and more difficult formatted inputs. His reported generation times were about 1.7 seconds per second of audio for 40M and 3.5 seconds for 80M. Neither was real-time on that setup. That is important context for anyone planning an interactive feature: support for CPU inference does not mean every CPU will meet the same response-time requirement. It also explains why results from a more capable local machine should not be used as a direct prediction for a small shared runtime. The other measurements matter just as much to deployment planning. Alamin reported peak RAM of 1.3GB versus 2.2GB and load times of 6 seconds versus 14 seconds. Those values belong to his environment, but they expose two separate engineering questions. Can the process fit while the rest of the application runs? And can the application tolerate a cold start? Keeping a model loaded may avoid repeated loading, but it also means retaining its memory footprint. A team has to decide which trade-off fits its product. The choice between the variants is not simply a race to the larger model. 40M comes with 15 built-in voices; 80M adds cloning from a short reference, used with the speaker’s permission. Alamin did not find a clear naturalness winner on ordinary sentences. If an application only needs a clear notification voice, a preset may already satisfy the requirement. If a particular voice identity is central to the experience, the reference workflow becomes part of what needs to be evaluated. His pronunciation observations are also useful. The ordinary sentences and technical words were clearer in his examples than the formatted price-and-date line. That is a reason to keep difficult inputs in the evaluation set, not to discard the whole result or assume the issue disappears in other messages. Prepare the intended spoken form, retain the original input, and compare the audio again. Correctness has to be checked on the content the product will actually speak. There is one deployment distinction worth making explicit: Colab is cloud-hosted. The test demonstrates CPU inference in that environment, not an on-device privacy guarantee. Self-hosting gives a team a choice about where synthesis runs, but compute, integration and maintenance still have costs. For offline deployment, the surrounding application and its data flows need to be assessed too. Thanks for sharing the trade-offs, @iam_chonchol. For us, the value of an open model includes this ability to examine it under ordinary constraints. A useful adoption decision starts with a specific voice task and a target machine, then checks the audio, startup behaviour and resource use together. That is more informative than choosing by model size alone. github.com/HojoAI/Hojo-TTS-L…