1. プロジェクトに合った出発点を選ぶ
ソフトウェアスタックを自分で構成でき、そのシステム依存関係を記述できる場合は、Ubuntuベースが適しています。PyTorchの準備は、プロジェクトの中心となるフレームワークを示すのに役立ちます。Blenderは、制作またはレンダリングのニーズを示します。カスタム準備は、アプリケーションにすでに固有の条件があり、これらの表示ではうまく要約できない場合に使用します。
これらの選択によって、コード、重み、データ、ライセンスが自動的に含まれるわけではありません。何を利用可能にする必要があるか、何を持ち込むか、起動時に何を確認するかを記述してください。準備の名前があるからといって、実際に実行されるバージョンの確認を怠ってはなりません。
良い依頼とは、既知のツールをすべて列挙することではありません。有用な流れを記述します。入力を読み、リソースを読み込み、計算し、結果を書き出す。これにより、必須の依存関係と利便性のためのツールを区別し、欠けている工程を診断しやすくなります。
表をスクロールしてすべての列を表示してください。| 準備 | 記述するニーズ | プロジェクト固有のチェック |
|---|---|---|
| Ubuntu | 期待するバージョンと必須のシステム依存関係 | プログラムが必要なライブラリとともに起動する。 |
| PyTorch | Python、フレームワークのバリアント、拡張機能 | インポート、バックエンドでの計算、その後の代表的なタスク。 |
| Blender | バージョン、拡張機能、関連リソース、エクスポート形式 | プロジェクトを開き、処理工程を確認済み。 |
| カスタム | 手順、バージョン、参照ファイル | 準備仕様書の各基準が確認されている。 |
2. コンパクトな準備ノートを書く
Pythonプロジェクトでは、システム、インタプリタ、パッケージ、アプリケーションのリソースを区別してください。依存関係が要求する場合は正確なバージョンを保持します。範囲を許容する場合は、それを検証するためのチェック方法を説明してください。「最新バージョンをインストールする」は基準環境と照らし合わせるのが困難です。
教育用の例：あなたのプロジェクトがネイティブ拡張で画像を分類するとします。依頼にはPythonのバージョン、選択したPyTorchのバリアント、プロジェクトのリビジョン、拡張の前提条件を記載します。許可された3つのコントロール画像を提供し、期待される出力形式を記述します。試行なしにスループットや十分なメモリを保証してはいけません。
準備ノートは短くても構いません。手順とアクセス方法が明確であれば、README、依存関係ファイル、コードのリビジョンで十分です。変更可能なパラメータは別ファイルに保管し、新しいバッチサイズが依頼を別のインストールに変えてしまわないようにします。
目的：画像の小さなサンプルを分類する
コード：プロジェクトのリポジトリとリビジョン
Python：アプリケーションが要求するバージョン
PyTorch：採用したバージョンとCUDAまたはROCmのバリアント
拡張：バージョン、入手元、コンパイルの前提条件
入力：許可されたサンプルと期待される識別子
チェック：識別子ごとの出力、有効な形式、再読み込み可能な結果
アクセスの提供：別手順とし、このノートにシークレットを含めない3. PyTorch固有の依存関係を確認する
パッケージを増やす前に、計算チェーンの検証を行ってください。PyTorchの公式セレクターでは、プラットフォームに応じたインストールを選択できます。CUDAとROCmは、同じバイナリの互換性のある2つの名前ではありません。メインのフレームワークが動作していても、特殊なオペレーターやプロジェクトの拡張機能が非互換のままであることがあります。
拡張をコンパイルする必要がある場合、そのビルドには追加のツールやライブラリが必要になることがあります。PyTorchのドキュメントには、torchパッケージのインストールだけではすべての拡張に必要なコンパイルチェーンが自動的に提供されないと記載されています。これらの前提条件を手順に記載してください。コンパイルを試みるインストールコマンドは、隠すべき異常ではありません。
3つの独立したチェックを計画してください。フレームワークのインポート、デバイス上での小さな計算、拡張機能を使用する演算です。最初の2つが成功し3つ目が失敗した場合、「PyTorchが動かない」という単純な結論よりも精度の高い診断が得られます。最初に発生した完全なエラーと該当するバージョンを記録してください。
4. 環境の記述方法を選ぶ
Pythonパッケージの場合、仮想環境を使った再構築手順がしばしばシンプルな基盤となります。これは特定のインタプリタを対象とし、プロジェクトの依存関係を分離します。マシン全体を記述するものではないため、システム要件はREADMEに記載し、インストール済みディレクトリのコピーをポータブルな手順として提示しないでください。
プロジェクトがすでにコンテナを使用している場合は、そのレシピ、リビジョン、起動に必要なパラメータを提供してください。タグは変わり得ますが、ハッシュによるリビジョンは特定のイメージをより正確に識別します。それでも更新を整理し、プロジェクトを再検証する必要があります。コンテナはそれだけではGPUへのアクセスやデータの存在を証明しません。
自分が維持できる仕組みを選んでください。非常に完全なイメージは不要な依存関係を隠すことがあり、最小限すぎるレシピは手動インストールをノートの外に残すことがあります。どちらの場合も、アプリケーションのチェックが比較の基準となります。これらの説明はあなたの準備を記述するものであり、サービスによるイメージ提供の方法を前提とするものではありません。
5. ノートブックとグラフィカルプロジェクトを準備する
ノートブックはデータの探索や出力の可視化に役立ちます。ただし、そのファイルとセルを実行するプロセスは別物です。以前のセッションの変数は、文書化された依存関係ではありません。移行する前にカーネルを再起動し、セルを順番に実行してください。使用した Python も記録しておきましょう。
試用が定期的な処理になったら、セルを一つずつ操作する必要のないエントリーポイントを用意しましょう。ノートブックからスクリプトへの移行を扱ったガイドで、この変換を詳しく説明しています。準備を依頼する際は、ノートブックの必要性を明示しつつ、作業用インターフェースとプログラムの正常な制御を混同しないようにしてください。
Blender やその他のグラフィックソフトウェアの場合は、関連するリソース、拡張機能、エクスポート手順を追加してください。自分のマシンで開けるプロジェクトが、別の場所にあるファイルに依存していることがあります。別のマシンがそれぞれのファイルをどう見つけるか、そして作業全体の前に連携を確認できる小さな成果物は何かを考えましょう。
6. 基準と再確認した成果物で受け取る
提供時には、確認したバージョンを自身の記録と比較してください。診断を実行し、その後予定しているアプリケーションケースを実行します。例の3つのイメージについては、各識別子に出力があること、カテゴリが有効であること、生成されたファイルが再読み込みできることを確認してください。エラー画面がないことは、この検証の代わりにはなりません。
有用な差分は残しておきましょう。バージョンの違い、拡張機能の欠如、アクセスできない入力、別の場所に書き出された出力などです。開始を妨げるものと、単にドキュメントの更新が必要なものを区別してください。サポートを求める際は、注文参照と最小限の抜粋を添えてください。コーパス全体を送る必要はありません。
サンプルで検証済みの準備であっても、メモリ容量や今後のすべてのワークロードの動作を保証するものではありません。次に、明確な目標を定めてデータ量を増やし、最初に遭遇した制限を確認してください。最後に、修正した手順を保存しておきましょう。それが次回のレンタルでの基準になります。