TrueFoundryとのArize連携

TrueFoundry AI Gatewayを通過するすべてのLLMリクエストはトレースを生成します。そのトレースは、ゲートウェイ処理、JWT検証、認証解決、プロバイダールーティング、アウトバウンドモデル呼び出し、ストリーミング応答といったリクエストの完全なスパンツリーを捕捉します。これらのトレースは、TrueFoundry Monitor UIのために内部に保存されます。しかし、標準のOpenTelemetryプロトコルを介して、外部の可観測性バックエンドにエクスポートすることも可能です。Arizeはそのようなバックエンドの一つです。

この記事では、アーキテクチャレベルでトレースのエクスポートがどのように機能するかを解説します。具体的には、どのようなOTELプリミティブが関与しているか、ゲートウェイがリクエストパスにレイテンシを追加することなくトレースをどのように出力するか、そしてトレースデータが到着した後にArizeがそのデータをどう処理するかについてです。また、設定インターフェースや、プロンプトコンテンツがインフラストラクチャを離れる前に削除できるデータプライバシー制御についても説明します。

OpenTelemetryとLLMの可観測性

OpenTelemetryは、分散トレースのためのベンダーニュートラルなワイヤーフォーマットを定義しています。トレースは、親子関係によって接続されたスパンのツリーです。各スパンは、HTTPハンドラ、LLM呼び出し、ツール呼び出しといった個別の作業単位を表します。スパンには、レイテンシ、ステータスコード、トークン数などの運用コンテキストをエンコードする型付きキーバリュー属性が含まれます。

標準のOTELセマンティック規約は汎用分散システムをうまくカバーしていますが、LLMワークロード向けには設計されていませんでした。LLM呼び出しは、構造化された入力（システムプロンプト、ツール定義、マルチモーダルコンテンツを含む複数ターンのメッセージ配列）と構造化された出力（完了理由と関数呼び出しを含む完了）を伴います。トークンエコノミクスは、第一級の運用メトリクスです。プロンプトトークン、完了トークン、キャッシュトークン、推論トークンはすべてスパンごとに追跡する必要があります。単一の input.value 文字列属性では不十分です。

ここで、LLM固有のセマンティック規約が登場します。Arizeは、OTELスパンの上に具体的な属性スキーマとスパン種別の分類法を定義するOpenInference仕様を維持しています。すべてのOpenInferenceトレースは、有効なOTLPトレースです。これらの規約は、属性名にAI固有の意味を与えます。LLM、 LLM や CHAIN や RETRIEVER や TOOL や EMBEDDING といったスパン種別は、操作を分類し、可観測性プラットフォームがAI対応の可視化と集計でトレースをレンダリングできるようにします。

TrueFoundry AI Gatewayは、独自の属性ネームスペースを使用してトレースを出力します（tfy.input と tfy.output と tfy.input_short_hand 標準の gen_ai.* トークン数、モデルのメタデータ、完了終了理由に関する属性）。Arizeはこれらを有効なOTLPトレースとして取り込み、その属性をトレースUIにマッピングします。

ゲートウェイがトレースを生成する方法

TrueFoundry AI Gatewayは、設定を管理するコントロールプレーンと、推論リクエストを処理するゲートウェイプレーンという分割アーキテクチャを採用しています。ゲートウェイプレーンは、超高速なエッジ最適化HTTPランタイムであるHonoフレームワーク上に構築されています。1 vCPUと1 GB RAMを搭載した単一のゲートウェイポッドは、約3ミリ秒の追加レイテンシで毎秒250以上のリクエストを処理します。

重要な設計原則は、実際のLLMプロバイダーへの呼び出しを除き、リクエストパスに外部呼び出しがないことです。リクエストがゲートウェイポッドに到着すると、以下の処理がすべてメモリ内で実行されます。

