1つのファイル内の5つの領域

フォーマット

すべての step_NNNNNN.bin は、5つの連続した領域を格納しています：

[int32 step] [int32 n_params] [n_params x float32 weights] [n_params x float32 m] [n_params x float32 v]

領域ごと

ヘッダー（合計8バイト）。 32ビットのステップ番号が、このスナップショットがトレーニングのどの位置にあるかを示します。32ビットのパラメータ数が、後続の3つの配列のそれぞれのサイズを示します。

重み（n_params x 4バイト）。 すべての学習済みパラメータをフラットに。順序はモデルのパラメータイテレータと一致：トークン＆位置埋め込み、次に層ごとの注意機構＆MLP重み、最後に出力ヘッド。

Adamの第一モーメント m（n_params x 4バイト）。 過去の勾配のEMA（beta1 = 0.9）。重みと同じ形状。AdamWの再開に必要。

Adamの第2モーメントv（n_params x 4バイト）。 過去の二乗勾配のEMA（beta2 = 0.999）。重みと同じ形状。AdamW再開に必要。

合計サイズ

総バイト数 = 8 + 12 x n_params。ANDREA-12M（12.8M params）：ディスク上154 MB（147 MB丸め）。ANDREA-120M（~120M params）FP32：~1.44 GB。同一形状の3つの配列を背中合わせに積み重ね、小さなヘッダー付き。

m & vを保存する理由

Vanilla Adamはm & v経由でパラメータごとの学習率を追跡。チェックポイント書き込み時にこれらを落とすと、再開実行はゼロモーメンタム＆ゼロ分散推定から開始し、1ステップ学習率0に等しくその後急激にランプアップ。損失がスパイクし、モデルが現在のバシンから落ちる可能性。m & vを保存することで、再開が（データローダー乱数以外）ビット等価（never-stoppedベースラインと同等）になる。

1つのチェックポイントのサイズ計算

SIGTERM & SIGUSR1

CUDAがシグナルを扱う理由

トレーニングは長時間稼働するフォアグラウンドプロセスとして実行されます。プロキシやオペレーターがGPUを停止させたい場合、CUDAエンジンにシグナルが送信されます。ハンドラーがない場合、デフォルトのSIGTERMがプロセスを即座に終了させます：進行中の勾配計算が破棄され、最後のチェックポイント以降の最新ウェイトが失われます。ハンドラーがある場合、エンジンはまずチェックポイントを書き込み、その後クリーンに終了します。

SIGTERM: 書き込み & 終了

停止ボタン、systemctl stop、または親プロキシからのkillによって送信されます。CUDAは現在のステップを完了させ、step_NNNNNN.binをディスクに書き込み、その後終了します。この状態からの回復には最新の.binだけで十分です：飛行中の部分ステップを超えて失われる作業はゼロです。

SIGUSR1: 書き込み & 継続

オペレーターやプロキシスクリプトによって需要に応じて送信されます。CUDAは現在のステップを完了させ、step_NNNNNN.binを書き込み、その後何事もなかったかのようにトレーニングを継続します。有用な用途：設定変更直前に監査ポイントをトリガーする；既知の良好な時点でウェイトをキャプチャする；外部サンプル品質評価実行とチェックポイントを同期させる。

ポーランド式ピボットシーケンス (ステップ 112,619)

1. オペレーターがCUDAにSIGUSR1を送信。次の100ステップ境界 (ステップ 112,700) でチェックポイントが書き込まれます。

2. オペレーターがプロキシを停止します。

3. .samples.json & .state.json がアーカイブされます (サンプルログとバンディット状態が履歴記録として保存されます)。

4. .loss.json はその場に残ります。 累積トレーニング履歴; 決してアーカイブされません。

5. プロキシが新しい上限値 & 下限値で再起動します。

6. CUDAが step_112700.bin から再開します。新鮮なバンディットですが、完全な重み、m、& v で。

損失履歴はピボットを超えて途切れず継続します。サンプルログはクリーンにリセットされます。Banditは新しいポリシーのもとで新たにスタートします。

