このトピックでは、Platform for AI (PAI) の Deep Learning Containers (DLC) についてよく寄せられる質問への回答を提供します。
Q: モデルのトレーニングが「 SupportsDistributedTraining false, please set InstanceCount=1」というエラーで失敗しました
原因: 現在のトレーニング タスクは複数のインスタンス（ノード数が 1 より大きい）を使用していますが、このモデルは分散トレーニングをサポートしていません。
解決策: ノード数を 1 に設定します。
Q: モデルのトレーニングが「failed to compose dlc job specs, resource limiting triggered, you are trying to use more GPU resources than the threshold.」というエラーで失敗しました。
トレーニング ジョブが同時に実行されている 2*GPU の制限を超えています。新しいジョブを開始する前に現在のジョブが完了するまで待つか、チケットを送信 して、より高いクォータをリクエストしてください。
Q: 「exited with code 137」というエラーメッセージが表示された場合はどうすればよいですか?
"exited with code 137" というエラーメッセージが表示された場合は、より大きなメモリサイズを持つインスタンスを使用するか、ワーカーノードの数を増やすか、コード内の予約メモリサイズを変更することができます。
Linux では、エラーコード 137 は、プロセスが SIGKILL 信号によって強制的に中止されたことを示します。最も一般的な理由は、メモリ使用量が高すぎることで、Out of memory (OOM) エラーとも呼ばれます。ジョブ詳細のワーカーノードのメモリ使用量に基づいて、メモリ不足の原因を特定し、使用可能なメモリを増やすことができます。
Q: ジョブのステータスが Failed または Dequeued の場合はどうすればよいですか?
次の表は、DLC のジョブ実行ステータスのシーケンスを示しています。
ジョブ タイプ | ステータス シーケンス | |
従量課金制リソース | 凌雲プリエンティブル リソース |
|
凌雲リソースまたは汎用コンピューティング パブリック リソース |
| |
サブスクリプション リソース |
| |
ステータスが Environment Preparing の場合はどうすればよいですか?
ジョブが Environment Preparing 状態のままになっている場合は、VPC (Virtual Private Cloud) を設定せずに CPFS タイプのデータセットを構成したことが原因である可能性があります。これを解決するには、ジョブを再作成し、CPFS タイプのデータセットと VPC を構成します。構成された VPC が CPFS の VPC と同じであることを確認してください。詳細については、「トレーニング ジョブを送信する」をご参照ください。
ステータスが Failed の場合はどうすればよいですか?
ジョブ詳細ページの
アイコンにマウスポインタを合わせるか、ログを表示して、ジョブ実行の失敗の原因を特定します。詳細については、「トレーニング ジョブを表示する」をご参照ください。
Q: パブリックリソースを使用するジョブを専用リソースに変更できますか?
リソースを変更するには、ジョブを再作成する必要があります。元のジョブの [アクション] 列の [複製] をクリックして、同じ構成で新しいジョブを作成します。その後、リソースを変更できます。課金については、「DLC の課金」をご参照ください。
Q: DLC で複数のノードと GPU を設定するにはどうすればよいですか?
DLC ジョブを作成するときに、次のコマンドを構成します。詳細については、「トレーニング ジョブを送信する」をご参照ください。
python -m torch.distributed.launch \ --nproc_per_node=2 \ --master_addr=${MASTER_ADDR} \ --master_port=${MASTER_PORT} \ --nnodes=${WORLD_SIZE} \ --node_rank=${RANK} \ train.py --epochs=100Q: DLC でトレーニングしたモデルをローカルマシンにダウンロードするにはどうすればよいですか?
DLC ジョブを送信するときに、データセットを関連付けて、トレーニング結果をマウントされたデータセット フォルダに保存するようにスタートアップ コマンドを構成できます。
トレーニング後、モデル ファイルはデータセットのマウント パスに自動的に保存されます。その後、対応するファイルシステムにアクセスして、モデル ファイルをローカルマシンにダウンロードできます。
DLC ジョブの送信中にデータセットを関連付ける方法については、「PAI コンソールでジョブを送信する」をご参照ください。
Object Storage Service (OSS) からローカルマシンにファイルをダウンロードする方法については、「OSS コンソールを使用して開始する」をご参照ください。
NAS ファイルシステムからローカルマシンにファイルをダウンロードする方法については、「Function Compute 関数にファイルシステムをマウントする」をご参照ください。
Q: DLC で Docker イメージを使用するにはどうすればよいですか?
Docker イメージを使用して DLC タスクを作成する: Docker イメージを Alibaba Cloud Container Registry (ACR) にプッシュし、PAI ワークスペースの[カスタムイメージ]に追加できます。そのため、DLC タスクを作成するときに、対応するイメージを選択してインスタンスを起動できます。
Docker イメージを Container Registry ACR にプッシュするには、「Container Registry Personal Edition インスタンスの[イメージリポジトリ]にイメージをプッシュする、および[イメージリポジトリ]からイメージをプルする」をご参照ください。
PAI [カスタムイメージ]を追加するには、「カスタムイメージ」をご参照ください。
Q：DLC ジョブで完了したノードを解放し、他のジョブが使用できるようにする方法
問題の説明：
DLC ジョブがマルチワーカーの分散トレーニングタスクを実行する際、一部のワーカーが早期に終了することがあります。これは、データスキューなどの要因によって発生する可能性があります。しかし、デフォルトの構成では、これらの完了したワーカーはスケジュールされたノードを占有し続けます。
解決策: 設定するのは PAI-DLC の高度なパラメーター ReleaseResourcePolicyです。デフォルトでは、このパラメーターは設定されておらず、計算リソースはジョブ全体が完了した後にのみ解放されます。これを pod-exit に設定すると、worker が終了するとすぐに計算リソースが解放されます。
Q：DLC ジョブで「OSError: [Errno 116] Stale file handle」エラーが返される理由
問題の説明：
複数のワーカーが PyTorch の torch.compile を実行して事前 (AOT) コンパイルを行う際に、「OSError: [Errno 116] Stale file handle」 (無効なファイルハンドル) エラーで失敗します。この失敗は、キャッシュファイルの読み取りができないことが原因です。
分析：
このエラーは通常、ネットワークファイルシステム (NFS) 環境で発生します。プロセスが、サーバー上で削除または移動されたファイルのファイルハンドルを保持している場合にトリガーされます。ハンドルが無効になり、クライアントがこの無効なハンドルを使用してファイルにアクセスしようとするとエラーが発生します。
根本原因：
PyTorch の事前 (AOT) コンパイルは、最適化された計算グラフをファイルシステムにキャッシュします。デフォルトでは、キャッシュは通常ローカルの tmpfs である /tmp に保存されます。しかし、クラスターコンピューティング環境では、このキャッシュは NFS 経由でマウントされた分散ファイルシステムである CPFS に保存されることがあります。NFS はファイルの削除操作に敏感です。無効なファイルハンドルは、いくつかの条件下でトリガーされる可能性があります。たとえば、PyTorch が古いキャッシュファイルを自動的にクリーンアップしたり、別のプロセスがキャッシュディレクトリを削除したりする場合があります。また、クライアントが古いハンドルを保持している間に、NFS サーバー上でファイルが移動、削除、または権限が変更された場合にもエラーが発生する可能性があります。さらに、NFS クライアントはデフォルトでファイル属性をキャッシュするため、サーバー上で行われた変更を検出できないことがあります。この問題は、いくつかの環境要因によって悪化します。CPFS は NFS 上に構築されており、高い同時実行性の下では無効なファイルハンドルエラーが発生しやすくなります。これは、一時的なキャッシュファイルなどのライフサイクルが短いファイルで特に顕著です。同じキャッシュを読み書き、またはクリーンアップしている複数のワーカーからの同時アクセスも、競合状態を引き起こす可能性があります。
解決策：
まず、環境変数 TORCHINDUCTOR_CACHE_DIR を /dev/shm/torch_cache に設定して、キャッシュを強制的にローカルの tmpfs を使用させることで、この問題を確認できます。
代替ソリューション：
PyTorch の公式ドキュメントに従って、Redis を共有キャッシュとして使用します (これには Redis サービスの設定が必要です)。
CPFS の NFS マウント構成を確認します。noac マウントオプションを使用すると役立つ場合がありますが、パフォーマンスが低下します。
TORCHINDUCTOR_CACHE_DIR="" を設定して、キャッシュを完全に無効にします。ただし、これによりコンパイルのパフォーマンスが犠牲になります。