実行する内容
Kernodeck のミニプロジェクトには、小規模な合成データセット、dropout を含むネットワーク、学習ループ、検証ツールが含まれています。このプロトコルは保存と再開のロジックを分離するために CPU を強制します。これは CUDA、ROCm、マルチカードの適格性や、レンタルした GPU の性能測定を構成するものではありません。
検証ツールは、連続経路、中断、完全再開、そして乱数生成器を復元しないネガティブケースのために、新しいプロセスを開きます。後者の目的は、重みとステップ番号が正しく見えても、不完全な再開を検証ツールが検出できることを確認することです。
表をスクロールしてすべての列を表示してください。| 経路 | 実行 | 検証する問い |
|---|---|---|
| 連続 | 初期状態から 10 回の更新。 | 中断なしでどの状態に到達するか？ |
| 中断 | 5 回の更新後、保存して停止。 | 中間地点に期待される状態が含まれているか？ |
| 完全再開 | 新しいプロセスで、チェックポイント 5 を読み込み、さらに 5 回の更新。 | 選択した許容範囲内で、同じ一連の入力、学習率、パラメータが得られるか？ |
| RNG なしの再開 | 新しいプロセスで、同じ再開地点だが乱数の復元を省略。 | 重みを単に読み込むだけでは見逃すドリフトをテストが検出するか？ |
前提条件とプロトコルの起動
アーカイブをダウンロードし、作業フォルダに展開して、train.py と verify_resume.py が含まれるフォルダに移動します。PyTorch と NumPy が利用可能な Python 環境を使用してください。アーカイブにはコードと合成データが含まれています；モデルのダウンロードは行わず、演習の実行に Kernodeck アカウントも必要ありません。
提供された証拠は Python 3.14.6、PyTorch 2.11.0+cu128、NumPy 2.4.4 で実行されました。プログラムは CPU、float64 精度、PyTorch の単一スレッドを強制します。したがって、パッケージのサフィックスは再開が CUDA を使用したことを意味しません。別の環境では、ご自身で検証を実行してください。
まだ存在しない出力ディレクトリを選択してください。各経路は checkpoint.pt、そのハッシュ checkpoint.pt.sha256、および summary.json を生成します。検証ツールは比較結果を verification.json にまとめます。--steps オプションは追加のステップ数をカウントします：5 での中断後、再開コマンドは 10 に到達するために 5 を実行します。Python オプション -B は演習フォルダ内のバイトコードキャッシュを回避します。
python -B verify_resume.py --output runs/preuve-cpupython -B train.py --steps 10 --output runs/continu
python -B train.py --steps 5 --output runs/coupure
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --output runs/reprise重みのエクスポートと再開チェックポイントは役割が異なる
まず、何を復元したいのかを決めましょう。推論用のエクスポートは、学習済みモデルで予測を生成するためのものです。学習の再開では、次の更新を決める状態も復元する必要があります。ファイル単位の推論処理では、完了済み要素の信頼できるリストが必要です。この3つの用途は、それぞれ異なる保存を必要とします。
この永続的な保存を activation checkpointing と混同しないでください。この手法はメモリに保持する一部のアクティベーションを、逆伝播中に再計算することで削減します；それだけでは停止後の再開を可能にするファイルを作成しません。したがって、プロジェクト内で checkpoint という語がメモリ最適化を指すのか、再開地点を指すのかを明確にしてください。
まとめて保持すべき状態
モデルのstate_dictには登録されたパラメータとバッファが含まれ、オプティマイザーは独自の状態を持ちます。ここでは、Adam、StepLR、ドロップアウト、および3つの乱数ジェネレーターが以降の更新に影響します。チェックポイントは、これらのすべての要素について同一の時点を表している必要があります。
コードのバージョン、実験のパラメータ、データの識別情報も記録してください。エポックの途中では、その番号だけでは不十分です。サンプルの順序と、次に消費するグループを復元できる必要があります。ここで誤ると、入力を飛ばしたり、二重に処理したりする可能性があります。
24行のデータセットは、2つの変数とターゲットの間の合成された関係を表しています。ネットワークは33個のパラメータを持ち、8ニューロンの層とドロップアウト0.25で構成されています。バッチには4行が含まれます。5回の更新後、カーソルは24のうち20となり、エポックの途中で区切られます。10回の更新は40個の観測を消費するため、検証はデータの新しい並び順をまたぐ必要があります。
表をスクロールしてすべての列を表示してください。| 状態 | 役割 | 実施すべき確認 |
|---|---|---|
| モデル | 重みとバッファを保持する。 | 最終パラメータと評価出力を比較する。 |
| オプティマイザ | 次の更新で使用される状態を保持する。 | ハイパーパラメータだけでなく、その再読み込みを確認する。 |
| スケジューラ | 学習率の系列を継続する。 | 次に適用される学習率、続いてその後の学習率を比較する。 |
| Python、NumPy、PyTorchのRNG | 実際に使用された乱数生成を継続する。 | 復元なしのネガティブテストが発散することを確認する。 |
| データ | 並び替えとカーソルを再開する。 | 区切りの後に入力の識別子を比較する。 |
| 進行状況 | ステップとエポックを解釈する。 | やり直しや漏れなく、合計10回の更新に到達する。 |
| 構成 | 同じ実験を再現する。 | 次元、精度、設定、バージョンを保持する。 |
正しい順序で復元する
状態を読み込む前に、モデル、オプティマイザ、スケジューラを再構築してください。スケジューラは optimizer.load_state_dict() より前に作成する必要があります。そうしないと、その構築によって復元された学習率が上書きされる可能性があります。スケジューラ自身の状態も再読み込みし、次のステップで実際に使用される学習率を確認してください。
乱数生成器を消費するオブジェクトを構築した後に、作業を続行する直前に乱数生成器を復元してください。初期シードを単に戻すだけでは、シーケンスが先頭から再開されてしまい、5回目の更新後に到達した状態を復元することにはなりません。プロジェクト内で、変換やデータ読み込みのものを含め、使用されているすべての乱数生成器を特定してください。
この演習では、Pythonが入力に対してわずかなゲインを調整し、NumPyのPCG64生成器がノイズと並び替えを生成し、PyTorchがドロップアウトを生成します。チェックポイントは、区切り時点で到達したこれらの状態を保持します。検証では、計算の続行を妨げないよう状態を即座に復元しながら、次の乱数生成も確認します。
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)
# 再開フローでは、オブジェクトの構築後に：
state = load_checkpoint(resume)
model.load_state_dict(state["model"])
scheduler.load_state_dict(state["scheduler"])
optimizer.load_state_dict(state["optimizer"])
progress = state["progress"]
history = state["history"]
restore_rng(state["rng"], generator)
model.train()一貫した保存境界を選ぶ
例えば、オプティマイザの完全な更新後など、明示的な境界を定めてください。この更新前に複数のマイクロバッチを蓄積する場合、途中で保存すると中間状態も管理する必要があります。蓄積された勾配がすでに消費された境界で保存するほうが、最初の実装は検証しやすくなります。
複数世代のバックアップを保持してください。新しいファイルを別名で書き込み、書き込みの完了を待ち、読み取り可能であることを検証してから、使用可能としてマークします。この確認が済む前に、唯一の有効なチェックポイントを置き換えないでください。頻度は、やり直すことを許容できる作業量と、観測された書き込み時間に依存します。レンタル時間だけから導き出せるものではありません。
ミニプロジェクトは、イテレーションが完了した後に保存し、その後ファイルとそのハッシュをエクスポートします。各実行ごとに新しいフォルダを使用し、以前の証跡を上書きしません。トレーニングで GradScaler を使用した混合精度を採用している場合、その状態も再開の対象に含まれます。このバリアントは CPU 演習では扱いません。
比較とその許容範囲を読む
プロトコルは、ポイント5以降の継続を比較します。消費されたデータ、学習率、損失、到達したパラメーターです。ステップ番号だけの一致では十分ではありません。リセットされたオプティマイザーはループを続行しても、異なる更新を生成する可能性があります。
この演習で選択された許容範囲は絶対値です：1e-12、相対許容範囲は0です。このしきい値は提供された CPU プロトコルの一部であり、モデル全般に適用される普遍的なルールではありません。比較は、非有限値や構造の違いを検出する必要があり、利用不可能な出力を黙って受け入れてはなりません。
PyTorch は、バージョン、プラットフォーム、CPU と GPU 間での結果の同一性を保証しません。この演習を移植する場合は、ターゲット上で証跡をやり直し、採用した許容範囲を説明してください。原因を理解していない失敗を消すためだけに、しきい値を広げないでください。
提供された証跡では、完全な実行のすべての差がゼロです：パラメーター、オプティマイザーの状態、損失、学習率、MSE。行の順序、進行状況、スケジューラの状態、次の抽選も一致しています。ステップ10以降の次の学習率は、両方の実行で0.00375です。したがって、結果は中間の違いを覆い隠す可能性のある最終的な単一の指標だけに依存するものではありません。
表をスクロールしてすべての列を表示してください。| 比較 | 完全再開 | RNG 復元なしの再開 |
|---|---|---|
| 重みの最大差 | 0 | 0,011669328447718508 |
| 最終 MSE | 0,09538858591775097 | 0,0936034144665111 |
| 連続実行に対する MSE の差 | 0 | 0,001785171451239867 |
| 一致サブテストの判定 | 1e-12 の許容範囲内で一致 | 発散を検出 |
乱数復元なしのネガティブケースを保持する理由
どのエラーを検出するか分かっていると、検証はより有用になります。ネガティブバリアントは、同じ重み、オプティマイザー状態、スケジューラ、進行状況を再ロードしますが、RNG の復元を意図的に省略します。プロセスは Python 例外なしで終了しても、別の軌跡をたどる可能性があります。
提示された検証では、この省略により重みの最大差が0.011を超え、MSEの差が0.0017を超えます。ここでの負のMSEは連続経路のものより低いですが、それは再開が正しいことを意味しません。目的は同じ実験を再現することであり、2つのモデルを最終的な誤差で順位付けすることではありません。
検証ツールは、完全な実行が一致し、ネガティブケースが発散した場合にのみ成功します。そのとき all_checks_passed: true、positive: true、negative_divergence_detected: true を表示します。終了コードは、プロトコル成功時が0、比較失敗時が1、検証を完了できなかった場合が2です。
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incomplete保護を緩めずに演習のファイルをロードする
このプロジェクトは、この演習で作成し、あなたの管理下に置かれたチェックポイントのみをロードします。明示的に torch.load(..., map_location="cpu", weights_only=True) を使用します。Python の状態にはプリミティブ、NumPy PCG64 ジェネレーターの状態には整数と文字列、PyTorch CPU の状態にはバイトテンソルが含まれます。任意の NumPy 配列は、保存された RNG 状態に含まれません。
ローダーは、関連付けられたフィンガープリント、サイズ、スキーマ、進行状況、バージョン、およびコードとデータの同一性を検証します。欠落した要素を黙ってリセットするのではなく、矛盾した状態を拒否します。フィンガープリントは変更を検出しますが、ファイルの送信者を認証するものではありません。
読み込みエラーを黙らせるためだけに weights_only=False を追加しないでください。保存されたフォーマットとその再構築は一貫している必要があります。制限付き読み込みはデシリアライズの可能性を減らしますが、未知のファイルを信頼できるものにするわけではありません。
分散トレーニングで変わること
複数のプロセスや GPU 間に分散した状態を使用する場合は、誰が何を書き込むかを確認してください。単一のプロセスが生成したファイルは、必ずしも分散作業の完全なバックアップではありません。戦略で定められたバックアップ手順を使用し、対象の参加者上でその完了を待ってください。同じ再開ポイントに属する断片を明確に識別してください。
GPU 数の変更は状態の再分散を必要とし、データの配分を変える可能性があります。分散チェックポイントの仕組みは一部の変更に対応できますが、その可否はお使いのフォーマットと構成で確認する必要があります。予定されたターゲット上で読み込みテストを行ってください。注文にバッチを追加しても、シングルカードのバックアップが自動的に分散プログラムに変わるわけではありません。
実際に復元可能なエクスポートで締めくくる
期限前に、設定、メトリクス、読み込み手順、データ識別子とともに有用なチェックポイントをエクスポートしてください。コピーしたファイルのサイズとフィンガープリントを検証し、少なくとも 1 つのバックアップをその保存先から読み込んでください。同一のフィンガープリントはコピーを検証しますが、再読み込みはその内容が実際に作業を再構築するのに十分かどうかを検証します。
出所がわかっているファイルのみを読み込み、フォーマットとデシリアライズオプションを適切に選択してください。新しい再開ポイントが検証を通過するまでは、最後に検証済みの再開ポイントを保持してください。期待される成果物は、復元可能なフォルダと短い再開の証拠です：実行したコマンド、復元したステップ、成功したチェック、エクスポートした結果。この時間を 3 日、7 日、または 30 日の期間に組み込んでください。
証拠の範囲とレンタルの選択
2026年9月24日の検証は、CPU上の4つの新規プロセスを比較し、絶対許容誤差1e-12、相対許容誤差なしとしています。CUDA、ROCm、AMP、分散学習、データ読み込みワーカーはいずれも対象外です。この検証は、記載された環境において提供バージョンの再開ロジックを検証するものであり、レンタルしたGPUの性能を測定するものではありません。
この小さな演習の後、同じプロトコルを自分のモデル、データ、バックエンドに適用してください。80 GB のカードや 192 GB のカードは不完全なチェックポイントを修正しません：まず互換性のあるチェーンを選択し、次に実際のステップのメモリを見積もってください。以下にリンクされたプランは、この証拠のためにテストされたハードウェアとして提示されているものではありません。
3 日、7 日、または 30 日の期間に、最初のバックアップ・停止・再開サイクルと最終エクスポートの時間を組み込んでください。有用な成果物は、バージョン、再開ポイント、比較チェック、および制限を説明できるフォルダです。.pt ファイルが存在するだけでは、この保証は得られません。