-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support onnx #21
Support onnx #21
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
良いですね!!!!!!!
僕も勉強しなきゃなと思ったので、いい感じの参考資料とかあったらぜひ教えていただきたいです!!
正直たいしたチュートリアルはなかったです...
これをもとに勘で書きました |
ありがとうございます!! |
GPUがテストできない件に関しては、googleから提供されている、なぜか無料でgpuが使えるcolaboratoryを使うとテストできるかもしれません。 |
CUDAリンクがどうなってるか気になりましたが、どうやらonnxruntime-gpuに同梱されているonnxruntime_providers_cuda.dllを動的にロードするようです |
なるほど〜 でも全部のDLL含めてもlibtorchよりは圧倒的に軽いので嬉しいですね…! |
Windows, linux (WSL, GoogleColab)で動作確認済み https://gist.github.com/Yosshi999/f5c64cb5f0afe7f1c053af0204b1feb1 |
週末のまとまった時間が取れたタイミングで見てみたいと思います!! |
こちらでも動きました!!! WIndowsのGPU環境でも動きましたが、気になる点が2つありました。 CPU版よりGPU版のほうが実行時間が長かったです。 あと、yukarin_saの実行結果(f0_list)がCPUとGPUで異なっていました。 ↓CPU版 phoneme_length f0_list ↓GPU版 phoneme_length f0_list 速度がGPUのほうが遅そうな理由と、yukarin_saの結果がGPUとCPUで異なる点の心当たりがあれば伺いたいです。 ちなみにですが、libtorch版の場合はCPUで2.1秒、GPUで1.5秒でした。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
コードも読んでみました! C++が全然わからず質問ばかりですが、よろしくおねがいします。
調べてみます。
なるほど...ただのfloat誤差ではなさそうですね...
onnx変換時にいくらか最適化を走らせているようです。詳しいことは分かりませんが、例えばbatchnorm -> convolutionを一つのconvolutionに変換するといったことなどをやっているようです。 |
c353702
to
bf63a04
Compare
yukarin_sとyukarin_saはCPUでも十分早いのでGPUモードでもCPU上で走らせるようにしました。 これに加えて、GPU版では初期化時にlength=500のダミーデータでdecodeを実行し、メモリ確保を行わせています またfinalize関数をcore.hに追加しました。僕の用意したGPU環境では以下のコマンドを実行したときにexit時例外が発生したためです。どうやらdestructorをシステムに任せると例外がおこってしまうようです |
おそらく通信がかなりのコストになっているのですが、decode.onnxをcudaに載せたときのログを置いておきます。 verbose log
https://netron.app/ にdecode.onnxを放り込んで↑のログとにらめっこすると何かわかるかもしれません。ただonnxruntimeをいじってノードに置き場所を強制するのは多分不可能で、onnx変換時にモデルを分割して頑張ることになりそうです |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
コメント追加などありがとうございます、とても読みやすいです!
1つだけ追加でコメントしました。そちらが完了し次第、一旦マージできればと思っています。
GPUの方が遅いことに関して実測してみたところ、テキスト長を増やしていくと逆転することがわかりました!
テキストは1番目は「テスト、0」、二番目は「テスト、0、1」というように増やしています。
どうやらCPU・GPUどちらを使ったほうが速いかは、文字数(というよりはyukarin_sの出力による音素の全長)に依存しそうです。
おそらく通信がかなりのコストになっている
同意です! メモリ転送・命令通信どっちも変なコストが掛かってそうな印象です。
CPU→GPUのメモリ転送やその逆はもっと早くする方法があるかもです。(pytorchにおけるpinned memory)
命令通信はCUDAレベルの最適化が必要な気がしています。文字数が少ないときはたぶんもっと速くなれるはずです。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM・・・!!!!!!!!!!!
頂いたプルリクエストは、VOICEVOXの大きな課題を2つ解決しています。
1つ目は容量が非常に大きい問題です。
チェックや暗号化などが必要な関係ですぐに製品版VOICEVOXに反映できませんが、おそらく次の次のマイナーアップデートの際に容量が激減するはずです。
2つ目は、コアの部分のOSS化が全くできていなかったC++実装の一歩目を作っていただけたことです。
入出力さえあっていれば別のモデルでもちゃんと動き、かつ(非常に険しい道程ですが)自分のVOICEVOXを作ることができるようになるはずなので、かなり大きな一歩だと思います。
リリースの際は少し大きめに広告し、 @Yosshi999 さんの貢献であることも紹介したいと思います。(もしよろしければツイッターIDを教えてください・・・!)
一方で、頂いたこの実装に機能を追加するには、onnx化されたモデルが必要になります。
今だとvv_core_inferenceにあるモデルをコンバートする必要があって、チェック実行にかなり手間がかかってしまいます。
もしよろしければ、vv_core_inferenceにあるモデルをこのリポジトリに追加するプルリクエストや、ドキュメントの追加もお願いしたいです。
本当にありがとうございました!!!
一部(decode.onnx)が50MB近くあるのですが、そのまま突っ込んでしまっても良いものでしょうか。一応gdrive linkもあるのですが僕の一存で共有が止まるようなところに置いておくのもアレな気がします。
👍 |
ツイッターIDありがとうございます!
LFSにしてもよいのですが、50MBだと月20回pullされるだけで帯域がなくなるんですよね・・・
ですね! |
Hiroshiba/vv_core_inference#1 に対応したonnxruntime実行サンプル
Google Colabで動かしたもの:https://gist.github.com/Yosshi999/f5c64cb5f0afe7f1c053af0204b1feb1
テキスト
"親譲りの無鉄砲で小供の時から損ばかりしている。小学校に居る時分学校の二階から飛び降りて一週間ほど腰を抜かした事がある。"
に対して、CPU版は14.8秒、GPU版は6.24秒だった。(GPU版の初回起動は34.5秒と時間がかかった。原因は不明です。)