OpenTelemetryで作るAI基盤のGPUオブザーバビリティ
この記事はオープンソースカンファレンス2026 Sendai(OSC仙台)での発表をさくナレ編集部で記事化したものです。
はじめに
さくらインターネットの芦野(@tar_xzvff)です。サービス統括本部 サービス開発部 AI基盤グループで勤務しています。仕事は、弊社が提供している「さくらのクラウド」の開発・運用を行っています。また、最近はGPUリソースを使ったAIサービスが多数登場しており、こちらにも関わっています。職種としてはインフラエンジニアやバックエンドエンジニア、SREなど、さまざまなものを担当しています。
私の経歴としては、10年前にIT系の専門学校を卒業し、2016年にさくらインターネットに新卒で入社して今年で10年目を迎えています。実は私が卒業した専門学校は本日の会場でもある東北電子専門学校で、10年ぶりにこの学校に来て懐かしい気持ちに浸っています。また、2012年に行われたOSC仙台(今回のOSC仙台はそのとき以来の開催となります)に初めて参加し、そのときにオープンソースの世界を知りました。それまで自宅の古いサーバーにLinuxを入れて遊んでいた程度でしたが、このイベントが転機となり、今の自分につながっていると感謝の気持ちでいっぱいです。専門学校生時代に多くのITコミュニティに支えられ、さまざまなことを学び、キャッチアップできたことにも感謝しております。
さくらインターネットのサービス
さくらインターネット株式会社はクラウドコンピューティングサービスを事業の柱として、日本に3か所のデータセンターを運営して事業を展開しています。最近のトピックとしては、2026年にガバメントクラウドに採択されたことや、今年で創業30周年を迎えることなどがあります。
さくらインターネットのサービスは大きく3つのカテゴリーに分かれています。クラウドサービス、物理基盤サービス、周辺サービスです。
クラウドサービスとしてはパブリッククラウドを提供しており、ガバメントクラウドに採択された「さくらのクラウド」は多くの機能を拡充しながら提供を続けています。また、これよりも長い歴史を持つ「さくらのVPS」というサービスもあり、非常に使いやすいサーバーとしてお客様にご利用いただいています。
物理基盤サービスとしては、「さくらの専用サーバ PHY」というベアメタルサーバーのサービスがあります。クラウドサービスと物理基盤サービスを組み合わせた「高火力」というシリーズもあります。これはさくらインターネットのGPUサーバーサービスで、3つの種類があります。お客様のワークロードに合わせて、「高火力 DOK」というGPUコンテナサービス、「高火力 VRT」というGPUのVM型サービス、そして「高火力 PHY」というGPUのベアメタルサーバーサービスという形でラインナップをそろえています。
さらに新しい取り組みとして、弊社は生成AIのサービスにも注力しており、国内完結で利用できるAIプラットフォーム「さくらのAI」を展開しています。「さくらのAI Engine」という国内に閉じた環境で動作するAPIサービスがあり、また「さくらのAIソリューション」という、AIを活用した課題解決や業務支援のパッケージ型サービスも提供しています。
AIの普及過程の振り返り
ここからが本題で、まずAI基盤とGPUオブザーバビリティについてお話ししていきますが、その前に、AIが身近な技術として急速に普及した背景を振り返ります。
まず2022年にChatGPTが登場し、ここを皮切りに生成AIブームが始まりました。ChatGPTでは対話型AIの可能性が広く認知されました。その翌年にはStable Diffusionがリリースされ、今度はテキストプロンプトから画像を生成するブームが巻き起こり、生成AIがさらに普及しました。2024年にはSoraが公開され、テキストから動画を生成する技術が実用化されました。同時期にMCPサーバーが登場し、既存のサービスやツールとAIを連携させるインターフェースが整備されました。2025年になるとAIエージェントという概念が広まり、AIが自律的に作業したり、モノを作ったりといったところにもAIが普及してきました。
ここまでの過程をAIの一般化という観点で見ると、AIの利用は個人レベルから企業・組織へと段階的に拡大してきていることがわかります。また、各企業がオープンなAIモデルを公開したことや、それらを扱うソフトウェアも充実してきたことで、誰でも高度なモデルを活用できる環境が整いました。さらに、ローカル環境でLLMを動かすユーザーも増えており、AIが日常生活やビジネスに深く根付いていることがうかがえます。
AI基盤のオブザーバビリティとは
このような状況に対応すべく、弊社はGPUクラウドサービスの拡充や生成AI向けプラットフォームの提供に注力していますが、このようなサービスを動かす中で新たな課題も生まれています。
AIサービスは、まずモデル(LLM)があり、それを動かすGPU、それからデータベースなど、いろいろなもので構成されていて、結構複雑です。そんな中で安定した品質のサービスを提供するために、性能の監視や可視化が必要になってきます。つまり、AIサービスを安定運用するためのオブザーバビリティが現在の重要な課題になっています。
ではAI基盤の監視として聞いて、皆さんは何を思い浮かべるでしょうか。従来のインフラ監視であれば、CPU・メモリ・ディスク・ネットワークなどがオーソドックスな監視要素になるかと思います。一方、AI基盤にはGPUというハードウェアコンポーネントがあるので、それを監視するにはGPUのメトリクスやAI関連のメトリクスを見るといったところがあるかと思います。実際、私もAI関連のサービス開発に今年から関わるようになったのですが、最初はGPUのメトリクスを見ていればいいのかなと思っていました。
GPUのメトリクスを見てみよう
というわけで、まずはGPUの状態を見るところから入っていきます。そのために今回、上図のような検証環境を用意しました。さくらのクラウド上に、高火力 VRTというGPUの仮想サーバーと、サーバーで発生するメトリクスを保存するためのストレージを用意しました。ここで登場する要素を紹介します。
- 高火力 VRT
さくらのクラウドの仮想GPUサーバーです。現在はNVIDIA H100というGPUが利用可能です。 - vLLM
OpenAI互換のAPIを提供するLLM推論エンジンです。GPU上でモデルを実行し、推論リスエストを処理します。こちらには推論メトリクスをPrometheus形式で公開するという機能があります。 - DCGM Exporter
GPUからさまざまなメトリクスを取得するものです。こちらもメトリクスをPrometheus形式で公開できます。 - モニタリングスイート メトリクスストレージ
さくらのクラウドの機能のひとつで、PrometheusのRemote Storageとして利用可能なメトリクスストレージです。
次に、今回の発表タイトルにも入っているOpenTelemetryを紹介します。OpenTelemetryは一言で説明すると、メトリクス・ログ・トレースを統一的に扱うためのオープンな仕組みです。OTLP(OpenTelemetry Protocol)というオープンな仕様を提供しており、ベンダーニュートラルな計装ができます。あとは既存の監視や可観測性基盤との連携もできるところが非常に大きなポイントかと思います。
このOpenTelemetryには、主要なコンポーネントとなるOpenTelemetry Collectorというものがあります。これがログ・メトリクス・トレースを収集する役割を担っています。収集したデータに対してフィルタリングや変換などの加工をして、最終的にバックエンドのストレージに保存することもできます。Goで開発されていて、シングルバイナリとして動作するプログラムになっています。
今回なぜOpenTelemetryを使ったのかですが、まずCNCF標準の可観測性エコシステムを活用できるので、いろいろなところと接続できるという点が大きなメリットと思っています。今回はメトリクスしか扱わないのですが、ログもトレースも統一的に扱えるのは非常に便利です。
それでは再び構成図を提示します。高火力 VRTの上でGemmaというGoogleのLLMを動かしています。これに対して外部からOpenAI互換のAPIを通してリクエストを送るという構成です。
GPUのメトリクスを取る部分は上図のようになっています。GPUに対してDCGM Exporterを適用します。ExporterはHTTPのエンドポイントを公開しているので、OpenTelemetry CollectorがPrometheus Receiverを使ってデータを取得します。最後にPrometheus Remote Write Exporterという、外部に書き出すコンポーネントを使って、外部のメトリクスストアに保存するという流れになっています。
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'nvidia-gpu-dcgm'
scrape_interval: 5s
static_configs:
- targets: ['localhost:9400']
processors:
resourcedetection:
detectors: [system]
system:
hostname_sources: [os]
exporters:
sacloud:
metrics:
endpoint: "${env:SACLOUD_METRICS_ENDPOINT}"
token: "${env:SACLOUD_METRICS_TOKEN}"
service:
pipelines:
metrics:
receivers:
- prometheus
processors:
- resourcedetection
exporters:
- sacloud上記はOpenTelemetry Collectorの設定例です。上がReceiverの定義で、どこから対応するかを書きます。exportersの部分はメトリクスの保存先です。serviceの部分にReceiverとExporterをつないでパイプラインを作成してメトリクスを保存するという流れを記述しています。非常にシンプルに定義できてよいと思います。
GPUのメトリクスだけでは利用者の快適度はわからない
この構成に対して、実際にvLLMにリクエストを投げて負荷をかけたときに取得したGPUのメトリクスは上図のようになります。左上がGPUの使用率、その右隣がGPUの温度です。中段左が電力の使用状況で、その右隣がその推移、下段左側がGPUメモリの使用量です。
負荷をかけると温度や消費電力がどんどん上がることがわかりますが、メモリ使用量は一定の値で推移しています。何か動いてることはわかりますが、より詳細なところはこれではわかりません。ここでGPUのメトリクスを確認してみたのですが、GPUの使用率は0か100近くで、GPUのメモリ使用量は一定という結果でした。なぜメモリの使用量は一定かというと、vLLMが起動したタイミングで使用するメモリを確保するようで、それ以降は一定になるような挙動をするようです。
ここで、これはシステムの状態という観点で良い状態かという問いがあるのですが、これではちょっとわからないというのが正直なところです。AIを利用しているユーザが本当に快適に使えているかもよくわからないような気がします。これらの数値だけを見ても本当に良い状態かはわからないので、GPUメトリクスだけでは利用者は快適かどうかわからないということになります。
結局、ユーザーは何を見ているかというと、例えばChatGPTにおけるチャット画面があるとして、人が入力して送信してAIから回答が来るときに、返答が早いか、出力がスムーズか、待たされないか、といったところを見ています。GPUメトリクスはシステムの状態を知るためには必要なものですが、その一方でサービス品質やユーザー体験に影響する部分は観測できないという課題もあります。その課題を解決するために、AIサービスには独自のメトリクスがあります。代表的なものが4つあるので、これらAIサービス独自のメトリクスについて見ていきます。
AIサービスで見るべきメトリクス
従来のWebサービスでは、CPU・メモリ・レスポンスタイムを見たり、システム負荷を測っていたと思います。一方、AIサービス系には新しい指標があります。その中から今日は代表的なものをいくつか紹介します。
まずはTTFT(Time To First Token)です。どのようなものかというと、ユーザーがリクエストを送信してから回答の1文字目(正確には1トークン目)を返すまでの待ち時間となります。上図の例では、ユーザーがリクエストを送り、AIが「こんにちは」というレスポンスを返すときの最初の1文字目を返すまでの時間ということになります。
続いてITL(Inter-Token Latency)です。こちらは文字が次々と出てくる速度です。先ほど「こんにちは」という文字列を返す話をしましたが、1文字目以降の文字を返す間のレイテンシをITLと呼びます。上図では「に」と「ち」の間とか、「ち」と「は」の間のレイテンシですね。
続いてはEnd-to-end latencyです。こちらはリクエスト送信から応答完了までの全体の処理時間です。上図ではリクエストを投げてから「こんにちは」の「は」までが返る時間、つまりすべての回答が完了するまでの時間です。
次にTPS(Tokens Per Second)です。LLMが1秒間に生成できるトークン数を指します。この値が高いほど多くの処理ができ回答文を早く生成できるという性能指標になっています。それからRPS(Requests Per Second)、これは1秒間に処理できるリクエスト数です。
これらのメトリクスはvLLMから取得できます。それぞれに項目も定められています。下記に掲げます。
ここまでの話をまとめると、冒頭でお話ししたGPU使用率は、システムの状態を見るために必要でした。一方で先ほどお話ししたTTFTやITLはユーザーの体験を知ることができる値ということになります。どちらも大切な値ですが、ユーザー体験を大切にするサービスでは、ユーザーの体験に近いメトリクスを見ましょうということになります。
実践編: OpenTelemetryによるメトリクス収集
ではこれらのメトリクスを実際に収集し可視化してみましょうというところで後半の内容に入っていきます。
システム構成とシナリオ
今回用意したシナリオは、TTFTが大きく悪化したというものです。つまり、ユーザーがリクエストを送ってから最初の1文字目が返ってくるまでの時間が非常に長い状態が発生したという状況です。ユーザーからすると、何か遅い、そもそもサービスは動いているのか？ という心境になります。
これの原因はさまざまなものが考えられますが今の時点では全然わからないので、メトリクスを収集して見てみましょう。システム状態としてはCPU・メモリ・GPU、ユーザー体験やサービス品質というところではTTFT・ITL・TPSといったところを見ましょうという感じです。
今回の構成(上図)においては、vLLMからメトリクスを取得するような設定を投入します。vLLMの下にメトリクスのエンドポイントを記載しています。Exporterと同様にHTTPのエンドポイントを提供していますので、vLLMのメトリクスのエンドポイントをOpenTelemetryコレクタからPrometheusレシーバーを通して値を取得しに行くという形になっています。下記の設定例のようにレシーバーの設定を追加することでメトリクスが取得できるようになります。
receivers:
prometheus:
config:
scrape_configs:
- job_name: 'nvidia-gpu-dcgm'
scrape_interval: 5s
static_configs:
- targets: ['localhost:9400']
- job_name: 'vllm'
scrape_interval: 5s
static_configs:
- targets: ['localhost:8000']
processors:
resourceDetection:
detectors: [system]
system:
hostname_sources: [os]
exporters:
sacloud:
metrics:
endpoint: "${env:SACLOUD_METRICS_ENDPOINT}"
token: "${env:SACLOUD_METRICS_TOKEN}"
service:
pipelines:
metrics:
receivers:
- prometheus
processors:
- resourceDetection
exporters:
- sacloud平常時のメトリクス
では実際に取得した値を見てみましょう。最初は平常時の数値です。平均5リクエスト/秒で最大同時実行数が8です。ここでシステムのメトリクスを見てみます。グラフの左列がロードアベレージ(1分〜15分平均)、右上がメモリ使用量で、その下がプロセス数とネットワークコネクションです。これを見るとロードアベレージが0から0.9ぐらいまで上がっていますが、それほど負荷がかかっているわけでもないかなと思います。
GPUの方を見ると、GPUを使い始めると使用率が0から100に上がります。それ以外の値も追従して上がっています。
それから上図は、平常時のvLLMのメトリクスになります。左上がTTFTの平均、その右隣がITLの平均、左下2番目がEnd-to-end latencyの平均です。その右隣は実行中のリクエスト数です。3段目はTPSとRPS、最下段はキューに入っている時間とリクエスト数です。
左上のグラフを見ると、TTFTが0から0.2という値を示していますが、これはレスポンスとしては十分に速いかなと思います。ITLも0.03秒なので非常に速い状況になっています。End-to-end latencyを見ると4秒となっています。これも十分に許容範囲と考えています。実行中のリクエスト数はほぼ常に0なので、すべてのリクエストが実行できている状況になっています。
高負荷時のメトリクス
次に、負荷がかかっている状態ではどうなるかを見てみます。平均50リクエスト/秒で最大同時実行数64です。こちらもまずはシステムのメトリクスを見ていきます。左上がロードアベレージですが、それほど高負荷という状況でもないと思います。CPU使用率やメモリの使用状況も変わらずといったところです。顕著に違っているのがネットワークコネクションで、平常時は30以下だったところが150ぐらいまで跳ね上がっているのが見てとれます。
続いてGPUです。こちらも平常時とあまり変わっておらず同じような推移をしています。負荷をかけるとGPUの使用率が0から100に変わります。
続いてユーザ体験に関するグラフを見てみましょう。左上がTTFTで、最初は0だったところが徐々に上がって、一番右端では25秒になっています。つまりリクエストしてから1文字目が返ってくるまでだいたい平均25秒かかるという非常に遅い状況であることがわかります。またEnd-to-end latencyも25秒ぐらいとなっていて、システム全体で見ても遅いという形になっています。一方、ITLはあまり変わっておらず、平均0.03秒ぐらいで推移しています。それからRunning Requestsがだいたい10ぐらいで、キューに入ったリクエスト数、右下のグラフですが、こちらが50くらいですので、足して64ぐらいになるのかなと思います。半分以上のリクエストがキューに入ったところで処理されず、非常に遅い状況になっていることがわかりました。
実践編まとめ
高負荷の状態をユーザ体験という観点でまとめるとこちらのスライドのようになります。プロンプトを投げて回答待ちの状況になっていることがわかります。
この先、どういったテクニックを使ってこういう値を改善していくかという話もできたらよいのですが、まだ勉強中なのでまた機会があればそういった話もできればいいなと思っています。
ところで、この実践編ではsacloud-otel-collectorというものを使いました。OpenTelemetryコレクターにもいろんな種類があって、今回使ったのはさくらのクラウド向けにカスタマイズされたディストリビューションです。どんなところがカスタマイズされているかというと、さくらのクラウドにはモニタリングスイートという、メトリクス・ログ・トレースなどを保存するサービスの集合体がありまして、そちらとの連携が非常にしやすいものになっています。メトリクスのストレージを作成するとエンドポイントとトークンが発行されて、それら2つの値を設定するだけで送信可能になっています。
まとめ
それでは今回のまとめに入ります。
AIサービスには独自のメトリクスもあるというところで、TTFT、ITL、End-to-end latency、TPS、RPSといった項目があります。これらの項目はユーザー体験に近いメトリクスなので、こういった項目を見ることを心がけるといいかなと思います。従来から存在するシステムのメトリクスや低レイヤーのメトリクスも重要で必要不可欠なものですが、やはりそこだけではサービス品質がわからないという状況があります。ですので、ユーザー体験を改善するためにこういった値を観測し、その体験品質をSLOとして定義して継続的に改善することが非常に大事かなと考えています。