自分のマシンでベンチマーク
HayaKoe が 自分のハードウェアでどれくらい速いか 直接測るページです。
リポジトリをクローンしてあればコマンド1行で完了します。
なぜ自分で測るのですか?
TTS 推論速度は CPU 世代・メモリ帯域幅・ONNX Runtime バージョン・バックグラウンド負荷に大きく依存します。
ドキュメントは参考程度にして、直接自分の PC で実行する方がはるかに正確です。
一度測定しておくと、どこにどう使えるか判断するときにも大いに役立ちます。
用語 — 倍速
HayaKoe はパフォーマンス指標として 倍速(speed factor)を使います。
倍速 = 生成されたオーディオの長さ(秒) ÷ 推論にかかった時間(秒)1.0x 以上が出たとき、準リアルタイムと感じられます。
もちろん速ければ速いほど良いです。
例えば10秒の音声を作る場合を考えてみてください。
1.0x— ちょうど10秒待つ必要があります5.0x— 2秒で済みます10.0x— 1秒で済みます
ベンチマーク実行
リポジトリに含まれている dev-tools のベンチマーク CLI を使ってください。
uv run poe cli benchmark実行するとインタラクティブメニューで CPU(ONNX)、GPU(torch.compile)、CPU + GPU のいずれかを選べます。
ウォームアップ2回 + 測定5回で、短い・中程度・長いの3種類の長さのテキストを自動で実行し、結果を表にまとめて表示します。
測定が終わると同じ内容が HTML レポートとして benchmarks/ 以下に保存され、ブラウザですぐに開けます。
リポジトリのクローンが必要です
dev-tools は pip パッケージに含まれていません。
プロジェクト GitHub からクローンした後、dev 依存関係をインストールした状態である必要があります。
結果の読み方
CPU + GPU を同時に実行したとき、ターミナルにおおよそこのような形式で表示されます。
数値はマシンごとに異なります(以下は Ryzen 3950X / RTX 3080 の組み合わせで、他の作業を実行中にあわせて測定した値です)。
倍速 = オーディオ長 ÷ 推論時間(高いほど速い)
例: 10.0x → 1秒分の音声を0.1秒で生成
ベンチマーク結果
┏━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━┓
┃ バックエンド ┃ テキスト ┃ 推論時間 ┃ オーディオ長 ┃ 倍速 ┃
┡━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━┩
│ ONNX (CPU) │ 短い │ 0.393s │ 0.8s │ 2.1x │
│ ONNX (CPU) │ 中程度 │ 1.297s │ 4.1s │ 3.2x │
│ ONNX (CPU) │ 長い │ 3.318s │ 11.0s │ 3.3x │
│ torch.compile (CUDA) │ 短い │ 0.182s │ 0.9s │ 4.7x │
│ torch.compile (CUDA) │ 中程度 │ 0.547s │ 4.9s │ 8.9x │
│ torch.compile (CUDA) │ 長い │ 0.747s │ 12.4s │ 16.6x │
└──────────────────────┴────────┴───────────┴─────────────┴───────┘
ベンチマーク完了!
benchmarks/benchmark_20260414_211131.html
? ブラウザで開きますか? Yes1文が長いほど倍速が出やすい
モデル呼び出しごとに固定オーバーヘッドがあるため、長い文ほどそのオーバーヘッドがよりうまく分散されます。
ただし、HayaKoe は長いテキストを内部的に文単位で分割して処理するため、文が多いからといって無条件に速くなるわけではありません。
ウォームアップは必ず除外
初回呼び出しには ONNX セッション初期化や(GPU なら)torch.compile グラフコンパイル時間が混ざっています。
CLI が WARMUP = 2 で最初の2回を捨てる理由です。
他のプロセスがない状態で
ブラウザ・ビルド・バックグラウンドダウンロードを整理してから測定すると値が安定します。
複数回実行して分散を確認
同じベンチマークを2〜3回実行してみてください。
倍速が数%以内で再現されればその値をより信頼できます。
ばらつきが大きければ他のプログラムがリソースを使っている可能性があります。
ラズベリーパイ 4B ではどうか
HayaKoe は arm64 環境でもそのまま動作します。参考として Raspberry Pi 4B で同じベンチマークを実行した結果は以下の通りです。
- Linux 6.8 · aarch64 · Python 3.10 · ONNX Runtime 1.23.2
| テキスト | 推論時間 | オーディオ長 | 倍速 |
|---|---|---|---|
| 短い | 3.169s | 0.8s | 0.3x |
| 中程度 | 13.042s | 4.1s | 0.3x |
| 長い | 35.119s | 10.8s | 0.3x |
対話型 UI にリアルタイムで使うには厳しいレベル(0.3x、約3倍遅い)ですが、オフラインバッチ合成や個人プロジェクト用にはそのまま使えます。
初回実行のモデルダウンロードは時間がかかる場合があります(〜10分)
ラズベリーパイのように SD カード I/O・ネットワークが遅い環境では、BERT・Synthesizer・スタイルベクトルの重みを HuggingFace からダウンロードするだけで 10分近く かかる場合があります。
一度ダウンロードすれば hayakoe_cache/ にキャッシュされ、次回実行からはすぐに起動します。
ログに表示される ORT / HF の警告は無視して構いません
実行中に以下の2つの警告が混ざって表示される場合があります。どちらも CPU 推論の動作・結果には影響がないのでそのまま進めてください。
Warning: You are sending unauthenticated requests to the HF Hub. ...
[W:onnxruntime:Default, device_discovery.cc:...] GPU device discovery failed: ...- HF 匿名リクエスト警告 — HuggingFace にトークンなしでリクエストしているという通知。ダウンロード速度・レートリミットにのみ影響します。
HF_TOKEN環境変数を設定すると消えます。 - ORT GPU 探索失敗警告 — ONNX Runtime がシステムに GPU があるか探索して失敗したもの。ラズベリーパイのように GPU がない環境では正常な動作で、CPU 推論には何の影響もありません。
倍速が 1.0x 付近の場合
CPU で測定して倍速が 1.0x に近い場合、本番サービスでリアルタイムに使うには厳しいです。
いくつかの選択肢があります。
- GPU に切り替え — 最も確実な解決策です。
- 文単位ストリーミング — 対話型 UI なら全体の合成を待たずに最初の文から流し出す方法があります(文単位ストリーミング)。
