 | 読み上げアプリを作りたくて、単語ごとのハイライトがTTSに同期して本を「読む」か「読む＋聞く」か、あるいは「聞くだけ」でも使えるようにし、さらに声がちゃんと良く聞こえるようにしたかったんです。 ところがiOSでKokoroを使うとなると、これは本当に難しい課題になりました。そこで私がぶつかったことはこちら： MLX Swiftは素晴らしいのですがMetalを使います。iOSは、アプリをバックグラウンドに回した瞬間にMetalへのアクセスを無効化します。バックグラウンド再生が必要な用途なら、ここは行き止まりです。 CPU上で動くONNX Runtimeならバックグラウンドの問題は解決しますが、単一（モノリシック）のKokoroモデルは2〜3倍のリアルタイム程度でしか動きません。生成を30分間ずっと続けると、私の電話はかなり熱くなっていました。 実際にうまくいった方法：モノリシックなモデルをマルチステージのパイプラインに分割し、合成の一部をAppleのAccelerateフレームワーク上のネイティブコードに置き換えました。これで、熱の問題なしにCPUで20倍のリアルタイムが出ました。 また、量子化は実際のところrtを遅くする傾向があります。アプリのサイズが気になるのでなければ、量子化しない方がいいです。 もし似たようなものを作っているなら、これらについて質問があれば何でも答えます。 それを試してみたい場合に備えて、私がそれを使ったEPUBリーダーを「Morph Books」という名前で作りました。https://apps.apple.com/us/app/morph-books/id6760332618 [link] [comments] |
Kokoro TTSをオンデバイスでCPUのみ動作、20倍リアルタイム!!!
Reddit r/LocalLLaMA / 2026/4/4
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage
要点
- iOS上でKokoro TTSをCPU-onlyかつバックグラウンド動作も含めて実用レベルにするための試行錯誤が共有されました。
- MLX SwiftはMetal依存で、バックグラウンドにするとMetalアクセスが遮断されるため、バックグラウンド音声が必要な用途では行き詰まったと説明されています。
- ONNX RuntimeでCPU実行するとバックグラウンド問題は解決する一方、単体（モノリシック）モデルだと2〜3倍リアルタイム程度で発熱が大きい課題が述べられています。
- 成功の鍵として、モノリシックモデルをマルチステージのパイプラインに分割し、合成の一部をAppleのAccelerateフレームワークのネイティブ実装に置き換えることで20倍リアルタイムを達成し、サーマル問題も回避できたとしています。
- 量子化はアプリサイズ削減には有効な一方、実効的にはリアルタイム性が落ちやすいため、必要がなければ非量子化のほうが良いという見解が示されています。
