GPU リソースを必要とするジョブの実行依頼

GPUリソース要件を設定した後、ジョブ提出時に` bsub -gpu command`オプションを使用してGPUリソース要件を指定するか、GPUリソース要件が設定済みのキューまたはアプリケーションプロファイルにジョブを提出してください。 複雑なGPUリソース要件（代替または複合リソース要件を含む）には、`` bsub -R コマンドオプションを使用してください。

手順

  • GPUリソース要件を伴うジョブを送信するには、オプション bsub -gpu を使用してください：

    bsub -gpu - | " [num= num_gpus [/task | host ] ] [:mode=shared | exclusive_process ] [:mps=yes [,shared ] [,nocvd ] | no | per_socket [,shared ] [,nocvd ] | per_gpu [,shared ] [,nocvd ] ] [:j_exclusive=yes | no ] [:aff=yes | no ] [:block=yes | no ] [:gpack=yes | no ] [:glink=yes ] [:gvendor=amd | nvidia ] [:gmodel=モデル名 [-メモリサイズ ]] [:gtile=タイル番号 |'!' ] [:gmem=メモリ値 ] [ :migpack=yes | no ]"

    -
    ジョブがジョブ・レベルの GPU 要件を設定しないことを指定します。 クラスター・レベル、キュー・レベル、またはアプリケーション・プロファイル・レベルで定義されている有効な GPU 要件を設定するには、ハイフンを文字なしで使用します。

    GPU 要件がクラスター、キュー、およびアプリケーション・プロファイルのレベルで指定されている場合、GPU 要件の各オプション (num、 mode、 mps、 j_exclusive、 gmodel、 gtile、 gmem、および nvlink) は別個にマージされます。 アプリケーション・プロファイル・レベルは、キュー・レベルをオーバーライドします。これは、クラスター・レベルのデフォルト GPU 要件をオーバーライドします。

    クラスター・レベル、キュー・レベル、またはアプリケーション・レベルで GPU 要件が定義されていない場合、デフォルト値は "num=1:mode=shared:mps=no:j_exclusive=no"です。

    num= num _gpus [/タスク | ホスト]
    ジョブが必要とする物理 GPU の数。 デフォルトでは、この数はホストごとです。 数値の後に /task を指定することによって、タスクごとに数値を指定することもできます。

    タスクごとの数を指定した場合、 lsb.resources ファイル内の ngpus_physical リソースの構成が PER_TASKに設定されている場合、 または RESOURCE_RESERVE_PER_TASK=Y パラメーターが lsb.params ファイル内に設定されている場合、この数はタスクごとに要求されるカウントです。

    mode=shared | exclusive_process (モード = 共用 | 排他プロセス)
    ジョブが実行されているときの GPU モード。 shared または exclusive_processのいずれかです。 デフォルト・モードは sharedです。

    共有モードは、 NVIDIA またはAMD DEFAULT コンピュートモードに対応します。 exclusive_process モードは、 NVIDIA のEXCLUSIVE_PROCESS 計算モードに対応します。

    注:
    • LSF NVIDIA GPUインスタンスまたはコンピューティングインスタンスでは、exclusive_process の設定をサポートしていません。 ジョブは通常通りディスパッチおよび実行できますが、ドライバーモードは設定されません。
    • AMD GPUを使用している場合（つまり、 gvendor=amdが指定されている場合）、 exclusive_processを指定しないでください。
    mps=yes[, nocvd][, shared] | per_socket[, shared][, nocvd] | per_gpu[, shared][, nocvd] | no
    ジョブに割り当てられたGPUに対して、 NVIDIA マルチプロセスサービス（MPS）を有効または無効にします。 MPS を効果的に使用すると、EXCLUSIVE_PROCESS モードはすべての MPS クライアントに対して DEFAULT モードのように動作します。 MPS では常に、複数のクライアントが MPS サーバーを介して GPU を使用できます。
    注: 動作の不整合を避けるため、AMD GPU を使用している場合 (つまり、 gvendor=amd が指定されている場合) は、 mps を有効にしないでください。 クラスター・レベル、キュー・レベル、アプリケーション・レベル、およびジョブ・レベルで GPU 要件をマージした結果が gvendor=amd であり、 スタンプ が有効になっている場合 (例えば、 gvendor=amd が MPS = NOを指定せずにジョブ・レベルで指定され、 MPS = YES がアプリケーション・レベル、キュー・レベル、またはクラスター・レベルで指定されている場合)、 LSF は スタンプ 要件を無視します。

    MPS は、共有プロセス GPU と排他プロセス GPU の両方に役立ち、GPU リソースをより効率的に共有し、GPU の使用率を向上させることができます。 詳細および制限事項については、 NVIDIA のドキュメントを参照してください。

    MPS を使用する場合は、EXCLUSIVE_PROCESS モードを使用して、単一の MPS サーバーのみが GPU を使用するようにします。これにより、MPS サーバーがその GPU のすべての CUDA プロセス間の単一調停点となる追加保険が提供されます。

    コンマとスペースなしで share キーワードを追加することにより、MPS デーモン共有を使用可能にすることもできます (例えば、 mps=yes,shared を指定すると、ホスト上で MPS デーモン共有が使用可能になります)。 共有が有効になっている場合、同じリソース要件を持つ同じユーザーによって実行依頼されるすべてのジョブは、ホスト、ソケット、または GPU 上の同じ MPS デーモンを共有します。

    LSF は、 mps キーワードの値に応じて、ホストごと、ソケットごと、または GPU ごとに MPS デーモンを開始します。

    • mps=yes が設定されている場合、 LSF はジョブごとにホストごとに 1 つの MPS デーモンを開始します。

      共有が有効になっている場合 (つまり、 mps=yes,shared が設定されている場合)、 LSF は、同じリソース要件を持つ同じユーザーによって実行依頼されたすべてのジョブに対して、ホストごとに 1 つの MPS デーモンを開始します。 これらのジョブはすべて、ホスト上の同じ MPS デーモンを使用します。

      CUDA_VISIBLE_DEVICES 環境変数が無効になっている場合 (つまり、 mps=yes,nocvd が設定されている場合)、 LSF はタスクの CUDA_VISIBLE_DEVICES<number> 環境変数を設定しないため、 LSF MPI はタスクの CUDA_VISIBLE_DEVICES を設定しません。 LSF は、 CUDA_VISIBLE_DEVICESではなく、タスクの CUDA_VISIBLE_DEVICES<number> 環境変数のみを設定します。 LSF MPI は、 CUDA_VISIBLE_DEVICES<number> 環境変数を CUDA_VISIBLE_DEVICES に変換し、それをタスク用に設定します。

    • mps=per_socket が設定されている場合、 LSF は、ジョブごとにソケットごとに 1 つの MPS デーモンを開始します。 共有が有効になっている場合 (つまり、 mps=per_socket,shared が設定されている場合)、 LSF は、同じリソース要件を持つ同じユーザーによって実行依頼されたすべてのジョブについて、ソケットごとに 1 つの MPS デーモンを開始します。 これらのジョブはすべて、ソケットに対して同じ MPS デーモンを使用します。
    • mps=per_gpu が設定されている場合、 LSF は、ジョブごとに GPU ごとに 1 つの MPS デーモンを開始します。 共有が有効になっている場合 (つまり、 mps=per_gpu,shared が設定されている場合)、 LSF は、同じリソース要件を持つ同じユーザーによって実行依頼されたすべてのジョブに対して、GPU ごとに 1 つの MPS デーモンを開始します。 これらのジョブはすべて、GPU に対して同じ MPS デーモンを使用します。
    重要: MPS で EXCLUSIVE_THREAD モードを使用することはサポートされていないため、予期しない動作が発生する可能性があります。
    j_exclusive=yes | いいえ
    割り振られた GPU を他のジョブが使用できるかどうかを指定します。 モードを exclusive_processに設定すると、 j_exclusive=yes オプションが自動的に設定されます。
    aff=yes | いいえ
    厳密な GPU-CPU アフィニティー・バインディングを適用するかどうかを指定します。 noに設定すると、 LSF は CPU アフィニティーを維持しながら GPU アフィニティーを緩和します。 デフォルトでは、 aff=yes は、厳密な GPU-CPU アフィニティー・バインディングを維持するように設定されています。
    注: aff=yes 設定は、 block=yes と競合します (タスクの数が要求された GPU の数より多い場合は、割り振られた GPU をブロックとして分散します)。 これは、厳密な CPU-GPU バインディングにより、CPU NUMA ID に基づいてタスクに GPU が割り振られるためです。これは、割り振られた GPU のブロックとしての配分と競合します。 aff=yes と block=yes の両方が GPU 要件ストリングで指定されている場合、 block=yes 設定が優先され、厳密な CPU-GPU アフィニティー・バインディングが無効になります (つまり、 aff=no が自動的に設定されます)。
    ブロック = はい | いいえ
    ブロック配布を使用可能にするかどうかを指定します。つまり、タスクの数が要求された GPU の数より多い場合に、ジョブの割り振られた GPU をブロックとして配布するかどうかを指定します。 yesに設定すると、 LSF は、タスクの数が要求された GPU の数より多い場合に、ジョブの割り振り済み GPU をすべてブロックとして分散します。 デフォルトでは、割り振られた GPU がブロックとして配布されないように block=no が設定されています。

    例えば、GPU ジョブが 4 個の GPU と 40 個のタスクを持つホスト上で実行するように要求した場合、ブロック配布により、 GPU0 (ランク 0 から 9)、 GPU1 (ランク 10 から 19)、 GPU2 (タンク 20 から 29)、および GPU3 (ランク 30 から 39) が割り当てられます。

    注: block=yes 設定は、 aff=yes (厳密な CPU-GPU アフィニティー・バインディング) と競合します。 これは、厳密な CPU-GPU バインディングにより、CPU NUMA ID に基づいてタスクに GPU が割り振られるためです。これは、割り振られた GPU のブロックとしての配分と競合します。 block=yes と aff=yes の両方が GPU 要件ストリングで指定されている場合、 block=yes 設定が優先され、厳密な CPU-GPU アフィニティー・バインディングが無効になります (つまり、 aff=no が自動的に設定されます)。
    gpack=yes | いいえ
    共用 モードのジョブの場合のみ。 パック・スケジューリングを使用可能にするかどうかを指定します。 yesに設定すると、 LSF は、割り振られた GPU に複数の共有モード GPU ジョブをパックします。 LSF は、以下のように共用モード GPU をスケジュールします。
    1. LSF は、既に実行中のジョブがある共有 GPU の数に基づいて候補ホストを (最大から最小の順に) ソートし、次に排他的でない GPU の数に基づいてソートします。

      リソース要件ストリングに order [] キーワードが定義されている場合、 LSF は、 order []をソートした後、 gpack ポリシーによって候補ホストを再ソートします (最初に実行中のジョブがある共有 GPU、次に排他的でない GPU の数によって)。 gpack ポリシーのソート優先度が order [] ソートより高くなっています。

    2. LSF は、実行中のジョブの数に基づいて、各ホスト上の候補 GPU を (最大から最小の順に) ソートします。

    スケジューリング後、共有モード GPU ジョブは、新しい共有 GPU ではなく、最初にソートされた、割り振られた共有 GPU にパックされます。

    Docker 属性アフィニティーが有効になっている場合、GPU でソートする前に、候補ホストの順序が Docker 属性アフィニティーでソートされます。

    デフォルトでは、 gpack=no はパック・スケジューリングが使用不可になるように設定されています。

    migpack=はい | いいえ
    Fix Pack 16 以降で利用可能であり、 NVIDIA の MIG スケジューリングが有効化されている必要があります（つまり、`` lsf.conf ファイル内で ` LSF_MANAGE_MIG=Y ` に設定されている必要があります）。 NVIDIALSF のMIGワークロードをパッキングモードでスケジュールするかどうかを指定します。 に設定すると yes、 LSF システムは最も負荷の低いGPUを優先するのではなく、ジョブのリソース要件を満たすのに十分な空きMIGスロットを持つ最も負荷の高いGPU上でワークロードを優先的に実行します。 LSF 各ホスト上の候補GPUをソートし、ホスト間でのGPUソートは行われません。 このオプションは、複数の小さなMIGインスタンスを詰め込んでジョブを完了させるため、GPU利用率を最大化します。

    デフォルト設定はnoです。 ジョブレベル、アプリケーションレベル、キューレベルで設定された場合、ジョブレベルが優先され、次にアプリケーションレベル、最後にキューレベルが優先される。

    ベンダー=amd | nvidia
    GPU ベンダー・タイプを指定します。 LSF は、指定されたベンダー・タイプで GPU を割り振ります。

    AMD GPUを要求するには amd を指定し、 NVIDIA GPUを要求するには nvidia を指定してください。

    デフォルトでは、 LSFNVIDIA のGPUを要求します。

    gmodel =モデル名[- mem _size]
    特定のモデル名と、オプションでその合計 GPU メモリーを使用して GPU を指定します。 デフォルトでは、 LSF は同じモデルを使用して GPU を割り振ります (使用可能な場合)。

    gmodel キーワードは、以下の形式をサポートします。

    gmodel =モデル名
    指定されたブランドとモデル名 (例えば、 TeslaK80) を持つ GPU を要求します。
    gmodel =short_model_name
    特定のブランド名 (例えば、Tesla、Quadro、NVS など) を使用して GPU を要求します。 またはモデル・タイプ名 (例えば、 K80、 P100)。
    gmodel= モデル名 - メモリサイズ
    指定されたブランド名と合計 GPU メモリー・サイズを持つ GPU を要求します。 GPU メモリー・サイズは、数値とその単位で構成されます。これには、 M、 G、 T、 MB、 GB、および TB (例えば、 12G) が含まれます。

    各ホストで使用可能な GPU モデル名を見つけるには、 lsload –gpuload、 lshosts –gpu、または bhosts -gpu コマンドを実行します。 モデル名ストリングにスペース文字が含まれていません。 さらに、スラッシュ (/) 文字とハイフン (-) 文字は下線文字 (_) に置き換えられます。 例えば、GPU モデル名は "Tesla C2050 / C2070「 LSFで「TeslaC2050_C2070」に変換されます。

    gmem=mem_value

    ジョブに必要な各 GPU 上の GPU メモリーを指定します。 mem_value の形式は、他のリソース値と同じです (例えば、次のようになります)。memまたはswap) ジョブ・リソース要件の rusage セクション (-R)。

    gtile=！ | タイル番号
    ソケットごとの GPU の数を指定します。 ホスト上のソケットごとの GPU の数を明示的に定義する数値を指定するか、感嘆符 (!) を指定して LSF が自動的に数値を計算できるようにします。これにより、ホスト上のすべてのソケットで GPU が均等に分割されます。 LSF は、アフィニティー・ジョブの場合でも gtile 要件を保証します。 これは、 gtile 要件を満たすことができない場合に、 LSF が、割り振られた CPU に GPU のアフィニティーを割り振らない可能性があることを意味します。

    アフィニティー・ジョブに対して gtile キーワードが指定されていない場合、 LSF は、GPU を割り振ったソケットに十分な GPU を割り振ろうとします。 最適なソケット上に十分な GPU がない場合、ジョブはこのホストに進むことができません。

    非類似性ジョブに対して gtile キーワードが指定されていない場合、 LSF は同じソケットに十分な GPU を割り振ろうとします。 これが使用可能でない場合、 LSF は GPU を別個の GPU に割り振る可能性があります。

    nvlink=はい
    LSFバージョン 10.1 フィックスパック 11 で廃止されました。 代わりに glink キーワードを使用してください。 GPU 間の NVLink 接続に対するジョブ適用を有効にします。 LSF は、NVLink 接続を有効にして GPU を割り振ります。
    glink=はい
    GPU 間の特殊な接続に対するジョブ適用を有効にします。 LSF は、GPU ベンダーに固有の特殊な接続を使用して GPU を割り振る必要があります。

    ジョブが AMD GPU を要求する場合、 LSF は xGMI 接続を使用して GPU を割り振る必要があります。 ジョブが NVIDIA GPUを要求する場合、NVLink接続を備えた LSF GPUを割り当てる必要があります。

    glink は、廃止された nvlink キーワードと一緒に使用しないでください。

    デフォルトでは、これらの接続に十分な GPU がない場合、 LSF は特殊な接続なしで GPU を割り振ることができます。

    lsb.params ファイルで GPU_REQ_MERGE パラメーターが Y または y として定義されており、GPU 要件が複数レベル (デフォルトのクラスター、キュー、アプリケーション・プロファイル、またはジョブ・レベルの要件のうち少なくとも 2 つ) で指定されている場合、GPU 要件の各オプションは個別にマージされます。 ジョブ・レベルはアプリケーション・レベルをオーバーライドします。これはキュー・レベルをオーバーライドし、デフォルトのクラスター GPU 要件をオーバーライドします。 例えば、GPU 要件の mode オプションが -gpu オプションで定義され、 mps オプションがキューで定義されている場合、ジョブ・レベルのモードとキューの mps 値が使用されます。

    lsb.params ファイルで GPU_REQ_MERGE パラメーターが Y または y として定義されておらず、 GPU 要件が複数レベル (デフォルトのクラスター、キュー、アプリケーション・プロファイル、またはジョブ・レベルの要件のうち少なくとも 2 つ) で指定されている場合、GPU 要件ストリング全体が置き換えられます。 ジョブ・レベルの GPU 要件ストリング全体がアプリケーション・レベルをオーバーライドします。これにより、キュー・レベルがオーバーライドされ、デフォルトの GPU 要件がオーバーライドされます。

    esub パラメーター LSB_SUB4_GPU_REQ は、 -gpu オプションの値を変更します。

    GPU 要件は、ジョブの rusage リソース要件に変換されます。 例えば、 num=2 は次のように変換されます。rusage[ngpus_physical=2]bjobs、 bhist、および bacct コマンドを使用して、マージされたリソース要件を確認します。

    ` bsub -gpu` コマンド bsub -gpu オプションの詳細については、bsub -gpu を参照してください。

    例えば、次のコマンドは、各 GPU に合計 12 GB のサイズを持つ 2 つの Tesla GPU を要求し、各 GPU に 8 GB の GPU メモリーを予約し、ホスト上のすべてのソケットに GPU を均等に分散させます。 ジョブの送信により、GPU上の NVIDIA が有効になり、割り当てられたGPUはすべてNVLink接続でなければなりません

    bsub -gpu "num=2:gmodel=Tesla-12G:gmem=8G:gtile='!':mps=yes:glink=nvlink ./myjob

  • アプリケーション・プロファイルまたはキューに GPU リソース要件が指定されている場合は、GPU リソース要件のあるアプリケーション・プロファイルまたはキューにジョブをサブミットします。

    bsub -app gpu_app ./myjob

    bsub -q "gpu_queue" ./myjob

  • 複雑な GPU リソース要件を持つジョブを実行依頼するには、 bsub -R コマンド・オプションを使用します。

    bsub -gpu オプションおよび GPU_REQ パラメーター構文がカバーできない複雑な GPU リソース要件が存在する可能性があります。これには、複合 GPU 要件 (異なるホスト上のジョブに対する異なる GPU 要件、または並列ジョブの異なる部分に対する異なる GPU 要件) および代替 GPU 要件 (1 つのジョブを実行するために複数の GPU 要件が受け入れ可能な場合) が含まれます。

    以下の bsub -R オプションは、GPU リソース要件に固有のものです。

    bsub -R " span[gtile=tile_num | '!'] rusage[ngpus_physical=num_gpus:gmodel=model_name [-mem_size ]:gmem=mem_value:glink=yes]"

    • span [] セクションで、 gtile キーワードを使用して、各ソケットで要求される GPU の数を指定します。
    • rusage[] セクションでは、 ngpus_physical リソースを使用して物理GPUの数を要求します。 gmodel オプションでGPUモデル（およびオプションの総メモリサイズ）を指定し、 gmem オプションで予約するGPUメモリの量を指定します。 glink オプションでは、特別な接続（AMD GPUの場合は xGMI 接続、 NVIDIA GPUの場合はNVLink接続）を備えたGPUのみを要求します。

    モード、 j_exclusive、および mps オプションを使用する必要がある場合、単純な GPU 要件を使用する必要があります。 複雑な GPU リソース要件の場合、 rusage [] セクションでこれらのオプションを使用することはできません。

    重要: bsub -R コマンド・オプションを使用してジョブ・レベルで複雑な GPU リソース要件を指定する場合、 lsb.queues ファイル内の RES_REQ パラメーターを使用してキュー・レベルを指定するか、 lsb.applications ファイル内の RES_REQ パラメーターを使用してアプリケーション・プロファイル・レベルを指定すると、 LSF はすべてのレベルで単純な GPU 要件を無視します (つまり、 LSF は bsub -gpu コマンド・オプション、 lsf.conf ファイル内の LSB_GPU_REQ パラメーターを無視します)。 および lsb.queues ファイルと lsb.applications ファイル内の GPU_REQ パラメーター)。

    複雑な GPU リソース要件など、リソース要件の指定について詳しくは、 リソース要件の指定を参照してください。

    例えば、以下の代替リソース要件ストリングは、2 つのタスクを持つ並列ジョブを指定します。各タスクは、各ソケットで均等に分割された 4 つの K80 GPU または 2 P100 GPU を持つ別個のホストで実行されます。

    bsub -n 2 -R "span[ptile=1,gtile=!] rusage[ngpus_physical=4:gmodel=K80 || ngpus_physical=2:gmodel=P100]" ./myjob

結果

GPU を割り振るときの GPU 条件の順序は、以下のとおりです。

  1. (Fix Pack 16 以降) GPU が MIG 対応 ( migpack=yes) であり、かつ LSF_MANAGE_MIG=Y が設定されている場合、最も空きのある MIG スロット。
  2. 負荷が最も少ないGPU。
  3. 最大の GPU 計算能力 (gpu_factor 値)。
  4. 直接 NVLink 接続を使用する GPU。
  5. 同じモデルの GPU (GPU 合計メモリー・サイズを含む)。
  6. 使用可能な最大 GPU メモリー。
  7. 同じ GPU 上の並行ジョブの数。
  8. 現在の GPU モード。