音声合成の並列化は可能ですか？

[neuwell]

質問の内容

音声合成の並列化は可能ですか？音声合成が並列的に処理されてレスポンスが返ることを期待していましたが、実際には1つの合成処理を待つ必要があるかなと思ってます。

例えばエンジンの音声合成リクエストを2件同時に実行すると1つ目の処理の完了よりも、2つ目の処理の完了に時間がかかるように思います。これは1つ目の処理の完了を待機している時間が上乗せされていると予想しています。

エンジンへのhttpリクエストのcurl

curl -s \
    -H "Content-Type: application/json" \
    -X POST \
    -d @query.json \
    "127.0.0.1:50021/synthesis?speaker=1" \
    > audio-l.wav

またcoreの関数 voicevox_tts をコールした場合も同様の結果が得られます。

利用したいユースケース上、アプリにcoreを組み込みユーザからの連続したリクエストを受けて、高速にレスポンスしたく、同時にリクエストを受けた場合にレスポンスが遅延するようになる課題を解決したいと思っています。

VOICEVOXのバージョン

0.14.6

OSの種類/ディストリ/バージョン

• Windows
• macOS ローカルのエンジンの場合
• Linux サーバーにてcoreを動作させる場合

• macOS Monterey
• Linux (ubuntu:22.04)

その他

ご返答よろしくお願いいたします 🙇

[sevenc-nanashi]

並列推論はサポートされていませんね。理由としては、以前に並列推論をしてエラー落ちしたことがあったからです（参照： VOICEVOX/voicevox_engine#427 ）

同時にリクエストを受けた場合にレスポンスが遅延するようになる課題を解決したい

まだ試していませんが、CoreをロードしたプログラムやエンジンをWorkerのように複数立ち上げるのはどうでしょう？

[Hiroshiba]

@sevenc-nanashi さんの仰るとおり、並列実行するとエラーが出たから（engine側で）mutexにしています。

なぜエラーが出るかに関しては実はちゃんと調査できていません。
予測として、VOICEVOXは内部でonnxruntimeを用いて音声合成（推論）しているのですが、そのonnxruntimeのSessionがどうやら並列実行に対応していないときがあるっぽい･･･？という感じです。
なのでワーカーを複数作る以外にも、Sessionを複数持つとかで望みのことができるかもしれません。

ちょうど今APIの刷新を考えていて、その一環にasync化が含まれています。こちらのプロジェクトです。

• project-vvm-async-api #497

ご興味あれば一緒に開発しましょう･･･！！

[neuwell]

@sevenc-nanashi ご教示ありがとうございます！複数workerにしてみるはありかなとも思っていました。

[neuwell]

@Hiroshiba API刷新中なんですね。Issue見て対応できるところはチカラになりたいと思います。Rust学ぶチャンスかと

[qryxip]

@neuwell お久しぶりです。音声合成の並列化についてですが、この間やってみました。

qryxip@5d17802

c.bench_function("decode_sequential", |b| {
    b.to_async(Runtime::new().unwrap()).iter(|| async {
        for _ in 0..4 {
            decode().await;
        }
    })
});

c.bench_function("decode_parallel", |b| {
    b.to_async(Runtime::new().unwrap())
        .iter(|| async { join!(decode(), decode(), decode(), decode()) })
});

動かしかたについて一応書いておくと、Windowsの場合

1. target/release/depsに手動でonnxruntime.dll (1.14), DirectML.dllを放り込んだ上で
2. cargo bench --bench decode-with-gpu --features directml

となります。

(追記) Linux版の場合はCUDA Execution Providerに必要なsoを$LD_LIBRARY_PATHに入れた上で、ORT_USE_CUDA=1で実行します。

結果としては音声合成を並列化しても速度はあまり改善されないか、悪化しました。次の画像は並列の方が微妙に速かったCUDA版のものですが、WindowsのDirectML版の場合逆に1.5倍程度遅くなりました。

CPUモードにしてcpu_num_threadsを1に絞ったりするときっちり4倍の速度差が出るので、上記実装における並列化自体は成されています。CPU/GPU両方において、ONNX Runtimeは計算資源をちゃんと有効活用するようです。並列実行でも逐次実行でもGPUの利用率は100%近かったです。

@Hiroshiba さんのDiscordでの発言を引用すると、

・onnxruntimeは割りと並列化をすでに頑張っているので、その上で並列にすると性能劣化するのは納得感はある
・よりスペックの高いGPUだと結果が異なるかも？（僕のは3070Ti）
・将来decodeがすごく軽くなったときに本領発揮するかも？
と思いました！！

https://discord.com/channels/879570910208733277/893889888208977960/1133099073470210168

で、私も同じ意見です。ただ今のところは逆に遅くなってしまう危険の方が大きいというのもあり、逐次実行のみ提供するという形になりそうです。audio_query (CPU bound)とsynthesis (GPU bound)の同時実行はできるかもしれませんが。

あと将来的には複数のGPUを使えるようにした上で、GPU毎に並列で回すといったことはできるかもしれませんが、需要次第かと思います。

[neuwell]

ご返信ありがとうございます。このことから離れてしまい返信遅くなりました。↑で掲載いただいた通りすでに処理自体がリソースを最適に活用されていたことは理解しました。ありがとうございます