ML Pipelineの開発と運用を OpenTelemetryで繋ぐ @ OpenTelemetry Meetup 2025-07

Presentation at "OpenTelemetry Meetup 2025-07"
https://opentelemetry.connpass.com/event/360245/

Transcript

1. ML Pipelineの開発と運用を OpenTelemetryで繋ぐ 2025.07.22 Naoya - @ OpenTelemetry Meetup 2025-07
2. About Me Naoya Yoshimura (X: @Getty708) Machine Learning and MLOps Engineer (Video Analytics) GDG Tokyo Organizer What I Like: Coffee ☕, Whisky 🥃 My Interests 機械学習, (行動認識技術) Software Engineering JCQA コーヒーインストラクター1級 実技
3. テクニカルな話はあまりしません ! シンプルな使い方で開発・運用のフローを改善する話です！
4. 動画の解析パイプライン 特徴 • 多数のモデルが必要 • 1台 の GPU で処理 • スループットが 認識性能 と運用コストに直結 [参考] Nvidia DeepStream の サンプル パイプライン (構成図) • (1) 車の検出 • (2) ナンバープレートの検出 (LPDNet) • (3) ナンバープレートの認識 (LPRNet) … README.md - NVIDIA-AI-IOT/deepstream_reference_apps GPU/ サーバー間のデータコピーの コストを無くし、Latencyを下げるため
5. 今回想定する ML Pipeline (ダミー) • Classical な機械学習モデル (Not LLM) • 1 GPU で全てを実行 • モデルの開発とプロダクションのコードがほぼ同じ ML Pipeline INPUT IMAGE (B3HW) Model 1 Model 2 Model 3 OUTPUT
6. ML Pipelineの開発 & 運用 サイクル (MLOps) • MLOps = CI + CD + CT (Continuous Training) (機械学習モデルの構築 + 継続的な学習 が DevOpsに追加) パイプライン構築 モデルの最適化 モデルの構築 パイプライン & モデルの運用 https://ubuntu.com/blog/what-is-mlops Accuracy Latency & Throughput 各フェーズで 重要なメトリクス
7. 課題 • 「モデル構築」と「開発・運用」フェーズで、使うツールが異なる。 https://ubuntu.com/blog/what-is-mlops Model Development Dev & Ops Latency / Throughput など 同じメトリクスを見ているのに、 個別に収集する必要が有 = 冗長
8. [補足] 実験管理ツール (Weights & Biases) • 機械学習の難しい点 ⇒ 再現性の担保 ◦ 実行時のパラメータや環境によって結果が異なる。 ⇒ これらの要因を自動的に収集・保存してくれるツール ⇒ (例) Weight & Biases • 用途 ◦ 実行パラメータと評価結果をセットで管理 ⇒ モデルの改善 • 記録するデータの種類 ◦ Accuracy, Latency, etc … Weight & Biases • 問題点 ◦ 開始・終了があるプロセスの監視を想定 (運用時など、常時稼働 & 複数プロセスの 監視では比較的使いにくい。 )
9. [補足] モデルの最適化 & プロファイラ • ML Pipeline のボトルネック ⇒ モデルの推論時間 • 対策例 ◦ TensorRT への変換 (命令セットの最適化、 FP32→FP16へ量子化 , etc) ◦ 変換結果を プロファイラ (NVIDIA Nsight Systems) で確認 (GPU の挙動を可視化) • 記録するデータの種類 ◦ Latency GPUでの実行命令 • 課題 ◦ 最適化は、モデルの精度に影響有 ⇒ 再評価が必要 (W&Bに戻って Accuracy 記録) ◦ オーバーヘッド大 & 粒度が細かい ⇒ 長期的な監視には向かない ◦ 処理単位に手動でラベルを付与が必要 with nvtx.annotate("model_1", color="green"): output = model1(input)
10. 課題 (再) 同じメトリクスを見ているのに、個別に収集する必要有 ⇒ これを許容できるか？ ts_start = time.time() with nvtx.annotate("model_1", color="green"): with tracer.start_as_current_span(“model_1”) output = model1(input) duration = time.time() - ts_start() wandb.log({“model1/duration”: duration}) モデル開発 & 評価 (W&B) プロファイル (nvtx) モニタリング (OTel) 冗長! 同時に使わない！
11. OpenTelemetry を活用した解決策 • 運用時に必要なテレメトリの収集を OpenTelemetry に集約 • OpenTelemetry のカスタム Exporter を実装 ⇒ OTel のメトリクスを W&B にフォワード ⇒ Accuracy とともに記録可能
12. カスタム Exporterの実装 “WandbSpanmetricsExporter” 参考: Span Metrics Connector Spanの Durationを メトリクスとして記録するコネクター (参考) 同じ Batchの情報を 同じ step に記録したい ⇒ Root Span にデータを保存 SpanExporterを継承して実装
13. Pipelineへの計装例 Root Span のマーカー付与 プロファイラと切り替えられる ようにエイリアスを使用 Model 1 Model 2
14. 実行結果: テスト用動画 Model 1 Pipeline https://wandb.ai/getty708/otel-in-wandb/runs/7vw27ac3?nw=nwusergetty708 本来はこの下に 評価 (Accuracy) が来る。 Model 2 Model 3 注) 異なる sin波 時間かかるダミーモデルを使用
15. モデルの開発と運用で メトリクスの収集を共通かできた！ で、本当にこれって嬉しいの？
16. メリット1: 開発フローが変わる (1) • これまでの開発 : 虫の目 ◦ 想定を決める ⇒ コンポーネントを一つ一つ作成＆評価 (に視野が狭まりがち ) ◦ 全体動かせるまで時間かかる . • OTel を使った開発 : 鳥の目 ◦ パイプラインをデプロイ (ひとまず全体を実行 ) ⇒ リアルな環境でのテレメトリを見てトリアージ ⇒ インパクトの大きい問題から改善 サービスが動いていて、 どこにどのくらい問題があるか分かる というのは心理的にとても安心
17. メリット1: 開発フローが変わる (2) • Accuracy と Latency / Throughput はトレードオフ ◦ ⇒ 同じメトリクスで議論できる & 行き来がしやすい。 ◦ ⇒ モデルを開発している人の視点を、モニタリングに転用できる。 W&Bで常に同時に見れる！
18. メリット2: 実データからのフィードバックが円滑に • 事例 1-1: 検証用のデータセットと実環境が異なる . ◦ 検証データでは見たことがない値のメトリクスを発見 ⇒ データセットの想定に入っていない (e.g., 検出数の分布) ⇒ 評価方法やロジックにフィードバック • 事例 1-2: W&B と Prometheus の両方にメトリクスを送信 (荒技) ◦ 平均値を取るとわからなかった異常値が見つかる ! • 事例 2: モニタリング用のメトリクスがモデル・ロジックの改善に役に立つ ◦ e.g., 物体の検出数 ⇒ すでに運用のために実装されている！ 異常値 ? 通常
19. メリット3: トレースの取得 • モデルの実行の様子が簡単に視覚的に確認できる！ ◦ パイプラインの挙動の理解ができる。 ◦ プロファイラで可能だが、本番環境で実行するには重すぎる。 • モデルとモデルの間の Queue での待ち時間 の確認 ◦ メトリクスとして取れていない ◦ トレースをみると、直感的に問題が分かる。 パイプラインが並行処理の 実行時に、特に役に立つ! post-process 長い？
20. まとめ • 試行: ML Pipeline の開発に OpenTelemetry を導入 ◦ 運用時に使用するメトリクスは、 OpenTelemetry の収集に統一 ◦ そのための カスタム Exporter を実装 ◦ ⇒ 冗長性の低減 & 同じメトリクスが各ツールで確認可能 • 結果: 開発フローが変化 ◦ 鳥の目で全体最適に集中できる。 ◦ 実データからのフィードバックがより簡単になった。 ◦ モデル開発者の視点を、そのまま運用に活かせる。 ◦ トレースは、パイプラインの挙動の理解においてとても有用 開発と運用を OTelが繋げた！ (と言ってもいいのでは？ )
21. 余談: LLM の開発における OpenTelemetry • OpenLIT (link) ◦ OpenTelemetry ネイティブな GenAI システムの監視ツール (コスト, Token数, Trace) • 各社ツールも OpenTelemetry をサポート ◦ Gemini CLI (link), ADK (link), LangFuse,