シグナルの選択

累積トレーニング履歴

3つのサイドカーファイル

すべてのチェックポイントと一緒に、プロキシは実行ディレクトリに3つのJSONサイドカーを維持します：

- .loss.json -- ステップごとのエントリ、常に。実行終了時には約200,000エントリ。累積トレーニング履歴。

- .samples.json -- 監査のための最近生成されたサンプル。polish pivotsでリセット。

- .state.json -- bandit arm pulls、EMA rewards、phase counters。polish pivotsでリセット。

何がリセットされ、何が持続するか

ポーランド語ピボットはポリシーの変更であり、リセットではありません。モデルの重み、m、v、および損失履歴はすべて途切れなく継続します。バンディットの蓄積報酬は継続しません：新しいキャップとフロアが異なるポリシーを定義し、バンディットは新しいポリシーの下でクリーンな状態から再学習する必要があります。

.loss.json が残る理由

損失履歴は実行の監査証跡として機能します。ANDREA-120M に関するすべての公開された主張（ステップ 110K での損失 EMA、ポーランド語ピボットの回復、ステップ 112K での収束）は、このファイルのエントリに遡ります。フェーズ間で .loss.json をアーカイブすると、読者が断片を縫い合わせて実行を再構築する必要が生じます。append-only でそのままにしておくことで、来歴が保持されます。

ゾンビアームの教訓

ステップ 112,619 で .state.json に prior run から重み 1.546 を運ぶ repo-docstrings アームが見つかりました。バンディット状態は以前のリスタートを跨いで保持されていましたが、データソースが利用できなくなり、探索会計を歪めるゾンビプルが発生しました。教訓：バンディット状態はリスタートを跨いで驚くべき方法でドリフトが許容されます。損失履歴は実行の全寿命にわたり変更せず残す必要がある唯一のファイルです。

これらすべてを統べる唯一のルール

.samples.json と .state.json はフェーズ間で自由にアーカイブしてください。.loss.json は決してアーカイブしないでください。最新の .loss.json が常に正準的なトレーニング履歴です。

ルールの適用

何が構築され、なぜか

5つの決定

1. Cadence: 100ステップごと。 回復ポイントの粒度 ~17分。sample_every に合わせ、すべてのチェックポイントが1つの新鮮なサンプル監査に対応。

2. Format: ヘッダー + 3つの配列。 最小限: 8バイトのヘッダーが後続する各配列のサイズを教えてくれる。メタデータ膨張なし。m & v が保存されるとビット等価で再開。

3. Signals: SIGTERM & SIGUSR1。 2つの役割、2つのシグナル。デフォルトのsystemdシャットダウンはSIGTERMでクリーンなチェックポイントを取得；オンデマンド監査ポイントは停止せずにSIGUSR1でクリーンなチェックポイントを取得。

4. Loss continuity: 決してアーカイブされない。 累積トレーニング履歴は、polishピボット、再起動、ポリシー変更を越えて持続。一つの監査トレイルが全体の実行をカバー。

5. Bandit state: リセット許可。 Banditポリシーは一度に1つのコンフィグの下で存在。Polishピボットでリセット；損失履歴は継続。2つの異なる寿命が同じ実行ディレクトリを共有。

このレッスンがつながるもの

- Activity 23 (grow_a_language_model_sample_audit). sample_every の頻度が checkpoint の頻度と一致；両方とも 100 ステップごとに発火。

- Activity 24 (grow_a_language_model_microgpt_to_andrea). v1 collapse、v2.5 patch、v3 polish pivot すべてクリーンなチェックポイントを必要とする。

- Activity 10 (grow_a_language_model_adamw). チェックポイントに m と v を保存することが重要。AdamW の更新ルールは両方に依存するため、削除して再開すると発散する。

最後のエンジニアリングの真実

コードは作者を生き延びる。インフラは構築者を生き延びる。シンプルなチェックポイント形式は、オプティマイザ状態の保存をスキップすると約束したあらゆる凝った再開スキームを生き延びる。バイトを保存せよ；実行を保存せよ。

何を構築しますか？