infer: kanalizer-rsをCIなどで連続ビルドすると、Hugging Faceのレートリミットに引っ掛かる

[qryxip]

不具合の内容

クレートとしてのビルドをvoicevox_coreのリポジトリのCIなどで同時に行うと、Hugging Faceからモデルを取ってくるところでレートリミットに引っ掛かる。

現象・ログ

c2k.safetensorsの代わりに、以下の文面を含むHTMLがステータス429 Too Many Requestsで返ってくる。

We had to rate limit you. Upgrade to a paid plan (https://hf.co/pricing) or send us an email at website@huggingface.co

再現手順

voicevox_coreのCIなどで連続ビルドする。

期待動作

少なくとも、voicevox_core程度のCI実行はできる。

[qryxip]

Hub Rate limits · Hugging Face

レートリミットのリセットは5分おきらしい。ただ同一IPのランナーを使っている人達がどれだけHugging Faceをトークン無し利用しているかわからないので、もしかしたらGitHubより厳しいかもしれないといったところ。

[Hiroshiba]

見直してたんですが、kanalizer のビルド時に build.rs が Hugging Face からモデルをダウンロードする設計なんですね。
core はテスト・ビルドする数が多いので、リミットに到達しやすいの気がします。
（kanalizerリポジトリも6個くらい同時にビルドするっぽいし、リトライしまくってたらリミット引っかかりそう？）

対策としては、ビルド処理にオプショナルで Hugging Face のトークンを渡せるようにするとか良さそうかも。
普通に使う分には1回ダウンロードするだけなのでトークンは不要で、CIとかの用途だと必要になる感じ。
この方針なら、各リポジトリごとではなく VOICEVOX org secret に置いて、kanalizer と core の CI から同じ名前で渡すのが運用しやすそうかな。

あるいはmodel fileのパスを指定可能にして、1回ダウンロードしたのを使いまわしてもらうか。
こっちはちょっとめんどくさそう。

@sevenc-nanashi さんの意見も聞きたみ。

[sevenc-nanashi]

なんらかのミラーを用意しちゃうのが手っ取り早いと思います。例えばcf workersでもいいし、R2でもいいし、GitHub Releasesでもいいし。一応checksumとか持たせてあげて失敗した時の最終手段として源流のHuggingFaceにリクエスト（オプションで$KANALIZER_HF_TOKENを指定できるようにする機構もつけていいかも）とか？

[sevenc-nanashi]

...というのが #76 ですね。

[Hiroshiba]

なるほどです。すでにissueがあったの見逃してました。

うーーーん。
タスクが詰まってるので、一旦簡単に実装できそうなhugging face tokenの流れで行くのどうでしょうか。

cloudflare使う周りは、アカウント整備とかルール決めとかドメイン周りとかがすでに整備されてたらすぐできるかもですが、そこから始めるので結構時間かかる気がしています。
token用意するだけなら時間かからないと思うし、変更もそこまでしんどくない（想像ですが）し、かつ @qryxip さん側でPR作ったらもできる（Rust領域なので）なーみたいな。

まあでもcloudflareアカウントはなんだかんだ必要になりそうなので考えていきたいですねぇ。
今回は迂回策があるから優先度を下げれたけど、迂回策がないものも今後出てきそうだし。

うーん、一旦これでどうでしょう…。
@sevenc-nanashi

[sevenc-nanashi]

とりあえず今すぐの対策としてできる環境変数でやるのはよさそう。

[Hiroshiba]

とりあえずトークンを取得して、org全体から見えるようにしました。
名称は一旦HUGGINGFACE_DOWNLOAD_TOKENにしました。
（HF_を避けたのは公開範囲が広くわかりづいかもなため、DOWNLOAD_を入れたのは将来デプロイもやる可能性を考えて区別しておきたかったため）

ついでに環境変数名も調べたんですが、 @sevenc-nanashi さんが提案されてるKANALIZER_HF_TOKENが良さそうに感じました。
公式がHF_TOKENっぽく、長いHUGGING_FACE_HUB_TOKENはdeprecated感ありました。

[qryxip]

良いと思いました。voicevox_core側からの要望としましては、とりあえず次の仕様だけ入れたいと思っています。

1. Hugging Face側から429 Too Many Requestsが返ってきたときの専用エラーメッセージを用意
2. 環境変数が存在していてもそれが空文字列だったら、無い扱いにする
   （フォークリポジトリ上でworkflow_dispatchできるようにしたいので、secretsがnullでも動くようにしたい）

トークンが無ければ警告
[追記] 途中送信してしまった。トークンが無ければ警告もやりたいけど、トークン無しだとレートリミットに必ず引っ掛かるというわけでもないのでダウンローダーのGH_TOKEN共々警告は別に無くてよいかなと思いました。

---

@qryxip さん側でPR作ったらもできる（Rust領域なので）なーみたいな。

私としては名無し。さんでも私でも、どちらでもと思ってます。

---

普通に使う分には1回ダウンロードするだけなのでトークンは不要

ちょっとこれに関して認識を合わせておきたいので、多分重箱の隅ですが一応補足しておきます。

Rustのプロジェクトを普通に継続的に運用していると、依存ライブラリに手を入れたりしたときに頻繁にリビルドが起きます。ダウンロード保存先を慣習通りに$OUT_DIRにしていると、ダウンロードもやりなおしです。
(以前利用していたort/download-binariesフィーチャや今のvoicevox_core/buildtime-download-onnxruntimeフィーチャのように、無理矢理グローバルな場所に保存している場合はその限りではない)

現在kanalizerは慣習通りに$OUT_DIRをダウンロード保存先にしているため、1回単位ではありますが再ダウンロードはそこそこ起きるかと思います。
[追記] あと継続的な開発をしているのなら、当然CIを用意すると考えられます。

…まあそんなことを言ったら、よく考えたらopen_jtalk-rsが既にやばいのでkanalizerに関しては誤差になるかなと今思いました。というのもopen_jtalk-rsは、コケることはないけどリビルドのたびにopen_jtalkリポジトリ（100MB超）のshallow cloneを行います。そしてそれが毎回ビルドキャッシュディレクトリに積み重なる。それに比べたら多分誤差。
(私の手元だと、open_jtalk-rsだけのせいではないにせよあっという間に100GBに迫ったりする)

[Hiroshiba]

hugging faceのレートリミットですが、トークンなしでもIP辺り５分間につき５００回とか３０００回とかいけるっぽいです。
ずっとこのままなのかは不明ですが、現状だとよほどのことがない限り通常環境では大丈夫な気がします。
https://huggingface.co/docs/hub/en/rate-limits#rate-limit-tiers

[qryxip]

伝えかたが悪かったです。GitHub Codespacesといった類の開発環境も一応存在していますし、継続的に利用するとなったら通常CIを用意すると考えたら、

通常環境

は手元の物理PCに限定されないという考えかたもあるのではないか、と思った次第です。

ただ私の意見としては、先述したように100MBのダウンロードがどんどんビルドキャッシュに積み重なるopen_jtalk-rsなどの方が余程問題なので、kanalizerに関してはとりあえずVOICEVOX/voicevox_coreのCIが落ちないような対応をするということでひとまずは大丈夫かなと思います。

[追記] このissueのdescriptionに書いた通り。

期待動作

少なくとも、voicevox_core程度のCI実行はできる。

[sevenc-nanashi]

一応 #133 を作りましたが、どちらにせよCIではsecretsにアクセスできないことがほとんどだと思うので、GitHub Releasesにミラーを作っておきたいです。

そうなると #45 をやりたくなってきますね...（Rust APIにバージョンをつける良い機会なので）