ビルド時にコアのダウンローダーを使う？

[Hiroshiba]

内容

コアは実行に必要なものをいろいろ取ってくるダウンローダーバイナリがあります。
https://github.com/VOICEVOX/voicevox_core/blob/00c43153d42032ad3044ebf9e780d6af5c3f2bf0/docs/downloads/download.md

./downloadでCUDAやDirectMLやonnxruntime.dllやモデルファイルやvoicevox_core.dllなどが手に入ります。

エンジン側のビルドではこのダウンローダーと関係なく、独自にCUDAやonnxruntimeを取得しています。
この方針だと、コア側が想定するCUDAのバージョンとずれたり、コア側とエンジン側で２回実装が必要になっています。

エンジン側もコアのdownloaderを使って統合していきたい気持ちがあります。
まず最初に、問題がなさそうかどうかのチェックが必要かもです。

Pros 良くなる点

コード量が大幅に減る

Cons 悪くなる点

コアのサブ機能と密結合になる
（ダウンローダーがあればコアが実行できるかのe2eテストがまだ無いため少し不安。issueはこちら。）

実現方法

bulid.yml内でコアのダウンローダーをdownloadし、使用する。

その他

問題点などがあるかもしれないので要議論ラベルを付けています。
気になる点があればコメント頂けると･･･！

[Hiroshiba]

ちょっとコアのダウンローダーに依存するべきかしないべきか、調査してみました。
結論から言うと、現状はメリットデメリットが拮抗している感じでした。

仮にコアのダウンローダーを使う場合、エンジンはCUDA11.8を使っているのに対し、ダウンローダーが持ってくるものはCUDA11.6なので、整合性をどうするか気をつける必要がありそうです。

整合性を取るためにはビルド系統（実行バイナリ版とdocker版）を一つにするのが手っ取り早そうですが、この場合実行バイナリ版にはarm64 cpu版ビルドがなく、docker版には存在するのが問題点となりそうです 😇
（arm64版エンジンのビルドはこちらにissueがあります。）

ビルド系統を一つにする以外にも、docker版と実行バイナリ版で分けて、少なくとも実行バイナリ版だけはダウンロードを使うという手も別にありかもしれません。
整合性は取れなくなりますが、まあそんなに問題ではないかなと。（本当に？）

まあでも、コアのダウンローダーに依存するのは一長一短（コードが楽になるｖｓ仕様変更に追従する必要がある）で、かつエンジンビルド的にも一長一短（必要なファイルだけダウンロードするので容量が少なくて済むｖｓ整合性乖離の許容が必要）という感じでした！

[tarepan]

@Hiroshiba

#514 と同様の内容と捉えてよいでしょうか？（とするとこっちが duplicated だけど、#514 側を close するのも手？）

[Hiroshiba]

そうですね、diplicatedになってそうです🙇
情報量的にこちらが多そうなので、 #514 側をcloseさせていただこうと思います🙇

[tarepan]

コア側が想定するCUDAのバージョンとずれたり

現在の VOICEVOX ENGINE は複数バージョンの CORE をサポートする方針です。
ゆえに「コア側が想定するCUDAのバージョン」がそもそも複数存在するケースが発生しそうです。

@Hiroshiba
VOICEVOX ENGINE の CUDA バージョンは何を基準に決定されますか？
「最新 CORE バージョンが想定する CUDA バージョン」「過去 CORE 後方互換性を最大化する CUDA バージョン」など、様々な方針が有り得そうです。

この基準次第で本 issue の方向性が大きく変わると考えます。

[Hiroshiba]

複数のcudaバージョンが存在しうるのは完全に認識の外でした…。

ちゃんとよく知らないのですが、そもそも新しいcudaは後方互換性を持っていて過去のonnxruntimeも動いたり…？
だとしたら最新版のコアに対応するのと、全コアに対応するのはほぼ同義かもです。

onnxrunitimeの要件見ると…別にhigherともlowerとも書いてないかもですかね…。どっちなんだろ…
https://onnxruntime.ai/docs/execution-providers/CUDA-ExecutionProvider.html

もし複数cudaが必要ということになれば、そもそも設計方針を大きく変えないといけない気がしてきました。

[tarepan]

ちゃんとよく知らないのですが、そもそも新しいcudaは後方互換性を持っていて

CUDA toolkit はメジャーバージョン間の後方互換性を保証しないようです。以下公式文章：

12.0 は新しいメジャー リリースのため、互換性はリセットされます。11.x でマイナー バージョンの互換性を使用していたアプリケーションは、12.0 に対してリンクする際に問題が発生する可能性があります。12.0 に対してアプリケーションを再コンパイルするか、11.x 内の必要なライブラリに静的にリンクして、開発の継続性を確保してください。
NVIDIA. (2022). CUDA Toolkit 12.0 の一般提供が開始. NIVIDIA 技術ブログ.

よって ORT の要件にある CUDA バージョンについて、少なくともメジャーバージョンは合わせるべきと考えます。

---

もし複数cudaが必要ということになれば

ORT は定期的に CUDA のメジャーバージョンを乗り換えています。

• ORT v1.0-v1.6: CUDA 10.x
• ORT v1.7-v1.16: CUDA 11.x
• ORT v1.17: CUDA 11.x & CUDA 12.x

最新の v1.17 で CUDA 11.x と 12.x の同時サポート（移行期間？）が始まったので、近いうちに CUDA 11.x はサポート外になりそうです。
CORE が ORT 更新についていくなら、近い将来、複数 CUDA サポートが必要になると考えます。

---

CORE 含めたプロジェクト単位での議論が必要そうです。
少なくとも、この issue の範囲は超えていそうです。

[Hiroshiba]

詳しくありがとうございます！！！！！
方向性決めるのにかなり重要な気づきだったと思います、助かりました。

onnxruntimeとonnxのバージョン対応関係も見てみました。
どうやら新しいonnxruntimeは古いonnxのものを読み込めるみたいでした！
https://onnxruntime.ai/docs/reference/compatibility.html#onnx-opset-support
（All versions of ONNX Runtime support ONNX opsets from ONNX v1.2.1+ (opset version 7 and higher).）
たしか一番古いコアでonnx 1.11とかだったと思います。1.14かも。

なので一番最新のコアに合わせる形でonnxruntimeを用意し、それに合うCUDAとかを用意すれば良い･･･？
となると最新版のコアを使って全部ダウンロードする形で大丈夫かもですかね！！

[github-actions]

本 Issue は直近 180 日間で活動がありません。今後の方針について VOICEVOX チームによる再検討がおこなわれる予定です。