Skip to content
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

GPUリソース管理の実現案 #1

Open
lunastera opened this issue Feb 22, 2020 · 1 comment
Open

GPUリソース管理の実現案 #1

lunastera opened this issue Feb 22, 2020 · 1 comment

Comments

@lunastera
Copy link
Collaborator

lunastera commented Feb 22, 2020

前提として

  • マイクロサービス側からはどのPCに所属しているかわからない
    • また互いに干渉することもない(互いが同一PCに存在することを認識できない)
  • langrid側からも各マイクロサービスどのPCに所属しているかは不明(サービスのURLだけは知っている)
    • よってlangrid側からのジョブキューの実装はできない
  • マイクロサービス側がGPUを意識せずにGPUを使用することは恐らく不可能
    • 既にサーバが建っている以上、GPUを指定してスクリプトを実行することも不可能なため、なんらかGPUを使うことを宣言するinterfaceを定義するのが無難

この上で実現する方法として

k8sを利用したGPU Scheduling

  • 大企業はだいたいこれだが、少人数プロジェクトでまともに運用するのは厳しい
    • 仮に自分が長時間かけて構築したとして、その後引き継ぐ側はそれ以上の学習コストがかかる
  • またこの機能は experimental であり、今後継続して動向を追う必要がある

GPU Managerのようなものを実装する

  • langrid -> GPU Manager -> microservices
  • 同一PC上のGPUを管理するプログラム
  • 実行可能なGPUを常に管理しており、利用状態になったときはロックしてジョブキューに積む
  • 利用可能なGPU情報をマイクロサービスに伝える
  • 明確にマイクロサービス側に使うメモリ量を制限させることは(調べている感じ)できなさそう
    • そもそも同一GPU上に複数のマイクロサービスが乗っかると、複数モデルのうち一つだけをGPU上から外すということがAPI上できない(はず)
@takawitter
Copy link
Member

GPU Managerを実装するという方向性は妥当だと思います。

langrid -> GPU Manager -> microservices
こういう構成ってことは、サービスのリクエストをまずGPU Managerが受け取って(あるいはmicroservicesが常に処理開始前にGPU Managerを呼び出すようにして)、GPUが利用可能になるまで待機するってことですよね?
で、microservices側は処理が終わったら速やかにGPUを開放する実装にする。
その方向でOKです。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants