7. コスト、トラブルシューティング、受け入れ基準¶
この章は順番に読む必要はありません。マシンを起動する前に 7.1 節を読んで予算を見積もり、エラーに遭遇したら 7.2 節を調べ、すべて終わったら 7.3 節と照らし合わせて確認してください。
7.1 まず速度を測ってからコストを見積もる¶
まずプロバイダーの時間単価、ストレージ料金、インスタンス停止後の課金ルールを確認してから、この実験の予算を決めます。以下の計算では仮の単価として 1 時間あたり US$0.74 を使っています。実際の価格は、インスタンス作成時に提示される金額に従ってください。
GPU 费用 = 小时单价 × 开机计费时长
总成本 = GPU 费用 + 存储 + 其他服务 + 数据制作/审核投入
训练时间估算 ≈ 预热后每个 optimizer step 耗时 × 预计更新步数
（訳：GPU 費用 = 時間単価 × 課金対象の稼働時間、総コスト = GPU 費用 + ストレージ + その他のサービス + データ作成/レビューの工数、推定学習時間 ≈ ウォームアップ後のオプティマイザーステップ 1 回あたりの所要時間 × 想定される更新ステップ数。）
メインパス（環境構築、ダウンロード、1 エポックの学習、マージ、デプロイ、負荷テスト）にはマシン稼働時間で 2～3 時間かかる見込みです。第 6 章の比較実験とレビューを加えると 10～20 時間かかることがあります。例の単価では、それぞれおよそ US$1.5～2.2 と US$7.4～14.8 です。実際には、セットアップ、転送、アイドル、ストレージのコストも計上する必要があります。
ノートブックの training-complete.json（CLI では metrics-step-N.json）には、学習時間と、allocated/reserved の VRAM のピーク値が記録されます。PyTorch の統計には他のプロセスやドライバーのオーバーヘッドすべては含まれないので、nvidia-smi や請求書と照らし合わせてください。実測した時間で予算を更新しましょう。
7.2 トラブルシューティング表¶
| 症状 | まず確認すること | やってはいけないこと |
|---|---|---|
| CUDA unavailable | ホスト、ドライバー、Torch の wheel、現在の仮想環境 | Mac に CUDA を何度も再インストールする |
| Python モジュールが見つからない | Python のパス、有効化している環境、インストール結果 | 複数の環境でライブラリを手当たり次第にアップグレードする |
| トークナイザーは動くがモデルが失敗する | トークナイザーだけをダウンロードしていないか、重みがそろっているか | いつも VRAM 不足だと決めつける |
| 長さの上限を超える | ファクト、履歴、ターゲットのトークン長 | 参考回答を黙って切り詰める |
| loss は低いが結果が悪い | ターゲットの漏洩、ほぼ重複したデータ、実際に読み込まれているアダプター | エポックを増やすだけ |
| loss が下がらない | マスク、学習対象パラメータ、学習率、データ | すぐに GPU を替える |
| 思考やロールのマーカーが出力される | モデルのバリアント、テンプレート、学習ターゲット、停止トークン | バックエンドで特殊なテキストを闇雲に削除する |
| 繰り返す/止まらない | EOS の教師信号、重複データ、過学習、出力上限 | 繰り返された文をフィルタで除くだけ |
| OOM | 他のプロセス、長さ、バッチ、KV キャッシュ、量子化 | RAM を VRAM と同等とみなす |
| 再開が拒否される | データ/コード/環境/モデルが変わっていないか | manifest のチェックを回避する |
| 作り話が増える | フィクションが事実として書かれていないか、誠実に応答するサンプルが不足していないか | 面白さのスコアで事実の誤りを覆い隠す |
| マージ後に劣化する | リビジョン、量子化していないベースモデル、テンプレート、精度 | NF4/BF16 の差をすべて LoRA のせいにする |
| API がタイムアウトする | サービスの正常性、モデルの読み込み、コンテキスト、同時実行数、ログ | 際限なくリトライする |
| API が 400 を返す | 入力 + max_tokens が --max-model-len を超えていないか、model の名前が /v1/models と一致しているか |
同じリクエストをリトライし続ける |
| 負荷テスト中にレイテンシが急増する | 同時実行数が --max-num-seqs を超えていないか、KV キャッシュが満杯でないか（/metrics とログを確認） |
キューイングを見ずに平均値だけを見る |
| vLLM が起動しない | 推論環境、ドライバー、モデルディレクトリ、他のプロセスによる GPU の使用 | 学習環境の依存関係を上書きする |
7.3 最終学習チェックリスト¶
- このプロジェクトが SFT+QLoRA を使う理由を説明できる。
- 1 つのサンプルの完全なコンテキストと、実際の教師ターゲットを示せる。
- 1 エポックの学習を完了し、loss 曲線を読み取り、完了記録を確認し、アダプターを保存して再読み込みした。
- 学習中の VRAM の内訳を挙げ、
nvidia-smiの数値と対応づけられる。 - 4.6 節の小さなサンプルでの過学習と、チェックポイントからの再開の演習を完了した。
- 1 エポックの学習と 1 回の rank 比較を完了し、再確認できるチェックリストを保存した。
- 学習中の性能、検証結果、凍結後のテスト結果を区別できる。
- 改善、退行、または「不確か」を報告し、根拠の限界を説明できる。
- マージ、エクスポート、vLLM の起動を行い、マルチターンとストリーミングの呼び出しができる。
- KV キャッシュの容量を見積もって vLLM の起動ログと比較でき、
--gpu-memory-utilization、--max-model-len、--max-num-seqsを説明できる。 - アダプターをマウントして同じサービス内でベースモデルと LoRA を比較でき、マージ済みデプロイとのトレードオフを説明できる。
- 異なる同時実行数で負荷テストを行い、TTFT、TPOT、スループットの表を埋め、スループットとレイテンシのトレードオフを説明できる。
プロンプトのベースラインに対する LoRA の改善または退行を記録し、他の人が再確認できるようにデータと出力を添付してください。