linter & formatterのupdateおよびリポジトリの整理

[e-mon]

最新のllm-jp-eval側にあわせてコードの変更および、formatter & linter設定のupdateを行いました。
また、以下のようなinterfaceでHTTP Serverによる推論の実行が行えることを確認しています。

# inference-modules/vllm内
$ uv run vllm serve llm-jp/llm-jp-3-3.7b-instruct

[e-mon]

linterなどの設定をllm-jp-eval側とあわせました

[e-mon]

interfaceが大きく変わっているのでひとまず削除しました

[namgiH]

承知いたしました。後でも良いのですが、変わったInterfaceに合わせた新しいスクリプトは書いていただけますでしょうか？

[namgiH]

自分が確認できた分では、特に問題はないと思いました。
ただこちらは以前も松田さんに見ていただいたと思いますので、よろしければ松田さんのレビューもいただきたいと思います。
@hiroshi-matsuda-rit

[namgiH]

承知いたしました。後でも良いのですが、変わったInterfaceに合わせた新しいスクリプトは書いていただけますでしょうか？

[hiroshi-matsuda-rit]

このPRの位置づけがわからず、すみませんが現状では私がvllm関連の更新についてapproveすることは難しいです。特に、

また、以下のようなinterfaceでHTTP Serverによる推論の実行が行えることを確認しています。

これはどのような要請からvllmのserverを使用することになったのか、経緯をご説明いただけるでしょうか。
または、ドキュメントを作成してポイントしていただけるでしょうか。 @e-mon @namgiH

[namgiH]

説明が足りず、大変失礼いたしました。
リファクタリングに対する議事録はこちらで：
https://www.notion.so/enotion/1658f844a0ee80198a6ccdfa5dc6ebef?v=7c137669908f408c979a87b0dc44ea25
今回の修正に対する関連Snippetとしてはこれらがございます：
https://www.notion.so/enotion/Design-1568f844a0ee8074aa62c1b671e610ce?pvs=4
https://www.notion.so/enotion/1b88f844a0ee8073ba58e97a1d9dd9b8?pvs=4

ただこの経緯を簡単にまとめますと、以下の通りです。

• llm-jp-evalで評価データの前処理と評価を、推論と分離することにしました
  • このレポジトリーは分離された推論パートとなります
• 分離された二つを一緒に使って評価を一通りで行いたい場合のやり方を議論いたしました
• 議論の結果、その方法として、推論を（OpenAIのAPIに合わせて）HTTPリクエストで行う機能の実装をお願いすることにしました
  • 推論レポの方でサーバーを立ててから、それを用いて評価レポの方で評価を行う流れです

もしご不明なところなどございましたら、遠慮なくお聞きください。
何卒よろしくお願いいたします。

[hiroshi-matsuda-rit]

経緯の共有、ありがとうございます。

議論の結果、その方法として、推論を（OpenAIのAPIに合わせて）HTTPリクエストで行う機能の実装をお願いすることにしました
推論レポの方でサーバーを立ててから、それを用いて評価レポの方で評価を行う流れです

まず確認したいのは、推論サーバの起動 ⇒ 評価の実施 ⇒ 推論サーバの停止 の一連の(非同期な)フローはどのように制御していますか？
また、複数の異なるモデルの評価を並行して実行する際はどういう設定が必要でしょうか？

私がoffline_inferenceを実装したときは、こういう運用面での整合性の確保を最低コストで実現するために、あえてバッチで実装していました。

あと、推論処理のサーバ化を行うなら、単純にすべてvllmのサーバを呼び出す前提にしてしまう方が圧倒的に工数が少なくて済むのではないでしょうか。

[hiroshi-matsuda-rit]

（申し訳ないですが私はvllm/tensortllmともに同期型APIで使用するノウハウしか持ち合わせていないので、もしこれらをサーバとして使用する場合は他の方にレビューを依頼してください）

[namgiH]

