search

VOICEVOX / voicevox_core

無料で使える中品質なテキスト読み上げソフトウェア、VOICEVOXのコア
https://voicevox.hiroshiba.jp/
MIT License
844 stars 114 forks source link

onnxruntime-rsからortに乗り換える #718

Closed qryxip closed 3 months ago

qryxip commented 7 months ago

内容

ONNX Runtimeを扱うためのライブラリを、onnxruntime-rsからortにします。

427 の方は、ちゃんと使えるようになるのに何年待たなくてはならないかわからないのでortの方がよいと思いました。

Pros 良くなる点

Cons 悪くなる点

onnxruntime-rsと比べると無いはず。 microsoft/onnxruntime本家のRustバインディングが動きだしたら別かとは思いますが、今動きだしたとして半年は待つ必要はありそうな感じなので…

実現方法

  1. ortをVOICEVOX下にフォークする
  2. onnxruntime-rsをortに置き換える

VOICEVOXのバージョン

N/A

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

その他

Hiroshiba commented 7 months ago

賛成です！ onnxruntime-rsや、本家onnxruntimeのRustよりも、ortに依存する形が今は良さそうに思いました！

乗り換えコストと恩恵どっちが大きそうか分からなかったのですが、メンテされているライブラリに乗っかるのは基本的に正義だと思うのでそちらが良いのかなと思いました。 例えばonnxruntimeのバージョン上げたりとか。

qryxip commented 7 months ago

リポジトリにはv2ブランチが生えていて、2023-12-28にv2.0.0-alpha.4がリリースされていました。v2の変更点の多さから、v2をベースにフォークするのがよいと感じました。

以下v2を見た感触です。

Hiroshiba commented 7 months ago

お～～～　なるほどです！！ v2はまだ正式リリースじゃないんですね。

依存をortへ変更していくタイミングですが、いつが良さそうでしょうか？ ortがv2になった直後とか、１ヶ月くらい様子見した後とか、今すぐとか。

個人的には、ちょっとコア周りのタスクがいっぱいある現状がちょっと片付くのを待てるから嬉しいな～というのと、一般論としてやはりメジャーアプデしてしばらく経ってからが良いのかな～とか思っています。

あ、VVM asyncのタイミングに合わせる・合わせないの思いは自分的に特に無いです。 マイナーアプデ（実質メジャーアプデ）で依存変更するのも良いと思うし、ortにしてもコアAPIは変わらないと思うのでパッチアプデで依存変更するのも問題ないと思うし、という感じです。

qryxip commented 7 months ago

721, VOICEVOX/voicevox_project#24, ONNX Runtimeのv1.16化の3つを合わせると、コアv0.15に合わせるのがよいのかなと思ってます。

2月にまとめてできればとよいなと思っています。少なくともortへの移行は名無し。さんと白緑さんが前試してましたし、そんなに労力はかからないかなと。

Hiroshiba commented 7 months ago

あ～なるほどです。dlopenとかは特に大きめではありますね！ でもまあVVM+async対応のあとにサクッとまた大きめのバージョンアップとしちゃっても良いかもとか思いました。 焦る必要はないけど、のんびりじゃないといけない理由もない、って感じかなと思いました。

ortが２月もずっとv2-alphaだったらどうすべきか悩みそうですね･･･。 できればalpha版に依存するのは避けたいのですが、いよいよもう他にやることがなかったり、ortじゃないと進めづらいとなったらv2-alphaでも移行しちゃって良いかも。

qryxip commented 7 months ago

個人的にはalphaでも強行していいかなと思っています。メンテされていないものを自力メンテして使うよりはましではないかなと(今回のortの場合フォークして改造する手間もおそらくそんなに無いわけですし)。

あと移行の労力についてもそんなに無いと思ってます。ちょっとさっきまで航空機内と空港の充電スペースでortへの切り替えをやってみたのですが、Linux/CPUでテストを通せるところまで割とさくっといきました。

エラー分岐は所々todo!()ですし、DirectMLとかiOS/Android対応もしてませんが、そういう範囲であればortに改造を加えることなく行けました。

❯ git diff --stat
 Cargo.lock                                             |  66 +++++++++++++---------
 Cargo.toml                                             |   6 +-
 crates/voicevox_core/Cargo.toml                        |   5 +-
 crates/voicevox_core/src/infer/runtimes/onnxruntime.rs | 286 +++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------
 4 files changed, 192 insertions(+), 171 deletions(-)
Hiroshiba commented 7 months ago

なるほどです。僕個人もまあalphaでも良いかなと正直思ってます。 が、まあメンテナ的にはalphaを避けられるなら避けるべきな気がして、これ以外やることないときまで待つのが良いのかなと感じた次第です。

けどまあortを今forkしたほうが楽であればforkします！ もっとあとでも良いならあとでforkします。

qryxip commented 7 months ago

@tuna2134 さんの #693 のために #721 を早めにやっておきたいという動機は発生しそうかなと思いました。 (manylinuxについては、すぐ使わなくなるであろう機構のためにあれこれやる、というのがあまり望ましくはないのではと思っています)

(追記) Discordに書いたのですが、 #693 については問題を一時的に放置してマージという選択肢がありましたね。

neoedmund commented 7 months ago

乗換なら https://github.com/webonnx/wonnx はいかがでしょうか? vulkanによって、対応platformが広く、runtimeもサイズ小さい。

Hiroshiba commented 7 months ago

@neoedmund 現状だと対応している演算が少なくて難しそうです！ でも面白いですね。ちなみに実行速度は速いのでしょうか？

neoedmund commented 7 months ago

対応している演算はVOICEVOXで使ているのと合致するかどうか。実行速度はvulkanでわるくない筈。