 | 私はリアルタイムの音声翻訳者（STT → LLM翻訳 → TTS）を作っていて、見つけられる限りのTTSエンジンをすべて（クラウドとローカルの両方）ベンチマークするのに数週間を費やしました。MacBook Air M4、24GB RAMで動かしています。 いくつかの結果は……予想とは違っていました。始めた当初、このデータがどこにも見つからなかったので、見つけたものをすべて共有します。 セットアップパイプライン：Deepgram Nova-3（STT、約300ms）→ Groq Llama 3.3 70B（翻訳、約200ms）→ TTS → スピーカー TTSコンポーネントがボトルネックです。STTとLLMを合わせても約500ms。TTSがさらに1秒足されると、会話がトランシーバーみたいに感じます。 ローカルTTSベンチマーク（Apple M4、ウォーム、同じフレーズ）
Piperは最速ですが、2015年のロボットみたいな音です（そしてこのプロジェクトは2025年10月にアーカイブされました）。Kokoro 82Mはちょうどよいところで、短いチャンクで370ms、A+の品質です。 200Mパラメータ以上のものは、Macでのリアルタイム用途では基本的に使い物になりません。 量子化の意外な結果（これには痛かった）M4でKokoroを速くしようとしてみました：
INT8は、Apple Siliconではfp16よりほぼ2倍遅いです。ARMチップはfp16の演算が最適化されています。量子化はRAMを節約しますが、型変換のオーバーヘッドが追加されます。ドキュメントのどこにもこれに言及がなかったので、この件で丸1日溶かしました。 CoreMLもダメでした。CoreML EPがサポートするのは、2493個のモデルノードのうち37だけです。 MLXも短いテキストでは速くなりません。逆説的に、短いフレーズではPyTorchのCPUのほうがMLXより速かったです（6文字で98ms vs 364ms）。これはMLXのグラフコンパイルによるオーバーヘッドのためです。 クラウドTTS：プロバイダよりプロトコルが重要これが最大の衝撃でした。同じプロバイダ、同じモデル、同じテキスト：
CartesiaのWebSocketとsyncは5.5倍の差。 TTSプロバイダをsync SDKでベンチマークしているなら、測っているのは違うものです。 コストの問題
ElevenLabsは、同等の品質の代替手段と比べて4〜20倍高価です。月1,000時間なら、$5,310の差になります。 最終的に採用したものDeepgram Nova-3 → Groq Llama 3.3 70B → StreamChunker（2〜3語のチャンクに分割）→ Kokoro 82M 最初のオーディオまでの総遅延：約870ms。Google Meet S2STは約2000ms。Palabra.aiは$25+/月で約800msです。 近々オープンソースにします。翻訳者はElixir + Rust + Flaskで動きます。 TL;DR
30+のプロバイダ、ELOランキング、そしてフレーズごとの詳細なベンチマークを含む長文の記事を書きました。全データが必要ならこちら：https://ai.gopubby.com/i-benchmarked-30-voice-ai-engines-and-built-a-real-time-translator-faster-than-google-meet-e6a160def969 特定のプロバイダやセットアップについての質問なら、何でもお答えできます。 [link] [comments] |
Apple M4でリアルタイム翻訳用に30+のTTSエンジンをベンチマークした。量子化は逆にSLOWになった。すべてのデータはこちら。
Reddit r/LocalLLaMA / 2026/4/15
💬 オピニオンIdeas & Deep AnalysisTools & Practical Usage
要点
- 著者はリアルタイム音声翻訳のパイプライン（Deepgram Nova-3 STT → Groq Llama 3.3 70B 翻訳 → TTS）を構築し、会話の体感における主要な遅延ボトルネックがTTS段階であることを見いだした。
- Apple M4 のMacBook Airでのベンチマークでは、Piper ryan-med が最速だが品質が低く、一方で Kokoro 82M（fp16）は最も良いリアルタイムのトレードオフを提供し、短いチャンクで約370ms、品質もA+だった。
- テスト結果は、当該Macハードウェア上では、約200Mパラメータを超えるTTSモデルがリアルタイム運用に事実上使えないことを示している。
- 重要な発見として、M4上でKokoroを量子化するとパフォーマンスが悪化した（INT8: 約687ms vs fp16: 約373ms）。推論が速くなるはずだという期待に反する結果となった。
- 一部のプラットフォーム固有の最適化（例：CoreML Neural Engine）は、テストしたモデルのアーキテクチャではサポートされていなかった。また、単一スレッドの使用はレイテンシを大幅に増加させた（約1723ms）。
