Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ML Pipelineの開発と運用を OpenTelemetryで繋ぐ @ OpenTelem...
Search
Yoshimura Naoya
July 23, 2025
Technology
1
410
ML Pipelineの開発と運用を OpenTelemetryで繋ぐ @ OpenTelemetry Meetup 2025-07
Presentation at "OpenTelemetry Meetup 2025-07"
https://opentelemetry.connpass.com/event/360245/
Yoshimura Naoya
July 23, 2025
Tweet
Share
More Decks by Yoshimura Naoya
See All by Yoshimura Naoya
20250426 GDGoC 合同新歓 - GDGoC のススメ
getty708
0
140
回想録 ~ GDSC Osakaの立上げから引継ぎまで ~ @ GDGoC Japan Connect 2025
getty708
0
62
"OpenPack: A Large-scale Dataset for Recognizing Packaging Works in IoT-enabled Logistic Environments" (PerCom2024 - Presentation)
getty708
0
94
OpenPack Challenge 2022 - チュートリアル (日本語)
getty708
0
550
Other Decks in Technology
See All in Technology
インサイト情報からどこまで自動化できるか試してみた
takas0522
0
140
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
900
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
5.4k
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
950
stupid jj tricks
indirect
0
7.8k
Escaping_the_Kraken_-_October_2025.pdf
mdalmijn
0
120
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
200
KAGのLT会 #8 - 東京リージョンでGAしたAmazon Q in QuickSightを使って、報告用の資料を作ってみた
0air
0
200
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.8k
about #74462 go/token#FileSet
tomtwinkle
1
280
#普通の文系サラリーマンチャレンジ 自分でアプリ開発と電子工作を続けたら人生が変わった
tatsuya1970
0
940
20250929_QaaS_vol20
mura_shin
0
110
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Speed Design
sergeychernyshev
32
1.1k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
Rails Girls Zürich Keynote
gr2m
95
14k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
19
1.2k
Designing for humans not robots
tammielis
254
25k
How GitHub (no longer) Works
holman
315
140k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
The Language of Interfaces
destraynor
162
25k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Transcript
ML Pipelineの開発と運用を OpenTelemetryで繋ぐ 2025.07.22 Naoya - @ OpenTelemetry Meetup 2025-07
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級 実技
テクニカルな話はあまりしません ! シンプルな使い方で開発・運用のフローを改善する話です!
動画の解析パイプライン 特徴 • 多数のモデルが必要 • 1台 の GPU で処理 •
スループットが 認識性能 と運用コストに直結 [参考] Nvidia DeepStream の サンプル パイプライン (構成図) • (1) 車の検出 • (2) ナンバープレートの検出 (LPDNet) • (3) ナンバープレートの認識 (LPRNet) … README.md - NVIDIA-AI-IOT/deepstream_reference_apps GPU/ サーバー間のデータコピーの コストを無くし、Latencyを下げるため
今回想定する ML Pipeline (ダミー) • Classical な機械学習モデル (Not LLM) •
1 GPU で全てを実行 • モデルの開発とプロダクションのコードがほぼ同じ ML Pipeline INPUT IMAGE (B3HW) Model 1 Model 2 Model 3 OUTPUT
ML Pipelineの開発 & 運用 サイクル (MLOps) • MLOps = CI
+ CD + CT (Continuous Training) (機械学習モデルの構築 + 継続的な学習 が DevOpsに追加) パイプライン構築 モデルの最適化 モデルの構築 パイプライン & モデルの運用 https://ubuntu.com/blog/what-is-mlops Accuracy Latency & Throughput 各フェーズで 重要なメトリクス
課題 • 「モデル構築」と「開発・運用」フェーズで、使うツールが異なる。 https://ubuntu.com/blog/what-is-mlops Model Development Dev & Ops Latency
/ Throughput など 同じメトリクスを見ているのに、 個別に収集する必要が有 = 冗長
[補足] 実験管理ツール (Weights & Biases) • 機械学習の難しい点 ⇒ 再現性の担保 ◦
実行時のパラメータや環境によって結果が異なる。 ⇒ これらの要因を自動的に収集・保存してくれるツール ⇒ (例) Weight & Biases • 用途 ◦ 実行パラメータと評価結果をセットで管理 ⇒ モデルの改善 • 記録するデータの種類 ◦ Accuracy, Latency, etc … Weight & Biases • 問題点 ◦ 開始・終了があるプロセスの監視を想定 (運用時など、常時稼働 & 複数プロセスの 監視では比較的使いにくい。 )
[補足] モデルの最適化 & プロファイラ • 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)
課題 (再) 同じメトリクスを見ているのに、個別に収集する必要有 ⇒ これを許容できるか? 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) 冗長! 同時に使わない!
OpenTelemetry を活用した解決策 • 運用時に必要なテレメトリの収集を OpenTelemetry に集約 • OpenTelemetry のカスタム Exporter
を実装 ⇒ OTel のメトリクスを W&B にフォワード ⇒ Accuracy とともに記録可能
カスタム Exporterの実装 “WandbSpanmetricsExporter” 参考: Span Metrics Connector Spanの Durationを メトリクスとして記録するコネクター
(参考) 同じ Batchの情報を 同じ step に記録したい ⇒ Root Span にデータを保存 SpanExporterを継承して実装
Pipelineへの計装例 Root Span のマーカー付与 プロファイラと切り替えられる ようにエイリアスを使用 Model 1 Model 2
実行結果: テスト用動画 Model 1 Pipeline https://wandb.ai/getty708/otel-in-wandb/runs/7vw27ac3?nw=nwusergetty708 本来はこの下に 評価 (Accuracy) が来る。
Model 2 Model 3 注) 異なる sin波 時間かかるダミーモデルを使用
モデルの開発と運用で メトリクスの収集を共通かできた! で、本当にこれって嬉しいの?
メリット1: 開発フローが変わる (1) • これまでの開発 : 虫の目 ◦ 想定を決める ⇒
コンポーネントを一つ一つ作成&評価 (に視野が狭まりがち ) ◦ 全体動かせるまで時間かかる . • OTel を使った開発 : 鳥の目 ◦ パイプラインをデプロイ (ひとまず全体を実行 ) ⇒ リアルな環境でのテレメトリを見てトリアージ ⇒ インパクトの大きい問題から改善 サービスが動いていて、 どこにどのくらい問題があるか分かる というのは心理的にとても安心
メリット1: 開発フローが変わる (2) • Accuracy と Latency / Throughput はトレードオフ
◦ ⇒ 同じメトリクスで議論できる & 行き来がしやすい。 ◦ ⇒ モデルを開発している人の視点を、モニタリングに転用できる。 W&Bで常に同時に見れる!
メリット2: 実データからのフィードバックが円滑に • 事例 1-1: 検証用のデータセットと実環境が異なる . ◦ 検証データでは見たことがない値のメトリクスを発見 ⇒
データセットの想定に入っていない (e.g., 検出数の分布) ⇒ 評価方法やロジックにフィードバック • 事例 1-2: W&B と Prometheus の両方にメトリクスを送信 (荒技) ◦ 平均値を取るとわからなかった異常値が見つかる ! • 事例 2: モニタリング用のメトリクスがモデル・ロジックの改善に役に立つ ◦ e.g., 物体の検出数 ⇒ すでに運用のために実装されている! 異常値 ? 通常
メリット3: トレースの取得 • モデルの実行の様子が簡単に視覚的に確認できる! ◦ パイプラインの挙動の理解ができる。 ◦ プロファイラで可能だが、本番環境で実行するには重すぎる。 • モデルとモデルの間の
Queue での待ち時間 の確認 ◦ メトリクスとして取れていない ◦ トレースをみると、直感的に問題が分かる。 パイプラインが並行処理の 実行時に、特に役に立つ! post-process 長い?
まとめ • 試行: ML Pipeline の開発に OpenTelemetry を導入 ◦ 運用時に使用するメトリクスは、
OpenTelemetry の収集に統一 ◦ そのための カスタム Exporter を実装 ◦ ⇒ 冗長性の低減 & 同じメトリクスが各ツールで確認可能 • 結果: 開発フローが変化 ◦ 鳥の目で全体最適に集中できる。 ◦ 実データからのフィードバックがより簡単になった。 ◦ モデル開発者の視点を、そのまま運用に活かせる。 ◦ トレースは、パイプラインの挙動の理解においてとても有用 開発と運用を OTelが繋げた! (と言ってもいいのでは? )
余談: LLM の開発における OpenTelemetry • OpenLIT (link) ◦ OpenTelemetry ネイティブな
GenAI システムの監視ツール (コスト, Token数, Trace) • 各社ツールも OpenTelemetry をサポート ◦ Gemini CLI (link), ADK (link), LangFuse,