ご返信いただきありがとうございました。

まず確認したいのは、推論サーバの起動 ⇒ 評価の実施 ⇒ 推論サーバの停止 の一連の(非同期な)フローはどのように制御していますか？
また、複数の異なるモデルの評価を並行して実行する際はどういう設定が必要でしょうか？
私がoffline_inferenceを実装したときは、こういう運用面での整合性の確保を最低コストで実現するために、あえてバッチで実装していました。

こちらは自分もバッチスクリプトが必要と考えてまして、レビューでその旨の質問をお聞きしています。

あと、推論処理のサーバ化を行うなら、単純にすべてvllmのサーバを呼び出す前提にしてしまう方が圧倒的に工数が少なくて済むのではないでしょうか。

なるほど。確かにそれはおっしゃる通りですね。
ちょうど17時から、llm-jp-eval リファクタリングに対する定期のMTGがありますので、
その場で議論させて頂きたいと思います。

[e-mon]

@hiroshi-matsuda-rit
#4 (comment)
本PRの意図がきちんと書かれていないために混乱を招いてしまって大変申し訳無いです。
本PRは飽くまでlinter & formatterのupdateと、既にインターフェイスが変わってしまったスクリプトを削除したのみです。

また、以下のようなinterfaceでHTTP Serverによる推論の実行が行えることを確認しています。

このコメントについてですが、llm-jp-eval-inferenceの既存の動きをHTTP Serverベースに書き直すといったことを意図しているわけではなく、vllm moduleはそれ単体でhttp serverとしてrequestを処理する機能があるため、これとllm-jp-evalの同期的な評価機能を組みわせることができるようになった、という意味でした。
（これは従来のChatGPTなどへのリクエストと同様に扱えるようになったという程度のものです)

推論サーバの起動 ⇒ 評価の実施 ⇒ 推論サーバの停止 の一連の(非同期な)フローはどのように制御していますか？
また、複数の異なるモデルの評価を並行して実行する際はどういう設定が必要でしょうか？

推論サーバの起動、評価の実施、停止については以下のように一連の処理をスクリプトにするなどができるかなと思っています (懸念している部分と私の回答が少しずれているかもしれません、もしそうであればご指摘ください)

uv run vllm serve llm-jp/llm-jp-3-3.7b-instruct &
PID=$!
uv run python scripts
kill $PID

本日のミーティングにおいて、あらかじめpromptを出力しておき、複数モデルで推論のみを繰り返し行うニーズがもとよりあるためにoffline推論機能があるとのはなしをお聞きしたのですが、そのような場合は従来どおりファイルベースでのoffline inferenceを実行するのがよいと思っています。
vllm serve での実行は、飽くまで単一のモデルをちょっと評価したい、といったような素朴な用途の場合の簡易な実行方法として機能することを意図しています。

[hiroshi-matsuda-rit]

@e-mon 返信おまたせしてすみません。詳細な説明ありがとうございました。

また、以下のようなinterfaceでHTTP Serverによる推論の実行が行えることを確認しています。
このコメントについてですが、llm-jp-eval-inferenceの既存の動きをHTTP Serverベースに書き直すといったことを意図しているわけではなく、vllm moduleはそれ単体でhttp serverとしてrequestを処理する機能があるため、これとllm-jp-evalの同期的な評価機能を組みわせることができるようになった、という意味でした。
（これは従来のChatGPTなどへのリクエストと同様に扱えるようになったという程度のものです)

こちらのcommitを読まないと意図は理解できないですね。
e-mon/llm-jp-eval@4f25cb7#diff-2044283683a51c49db2b8b2cf715b4a2de7195e3a50e1a6a2597510cb7aca8c4

langchainでopenaiとvllmを透過的に扱えるようにしていると書いていただければ、そのまま理解できました。
ただSlackにあったこちらの見解には、私は同意できません。