1. ポッドは、IdPからダウンロードされたキャッシュ済みの公開鍵に対してJWTトークンを検証します。外部認証呼び出しは発生しません。
2. メモリ内の認証マップ（NATSを介してコントロールプレーンから同期されます）を確認し、ユーザーが要求されたモデルへのアクセス権を持っていることを検証します。
3. モデル識別子を特定のプロバイダーエンドポイントに解決します。モデルがルーティングルールを持つ仮想モデルである場合、ゲートウェイはここで優先度ベース、重みベース、またはレイテンシベースの選択ロジックを適用します。
4. アダプターは、リクエストをOpenAI互換フォーマットからターゲットプロバイダーのネイティブフォーマットに変換します。
5. リクエストはプロバイダーに転送され、レスポンスはクライアントにストリーミングで返されます。

トレース生成は、このフローと並行して非同期で行われます。ゲートウェイは、リクエストライフサイクルの各ステージ（インバウンドHTTPハンドラー、認証チェック、モデル解決、アウトバウンドプロバイダー呼び出し、ストリーミングレスポンス）に対してOTELスパンを作成します。これらのスパンには、トークン使用量、レイテンシ、モデル名、プロバイダー、コスト見積もり、リクエストメタデータをキャプチャする属性が含まれています。リクエストが完了すると、ゲートウェイはトレースデータをNATSメッセージキューに公開します。これは、コントロールプレーンとゲートウェイポッド間の設定同期を処理するのと同じNATSバスです。

OTELエクスポーターは、この非同期パスからトレースデータを取得し、設定された外部エンドポイントに転送します。トレースのエクスポートはリクエストパスから分離されているため、推論リクエストにレイテンシを追加しません。外部OTELエンドポイントに到達できない場合でも、ゲートウェイがリクエストを失敗させることはありません。

Arizeによるトレースの活用

Arizeは、LLMおよびエージェントのワークロード向けに特別に構築されたAIオブザーバビリティおよび評価プラットフォームです。gRPCを介してOTELトレースを受け入れます。 otlp.arize.com:443 生のトレースデータの上に、多層的な分析を提供します。

トレースの可視化。 Arizeは、各リクエストのスパンツリーを示す完全なトレースウォーターフォールをレンダリングします。個々のスパンを検査して、トークンの使用状況、レイテンシーの内訳、入出力コンテンツ、モデルのメタデータを確認できます。単一のユーザーリクエストが複数のLLM呼び出しやツール呼び出しをトリガーするエージェントワークフローでは、このウォーターフォールビューによって実行パスが明確になります。

パフォーマンス分析。 Arizeは、トレースストリーム全体で集計メトリクスを計算します。具体的には、モデル別およびプロバイダー別のレイテンシー分布、時間経過に伴うエラー率、スループットの傾向などです。これらの分布に異常が現れたときに発動するアラートルールを設定できます。これは、エンドユーザーに影響が及ぶ前にプロバイダーの劣化を検知するのに役立ちます。

LLM評価。 生のトレース機能を超えて、Arizeは自動評価パイプラインをサポートしています。関連性、一貫性、事実性などの側面で完了を評価する「LLMをジャッジとして使用する」ワークフローを実行できます。また、より詳細な品質評価のために、人間のアノテーションワークフローを導入することも可能です。トレースは、これらの評価ループに供給される生のデータ（入力、出力、モデルパラメータ）を提供します。

重要な差別化要因は、ArizeがLLM固有のセマンティクスをネイティブに理解している点です。一般的な文字列のキーと値のペアとして扱うのではなく、スパンス属性からトークン数、モデル識別子、プロンプトコンテンツを解析し、それらを専用のビューで表示します。

統合インターフェース

この統合は、ゲートウェイからArizeへの直接gRPCエクスポートです。コレクターサイドカーもカスタムSDKも不要です。TrueFoundryダッシュボードでOTELエクスポーターを設定するだけで、トレースが流れ始めます。

統合手順はこちらで確認できます。 https://www.truefoundry.com/docs/ai-gateway/arize

リソース属性

