## Memo ## Memo with LLM ### 論文情報 - **タイトル**: ProfInfer: An eBPF-based Fine-Grained LLM Inference Profiler - **著者**: Bohua Zou, Debayan Roy, Dhimankumar Yogesh Airao, Weihao Xu, Binqi Sun, Yutao Liu, Haibo Chen - **カンファレンス**: Machine Learning and Systems (MLSys 2026) - **発表年**: 2026年 ### 論文概要 ProfInferは、eBPF技術を基盤とした細粒度かつ非侵襲的なLLM推論エンジン向けプロファイリングフレームワークである。ソースコードの変更や再コンパイルを必要とせず、実行時関数に動的にプローブをアタッチし、オペレータレベルの可視性を提供する。4%未満のランタイムオーバーヘッドで、モバイル・エッジ環境におけるLLM推論の性能ボトルネックを診断可能にする。 ### 詳細解説 #### 問題設定 LLMの推論エンジン（特にllama.cppのようなシステム）は、ONNX Runtimeのような汎用エンジンとは異なり、オペレータレベルの可視性をほとんど提供しない。開発者はワークロードがメモリバウンドなのかコンピュートバウンドなのかという基本的な問いにすら答えられず、時間とリソースの消費状況を把握できない。既存のプロファイラは、ソースコードの再コンパイルが必要か、大きなオーバーヘッドを導入するかのいずれかであり、特にモバイル・エッジ環境での実用性に欠ける。 - **入力**: LLM推論エンジン（llama.cpp）の実行バイナリ - **出力**: トークンレベル、グラフレベル、オペレータレベル、スケジューラレベルのトレースデータと可視化結果 - **前提条件**: Linux系OS（Ubuntu、OpenHarmonyなど）が動作するデバイス上での実行 #### 提案手法 - **アーキテクチャ**: ProfInferはユーザ空間トレーサとカーネル空間ハンドラの2コンポーネントで構成される。ユーザ空間トレーサはBPFプログラムのコンパイル・起動、プローブのアタッチ、カーネルバッファからのデータ処理を担当する。カーネル空間ハンドラはタイムスタンプ、スレッドID、パフォーマンスカウンタデータを収集する。多粒度トレーシングとして4レベルのトレースを提供する：(1) トークンレベル：`llama_decode` へのuprobe/uretprobeによりTTFT（prefill段階）とTPOT（decoding段階）を計測、(2) グラフレベル：`ggml_backend_graph_compute_async` を用いたバックエンド固有の計算グラフの追跡、(3) オペレータレベル：MatMul、アテンション等の個別オペレーションをテンソル次元とともにプロファイル、(4) スケジューラレベル：カーネルトレースポイントによるスレッドスケジューリングの監視。 - **アルゴリズム/手法の詳細**: eBPFのuprobe/uretprobeを使用して、LLM推論エンジンのユーザ空間関数に動的にプローブをアタッチする。PMC（Performance Monitoring Counter）サポートとして、L3キャッシュリフィル、メモリアクセスパターン、CPUサイクルメトリクスを収集してボトルネックを特定する。MoEモデルに対しては、`ggml_compute_forward_mul_mat_id` へのuprobeをアタッチし、テンソル引数から活性化エキスパートのIDを読み取り、エキスパート再利用距離とオペレータ実行時間の相関を分析する。収集したトレースを3種類の可視化フォーマットに変換する：ProfDAG（DAGによる計算構造の可視化）、ProfTime（Chrome Trace Event FormatとPerfettoによるタイムライン表示）、ProfStat（トークン・オペレータタイプ・エキスパート活性化の統計分析）。 - **実装上の工夫**: 実装にはlibbpfとBCC（BPF Compiler Collection）の2フレームワークを活用する。BCCはPythonバインディングを提供し、Ubuntu上での高速なプロトタイピングに使用する。OpenHarmonyはデフォルトでPython環境をサポートしないため、libbpf（Cライブラリ）を使用して実装する。CPU、GPU、NPUバックエンド（Rockchip、ARM Mali、Adreno）をサポートする。 #### 新規性 既存のLLM推論プロファイリングツールはソースコードの変更・再コンパイルを必要とするか、大きなオーバーヘッドを導入する（llama.cpp組み込みの可視化ツールは13%のオーバーヘッドを発生させる）。ProfInferはeBPFの動的プロービング機能を活用することで、ソース変更なしにオペレータレベルの粒度でプロファイリングを実現する。さらに、ハードウェア性能カウンタ（PMC）をセマンティックなオペレータ情報と統合し、計算グラフのDAG可視化、タイムライン分析、統計分析の3種類の補完的な可視化形式を提供する点も新規性として挙げられる。モバイル・エッジ環境（OpenHarmony）への対応も特徴的である。 #### 実験設定 - **実験環境**: Orange Pi 5 Plus/Ultra（RK3588 SoC、OpenHarmony/Ubuntu）、RUBIK Pi 3（QCS6490、Ubuntu） - **データセット**: LLaMA3.2-1B、Qwen2.5-1.5B、Gemma2-2B、Qwen1.5-MoE-A2.7Bなどのモデルを使用 - **比較対象 (Baseline)**: llama.cppの組み込み可視化ツール（13%オーバーヘッド） - **評価指標**: デコード速度の劣化率（オーバーヘッド）、プロファイリングの忠実度 #### 実験結果 - **定量的評価**: ProfInferのオーバーヘッドは設定に応じて2.8%〜4.0%のデコード速度劣化にとどまり、llama.cpp組み込みツールの13%と比較して大幅に低い。libbpf版は機能を絞ることで1.7%という最低オーバーヘッドを達成する。LLM推論はintra-operatorパラレリズムのみを利用しており、MatMul演算がTTFTとTPOTの97%以上を占める。スレッド数を増加させると速度が劇的に向上するが、2スレッドが上限であり、それ以上ではストールサイクルが80%超に達する。コンテキストが成長するとKQ・KQVオペレータが実行時間増加に最も貢献する。MoEモデル（Qwen1.5-MoE-A2.7B）ではエキスパート再利用距離とオペレータ実行時間が相関し、メモリ帯域幅ではなくディスクI/Oがボトルネックであることが明らかになる。マルチバックエンド比較では、GPUへの選択的オフロードは特定テンソル次元でのみ有効であり、小行列ではCPUがGPUを上回る。 - **アブレーションスタディ**: libbpf版（最小機能）とBCC版（フル機能）のオーバーヘッドを比較することで、各機能コンポーネントがオーバーヘッドに与える影響を分析している。 - **定性的評価**: LLaMA3.2-1B、Qwen2.5-1.5B、Gemma2-2Bの3モデルを比較分析することで、セルフアテンション実装の違いやオペレータ実行シーケンスの差異を可視化している。 #### 考察 (Discussion) - **結果の解釈**: eBPFの動的プロービング機能により、ソースコードを変更せずにオペレータレベルの観測を実現できることが示された。PMCデータとセマンティック情報の統合により、ストールサイクルなど従来困難だったボトルネックの特定が可能になる。MoEモデルのエキスパートルーティング分析では、メモリに収まらないエキスパートのストレージからのフェッチがボトルネックになることが判明した。 - **優位性の根拠**: llama.cpp組み込みツールと比較して大幅に低いオーバーヘッド（4% vs 13%）を実現しつつ、より詳細なオペレータレベルの情報を提供する。ソース変更不要の非侵襲的アプローチにより、本番環境やリソース制約のあるモバイル・エッジデバイスへの展開が容易である。 - **限界と例外**: 現在はllama.cppに特化しており、他の推論エンジンへの拡張は将来課題として残されている。OpenCLトレーシングには外部プロファイリングツールが必要であり、完全な可視性を得るには追加ツールとの組み合わせが必要である。 #### 強み (Strengths) - ソースコードの変更・再コンパイルなしにオペレータレベルの細粒度プロファイリングを実現する点が最大の強みである - 4%未満という低オーバーヘッドにより、本番環境や資源制約のあるデバイスでの実用的な利用が可能である - ハードウェア性能カウンタとセマンティックなオペレータ情報の統合により、ストールサイクル等の複合的な性能分析が可能になる - DAG可視化、タイムライン、統計分析という3種類の補完的可視化により、異なる観点からの性能解析を支援する - MoEモデルのエキスパート活性化分析など、LLM固有のアーキテクチャに対応した分析機能を提供する #### 弱点・課題 (Weaknesses / Limitations) - 現時点ではllama.cppに特化しており、vLLMやTGI等の他の推論フレームワークへの対応は今後の課題である - OpenCLバックエンドのトレーシングには外部プロファイリングツールが必要であり、完全な可視性を一つのツールで実現できていない - inter-operatorパラレリズムや帯域幅予測への対応は将来課題として残されている - 著者所属が論文中に明示されていない（ダブルブラインドレビュー中のプレプリント）ため、再現性確認に必要な実装の詳細が一部不明確である ## Abstract 大規模言語モデル（LLM）が研究から本番環境へと移行するにつれ、推論エンジンがリアルタイムでどのように動作するかを理解することが不可欠かつ難解な課題となっている。ONNX Runtimeのような汎用エンジンとは異なり、今日のLLM推論システムはオペレータレベルの可視性をほとんど提供しておらず、開発者は時間とリソースがどこに消費されているかを把握できない状況にある。「このワークロードはメモリバウンドなのか、それともコンピュートバウンドなのか」という基本的な問いでさえ、多くの場合答えが得られない。このギャップを埋めるため、我々は現代のLLM推論エンジン向けの細粒度かつ非侵襲的なプロファイリングフレームワークを開発した。このフレームワークはllama.cppを例示として構築されているが、類似のランタイムアーキテクチャにも適用可能である。拡張Berkeley Packet Filter（eBPF）技術を基盤とし、我々のシステムはソースを変更・再コンパイルすることなく、複数のレイヤーにわたってランタイム関数に動的にプローブをアタッチする。収集したトレースをオペレータ、グラフ、タイムライン、ハードウェアカウンタのトレンドの豊富な可視化へと変換し、密な推論、Mixture-of-Expertsルーティング、オペレータオフロードが実際にどのように動作するかを明らかにする。4%未満のランタイムオーバーヘッドと高いプロファイリング忠実度により、我々のフレームワークはLLM推論を透明かつ診断可能なものにし、性能プロファイリングを最適化、スケジューリング、リソースを考慮した展開のための実践的なツールへと変える。