Kokoro vs Microsoft TTS: Choosing Local Models or Cloud Speech Services

What is kokoro-onnx?

Kokoro is a speech synthesis model with 82 million parameters and open weights, meaning the trained model files can be downloaded. kokoro-onnx is a separate Python project that runs Kokoro via ONNX Runtime, the software that executes model inference. The Python package, model files, and voice data work together to convert text to audio.

Distinguishing these layers is essential to understand voice quality differences. The Kokoro model and voice data directly affect the sound, as does how text is converted to phonemes. The project recommends Misaki G2P for the 1.0 model; G2P handles text-to-phoneme conversion. The runtime mainly influences model execution and hardware support — using ONNX alone does not guarantee more natural speech.

With the model, voice data, and language dependencies ready, inference runs locally. The application does not need to send each text segment to a remote speech service. The project also supports CPU, so trying it does not require a dedicated GPU.

Licenses must be considered separately: kokoro-onnx uses MIT, while the model weights use Apache 2.0. When bundling them into an application, you must retain the required notices for each license.

The diagram (green boundary) shows Kokoro's speech generation staying on the device, while the blue path crosses the network boundary. This affects offline capability, data flow, and behavior during network failures.

Kokoro generates speech on the device; Microsoft's online solutions require sending text to a remote service. The diagram compares local Kokoro, Edge online service, and Azure managed API. Microsoft also offers dedicated embedded and container solutions, which need separate evaluation — this diagram does not imply all Microsoft TTS cannot run offline.

Which Microsoft TTS do you remember?

Edge TTS: Good for a quick Python script

If you recall a Python package that generates Microsoft voices without an Azure key, it is likely edge-tts. It connects to Microsoft Edge's online text-to-speech service and does not require the Edge browser installed. The package is community-maintained. Installing it does not place Microsoft's voice models on your machine.

It supports voice selection, speech rate, pitch, and volume adjustments, and can output subtitles. However, the documentation explicitly states it does not support arbitrary custom SSML . SSML is the XML markup language for controlling speech output, so Azure SSML examples cannot be directly reused assuming feature parity.

It is convenient for trying voices or creating personal listening material. If used in an automation pipeline, I would keep an alternative ready: accessing via the community client is not the same service-level relationship as using the official Azure API.

Azure AI Speech: For applications needing an official API

Azure Speech provides Microsoft's official SDK and REST API. After creating an Azure subscription and Speech resource, the application can call the service.

From the documented scope, Azure offers a visibly wider range of languages and voices than Kokoro, plus controls for pauses, pronunciation, and speaking styles. However, specific feature support depends on the chosen voice and model series. A name containing "HD" does not mean it supports all SSML features.

For product development, it provides a service interface with official documentation. The application must still handle authentication, request limits, network failures, and billing.

Which sounds better?

Comparing "which sounds better" without fixing language, voice, and text rarely yields a usable conclusion.

A gentle English voice may suit audiobooks but mispronounce technical terms. A Chinese voice may read plain sentences clearly but mishandle English abbreviations. A pleasing ten-second demo does not prove a twenty-minute lesson will be equally comfortable.

Kokoro's own voice documentation notes that quality varies across languages and voices. It also warns that very short utterances may perform poorly, and very long ones may sound rushed. Therefore, whether to merge short sentences and how to split long paragraphs should be part of application testing.

If generating mainly English, I would put af_heart in the first listening round. The project's internal ratings for it are higher, but those ratings estimate training data quality and quantity — not direct listening scores, nor independent benchmarks against Microsoft voices.

If generating mainly Chinese, I would bring Microsoft voices into the first comparison early. Kokoro lists Mandarin voices, but the documentation also states that training data and pronunciation support for some non-English languages are limited. Chinese must be validated separately; English evaluations cannot be reused. This does not mean every Microsoft voice beats every Kokoro voice.

Mixed Chinese-English deserves dedicated testing, for example:

Please check the API's timeout, then run Kubernetes's health check.

Here you must listen not only for naturalness but also for language switching, abbreviation handling, and pausing. Supporting two languages does not guarantee a single sentence mixing both is handled well.

Also, do not treat old leaderboards as today's verdict. Kokoro's evaluation page includes a leaderboard screenshot saved in February 2025, which cannot be used to judge its standing against all current Microsoft voices.

Cost and speed must be compared under the same conditions

Running Kokoro locally avoids per-character fees to a speech provider, but hardware, electricity, deployment, and maintenance still cost money. If the server sits idle most of the time, the amortized cost per audio file may not be low.

Edge TTS usually works without an Azure key, but that does not imply "unlimited capacity" nor that it carries the same service terms as a paid developer API. Personal experiments value quick start; product selection still needs comparison with the official Azure service.

Azure TTS typically bills by processed characters. As of the article's fact-check, the official pricing page lists the F0 free tier quota as: 500,000 characters per month for Neural TTS . Budgeting still requires confirming applicable conditions, voice categories, and quota limits. Paid per-unit prices should be checked against current regional rates, not borrowed from old articles.

Speed has different meanings. A voice assistant cares about time-to-first-audio; audiobook generation cares about total completion time. Cloud solutions include network latency; local solutions depend on machine performance.

For real comparison, at least record "time to first audio chunk" and "time to full generation" separately. Local models must separate first-load time from subsequent requests; online services must include network time. Input text should be equivalent, and the audio delivery stage compared should be consistent.

Before deciding, run a small-scale side-by-side test

I would prepare a short test set from the actual content to be processed:

Regular paragraphs in the primary language.

Dates, prices, decimals, and measurement units.

Person names and technical terms, e.g., PostgreSQL, Kubernetes.

Short commands like "try again".

A longer text and the mixed Chinese-English sentences the application needs.

For each tool, pick two or three voices matching the target accent and use case, and have them read the same text set. Play back at uniform volume using the same headphones, and hide filenames to reduce brand/tool bias.

Log mispronunciations, dropped words, repetitions, unnatural pauses, and listening fatigue over long sessions. Also note how much manual correction each result needs. A voice that sounds slightly better but often requires rework may not suit daily automated generation.

If used for language learning, I would especially value clear pronunciation, proper pausing, and stable output. More expressive does not necessarily mean better for shadowing and listening practice.

My selection order

If offline is a hard requirement, follow the left green "yes" branch in the diagram and evaluate Kokoro first. If online is allowed, then check whether an official API is needed. This branching narrows the three options quickly; final choice still requires listening tests.

First decide if offline is mandatory, then decide if an official API is needed — this narrows the three solutions faster.

Local readers, offline assistants, or batch tasks where text must stay on the device: try Kokoro first. Verify language quality and generation speed on the target machine, then build around it.

Online personal scripts, listening practice: try Edge TTS first. Check the actually available voices and keep the pipeline easy to swap speech sources.

Need Microsoft official API, broader voice selection, or supported speech control features: prioritize Azure Speech. Test with the exact voices and features you plan to ship.

If making English learning audio, I would audition both Kokoro and Microsoft together; if doing Chinese voiceover, I would put Microsoft in the first comparison round; if offline is mandatory, I would start with Kokoro and judge quality against real recordings.