エクスポートされるすべてのトレースに、追加のリソース属性を付加できます。これらはトレースレベルで追加されるキーと値のペアであり、Arizeでのフィルタリングやグループ化に役立ちます。

設定する最も一般的な属性は model_idです。Arizeはこれを使用して、ダッシュボードビューでトレースをモデル別にグループ化します。ファインチューニングされたLLamaモデルを介して本番トラフィックをルーティングしている場合、 model_id に finetuned-llama-3-production。また、 model_version を追加すると、並行デプロイを実行している場合にArizeでバージョン間のパフォーマンスを比較できます。

データプライバシー管理

プロンプトの内容や完了の内容がインフラストラクチャから外部に出るべきではないデプロイシナリオがあります。コンプライアンス要件により、リクエストボディをサードパーティサービスに送信することが禁止される場合があります。プロンプト内のPII（個人識別情報）により、外部へのエクスポートが不可能になることもあります。

TrueFoundryは、OTELエクスポーター設定の「リクエストデータ除外」トグルでこれを処理します。有効にすると、ゲートウェイはエクスポート前に3つのスパン属性を破棄します。 tfy.input および tfy.output および tfy.input_short_handです。Arizeは構造的なトレースデータ（レイテンシー、トークン数、モデルメタデータ、エラー状態）を受け取りますが、プロンプトや完了の実際の内容を見ることはありません。

これは重要なアーキテクチャの詳細です。フィルタリングは、トレースデータがgRPCエクスポーターに到達する前にゲートウェイレベルで行われます。コンテンツがゲートウェイポッドから出ることはありません。機密性の高いコンテンツを外部プラットフォームに公開することなく、パフォーマンス、コスト、信頼性に関する完全な可観測性を得られます。

統合の検証

OTEL設定を保存した後、ゲートウェイ経由でいくつかのLLMリクエストを送信します。その後、Arizeダッシュボードを開き、「Traces」に移動します。 tfy-llm-gateway サービスからのトレースを探します。各トレースには、ゲートウェイ処理スパンと外部LLMプロバイダー呼び出しスパンを含む完全なスパンツリーが表示されるはずです。個々のスパンをクリックして、トークン使用量、レイテンシー、モデルメタデータが正しく入力されていることを確認します。

リソース属性を設定した場合、それらがトレースメタデータに反映されているはずです。 model_id トレースリストをフィルタリングし、トレースがモデルごとに正しくグループ化されていることを確認するための属性。

アーキテクチャ概要

データフローはシンプルです。アプリケーションはLLMリクエストをTrueFoundry AI Gatewayに送信します。ゲートウェイはリクエストをメモリ内で処理し（認証、認可、ルーティング、レート制限）、設定されたモデルプロバイダーに転送します。並行して、ゲートウェイはリクエストのライフサイクルに関するOTELスパンを生成し、NATSメッセージキューに非同期で公開します。OTELエクスポーターはこのキューから読み取り、gRPC経由でトレースを送信します。 otlp.arize.com:443。ArizeはOTLPトレースを取り込み、それらを可視化、分析、評価に利用できるようにします。

推論パスに外部呼び出しは追加されません。コレクターサイドカーをデプロイする必要はありません。アプリケーションコードの変更は不要です。ゲートウェイが唯一の計測ポイントであり、OTELエクスポートはゲートウェイ自身の内部トレースストレージに追加される形です。同じトレースデータに対して、TrueFoundryの組み込みMonitor UIを引き続き使用しながら、Arizeにエクスポートできます。

これが、OTELをプロトコルとして選択する価値がある理由です。ゲートウェイは標準のOTLPトレースを出力します。Arizeは標準のOTLPトレースを受け入れます。もし明日、オブザーバビリティのバックエンドを切り替えることにした場合、ゲートウェイ設定のエンドポイントとヘッダーを変更し、別のOTLPレシーバーを指すようにするだけです。アプリケーションコード、ゲートウェイ設定、トレース計測はすべてそのまま維持されます。