バックエンド選択（CPU vs GPU）
HayaKoe は CPU（ONNX Runtime）と GPU（PyTorch）の2つのバックエンドをサポートしています。コードレベルでは device パラメータひとつの違いです。
python
tts_cpu = TTS(device="cpu").load("tsukuyomi").prepare()
tts_gpu = TTS(device="cuda").load("tsukuyomi").prepare()ただし インストールプロファイルから異なります — CPU は pip install hayakoe だけで済みますが、GPU は hayakoe[gpu] + PyTorch CUDA ビルドが追加で必要です。ひとつの環境に両方をインストールして動かすことも可能ですが、実際のデプロイではターゲット環境に合わせて 片方だけ インストールするのが一般的です（詳細は インストール — CPU vs GPU）。
その下の構造もまったく異なります。どちらが自分のデプロイ環境に適しているか判断する基準をまとめます。
CPU（ONNX）が適する場合
- GPU のないサーバー環境 — 一般的な Web ホスティング、VPS、マネージドコンテナプラットフォームのように CUDA サポートがない環境でそのまま動作します。
- イメージサイズを最小化する必要がある場合 — PyTorch + CUDA スタックは数 GB 規模ですが、ONNX Runtime のみを含むイメージは数百 MB 台に縮まります。
- 低い同時リクエストを処理するワークロード — 個人プロジェクトや社内ツールのように同時負荷が大きくない場合、CPU だけでも十分なスループットを確保できます。
- コールドスタートが短い必要があるとき — ONNX 経路はプロセスが起動するとすぐに
prepare()が完了し合成を受け付けられます。GPU 経路もデフォルトでは速いですが、compile=Trueを有効にすると初回のprepare()で約80秒の BERT コンパイル時間を負担する必要があるため、オートスケール・サーバーレス環境で体感差が大きくなります。
CPU 経路の構成
- BERT —
bert_q8.onnx（Q8 量子化 DeBERTa）、ONNX RuntimeCPUExecutionProvider - Synthesizer —
synthesizer.onnx（ONNX で export された VITS デコーダー） - Duration Predictor —
duration_predictor.onnx
GPU（PyTorch）が適する場合
- 低レイテンシが求められるリアルタイムサービス — ユーザー対面のレスポンス、対話型 UI など、単一リクエストの応答時間が体感品質に直結する場合。
- 高い同時スループットが必要な環境 — ひとつの GPU で複数話者を並列合成でき、CPU 比で同時リクエスト許容幅が大きいです。
- 既に GPU インフラが構築された環境 — 追加投資なしに既存リソースを活用でき、同一コストでより良いレイテンシ・スループットが得られます。
- 長時間稼働するサーバーワークロード —
prepare(compile=True)で BERT にtorch.compileを適用すると、約80秒のウォームアップと引き換えに steady-state の合成が1文あたり約20%速くなります。
GPU 経路の構成
- BERT — FP32 DeBERTa が GPU VRAM にロードされ埋め込みを計算します。量子化しないため CPU ONNX 経路より精度がやや高くなります。
prepare(compile=True)指定時にtorch.compileが適用される唯一の構成要素です。 - Synthesizer — PyTorch VITS デコーダー（eager 実行）。
- Duration Predictor — Synthesizer と同じ PyTorch 経路（eager 実行）。
GPU バックエンドのコールドスタートを縮める
GPU バックエンドの初回 prepare() はモデルダウンロードが重なり長くかかる場合があり、compile=True を有効にすると BERT コンパイルの約80秒が加わります。実際のサービスでは以下の2つでこのコストを事前に支払っておくことを推奨します。
- Docker ビルド時に
pre_download()— ビルド段階で重みをイメージ内に焼き込んでおくと、ランタイムのprepare()は HF・S3 アクセスなしにキャッシュから即座にロードします。イメージが起動するとすぐにネットワーク遅延なしに初期化が進行します。(→ Docker イメージ) prepare(warmup=True, compile=True)— prepare 時にダミー推論を先行して BERT コンパイルと cuDNN 初期化まで prepare に前倒しします。prepare 自体はやや長くなりますが 最初の実リクエストが warmup コストを負担しなくなります。(→ FastAPI 統合)
並列比較
| 項目 | CPU (ONNX) | GPU (PyTorch) |
|---|---|---|
| インストール | pip install hayakoe | pip install hayakoe[gpu] |
| イメージサイズ | 数百 MB | 数 GB |
| コールドスタート | 速い（秒） | 速い（秒） — compile=True 時 ~80秒 |
| 単一リクエストレイテンシ | 普通 | 最低 |
| 同時スループット | コア数制限 | GPU 1台で並列 |
| メモリ（話者1名ロード） | ≈ 1.7 GB RAM | ≈ 1.3 GB RAM + 1.8 GB VRAM |
| メモリ（話者あたり増加） | +300~400 MB RAM | +250~300 MB VRAM |
| 必要ハードウェア | 任意の CPU | NVIDIA GPU + CUDA |
具体的な数値はベンチマークで
倍速・メモリ・レイテンシの数値はハードウェアに強く依存します。
- 倍速測定 — 自分のマシンでベンチマーク
- メモリ測定（実測表と再現スクリプト） — FAQ — 話者を複数ロードするとメモリはどれくらい増えますか