OpenTelemetryはローカルAIのレイテンシーをストレージおよびネットワークのスパンにどのように結び付けるのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does OpenTelemetry Connect Local AI Latency to Storage and Network Spans? - Zima Store Online

OpenTelemetryは、各操作を共有コンテキストと一貫したセマンティック属性を持つ時間計測済みのスパンとして表現することで、ローカルAIのレイテンシーをストレージやネットワーク処理と関連付けます。

家庭内AIの4秒間の応答では、トークン生成に使われる時間は一部にすぎず、残りはベクトル検索、ファイルシステムやデータベースの読み取り、キュー待ち、HTTP呼び出し、ツール実行などに費やされている可能性があります。OpenTelemetry自体がこれらの依存関係を高速化するわけではありません。1つのリクエストを、実際に経過時間を消費した各レイヤーに分解できる、互換性のあるテレメトリを提供します。

セマンティック規約により、異なるサービスで比較可能な語彙を使える

すべてのサービスが独自のスパン名や属性キーを作ると、同等の操作がモデルサーバー、データベースクライアント、ツールゲートウェイ間で無関係に見えてしまい、トレースの検索が難しくなります。セマンティック規約は、繰り返し登場する操作の分類に共通の名前と属性を定義することで、この曖昧さを減らします。

一貫した語彙があれば、各ライブラリ固有のスキーマを最初に正規化しなくても、レイテンシー分析で操作を比較できます。共有セマンティック語彙により、すべてのライブラリ固有のフィールド名を事前に変換しなくても、異なるコンポーネントのスパンを集約して解釈しやすくなります。

ローカルAIスタックにとって有益なのは、処理を平坦化することではなく分離することです。モデル生成はモデル処理として、データベースクエリはストレージ処理として、HTTP呼び出しはネットワーク依存として扱われ、3つすべてが1つのトレースに含まれていても区別できます。

GenAIスパンにより、モデル処理とエージェント・ツール処理を分離できる

モデル呼び出し、エージェント実行、ツール実行は同じリクエストに含まれていても、レイテンシーやリソースの挙動が異なる場合があります。そのため、処理全体を単一の「AI」スパンとして扱うと、実際にどこで時間が費やされたのかが分からなくなります。GenAI向けの計装では、各段階を分離して把握できる、操作レベルのフィールドが提供されます。

GenAIの操作とツール活動に関する発展途上の規約は、モデルやエージェントのワークフロー向けテレメトリを標準化しながら、アプリケーションが独自の統合スパンを追加できるようにしています。

この区別はホームサーバーで重要です。高速なローカルモデルでも、遅い検索処理やリモートツール呼び出しの背後で待たされる可能性があるためです。トレースでは、モデルにかかった時間はモデルに、オーケストレーションの遅延はそれを生み出した各レイヤーに帰属させる必要があります。

GenAIの領域では、規約がまだ発展途上の部分もあります。そのため、実装ではスキーマのバージョンを記録し、すべてのライブラリが自動的に同一の属性を出力すると想定しないようにしてください。

データベースとストレージのスパンで検索処理とI/O待ちを明らかにする

プライベートRAGやホームオートメーションでは、モデルが回答する前にベクトルストア、SQLデータベース、メタデータカタログ、ファイルシステムベースのサービスへアクセスすることがよくあります。推論が高速でも、これらの処理がレイテンシーの大部分を占める可能性があります。これらを個別のスパンとして計装すれば、ストレージにかかった時間が大まかなエージェント操作の中に埋もれるのを防げます。

データベーストレーシングでは、完全なプライベート文書をテレメトリに含めることなく、操作時間、対象システム、サニタイズ済みのクエリメタデータを確認できます。データベース呼び出しをスパンとして表現すれば、SQLやNoSQLの処理に独自の実行時間と制限された操作メタデータを持たせることができ、エージェント全体のタイマーに埋もれなくなります。

ホームナレッジベースで検索スパンが長い場合、原因はモデル生成ではなく、ディスク競合、インデックス処理、低速なリモートNASマウント、データベースのキュー待ちなどかもしれません。この診断は、最終的なAPI応答だけを計測するよりも正確です。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

クライアントとサーバーのスパンでネットワーク依存関係の範囲を把握する

ネットワーク遅延は通常、単一の普遍的な「ネットワークレイテンシー」スパンではなく、クライアントとサーバー間の操作の一部として現れます。そのため、呼び出し側の待機時間と、受信側の処理時間を比較することが有効です。対応するスパンを確認すれば、時間がサーバーにリクエストが届く前、サーバー内部、レスポンス送信後のどこで蓄積したのかを把握できます。

分散トレーシングのガイダンスでは、クライアントとサーバーのスパン関係を、計装とコンテキスト伝播によってサービス間のリクエスト経路を再構成する要素として説明しています。

これはMCPやHTTPツールで特に役立ちます。クライアントスパンが長い一方で、下流の処理スパンがかなり短い場合、サービス周辺の転送、プロキシ、接続確立、キュー待ちなどが原因である可能性があります。一方、サーバースパンが長ければ、その依存先自体の処理に注目できます。

ZimaSpaceによるMCPツールのレイテンシーの分析では、遅延が発生しうる各レイヤーを説明しています。OpenTelemetryトレーシングは、実際の1回の実行でどのレイヤーが支配的だったのかを、リクエスト単位の証拠として提供します。

メトリクスは遅い集団を示し、トレースは1つの事例を説明する

集計されたレイテンシーメトリクスは、サービス全体が広く遅くなっているかどうかを示します。一方、トレースは、代表的な1件のリクエストで遅延がどのように積み重なったかを説明します。p95の急上昇に対して、別の集計グラフではなく具体的なリクエスト経路が必要な場合、この2つを関連付けると有効です。

エグゼンプラーやトレースから生成したメトリクスを使えば、分布を個々のリクエストの証拠に結び付けられます。エグゼンプラーを利用すると、すべてのリクエスト属性をメトリクスラベルにすることなく、集計されたレイテンシー分布を代表的なリクエストトレースへ結び付けられます。

したがってホームサーバーでは、検索やツール呼び出しのレイテンシー上昇を検知し、同じリクエストに含まれるモデル、ストレージ、ネットワークのスパンを備えた代表的なトレースを調査できます。

デバッグ用データがプライベートな内容になる前に、有用なテレメトリを止める

属性を追加すると診断精度は向上しますが、テレメトリ自体がファイル名、プロンプト、文書の抜粋、家庭内の識別情報、上限のない高カーディナリティ値を含み始める可能性があります。プライベートなAIスタックには、遅い操作を特定できるだけのコンテキストが必要ですが、その操作が処理した機密内容までコピーする必要はありません。

AIオブザーバビリティには意図的な計装の境界があります。テレメトリの構造化とモデル品質の評価は、異なる問題を解決するためです。テレメトリと評価を分離することで、機密性の高いプロンプト内容が通常のパフォーマンスメタデータになるのを防ぎやすくなります。

サンプリング、エクスポート量、属性の選択にもオーバーヘッドがあるため、考えられるすべてのスパンを永続的に保持することが目的ではありません。モデル、検索、ストレージ、ネットワークの遅延を分離できる十分な詳細さを保ちつつ、ホームオブザーバビリティサーバーに安全に保存できるトレースが、実用上の到達点です。

カーディナリティも保持における境界の1つです。制限された少数の属性であればグループ化やフィルタリングを支援できますが、一意のプロンプト本文、完全なパス、文書本文、リクエストごとの識別子をメトリクスラベルにコピーすると、値が機密情報でなくても、オブザーバビリティストアのコストが上がり、検索も難しくなる可能性があります。