1. 参照と期待される結果を定義する
まず、何を再現したいのかから始めます。同じカテゴリを生成する、近い値を得る、またはトレーニングの軌跡を再開するなどです。重要なステップを通過する小さな入力セットと、有効な出力の例を保持してください。エラーなく終了するインストールは、まだこの問いに答えてはいません。
教育用のケースを考えてみましょう。あなたのアプリケーションが、特定のサンプルに対して埋め込みを生成するとします。参照環境では、出力の形状、型、非有限値が含まれていないこと、そして有用な業務上の判定基準を確認する必要があります。値を比較する場合は、用途に応じて正当化できる許容範囲を選びましょう。ここでは普遍的な数値しきい値は提供していません。
コード、データ、重みにリビジョンを割り当てましょう。「最新モデル」のような名前は、プログラムが示さなくても変わり得ます。パラメータと前処理も参照に関連付けましょう。この記録があれば、差異がソフトウェア由来なのか、入力由来なのか、実行条件由来なのかが分かります。
表をスクロールしてすべての列を表示してください。| 要素 | 保持するもの | 再構築後の確認 |
|---|---|---|
| コードとパラメータ | リビジョン、変更があればその内容、設定 | 同じエントリポイントと同じオプション |
| データと重み | バージョンまたはフィンガープリント、出所、アクセス権 | 同じサンプルと同じ期待内容 |
| Python とパッケージ | バージョン、手順、インストール元 | 正しいインタプリタと整合性の取れた依存関係 |
| システムとバックエンド | OS、アーキテクチャ、ドライバ、CUDA または ROCm | 認識されるデバイスと最小限の計算の成功 |
| 結果 | 形式と受け入れ基準 | まず構造、次に品質または想定する許容範囲 |
2. システムチェーンと Python パッケージを分離する
カード、システム、ドライバ、Python、ライブラリをまとめて確認しましょう。仮想環境は Python パッケージを整理するものであり、システムのドライバを置き換えるものではありません。同様に、イメージの参照だけでは、そのホストからの実際の GPU アクセスを記述するには不十分です。コンパイルされた拡張機能については、必要なコンパイルツールとライブラリを記録しておきましょう。
PyTorch のディストリビューションは、プロジェクトの計算プラットフォームに基づいて選びましょう。ROCm では、PyTorch は torch.cuda 呼び出しと cuda という名前のデバイスを再利用します。つまり、インターフェース名だけでは NVIDIA を識別できません。torch.version.cuda と torch.version.hip は別々に確認しましょう。特定のチェーン向けに書かれた拡張機能には、独自の確認が必要です。
実際にインストールを可能にした手順を、パッケージの取得元とともに保存しましょう。オンラインで見つけた最近のコマンドと古い依存関係ファイルを、互換性を確認せずに混在させるのは避けましょう。参照したドキュメントは変わり得ます。使用したバージョンは自分の記録に記載しておきましょう。
3. インストール済みディレクトリをコピーするのではなく、再構築を書く
選定した Python で新しい環境を作成しましょう。次に、そのインタプリタを明示的に使ってプロジェクトをインストールし、起動します。Linux では例えば .venv-rebuild/bin/python、Windows では .venv-rebuild\Scripts\python.exe となります。以前のアクティベートに依存する必要はありません。Python のドキュメントにも、仮想環境は場所が変わったら再作成すべきだと明記されています。
pip freeze はインストール済みパッケージの一覧を提供するものであり、計算されたロックファイルではありません。これは観察記録として保存しましょう。再構築ファイルには、あなたの PyTorch の亜種に必要なインデックスやファイル、および互換バージョンも明記する必要があります。共有する前に、一覧に含まれる可能性のあるパスや URL を確認しましょう。
以下のコマンドは、適宜調整が必要な Linux での再構築の例であり、あなたのプロジェクトを実際に実行したテストではありません。requirements-rebuild.txt は、PyTorch の適切な選択を含め、あなたの環境をすでに記述している必要があります。これを普遍的な想定バージョンのリストで置き換えないでください。
python -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip --version
.venv-rebuild/bin/python -m pip install -r requirements-rebuild.txt
.venv-rebuild/bin/python -m pip check
.venv-rebuild/bin/python -m pip freeze --all > installed-after.txt4. 計算の前に依存関係の契約を確認する
正しいインタプリタで実行した python -m pip check は、メタデータに基づいて、インストール済みの依存関係の不足や非互換を検出します。競合なしという結果は、ドライバ、ネイティブ拡張機能、アプリケーションの品質を検証したことにはなりません。したがって、このステップは短く留め、計算の確認へと進みましょう。
再現性をより厳密にするには、バージョンを固定し、許可されたディストリビューションの指紋を保持することができます。この決定には、お使いのプラットフォームに対応する完全なリストを維持する必要があります。コンパイル済みホイールのアーカイブは、OS とアーキテクチャに依存する可能性があり、異なる2台のマシン間でのポータビリティを保証するものではありません。
埋め込みの例では、モデルやそのパラメータを変更する前に、再構築したインベントリをリファレンスと比較します。差異が意図的なものであれば、それを記録し、新しい実行をバリアントとして扱います。そうでなければ再構築を修正します。複数のレイヤーを同時に変更すると、診断の精度が低下します。
5. 最小限の確認から適用へ
プロジェクトのインタプリタで、Python、PyTorch、バックエンドを確認し、次にデバイスと簡単な計算を検証します。想定した GPU にアクセスできない場合はこのステップを中断してください。CPU によるフォールバック実行は比較を混乱させます。Kernodeck の診断は解釈可能なレポートを提供し、実際に通過したステップを区別します。
この確認が成功したら、小さなアプリケーションサンプルを使用します。埋め込みの場合は、出力数、その次元、識別子との対応、および選択した基準を確認します。出力フォルダからファイルを再読み込みします。行列計算の成功は、前処理やプロジェクトの拡張機能が動作することを証明するものではありません。
データの読み込み、転送、または特定の操作中に試行がクラッシュした場合は、そのステップと最初のエラーを保持します。一般的な再構築は正しいかもしれません。ブロックはデータローダーや特定のオペレータに属する可能性があります。その場合は、診断をそのレイヤーに向けてください。
6. 再構築と数値的同一性を区別する
同じ依存関係を再現しても、ハードウェア、プラットフォーム、PyTorch のバージョン間で同一の結果が保証されるわけではありません。シードを固定しても、すべての変動要因をカバーできるわけではありません。使用したジェネレータ、データの変換、および関連する精度や決定性の設定を文書化してください。
差異を確認する前に比較基準を定義します。厳密な構造、数値的な許容範囲、またはメトリクスの安定性です。一部の決定論的設定は、操作を拒否したり計算コストを変更したりする場合があります。求める結果は、公表された条件下で理解できる結論であり、あらゆるマシンでの同一性の約束ではありません。
トレーニングの再開には、バージョンだけでは不十分です。計算状態と進行状況も復元する必要があります。再開フォルダはこの問題を個別に検証します。その CPU 演習と許容範囲が、自動的にあなたのモデルの条件になるわけではありません。
7. 別の起動で使用できるフォルダで締めくくる
最終的なフォルダには、手順、観察されたインベントリ、構成、データの参照、および確認の結果をまとめます。正確な順序を追加します。再構築、診断、サンプルの実行、出力の再読み込みです。アクセス情報は別に保管し、提供方法のみを記載します。
環境を引き継ぎ可能と見なす前に、この順序をクリーンなフォルダで再現します。確認は、古いノートブックから変数を取得したり、忘れられたファイルを探したりすることなく成功する必要があります。変更が必要な場合は、手順を修正し、リファレンスに新しい識別子を付けます。こうして次の計算期間に使用できる基盤が得られます。