検証日: 2026-05-11 JST
実行環境: CUDA GPU 環境
duration-control モデルは、今回の実利用検証では NG と判断しました。
理由は、速度は大きく改善する一方で、seconds の指定がかなりシビアで、セリフ追従力が落ちるケースがあったためです。早口・ねっとりした読み方は許容できますが、音質劣化やセリフの欠落・言い換わりは問題になります。
そのため、検証対象の推奨構成は duration-control モデルではなく、通常の VoiceDesign モデルです。ただし、#10/#11 の推論コードは統合したままなので、Sway / WaveEx の検証は続けられます。
- Model:
Aratako/Irodori-TTS-500M-v2-VoiceDesign - Clone model:
Aratako/Irodori-TTS-500M-v2 - Code: #10 Sway / #11 WaveEx 統合版
- Precision: model
bf16, codecfp32
通常モデル構成での smoke test:
model: Aratako/Irodori-TTS-500M-v2-VoiceDesign
mode: Sway
seconds: 8
num_steps: 6
x-tts-duration: 4.72
x-tts-elapsed: 0.72
x-tts-rtf: 6.58
output: PCM 16-bit mono 48kHz WAV
| PR | 内容 | 現在の扱い |
|---|---|---|
| #10 | Sway Sampling の導入 | 通常モデルでも有効。安全寄りの高速化候補 |
| #11 | WaveEx の導入 | 通常モデルでも動作するが、duration-control 前提のコメントがあり注意 |
| #1/#2/#3/#7 | 周辺機能・環境対応 | 統合済み。今回のTTS品質判断の主対象ではない |
| 条件 | モデル | パラメータ | 平均 wall | 平均 elapsed | 備考 |
|---|---|---|---|---|---|
| baseline | Aratako/Irodori-TTS-500M-v2-VoiceDesign |
20 step / 既存経路 | 2.023s | 1.815s | 既存サービスの比較元 |
| 通常モデル + Sway | Aratako/Irodori-TTS-500M-v2-VoiceDesign |
Sway 6 | 1.692s | 1.526s | 約 1.20x 高速 |
通常モデルでも Sway による速度恩恵はあります。ただし duration-control モデルほど大きくはありません。
| 条件 | モデル | パラメータ | 平均 wall | 平均 elapsed | 出力長 | baseline比 |
|---|---|---|---|---|---|---|
| duration + linear | duration-control | 20 step / seconds=10 | 0.952s | 0.786s | 10s | 2.13x |
| duration + #10 | duration-control | Sway 6 / seconds=10 | 0.528s | 0.400s | 10s | 3.83x |
| duration + #11 | duration-control | WaveEx 20 / seconds=10 | 0.531s | 0.384s | 10s | 3.81x |
| duration + #10+#11 | duration-control | Sway 6 + WaveEx / seconds=10 | 0.509s | 0.368s | 10s | 3.97x |
| duration + #10 | duration-control | Sway 6 / seconds=8 | 0.461s | 0.348s | 8s | 4.39x |
| duration + #11 | duration-control | WaveEx 20 / seconds=8 | 0.472s | 0.332s | 8s | 4.29x |
速度だけを見ると duration-control は非常に速いです。しかし、この数値だけでは採用判断できません。
qwen repo 既存の stt_server.py / faster-whisper を使い、TTSで生成した wav を 8002/v1/stt に投げて、原文とWhisper転写の差分を見ました。
評価観点:
- 早口・ねっとり: 許容
- 音質劣化: NG
- セリフ欠落: NG
- 原文にない語の混入: NG
- セリフ追従力の低下: NG
代表結果:
| 文 | 条件 | Whisper追従 | 傾向 |
|---|---|---|---|
| 短文 | seconds=4/6, Sway |
1.00 | 良い |
| 短文 | omit/30s, Sway |
0.33 | 「おはよう」だけになり欠落 |
| 短文 | 12s, Sway |
0.00 | 無音/認識不能寄り |
| 中文 | 8s/10s, Sway |
0.91 | 良い |
| 中文 | 6s, Sway |
0.66 | 末尾欠落 |
| 中文 | 12s, Sway |
0.84 | 重複が出る |
| 中文 | 16s/30s, Sway |
0.68 / 0.11 | 長すぎて崩れる |
| 長文 | 12s/16s, Sway |
0.94 / 0.96 | 良い |
| 長文 | 8s/10s, Sway |
0.59 / 0.72 | 後半欠落 |
| 長文 | omit/30s, Sway |
0.93 | 長文では比較的安定 |
WaveEx も傾向は近く、中文では 8s/10s、長文では 16s が良好でした。ただし、Sway + WaveEx は速い一方で、セリフ追従力はやや不安定でした。
duration-control モデルは、seconds を明示して短い latent だけを生成することで速くなります。しかし、最適な seconds は文の長さや内容に依存します。
問題点:
secondsが短すぎると、後半のセリフが欠落するsecondsが長すぎると、安定するのではなく崩れる場合があるseconds未指定は本当の auto duration 推定ではなく、実質デフォルト値に落ちるだけ- 従来の「自動でそれなりに読める」性質が弱くなり、手動調整が必要になる
そのため、現時点ではユーザーが普通に触る環境には向いていません。
PR #11 は duration-control モデルをコード上で強制してはいません。通常モデルでも動きます。
ただし、PR本文には以下の趣旨が書かれています。
- Durationモデルでないと無音区間の latent が変わる
- その結果、無音区間が残る
また、WaveEx のコードコメントにも duration-control checkpoint で調整したデフォルトであることが示されています。
つまり、#11 の品質主張は duration-control 前提に近いです。PRとして取り込むなら、duration指定のシビアさと、通常モデルでの期待値をREADMEやPR本文に明記した方が安全です。
現時点の 実利用評価 では以下が良さそうです。
- 通常モデルを使う
- Sway を主な高速化手段にする
- WaveEx は品質比較用に残す
- duration-control はデフォルトにしない
- duration-control を再検討するなら、以下のどちらかが必要
- テキストから自動で適切な
secondsを推定する仕組み - 複数
secondsで生成し、Whisperでセリフ追従力を見て自動選別する仕組み