計算を開始する前に仮説を書く
改善すべき挙動を記述しましょう。ある分野の文書の分類、回答フォーマットの遵守、構造化情報の抽出などです。同時に、悪化させてはならない点も定めましょう。抽出の場合、フォーマットの妥当性や必須フィールドの存在がそれにあたります。分類の場合、単一の全体平均ではなく、カテゴリごとのメトリクスがそれにあたります。
まず、学習データから分離したデータセットで初期モデルを評価しましょう。この評価の出力と設定を保管してください。そうすれば、適応を具体的な出発点と比較でき、一部の例に限定された改善を特定できます。最終テストデータは取っておきましょう。すべての調整を順に選ぶためにそれを使うと、やがてその制御としての価値が損なわれます。
データとその分割を準備する
例、クリーニング規則、変換をバージョン管理しましょう。学習と評価の間の重複を探し、プログラムの正確な前処理後に小さなサンプルを検査しましょう。テキストの場合、トークナイザー、区切り文字、切り捨て、および損失が計算される位置を確認しましょう。画像の場合、次元とカテゴリに適用される変換を確認しましょう。
準備の例：各カテゴリから代表的なサンプルをいくつか選び、変換後の形状を表示し、期待されるターゲットを手動で確認します。その後、学習ループと評価を一通り実行します。この方法はデータや配線の誤りを探すためのものであり、モデルの最終的な品質について結論を出すことはできません。
学習するパラメータを選択する
完全なファインチューニングは、モデルが想定するすべてのパラメータを更新します。LoRAのような手法は、ベースの重みを保持し、選択したモジュール内で低ランクの追加行列を学習します。この選択は学習可能なパラメータの数を減らしますが、ベースモデルを読み込み、その活性化を処理する必要性はなくなりません。
対象とするモジュール、学習可能なパラメータ、および保存される追加層があればそれを記録しましょう。LoRAの場合、ランクは比較すべき設定の一部であり、それだけで品質を予測できるものではありません。更新が実際に想定されるパラメータを変更することを最初から確認しましょう。エクスポート時、アダプターはベースモデルとその正確なバージョンに関連付けられたままにしておく必要があります。
完全な学習ステップのサイズを見積もる
損失計算、逆伝播、オプティマイザの更新を含むステップを検証します。ロード中にメモリに収まっていたモデルでも、このステップ中に利用可能な容量を超えることがあります。代表的な入力長とマイクロバッチで測定してください。精度、オプティマイザの状態、および実際に学習されるパラメータも見積もりに含まれます。
勾配蓄積により、複数のマイクロバッチから1回の更新を構成できます。その数と損失の正規化を記録してください。アクティベーションチェックポイントは、一部の追加計算と引き換えに保持するアクティベーションを減らします。これらを組み合わせる前に、個別に確認してください。実験の進行の仕方が変わるため、結果のドキュメントに記載する必要があります。
CUDA、ROCm、分散をプロトコルに含める
モデル、拡張、適応手法が選択したバックエンドと互換性があるか確認します。NVIDIAではCUDAチェーンを、AMDではROCmチェーンを準備します。プラットフォームを変更すると、起動と品質の確認をやり直す必要があります。同じ名前の環境が同じ実行をもたらすと仮定せず、実際に使用したバージョンを保持してください。
DistributedDataParallelでは、各プロセスがモデルのレプリカで動作し、勾配が同期されます。この戦略はGPUメモリ間で重みを自動的に共有しません。データの分散も設定する必要があります。より大きな状態を収めることが目的であれば、その状態を分散する戦略を検討し、バッチ数を増やす前にその制約を確認してください。
バリアントと最終決定を整理する
各実験に識別子を付け、説明可能なパラメータのセットだけを変更してください。バリアント間で同じ評価手順を維持し、シード、トレーニング予算、使用するデータを揃えましょう。中断された試行や無効な試行も記録してください。説明なく除外すると、比較の解釈が難しくなります。
3日、7日、または30日のレンタルを、初期確認、実験、評価、再開、エクスポートといった明確なフェーズを中心に計画します。新しいプロセスでチェックポイントを再読み込みするための余裕を確保してください。最後に、モデルまたはアダプタ、その設定、比較結果、および観察された制限を納品します。処理内容の選択はあなたが自律的に行います。Kernodeckがその内容を検査することはありません。