Kokoro TTS running on-device, CPU-only, 20x realtime!!!

Reddit r/LocalLLaMA / 4/4/2026

💬 OpinionDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage

Key Points

  • Kokoro TTSをiOS上でCPU-onlyかつバックグラウンド動作も含めて実用レベルにするための試行錯誤が共有されました。
  • MLX SwiftはMetal依存でバックグラウンドにするとMetalアクセスが遮断されるため、バックグラウンド音声が必要な用途では行き詰まったと説明されています。
  • ONNX RuntimeでCPU実行するとバックグラウンド問題は解決する一方、単体(モノリシック)モデルだと2〜3倍リアルタイム程度で発熱が大きい課題が述べられています。
  • 成功の鍵として、モノリシックモデルをマルチステージのパイプラインに分割し、合成の一部をAppleのAccelerateフレームワークのネイティブ実装に置き換えることで20倍リアルタイムを達成し、サーマル問題も回避できたとしています。
  • 量子化はアプリサイズ削減には有効な一方、実効的にはリアルタイム性が落ちやすいため、必要がなければ非量子化のほうが良いという見解が示されています。
Kokoro TTS running on-device, CPU-only, 20x realtime!!!

I wanted a reading app where you could read, read and listen or just listen to books with word-by-word highlighting synced to TTS and i wanted the voice to actually sound good.

This turned out to be a really hard challenge with Kokoro on iOS, here's what I ran into:

Using MLX Swift is great but uses Metal. iOS kills Metal access the moment you background the app. If your use case needs background audio, this is a dead end.

ONNX Runtime on CPU fixes the background problem, but the monolithic Kokoro model only runs at 2-3x realtime. After 30 minutes of sustained generation my phone was scorching hot.

What actually worked: I split the monolithic model into a multi-stage pipeline and replaced part of the synthesis with native code on Apple's Accelerate framework. That got it to 20x realtime on CPU with no thermal issues.

Also quantization actually tends to make rt slower. So unless your concerned with app size id leave it unquantizied.

Happy to answer questions about any of this if you're working on something similar.

I built an EPUB reader around it called Morph Books if you wanted to test it out. https://apps.apple.com/us/app/morph-books/id6760332618

submitted by /u/aminsweiti
[link] [comments]