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

[qryxip]

内容

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

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

Pros 良くなる点

• ちゃんとメンテされるライブラリに乗っかることができる
  • dlopen/LoadLibrary, 静的リンク
  • DirectMLを含むEP対応
  • WASM対応
  • etc.

Cons 悪くなる点

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

実現方法

1. ortをVOICEVOX下にフォークする
   • 今までVOICEVOX/onnxruntime-rsに加えた変更のうち、必要なものを入れる (ortは結構先を進んでいるので、多分そんなに必要無いはず)
   • ortのAdd an option to use the input model bytes (ORT format only) directly without copy at session creation microsoft/onnxruntime#8502対応を、onnxruntime-rs本来の「コピー」する挙動に戻す
     • Discordで以前話した件です
2. onnxruntime-rsをortに置き換える

VOICEVOXのバージョン

N/A

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

• Windows
• macOS
• Linux

その他

[Hiroshiba]

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

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

[qryxip]

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

以下v2を見た感触です。

• https://pyke.ioというところにビルド済みのONNX Runtimeが置いてあり、そこからダウンロードするようです（ortのドキュメントもここ）。
  https://github.com/pykeio/ort/blob/v2.0.0-alpha.4/ort-sys/build.rs#L251-L300
  • tar.gzのファイル名にある_staticは、文字通り静的ライブラリを意味します。execution provider用のDLL（e.g. libonnxruntime_providers_cuda.so）が必要無い場合に限り静的リンクをする、という方針であるようです（ドキュメント）。
  • iOSやAndroidが抜けているため、どの道足す必要があります。
• Sessionの構築はSession::with_model_from_memory_directlyとSession::with_model_from_memoryに分かれたため、後者をそのまま使えばよさそうです。
• 必須なのはおそらく次の3つのみかと思います。
  1. iOSやAndroidなどの追加も兼ね、ONNX Runtimeのダウンロード先をVOICEVOX/onnxruntime-builderのものにする
  2. ロギングの削減
  3. 足りないAPIがもしあれば、それの追加
• pyke.ioとしてDiscordサーバーが立っています。入ってみましたが、そこそこ人がいました。

[Hiroshiba]

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

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

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

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

[qryxip]

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

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

[Hiroshiba]

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

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

[qryxip]

個人的には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]

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

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

[qryxip]

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

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

[neoedmund]

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

[Hiroshiba]

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

[neoedmund]

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