個人的にはllm-jp-evalの推論は、このシンプルなHTTP Serverでのやりとりをベースにしてもよさそうに思っていますが、

[hiroshi-matsuda-rit]

本PRは飽くまでlinter & formatterのupdateと、既にインターフェイスが変わってしまったスクリプトを削除したのみです。

削除するだけでは実装は完結しておらず、新たに何を実装/実行することになるのか説明は最低限必要だと思いますね。
README.mdの記述も変わっておらず、このPRを通すと過去に実現していた機能が何だったのか（少なくとも一時的には）不明になってしまいます。 @e-mon

あと、削除したスクリプトの新しい実装は誰が行う想定ですか？

[hiroshi-matsuda-rit]

推論サーバの起動、評価の実施、停止については以下のように一連の処理をスクリプトにするなどができるかなと思っています

まあそうなりますが、これだとサーバが起動してAPIを実行できるようになるタイミングを管理できないので、同期型APIと比べて何がメリットになるのかわかりません。
また、chat.completion APIはpromptごとの呼び出しなので、スループットを稼ぐうえで重要なバッチ化はサーバ側でリクエストをpoolingして実現することになり、そうした設定の最適化を新たにvllm側で行うことになりますね。

モデルを永続的にvllm serveしてモデル読み込みのオーバーヘッドを減らすことを目的とするなら、vllm serveは別途手動で実行しておき、ログを見てモデルの読み込みが完了したことを確認してからllm-jp-evalを実行する、といった案内を行うことになると思います。

[hiroshi-matsuda-rit]

全体に、リファクタリングと機能追加が同時進行していることに起因するコミュニケーションのややこしさを強く感じています。
先にリファクタリングを終えてから、機能追加を行うべきでしょうか。

[e-mon]

@hiroshi-matsuda-rit
前提を一旦整理させてもらった上で論点を明らかにさせて下さい。
前提として、"本PRはlinter & formatterのupdate + インターフェイスが変更になったため使用出来ないスクリプトの削除" です。
そのため、vllmによる推論をどのように最適化するか、というトピックについて扱うのは正しくないように思います (また、この点について私は手を加えていません)
また、HTTP Serverによる推論機能はllm-jp-eval-inferenceに影響を与えず、同様にllm-jp-evalにも仕様変更を与えないということについても認識を揃えておきたいです。
私が行った作業は既存のLangChainのコードを、OpenAIのみに閉じるのではなく少し汎用的に書き直したのみで、新しい概念を機能として追加したわけではありません。

付け加えるならば、今回のllm-jp-evalのリファクタリングの目的には、評価と推論の分離が含まれています。今回汎用的に書き直したことにより、llm-jp-eval側では、OpenAIのAPIフォーマットを満たしていればバックエンドの推論サーバの実装に注意を払う必要がなく、独立に評価を行えるようになった、という点でユーザーにとっては扱いやすいインターフェイスになったのではと思います。
この部分で、既存のオフライン推論に比べてパフォーマンスに関して懸念がある (スループットが稼げないのでは)、というのはおっしゃるとおりかと思いますが、llm-jp-eval側で推論のパフォーマンスを保障するということはメンテナンスコストを非常に引き上げることになってしまうのではと考えています。既存の実装も残してありますし、クライアント側の最適化についてはllm-jp-eval側の責務ではない、とするのが当初分離すると決めた際の意思決定に含まれていると考えております。
この点については @namgiH さんからもコメントいただきたいです。

本PRで扱うべき残論点として、HanさんやMatsudaさんがおっしゃるとおり、推論用のスクリプトをどうするのか、またそれに伴ってREADMEの改修をいつだれがするのかというのがあると思いますが、本件については私が実施する予定です。

[hiroshi-matsuda-rit]

@e-mon 論点整理ありがとうございます🙌
いったん作業を進めていただくために、削除したスクリプトを復活してください。
そちらご対応いただけたら、このPRはapproveしようと思います。