A few weeks back I wrote up self-hosting Kokoro-82M as a CPU-only, no-GPU TTS option. Since then I've been running a second model side by side — Qwen3-TTS — and it's worth a follow-up: they're not interchangeable, and picking the wrong one for your use case costs you either voice quality or latency.
Voice quality: Qwen3-TTS wins, clearly. I ran both directly against each other. It's a 1.7B model versus Kokoro's 82M, and it shows — tone and pacing hold together much better across longer narration. Qwen3-TTS also gives you things Kokoro doesn't: inline emotion markup ([joy], [sad], etc.), instruct-style steering, and multi-speaker presets. If you need expressive, controllable output, Kokoro doesn't compete here.
Kokoro wins on speed and footprint, no contest. Kokoro is faster than realtime on a shared vCPU and needs about 1GB RAM. Qwen3-TTS is CPU-bound — realtime factor around 2, so not real-time — and wants 4-6GB RAM. If your binding constraint is latency or you're squeezed on memory, Kokoro is still the right call. I won't pretend otherwise; measure it yourself and you'll see the same gap in about five minutes.
So: lead with Qwen3-TTS if voice quality and expressiveness matter more than raw speed, and reach for Kokoro when you need real-time output or you're running on a tight memory budget. Both expose an OpenAI-compatible /v1/audio/speech endpoint, so switching between them is a base-URL change, not a rewrite.
I maintain one-click Railway templates for both — full disclosure, I get a kickback if you deploy through either:
- Qwen3-TTS: https://railway.com/deploy/qwen3-tts?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=generic
- Kokoro: https://railway.com/deploy/kokoro-tts-api?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=generic
Both run the stock upstream images — nothing patched for the referral. If you'd rather skip the link, the Qwen3-TTS project itself is on the Qwen team's GitHub and runs fine anywhere Docker does.
