[System@Scale: AI Observability | At Scale Conferences](https://atscaleconference.com/systemscale-ai-observability/) ![[Pasted image 20240808110513.png|600]] 1. 私たちの観測可能性をサポートするレイヤーは、ベアメタルの遠隔測定とモニタリングです。 このレイヤーは、アプリケーションによって達成されたパフォーマンス・レベルを推定するために使用できるベアメタル・メトリクスを収集することを可能にし、さらに、リソース利用率を集約するすべてのデータセットを構築します。 2. 次に、高度な性能イントロスペクションに使用できるツールのセットがあります。 [[Pytorch Profiler]]やKineto、[[Strobelight]]/[[eBPF|BPF]]などのツールは、アプリケーションをトレースしてボトルネックや様々な問題（例えばメモリリーク）を特定するために使われます。 3. 第3のレイヤーは、パフォーマンス・イントロスペクションのスケールアウトに向かう。 メタスケールでは、毎日実行される数万のジョブ、数百のモデル、数千のMLエンジニアがいます。 一方、AIパフォーマンスの専門家の数は桁違いに少ない。 そこで、Meta Performance Profiling/Analysis Platformのようなツールを用いて、様々なプロファイリングツールからプロファイリングデータを収集・集約し、ハードウェアレベルの利用率やジョブレベルのパフォーマンスメトリクスを収集することを目指します。 さらに、Meta Performance Profiling/Analysis Platformは、収集したデータを分析し、主なパフォーマンス問題を指摘するプロセスを自動化します。 よく見られるアンチパターンはこのレイヤーで強調表示されるため、AIパフォーマンスの専門家はより複雑なユースケースに集中することができます。 4. 最後に、第4のレイヤーは、フリート全体のレベルで生成されたデータセットを使用して、最適化作業の指針となるダッシュボード／可視化を構築し、インフラとソフトウェアツールの構築方法に関する意思決定プロセスをサポートすることを目的としている。 # 1. Monitoring & Telemetry [[Dynolog]]は、すべてのMetaのホスト上で動作する分散型テレメトリーデーモンである。これは、いくつかの重要な役割を果たす。 - ホスト/プロセスレベルでシステム・テレメトリーを収集する。 - ワークロードのメタデータを収集し、適切なワークロードの所有者にリソースの使用状況を報告する。 - また、ロードバランシングやオートスケーリングなどのユースケースをサポートするリアルタイムのテレメトリクエリ用のサーバーとしても機能する。 - ホスト上のテレメトリツールの司会者として、リモートからのオンデマンドのユーザーリクエストとやりとりする。 - multiple data sinks (real-time ODS, Scuba, and Hive) ![[Pasted image 20240821235233.png|600]] ## Topline Efficiency Metrics | | | | | | | | ------------------------ | ------------------------------------------ | --------------------------------- | ---------------------------------- | ---------------------------------- | ---------------------------------- | | **Metrics** | **Correlation to Model Complexity Growth** | **Correlation to HW generations** | **Correlation to efficiency work** | **Create bad modeling incentives** | **Collection technical challenge** | | FLOPs/sec | High | High | High | Yes | Average | | Compute Unit Utilization | Medium | Medium | Non-linear | No | Low | | Device Power | Medium | Medium | High | No | Low | | Device Utilization | Low | Low | Medium | Yes | Low | | rDevice hour / Byte | High | Medium | High | No | Average | | % of Roofline | Low | Low | High | No | Difficult | このグラフは、FLOPs/secが、実現可能な実装上の課題を提示しながらも、モデルの効率と複雑さ、およびHW世代と最も相関していることを示しています。 私たちは、FLOPs/sec の悪いモデルインセンティブを緩和するために、FLOPs/sec を計算利用率および消費電力とともにトップラインの効率指標として使用しています。 Nvidia GPU を例として、私たちは DCGM を活用して、デバイスの消費電力、GPU-デバイスレベル、SM レベル、SM 内のワープレベルの性能信号を収集し、ヒューリスティックな推定に基づいて FLOPs/sec を導出しています。 これらのシグナルは、3 つのレイヤーの粒度を通してワークロード性能の包括的なビューを提供し、非常に低いオーバーヘッドでフリートレベルで継続的に収集されるため、フリート性能の包括的な基礎画像を提供します。 上のチャートには、あまり知られていない 2 つのメトリクスも表示されています。 ひとつはrDevice hour/Byteである。 これは、入力1バイトあたりの計算時間量を測定しようとする派生指標である。この指標を用いて、効率化の努力とよく相関するが、悪いモデリングの誘因を作らないような、正規化されたコスト指標を決定しようとしている。 例えば、FLOPs/secは、MLエンジニアが高いFLOPs/secの使用量を示すために線形レイヤーの数やサイズを増やすように誘惑するかもしれませんが、これはモデルの品質を向上させるための最良の方法ではないかもしれません。 あるワークフローのパフォーマンスを評価するための最良の指標は、そのルーフラインパフォーマンスのパーセンテージです。 これはより高度な指標であり、デバイスタイムラインをトラバースし、すべてのデバイスカーネルについて解析的なルーフラインモデルを記述し、カーネル間のアイドル時間を大幅に短縮すると仮定し、ルーフライン時間と実際の実行時間を比較する必要があります。 - FLOPs/sec Estimation - DCGM - NvidiaのDatacenter GPU Manager（DCGM）は、個々のALUの利用率を継続的に測定することができるため、各利用ユニットのピークスループットを乗算し、それらの合計を計算することで、FLOPs/秒を推定しています。 - CUPTI - CUDA Profiling Tools Interface（CUPTI）は、ハードウェア・カウンタとバイナリー・インスツルメンテーションの組み合わせを使用して、所定のワークロード反復の実行FLOPを収集するためのAPIを提供します。 これによってFLOPの正確な測定が可能になりますが、これを連続的またはフリートレベルで有効にすると、オーバーヘッドが大きくなります。 - Accuracy - CUPTI測定値をDCGM推定FLOPのベンチマーク・リファレンスとして使用したところ、DCGMによる測定値よりも10%未満高い結果が得られました。 この不正確さは、主に 3 つの要因に起因しています。 FP16 および FP32 のパイプライン使用率メトリクスは、整数命令のサブ セットを実行すると増加します。 パイプライン使用率メトリクスは、ビジーサイクル数のみを測定します が、浮動小数点命令は、ADD 命令、MUL 命令、および FMA 命令の間でレイテンシが類似しています。 テンソ ルコア命令には複数のプリシジョンがあり、ヒューリスティッ クに依存して特定のフォーマットを想定しています。DCGMからのヒューリスティック推定に基づいて、無視できるオーバーヘッドと妥当な精度で、フリートレベルでFLOPs/秒を収集することができます。 # 2. Automated Performance Introspection & Debugging ## End-to-End Profiling システムのパフォーマンスは、スタックの異なるレイヤー間の相互作用の結果である。 Metaでは、これらのレイヤー間のパフォーマンスと相互作用を理解するために様々なツールを使用しています。 例えば、ワークフローは、データを取得するためにネットワーク上でコールを行い、ホスト（CPU）上でいくつかの処理を行い、デバイス（GPU）上のカーネルを呼び出すかもしれません。 システム性能の全体像を把握するために、ネットワーク呼び出しに費やされた時間、CPU処理、デバイス上の呼び出しのキューイング、デバイス上での実際の実行開始時間と終了時間を把握したい。 このデータを使用して、ボトルネックを特定し、非効率性を理解し、改善の機会を特定することができます。 - Kineto - PyTorch Profiler - Strobelight - StrobelightはMetaの全フリートホスト上で動作するデーモンであり、プロファイラとプロファイラオーケストレーションツールの両方の役割を果たす。 Strobelightは複数のサブプロファイラで構成されています。 これらのサブプロファイラを通じて、フリート内のあらゆるホストからCPUスタックトレース、メモリスナップショット、Pythonスタックトレースなど、さまざまなパフォーマンスプロファイルを収集する機能を備えています。Strobelightは多くのサブプロファイラでeBPF（または単にBPF）に依存しています。そして最近、Strobelightのプロファイラ・スイートにBPFベースのCPU -> GPUプロファイラを追加しました。 - ![[Pasted image 20240822000149.png]] ## Using BPF for performance profiling AI/ML **workloads** - Gpusnoop - GpusnoopはStrobelightがサポートするBPFベースのプロファイラ・スイートです。 cudaカーネル起動、cuda同期イベント、cudaメモリイベントなど、さまざまな興味深いGPUイベントにフックできます。 また、PyTorchメモリイベントのプロファイリングもサポートしています。 ### Use Case: Profiling cuda memory allocations using BPF ### Automated Trace **Collection** # 3. Meta Performance Profiling/Analysis Platform Meta Performance Profiling/Analysis Platformは、MetaにおけるAIワークロードのパフォーマンス・プロファイリング、分析、洞察、アクションのための自動化されたワンストップ・ショップのセルフサービス・プラットフォームです。 サービスとしてのプロファイリングというアイデアから始まり、使いやすさを重視したプラットフォームへと進化しました。 Meta AIの開発環境と生産環境にシームレスに統合されています。 ![[Pasted image 20241001104035.png]] ## Example **Features** ### Auto-Profiling and On-Demand Profiling ### Auto-Analysis & Insights ### Trace-Based Fleet Level Workflow Characterization # 4. Fleet-Level Resource Attribution 効率化作業を導く上での課題の1つは、様々なエンティティごとにリソース使用量を帰属させることである。 これらは、ジョブ、ユーザー、モデル、製品、部門、アプリケーションタイプ、ベースフレームワークなど、さまざまな粒度を持つことができる。 このアトリビューションによって、最適化のために労力を投資する場所を決めることができる。 前のセクションで説明した基本的な遠隔測定を使って、最終的に下図のようなビューを示す一連のダッシュボードを構築した： ![[Pasted image 20240822001422.png]] 図は次のようになる： 選択されたインターバルの間、GPU時間数だけアプリケーションを実行します。 これらのGPU時間は、製品グループ、モデル、ユーザー、そして最終的にはジョブに分割されます。 例えば、GPU使用時間が多い特定のモデルを検出した場合、その使用状況を長期間にわたって時系列で観察することもできます。 GPU使用時間はインフラ運用コストと密接に結びついているため、このアトリビューションを使って、最もリソースを消費する部分に最適化の努力を投資することができます。 同様に、フレームワークの種類ごとにこの内訳を確認することもできます。 Metaでは複数のユースケースに対応しており、それらのユースケースに特化した特徴を持つソフトウェアスタックでは、特定の最適化が必要になります。 注意すべき重要な点は、フレームワークの改善は、すべてのジョブを高速化する可能性があるため、望ましいかもしれませんが、通常、フレームワークレベルの勝利は、一定の成熟度を超えると限界に達するということです。 対照的に、モデルは、その絶え間ない形状の変化により、常に大きな最適化の可能性を露呈する傾向がある。 場合によっては、モデルの最適化作業の方がフレームワークレベルの勝利よりもROIが高くなる。