Capordia分割可能な作業単位を定義する
受け入れられた結果とは何かを書き出します。1枚の画像、処理済みの文書、一連のシミュレーション、または学習の最終状態です。次に、ある単位が他を待たずに計算できるかを問いましょう。2つの文書は処理中は独立していても、共通のインデックス構築ステップに依存する場合があります。分割はこの第2のステップを記述すべきであり、並列化の約束の中で忘れてはなりません。
計算上の独立性と業務上の独立性を区別しましょう。出力は技術的なやり取りなしに生成されても、バッチ全体の承認前に使用できないことがあります。したがって、計算単位、納品単位、組み立てルールを命名します。この共通の語彙により、調達がカードを数える一方でアプリケーションチームがインスタンスや同じモデルの断片を数えるという事態を避けられます。
独立した作業か緊密な協調かを選ぶ
独立したタスクでは、各プロセスが独自の入力を受け取り、識別可能な出力を生成します。別のカードは各ステップで同期することなく別のタスクを実行できます。このモードは、一定期間内に完了した量が目標となる場合に有効です。単独のタスクを自動的に高速化するものではなく、データ、ストレージ、ライセンスの競合を引き続き確認する必要があります。
協調作業では、デバイス間でデータを交換したり、中間結果を待ったりします。プログラムがこの分割を管理する必要があります。CUDAのガイドでは、複数GPUの活用にはコンテキスト、データ分散、起動、通信が伴うと説明されています。これらはソフトウェア経路と観測されるシステムの特性であり、カタログ上のカード名はその経路がすでに存在することを証明しません。
| 質問 | 独立した作業 | 協調作業 |
|---|---|---|
| カードは何を受け取るか？ | 独立した完全なタスク | 作業の一部または複製 |
| 何を調整する必要があるか？ | 入力の割り当てと出力の収集 | 交換、順序、同期 |
| どのような効果を確認するか？ | 一定期間あたりの受け入れ結果数 | 所要時間または容量を調整した同一の結果 |
| どのような失敗を想定するか？ | 孤立したタスクまたは公開 | 利用できない参加者がグループに与える影響 |
複製とメモリ分割を混同しない
モデルのコピーが複数あるからといって、そのパラメータがカード間で分割されるわけではない。PyTorch DistributedDataParallelは、ローカルモデルを訓練するプロセス間で勾配を同期する。したがって、このアプローチだけで、1枚のカードには大きすぎるモデルが複数枚に収まると結論づけることはできない。分割の仕組みには、それ自体のドキュメントと検証が必要である。
各カードのメモリは、ソフトウェアが実際にそこに配置するもの、すなわちデータ、モデルの状態、一時領域、および必要に応じた交換を満たす必要があります。ピークは設定や処理フェーズによって変動します。デバイスごとに記録しましょう。公称容量の合計は、1枚がメモリ不足になる一方で他が余っているという不均衡を覆い隠します。バッチの総容量だけではシナリオを受け入れられません。
架空の例：8つの独立した変換を分散する
架空のチーム「Index des ouvrages」は、8つのドキュメント変換を準備する。その作業仮定では、各変換はロードと出力を含めてカードを12分間占有する。タスクはカード上で単独で実行され、最終的な組み立て前にやり取りは不要である。これらの所要時間は推論を組み立てるためだけのものであり、Capordiaが提供するGPUの実行や性能を表すものではない。
カード1枚では、8つのタスクを連続して行うと8 × 12 = 96分となる。カード2枚で4つずつ均等に分担すると、並列化可能な部分は理論上48分となる。最終的な組み立てに別のワークステーションで10分を要する場合、開始待ちを除いた全体の所要時間はそれぞれ106分または58分となる。この計算は、2枚のカードが互いのロードを遅くしないことを前提としている。
| 編成 | 並列化可能な部分 | 組み立て | 計算上の所要時間 |
|---|---|---|---|
| カード1枚、タスク8つ | 96分 | 10分 | 106分 |
| カード2枚、各タスク4つ | 48分 | 10分 | 58分 |
この理論上の利得を打ち消しうるものを見える化する
同じ例でも、ドキュメントのサイズは均一ではないかもしれません。最も長い4つを一方のカードに割り当てると、もう一方は終盤で待たされます。空き状況に応じた配分はバランスを改善できますが、信頼できる割り当ての仕組みと受け入れポリシーが必要です。キューのガイドではこの編成を扱っていますが、本計算はそれがすでに導入済みであることを証明するものではありません。
ストレージもまた、支配的な共通リソースになり得る。同じデータを読む、あるいは同時に大きな結果を書き込む2つのプロセスが、必ずしも2倍のスループットを持つわけではない。ツールやライセンスの同時実行の上限も確認すること。並列化できない部分が増える場合は、カレンダー全体をやり直すこと。あるフェーズで節約した時間が、別の場所で追加される遅延を覆い隠してはならない。
分散処理では、実際のトポロジーを把握する
どのカードが見えるか、どのように通信するか、どのホストリソースがプロセスを共有するかを確認してください。管理者コンソールからだけでなく、使用する環境からアクセス可能なデバイスを確認してください。CUDAは、別のGPUのメモリへのアクセスが、とりわけトポロジーとシステムの能力に依存すると明示しています。あるモデルが機能をサポートしていることは、そのマシンに期待する接続が存在することを示すものではありません。
データの流れを簡単な図にまとめてください。入力、対象となるカードまたはプロセス、やり取り、最終的な集約、出力です。各矢印について、それがホストメモリ、GPU間リンク、ネットワークのいずれを通るかを特定します。この見取り図は受け入れ検査の選定に役立ちます。特定の技術を強制するものではなく、マルチGPUの要望を特定のトポロジーの約束に変えるものでもありません。
期待される結果を変えずに2つの進め方を比較する
小規模で代表性のあるコーパスを用意し、許可された対象環境で、基準となる編成を実行してから候補の編成を実行してください。バージョン、設定、期待する品質、組み立てのルールを維持します。合格した結果に至るまでの時間、各カードのメモリピーク、エラー、共有リソースの消費量を比較してください。観察事項と推定は分けてください。提案されたコマンドは、すでに得られた結果と同等ではありません。
特に、合格した出力の数が同じままで、入力が1つも欠けていないことを確認してください。演算の順序に敏感な計算では、恣意的な一致ではなく、根拠のある許容範囲を選んでください。品質が異なるままより早く終わる編成は、別の問題に応えるものです。また、分担が有利にならないケースも残しておいてください。この限界は、共通の負荷を考慮しないカードのランキングよりも、選択をよく説明してくれます。
選択を要求する性能に翻訳する
最終的に、同時実行タスク数、それぞれに必要なカード、不可欠な条件を書き出すこと。2枚のカードに分散される1つのタスクと、1枚のカードで行う2つのタスクは、カードの合計が同じでも異なる進め方である。選択した構成は、必要な進め方を可能にしなければならない。公称の合計から出発し、後からそれに用途をでっち上げてはならない。
カタログにはカードのロットが記載されています。B200のロットには180GBのGPUが2基含まれますが、この構成はソフトウェアがそれらを単一のメモリとして扱うことを保証するものではありません。次のステップは、必要な要件をロットに照らし合わせ、実際に必要な特性を受け取ることです。決定的な条件が確認されるまで、スケジュール、コスト、判断は暫定的なものにとどまります。
判断のための質問
GPUは2枚あれば常に1枚より速いのか？
いいえ。効果は並列化可能な割合、やり取り、共有リソースによって異なります。分割できない単一のタスクでは、2枚目のカードが使われないままになることがあります。明確なプロトコルで、同じ許容結果に至るまでの時間を比較してください。
カード2枚のロットで、自分のプログラムが使えるメモリは2倍になるのか？
自動的には倍になりません。各デバイスはそれぞれメモリを持ち、プログラムはその状態やデータを配分する必要があります。モデルのレプリケーションでは、かえってその状態の大部分が重複することがあります。ソフトウェアの仕組みとカードごとのピークを確認してください。
いつ独立したタスクから始めるべきですか？
各単位を個別に計算でき、より多くの単位を完了させることを狙う場合です。ただし、割り当て、負荷分散、最終的な統合を検証する必要があり、ストレージやライセンスが自動的に追随すると仮定してはいけません。