re:Invent 2025: AI時代のオブザーバビリティ実践 - GPUからLLMまでの監視とトラブルシューティング手法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Scaling Observability for the AI Era: From GPUs to LLMs (AIM121)
この動画では、ChronosphereのセールスエンジニアRyanが、AIオブザーバビリティの概要と実践的なユースケースを解説しています。市場をmodel builder、GPU provider、AI native、feature builderの4つに分類し、モデルトレーニング、推論ホスティング、inference healthという3つの主要ユースケースを詳述します。NVIDIA DCGM Prometheus exporterやArize AIのOpen InferenceなどのOTelトレースを活用し、GPU利用率、hallucination rate、biased response rate、トークン消費などを可視化する方法を紹介。differential diagnosisによる異常検知機能や、モデル別のコストトレンド分析など、具体的なトラブルシューティング手法が示されています。オープンソースツールを組み合わせた実装例も提示され、AI時代のオブザーバビリティ戦略の実践的指針となっています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Chronosphereが提供するAIオブザーバビリティの全体像と市場の4つのバケット
皆さん、ようこそ。本日はご参加いただきありがとうございます。私は Chronosphere のセールスエンジニアの Ryan です。Chronosphere はオブザーバビリティ企業で、オープンソースのデータ収集、大規模なパフォーマンスと信頼性、そしてテレメトリーの制御に焦点を当てており、必要な分だけお支払いいただくというモデルです。最近、AI 企業や AI のユースケースで大きな成功を収めています。
この短いトークでは、AI オブザーバビリティの概要、私たちが見ている様々なパターンとユースケース、そしてオブザーバビリティを使用して落とし穴を防ぐ方法についてカバーします。製品のデモンストレーションについては深く掘り下げることはできませんが、Chronosphere のブースに立ち寄って、AI ガイド機能と他の新機能のデモをぜひご覧ください。
まず、ユースケース自体に入る前に、市場の観点から私たちが見ているものについて概要を説明させてください。市場を 4 つのコアバケットに分けています。foundation model を構築している model builder たちがいて、他の皆がそれをベースに構築して利用しています。GPU provider は AI 推論、モデルトレーニング、ファインチューニングのユースケースに合わせて GPU インフラストラクチャを調整しています。AI native は AI テクノロジーを中心に一からプロダクトを構築しています。そして feature builder は既存のプロダクトと機能を持っていて、それらの既存プロダクトラインに AI 機能を追加しています。全体を通じて強調したいのは、オブザーバビリティは常に難しく、今も課題であり続けているということ、そして AI はその上にさらに複雑さという層を追加しているということです。
既存の大規模クラウドネイティブの問題パターンはすべて確実に存在し続けており、AI オブザーバビリティのユースケースの中核をなしています。これらの課題についてもう少し詳しく掘り下げると、既存の大規模クラウドネイティブワークロードで見ているものには、大規模性、本当にミッションクリティカルな信頼性、高いパフォーマンス、分散システム全体にわたる多くのトラブルシューティングの複雑性、オブザーバビリティのコストとデータボリュームの制御、そしてインフラストラクチャが変わるにつれてカーディナリティを管理することが含まれます。
私たちが話している AI 固有の新しい課題には、モデルの動作、モデルが正確であり、期待通りに動作していることを確認することが含まれます。トークンエコノミクスを管理して、実際に取り組んでいるユースケースで投資対効果を得る必要があります。特に MCP、RAG、または agentic アーキテクチャを使用している場合、複雑な依存関係を理解する必要があります。そして最後に、独自の GPU インフラストラクチャを管理している場合、それは多くの組織にとって大部分が新しいコンポーネントです。
モデルトレーニングにおけるGPU利用率の最大化とトレーニング効率の向上
では、最初のユースケースであるモデルトレーニングについて掘り下げていきます。このユースケースの内容は、ファインチューニングを行う場合にも全て当てはまります。ここで本当に重要なのは、トレーニングの効率性、最終的な結果としてのモデルパフォーマンス、そして GPU の利用率です。これらのリソースは非常にコストがかかるので、投資から適切な利用率を実際に得ることが極めて重要です。観測可能性の側面に入る前に、標準的なモデル開発ライフサイクルの概要をさっと見ていきましょう。
確かに少し単純化しすぎているかもしれませんが、大規模なデータセットを取り、それを GPU アクセラレータを備えた大規模なコンピュート インフラストラクチャに投入して、そのインフラストラクチャで分散トレーニングジョブを実行し、その結果として実際に運用環境に展開して価値を得られるトレーニング済みモデルを生成することが目標です。モデルが完成したら、次のステップは実際に推論サービスをホストすることで、それは外部向けでも内部向けでもいいですし、プラットフォームチームとしてより多くの場合があります。
この時点から、ユーザーとしては、猫の説明や画像を提供できて、モデルが推論または予測を行い、はい、これは確かに猫です、と言うことができます。シンプルですね。これをどのように実装するかの基本的なアーキテクチャを見ると、スケール、信頼性、パフォーマンスが全てです。
市場で見ているのは、トレーニングサイクルが多く、コンピュートが多いほど、より大きく、より優れたモデルが得られるということです。効率的なトレーニングは競争上の優位性になります。特に誰もが大体同等のコンピュート インフラストラクチャにアクセスできる場合はそうです。問題パターンが発生し始める場所と、観測可能性を使ってそれらを防ぐことについて考え始められる場所を見ると、データセットから始まります。
少量の不正確または無効なデータがトレーニングサイクル全体を台無しにする可能性があることを理解することは非常に重要です。データセットの周りのメタデータを理解し、あるデータセットと別のデータセットがどのように得られる結果に影響するかを測定することは不可欠です。同様に、データ取り込みサービスがあり、これらが遅い場合や、スパイクやエラーがある場合、トレーニングパイプライン全体のボトルネックになります。モデルトレーニングジョブ自体があり、これは従来のサービスや監視する可能性のある他のジョブと非常に似ています。インフラストラクチャの問題をトレーニングの結果と相関させる必要があります。そして右側には GPU があります。
右側の端に見えるのは、ドル記号が燃えているGPUですね。続けて強調したいのは、ダウンタイムや低い利用率がある場合、単にお金を無駄にしているだけでなく、市場投入までの時間も遅くなり、投資から得られる価値も減少してしまうということです。結局のところ、自分たちに問いかけることになるんです。競争力を保つために、あらゆる方法でトレーニング効率を最大化できているのか、と。
では Chronosphere に移って、これを observability にもっと密接に結びつけてみましょう。ここで見ているのは Chronosphere のレンズサービスページです。これが興味深いのは、Chronosphere が NVIDIA DCGM Prometheus exporter から GPU メトリクスを検出しているからです。利用率、温度、エラー統計が得られます。しかし、私たちのラベリング戦略から、これが特定のトレーニングジョブをサポートしていることがわかります。また、Horovod Python SDK からトレーニングメトリクスも取得しており、トレーニング精度、勾配ノルム、サンプル毎秒が得られます。ここにこれらすべての情報があることで、トレーニングジョブで何が起きているのかをエンドツーエンドで素早く理解できるんです。
これはダッシュボードやサービスページを見ている人間の視点から見ていますが、同じ値のグループ化と分析がすべて、AI トラブルシューティングツール、MCP と Agentic インテグレーションに適用されます。これは本当に重要なポイントです。全体を通じて、低レイテンシーのアラートが不可欠です。XID エラーや故障している GPU がある場合、その故障している GPU から、対応できるオペレーターの前にアラートが届くまでの時間は絶対に重要です。そして全体を通じて、私たちが追求しているユースケースを達成するために実際に必要なデータだけを保持しています。
同じサービスページをスクロールダウンしたものです。これを強調しているのは、OTel を使った分散トレーシングがあり、すぐに依存関係マップが得られるからです。エラーのスパイクやデータインジェストサービスの遅延があるかどうかをすぐに確認できます。すべてのテレメトリが一箇所にあります。つまり、問題があることがわかるだけでなく、ログ、イベント、メトリクス、トレースがすべてあるので、掘り下げて本当に相関させ、根本原因を特定でき、最終的にはトレーニングのダウンタイムを最小化し、GPU 利用率を最大化できるんです。
推論ホスティングにおけるサービス信頼性とモデル精度の監視
では、トレーニング済みまたはファインチューニングされたモデルがあります。素晴らしいですが、ユーザーの前に置くことができなければ、それほど大きな価値は提供できません。モデルをホストして推論ホスティングのユースケースで実行することによってです。ここで重要なのはサービスの信頼性です。人々はこれの上に構築しようとしており、それが機能する必要があります。そうでなければ、他の選択肢を探すことになります。同様に、高速である必要があります。高速でなければ、ユーザーは待たされることになり、次のツールを使うことになります。そして最終的に、これはスケーラブルである必要があります。トレーニングとホスティングに時間とエネルギーをすべて投資しているのに、小規模なユースケースをサポートしたくはありません。多くのユーザーにスケールさせたいんです。
では、別のアーキテクチャ図をご紹介します。これは従来のクラウドネイティブサービスに非常に似た構成になっています。基本的には推論機能をバックエンドに組み込んでいるだけです。ただし、ユーザーは複数のクライアントデバイス全体で高速で正確なレスポンスが必要です。サービスはこれに依存しているため、稼働率とパフォーマンスが重要です。特にこの最後のポイントですが、推論に関しては、インシデントや障害は非常に大きな影響と高い可視性を持つ可能性があります。AIが不正確または有害な情報を提供しているというニュースになるのは避けたいところです。
では、問題パターンを見てみましょう。異なるUIのフロントエンドの問題、上流の依存関係、そしてこれらすべてのサポートサービスが信頼性に影響を与える可能性があります。ネットワークの問題があり、そしてAIユースケースについて話すときはGPUを常に視野に入れておく必要があります。推論ではそれほど重要ではなく、ユーザーの小さなセットにのみ影響を与える可能性がありますが、それでも最終的には追跡することが重要です。
では、Chronosphereに戻ります。ここでは、プラットフォームチームが推論を自社ホストしている観点から見ています。他のサービスと同様に、request、errors、durationなどの赤いメトリクスについてはすべて気にかけています。しかし、推論自体の精度と健全性を評価およびベンチマークする方法も必要です。それがここで見られるhallucination rate、biased response rate、toxic response rateです。つまり、すべてのテレメトリが1か所にあり、これらの異なるものを相関させています。
顧客からいただくポジティブなフィードバックの1つは、Chronosphereのあらゆるグラフをクリックして、differential diagnosisという異常検知機能にアクセスできるということです。例えば、そこにあるスパイクについて、その異常に最も独特に関連しているラベルを素早く特定することができます。それはビルドバージョンですか、クラスタバージョンですか、コンテナですか、それとも何か別のものですか?これが、大規模な observability 実装のノイズの中でしばしば失われる実行可能な情報です。
AI nativeプロダクトにおける幻覚・バイアス・トークン消費の課題とOTelトレースによる対策
では、ギアをシフトし始めます。モデルのトレーニングとファインチューニングについて話してきました。これは私たちの見方では、より小さな組織のセットです。ほとんどの組織が実際に行っているのは、推論を消費し、その上に構築することです。では、まずこの用語「AI native」を定義しましょう。
確実には主観的な部分もあると思いますが、私たちが AI native と言うときの見方は、最初の日から AI テクノロジーを中心に設計・構築している人たちのことです。これをテストする楽しい方法の一つは、プロダクト担当者やファウンダーが「もし私たちが」と言って、そこに任意のプロダクトカテゴリーを入れるんです。IDE でも HR ツールでも何でもいいんですが、「でも AI を使ったら」と言う。ほとんどの場合、それが AI native プロダクトになるということです。
上の方に見えるのが従来のアーキテクチャです。厳密なスキーマとデータモデルを持っていて、REST アーキテクチャを使っています。これらの機能を一つ一つエンドポイントの背後に実装して、異なるクライアントデバイスを通じてアクセスします。でも AI の場合は、下の方にあるように、データモデルについてそこまで厳密である必要がなくなります。また、すべての機能を個別に実装する必要もありません。なぜなら LLM には推論する能力があり、事前に実装されていない動的なリクエストに対応でき、構造化されていないデータも使用できるからです。
今見えているのは、inference とトークン、推論と RAG 機能を中心に構築された機能です。そして本当に prompt と context engineering を中心に最適化しています。もう一つ気づくかもしれないのは、スタートアップの URL が今は innovativeguy.AI みたいな感じになっているということです。disruptiveproduct.io ではなくて。
他にもいくつかの用語がありますが、これまでもたくさん話してきたので、念のため確認しておきたいのですが、トークンと言うときは、基本的に LLM に入出力される単語数のことを意味しています。これはスループットを測定するためにも、価格を計算するためにも使われます。他の重要な概念としては、evaluations があります。これは LLM への入力を取って、得られた出力を見て、それが期待通りなのか、健全なのか、必要なことをしているのかを評価することです。そして最後に、RAG、つまり retrieval augmented generation は、外部データセットを通じて foundation model が利用できる知識またはデータを拡張するものです。
最後に inference health のユースケースに到達します。通常重要なのは、モデルの精度またはパフォーマンスで、それを直接、それらの結果を達成するために必要なトークンエコノミクスとコストと比較します。結局のところ、AI native 企業が本当に目指しているのは、AI の使用を通じたプロダクトの差別化です。そうでなければ、AI はその問題を解決するためのツールではないかもしれません。
推論の健康状態に関する具体的な問題の例をいくつか見ていきます。observabilityがどのように解決するのかを説明します。 最初の例は、おそらく最も一般的なもので、誰もが聞いたことがあるはずです。それは幻覚（hallucinations）です。良い例としては、LLMに「OTEとは何か」と聞くと、OTEは3Dプリント望遠鏡だと答えてくるというものです。これは完全に間違っていますが、LLMは自信を持ってこれを事実として述べています。これを測定・評価する方法がなければ、ユーザーがどのくらいの頻度でこのような経験をしているのか、全く把握できません。
さらに潜在的に危険な問題は、バイアスです。採用ワークフローやエージェント型のHRなど、推論を使い始めるときに、気づかないバイアスがあると、モデルが「どの候補者を採用すべきか」と言って、「ホッケーファンだけを採用すべき」と答えるかもしれません。ホッケーコーチを採用しているのであれば、それは理にかなっているかもしれませんが、そうでなければ、これは本当に害になる可能性があります。そして最後に、推論の動作というより、トークンエコノミクスに関連する問題は、過剰なトークン消費です。「Aの次の文字は何か」という単純な質問をしているのに、モデルが「Aの次の文字はBで、その次はC」と答えてくる場合、余分な単語と文字の数を数えることができます。スケールで考えると、それは単なる無駄なお金とコストになってしまいます。
さらに詳しく掘り下げると、なぜこのようなことが起こるのでしょうか。 幻覚に戻ると、これは大部分が自分自身のプロンプティングとモデルの使用方法に関連しています。トレーニングデータの不正確さ、そしてRAGのツール不足、最新情報の欠如が考えられます。モデルは知識を持っていないため、利用できない答えを発明しようとします。バイアスに関しては、トレーニングデータにバイアスがあれば、推論にもバイアスが出ます。評価やガードレールがまったくないかもしれませんし、存在するバイアスから保護していない曖昧なプロンプトがあるかもしれません。
過剰なトークン消費は、MCP serverを使用する場合に発生します。モデルが空回りして無限にリクエストを作成し、大量のトークンを消費するのを見たことがあるでしょう。エージェント型ワークフロー内でこのようなことが起こっている場合、それをスケールすることができます。それは、GPUや他の場所に費やす可能性のある多くの無駄なコストです。また、単に出力フィルタリングがないかもしれません。レスポンス形式を指定していないため、LLMが何をしてほしいのか分からず、推測して何か無駄を生成しているのです。
推論を自分でホストしている例に戻ると、temperature設定と推論とモデル設定を確認することができます。常にトレーニングデータの品質に注意を払ってください。GPU パフォーマンスはモデルの動作に影響を与える可能性があります。ツール呼び出しを制限し、動作を変更し、レスポンスの精度に影響を与える可能性があります。
では、Chronosphere についてもう一度戻ってきましょう。これらの落とし穴から身を守るために、observability をどのように活用できるでしょうか。ここで見ているのは、Arize AI の Open Inference というライブラリでインストルメント化された OTel トレースです。これにより、標準的な OTel トレースで得られるすべてのものが得られるだけでなく、LLM 固有の属性も取得でき、それに対して多くの追加分析を行うことができます。このトレースのどこかで、従来のサービスエラーや hallucination、bias などが発生すると、この行全体が赤くなり、エージェントの推論やリクエストのどこに問題があるのかがすぐにわかります。
その後、トレンドを作成して、再び異常検知を使用することができます。右側には、スパンの詳細が表示されます。これらの LLM 固有の 属性について話すとき、私は何を意味しているのでしょうか。つまり、このようなものです。どのモデルを使用しているか、どのモデルバージョンか、実際のプロンプト、入力と出力を確認できます。これらを Phoenix のような評価システムに入力することができます。独自に作成することもできますし、コードレベルで評価を実行することもできます。また、トークンカウントと hallucination、bias、toxicity に関するこれらの評価属性もすべて取得できます。
これにより、これらの有用なトレンドをすべて駆動し、データの分析を開始することができます。では、AI ネイティブなプロダクトであれば、何を気にするでしょうか。仕事に適したモデルを選択することを気にするかもしれません。そのため、リクエストあたりの平均コストをモデル別に分解して確認できます。それを時系列で比較することができます。つまり、新しいリリースが実際にこれを変更し、プロンプティングの方法によって、あるモデルが別のモデルよりも安くなる可能性があります。例えば、これらはあなたが常に注視したい種類のものです。データドリブンな意思決定を行い、常にプロダクトと実装を改善することができます。
その後、下部ではすでに hallucination について多く話してきました。しかし、繰り返しになりますが、変更を加えるかもしれません。モデルプロバイダーが変更を加えるかもしれません。そして突然、hallucination のスパイクが見えます。あなたはそれに対応して、すぐに本番環境から取り出す必要があります。これは従来、AI と ML チームが焦点を当てていたことだと思いますが、今では SRE またはサポートオペレーターであり、本番環境でこれが起こっているのを見ると、それに対応するスピードがニュースに載らないようにするために重要になります。
最後に、私たちは多くの異なるデータについて話してきました。 強調する価値のあることの 1 つは、Chronosphere は独自のエージェントを持っていないということです。このトークで使用したすべてのデータは、OpenTelemetry SDK とコレクター、NVIDIA DCGM Prometheus exporter、Kube State metrics、Prometheus node exporter、Arize AI の Open Inference SDK、Phoenix AI、およびログ用の Fluent Bit からのオープンソースです。これがカバーしたいすべてです。うまくいけば、それは価値があったでしょう。このトークを聞いていただき、本当にありがとうございます。re:Invent の残りの時間を楽しんでください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion