Automate evaluation (llm-jp-eval)

[YumaTsuta]

概要

自動評価スクリプトの自動実行スクリプト作成

• 付随してcovert script自動実行

方針

• crontab コマンド
• Github actions
  • GitHubホストランナー (ssh経由)
  • セルフホストランナー

課題

• クラスタ上でcronjobどこに置くか
  • 特定のユーザ権限に集約して実行
• 対象スクリプトの実行可能性判定
  • llm-jp/automations などのリポジトリでスクリプトを管理

[YumaTsuta]

自動保存されるモデルについて任意のスクリプトを自動実行できるような設計でも良いかもしれない

• モデル削除や転送

[odashi]

パッと考えたんですが、cronを各自が弄るのは怖いので、次の方法でどうでしょうか。

1. 自動実行したいsbatchスクリプトを格納するGitリポジトリを用意する（llm-jp/automationsなど）
2. 自動実行ジョブを追加したい人はpull requestでスクリプトとメタデータ（実行間隔など）を追加する
3. クラスタ側のcronで、特定のユーザ（例えば自分）の権限で定期的に上記リポジトリをcloneし、スクリプトを実行

利点

• 実質cronが必要なのは1件だけなのでクラスタ側での処理が少ない
• 誰でもスクリプトを追加できる
• レビューが入るので比較的安全

欠点？

• 実行するユーザに制約を受ける

[odashi]

Sakuraのクラスタであれば管理者用ノードに上記のcronjobを押し込んでおくことができそうです。

[YumaTsuta]

cronを各自が弄るのは怖い

この辺の発想がなくて思い至ってなかったですが、良さそうですね

（想定内かもしれないですが）クラスタごとに導入するのでフォルダでクラスタごとに区切る感じですかね

[hkiyomaru]

Github で自動実行するジョブを管理するなら，システムの cron を使わず Github actions でやってしまうのもアリかもしれません．

[odashi]

（想定内かもしれないですが）クラスタごとに導入するのでフォルダでクラスタごとに区切る感じですかね

はい、(repository root)/{cluster_name}/{job}.json をメタデータとして置くみたいなのを考えています。

Github Actions

ログインさえできればそれもアリだと思います。ついでにログも残る

[odashi]

SSH鍵の扱いが面倒そうだなと思ったがマケプレにやってくれそうなものが転がっている（こういうのマケプレ信じていいのか…？

[hkiyomaru]

ログインさえできればそれもアリだと思います。

可能だと思います．Settings > Secrets and variables から ssh 鍵を公に晒さずに登録できます．

[odashi]

SSH keyはsecretsに登録（これは大前提）でaction内に持ってくる方法

• 自前でコピーする（できなくはない）
• 適当なマケプレのactionを流用する（楽・怖い）

[hkiyomaru]

マケプレ怖いので，$ echo $SSH_KEY > ~/.ssh/id_ed_25519_llmjp みたいな処理を自前で実行するので良いと思いますけどどうでしょう...．

[odashi]

やる場合はそれでいいと思います。

なんかYAML書くのダルいのと、あちらのcronで回すなら鍵のやりとりも不要なので、あえてGitHub Actions使わなくてもよいのではと思っていました。

[odashi]

ログはちゃんとどこかに蓄積できるように書いておくので代替できますね

[YumaTsuta]

Github Actionsについて詳しくないので調べていたのですが、GitHubホストランナーで実行するためにクラスタへのログインが必要という話でしょうか？
モデル容量などのことを考えると、セルフホストランナーなのかと思っていますが、あまり関係ない？

[hkiyomaru]

Github actions に乗っかっておいて，新しく定期実行ジョブを流したい人が現れたときは「Github actions の使い方を調べてください」で済ませるのが，長期的にはわれわれの時間の節約になる気がします．

[hkiyomaru]

セルフホストランナー

これは action を自前で用意したサーバーで実行できる機能で，これを使う手も考えられます（これを使うと鍵問題が解決するかも...？（しかしそれを上回る面倒臭さがあるかも...？））．上の ssh 鍵うんぬんのところでは， action は Github のサーバーで実行して，action の中で ssh を叩いて sakura 等のサーバーにログインして hogehoge する方法について話していました．

[odashi]

action の中で ssh を叩いて sakura 等のサーバーにログインして hogehoge する方法について話していました．

これが普通に怖いのであまりやりたくないです。分かっている人が書く分にはいいですが、ランダムな人間がGitHub Actionsに何か処理を書き始めるとセキュリティ問題を埋め込み始める可能性があります。

[odashi]

なので、リポジトリとして管理するのはあくまでconfigとサーバの内側から実行する処理だけにして、実行部分の設定は触らせない方向で考えています。

[YumaTsuta]

説明ありがとうございます

まとめると以下のような違いですかね。
cronでやる方が仕様が自由にできますが、現状で求めているものはGithub actionsだけでも十分で仕様についても当面は問題ない(ymalが面倒？)
拡張性を意識するなら、cronで仕様の設計固めつつやっていくのが良いのですかね

• cron
  • 利点：独自仕様で設計できる
  • 欠点：仕様の設計が必要（実行ログや記述方法）
• Github actions (GitHubホストランナー)
  • 利点：導入が簡単
  • 欠点：ssh経由？・仕様が固定されている
• Github actions (セルフホストランナー)
  • 利点：仕様が既に決まっている
  • 欠点：導入が大変かも？仕様が固定

[odashi]

今回はセルフホストランナーの選択肢はないと思います。

[odashi]

擬似コードでアレですが、下記のようなスクリプトを適当なマシンで定期実行するのを考えています。

shell(git clone this repo)
for config_dir in ls(repo/sakura):
  config = json.load(config_dir/config.json)
  if last_execution_time < now - config.duration:
    exec(config.command)

[odashi]

GitHub Actions側でも上記のようなスクリプトを毎回実行することにして、ユーザにはaction部分は触らせない形になると思います。

[YumaTsuta]

@odashi

今回はセルフホストランナーの選択肢はないと思います。

後学のために、理由聞いておいても良いですか？

[YumaTsuta]

下記のようなスクリプトを適当なマシンで定期実行するのを考えています。

GitHub Actionsを利用するメリットは、メタ情報記述する既定のフォーマット（＆機能が用意済）があることだと思っているので、この方法で行くならcronで十分そうですね。

適当なマシンとありますが、ログインノードで実行しつつ、slurmの機能で（configに指定したタイプのノードに）適切に割り振るのかと考えてました。
evaluationをする前にconverterされたモデルのjobが完了している、などの依存関係がありそうですね

追記：
GitHub Actionsでは needsの機能がありますね。

現状の方針であれば、同等の機能を作成するかツールで解決する(makeとか？)など必要そうですね

[odashi]

今回はセルフホストランナーの選択肢はないと思います。
後学のために、理由聞いておいても良いですか？

これは自前のマシンでどうしてもGitHub Actionsを使いたい場合の選択肢なので、わざわざ大変なことをやりに行くのに近いです。

GitHub Actionsでは needsの機能がありますね。

こういった機能も本当に必要になるまではあまり考慮しなくてよいと思います。

[hkiyomaru]

定期実行するスクリプトの方の整備を始めました．

#24