# AI訓練ログデバッグ ## 定義 AI 訓練ログデバッグとは、大規模・長時間実行される機械学習(ML)訓練ジョブのシステム層(PyTorch・データリーダー・チェックポイント・ハードウェア等)とモデル層(入出力テンソル・学習率・内部状態・勾配等)から高スループットに収集した**ログ**を用いて、訓練失敗やモデル収束問題をデバッグする取り組みである。訓練ジョブは失敗を再現するコストが高い(GPU リソースの浪費、非決定性)ため、追加ロギングによる事後再現でなく、実行中に継続的にシステム・モデルのテレメトリと状態をログとして捕捉しておくことが要となる。ログはメトリクス・リレーショナルテーブル・トレースに比べて書き込みコストが低く、高スループットな詳細記録に向く点がこのアプローチの前提になる。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) 分散訓練特有の課題として、単一プログラム・複数データ(SPMD)の性質上、全 rank が同じコードでデータバッチを反復するため、ある rank だけが異なるログ行(追加行・欠落行)を出すことが障害の症状または根本原因の手がかりになる。しかし複数 [[PyTorch]] rank の出力が単一ログファイルに多重化されると rank の区別がつかなくなり、これが log-based デバッグの中心的な難所になる。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) ## 横断的知見 - **rank ID のメタデータ付与は、ソースコード改変を要する計装(FSDP のアクティベーションチェックポイント等)とは異なる「後付け可能な」アプローチである**: [[Logarithm]] はロギング API 層でスレッドローカルコンテキストに rank ID を注入し [[glog]] ハンドラにアタッチすることで、サードパーティコードを含む全ロギング箇所を改変せずに rank 情報を付与する。[[LLM学習モニタリング]] で蓄積してきた検知信号(ハートビート・ホストメトリクス・トラフィック・CCL 内部状態等)がいずれも専用の計装追加(侵入的)か非侵入のフレームワーク/カーネルフック(uprobe・ioctl 傍受)を要するのに対し、ログベースの rank 付与は「既存のログ出力の意味だけを後から拡張する」という、計装の挿入点としてより軽量な選択肢を提供する。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) - **モデルテレメトリの「ログとして書く」設計は、GPU/ハードウェア中心の観測性(GPU観測性)とは異なるレイヤーを覆う**: [[GPU観測性]] が蓄積してきた計装(CUPTI・eBPF・PTX 注入等)はカーネル実行やメモリ転送といったハードウェア層の挙動を可視化するのに対し、Logarithm のモデルテレメトリはモデル入出力テンソル・内部状態・勾配といったモデル層の状態を、型付きキー・バリュー対としてログのメタデータに書き込む。両者は「GPU が何をしているか」と「モデルが何を学習しているか」という異なる問いに答え、収集手段(ハードウェアカウンタ/計装 vs ログ)も異なるが、いずれも訓練ジョブの継続的な状態把握という同じ目的に資する。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) - **可視化ダッシュボードの要求粒度が、クエリ API のブロッキング/非ブロッキング設計を規定する**: TensorBoard が 722 系列・45 万サンプルを対話的レイテンシで描画する要求に対し、Logarithm はソート済み一括返却(ブロッキング)でなくランダム順序のストリーミング API(非ブロッキング)を採用し、インクリメンタル並列描画を可能にした。これは [[ログ解析]] が整理する「情報を絞ってから推論・描画する」骨格とは逆方向で、ログ解析の下流タスクが「絞り込んでから深く見る」のに対し、訓練ダッシュボードは「広く浅く、速く返す」ことを優先する設計選択であり、ログ活用の目的(診断 vs 監視ダッシュボード)によって最適なクエリ設計が分かれることを示す。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) ## 未解決の問い - rank ID メタデータによる log-based デバッグと、[[LLM学習モニタリング]] が蓄積するマシン単位の障害検知(Minder・Pulse 等)は、同じ訓練クラスタの信頼性問題をどう分担するのか。前者は「どの rank が異常な挙動を示したか」を人間がログを読んで特定する事後的・対話的な手段であり、後者は自動検知・自動局所化を志向する。両者を統合し、自動検知が示した異常 rank に対して自動的に関連ログをスコープする(→ [[ログ解析]] の log scoping)パイプラインは構築可能か。 - Logarithm のモデルテレメトリ(テンソル時系列)と、[[GPU観測性]] が蓄積するハードウェア層の計装(カーネル実行・メモリ転送)を同一のタイムラインで相関させる仕組みは、本ソースからは読めない。モデル層とハードウェア層を跨いだ障害("勾配爆発がどのカーネルの数値不安定性に起因するか"等)の診断には、両者の時刻同期・相関がどこまで必要か。 - 高スループットなモデルテレメトリのログ化(型付きキー・バリュー対の書き込み)は、[[ログ解析]] が指摘する「ログイベント削減」(anti-event・duplicative-event の除去)の対象になりうるか。モデルテレメトリは訓練の全期間にわたり継続的に書かれるため、下流の診断に不要な冗長テレメトリを源流で削減する余地はどれだけあるか。 ## 関連 - ソース: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]] - エンティティ: [[Logarithm]] / [[PyTorch]] / [[TensorBoard]] / [[glog]] / [[Meta]] - 概念: [[GPU観測性]] / [[LLM学習モニタリング]] / [[ログ解析]] / [[テレメトリ]] / [[オブザーバビリティ]] ## 出典 - [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]](「AI training debugging with Logarithm」節: rank ID メタデータ API・filter-by-call-site・side-by-side ランク比較・モデルテレメトリ・TensorBoard ストリーミング API)