MiddlewareとTrueFoundry AI Gatewayの連携

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
TrueFoundry AIゲートウェイとのミドルウェア統合
組織がAIアプリケーションをスケールさせるにつれて、モデルを本番環境で稼働させることと同じくらい、それらが何をしているかを把握することが重要になります。エンジニアは、すべての推論リクエスト(レイテンシー、トークン使用量、モデルの動作、完了理由)について可視性を必要としますが、オブザーバビリティツールをすべてのモデルやプロバイダーに接続することは、各統合において複雑で反復的な計測作業を意味します。
そこで大きな疑問となるのが、チームが使用しているすべてのモデルに対して、それぞれにカスタムエンジニアリングを行うことなく、フルスタックの可視性をどのように得るかということです。
Middlewareでは、オブザーバビリティを強力であると同時に、可能な限り簡単にすることを目指しています。そのため、この度、以下の統合を発表できることを大変嬉しく思います。 ミドルウェア との TrueFoundry AIゲートウェイ。この統合により、貴社はすべてのAI推論リクエストに対して、インフラストラクチャメトリクス、アプリケーションのトレース、ログと相関付けられた形で完全な可視性を得ることができます。これらすべてを単一の集中型プラットフォームから提供することで、AI運用が透明で管理された状態であることを保証します。
TrueFoundry AIゲートウェイの力
TrueFoundry AIゲートウェイは、開発者やプラットフォームチームがAIアプリケーションを管理、監視、スケールするための強力な手段です。数百もの大規模言語モデルへの統合アクセス、スマートルーティング、集中型ポリシー適用をすべて一箇所に集約します。単一のゲートウェイポッドで毎秒250以上のリクエストを処理し、レイテンシーは約3ミリ秒しか追加しないため、初日から本番環境レベルで利用可能です。
AIの導入が加速するにつれて、真の課題はモデルへのアクセスではなく、それに伴う複雑性の管理です。複数のプロバイダー、進化するAPI、厳格なコンプライアンス要件は、チームの作業を迅速に遅らせる可能性があります。TrueFoundry AIゲートウェイは、この複雑性に秩序をもたらし、エンタープライズAIのコントロールプレーンとして機能します。ゲートウェイを呼び出すアプリケーションに変更を加えることなく、すべてのモデルと環境にわたってアクセスを統合し、ポリシーを適用し、OpenTelemetry準拠のオブザーバビリティを提供します。
ミドルウェア:OpenTelemetryを基盤としたフルスタックオブザーバビリティ
Middlewareは、OpenTelemetryをコアな計測標準として構築されたフルスタックオブザーバビリティプラットフォームです。OTEL Collectorを通じて、トレース、ログ、インフラストラクチャメトリクス、リアルユーザーモニタリングデータを受け入れ、それらを単一の相関データレイヤーに保存することで、エンジニアリングチームにシステム全体の完全な状況を一箇所で提供します。
Middlewareが他と一線を画すのは、トレースが到着した後の処理です。スパンを個別に保存するのではなく、Middlewareはサービスが実行されているホストまたはクラスターからのインフラストラクチャ信号とそれらを相関させます。ゲートウェイスパンにおけるレイテンシーの急増を調査しているエンジニアは、ダッシュボードを切り替えることなく、トレースビューから直接そのポッドのCPUおよびメモリメトリクスに移動できます。また、Middlewareは受信したスパンデータからライブサービスとトポロジーマップを構築し、すべての計測されたサービスをサービスマップ内のノードとして可視化し、そのスパンからレイテンシーとエラーレートを自動的に計算します。
連携による相乗効果:完全な可視性を実現するシームレスな統合
MiddlewareとTrueFoundry AIゲートウェイの統合は、AIオブザーバビリティを簡素化し、強化します。この組み合わせにより、本番環境レベルの可視性をAIワークフローに簡単に組み込むことができ、システムがデプロイされた瞬間からオブザーバブルであることを保証します。
この統合ソリューションにより、TrueFoundry AIゲートウェイを通過するすべての推論リクエストは、OpenTelemetryスパンの構造化されたセットを自動的に生成します。これらのスパンには、プロンプトコンテンツ、完了コンテンツ、トークン数、モデル名、レイテンシー、完了理由がクエリ可能な属性として含まれ、その後、OTLP/HTTPを介してMiddlewareに非同期で流れます。Middlewareは、それらを他のインフラストラクチャテレメトリーとともに取り込み、ゲートウェイトラフィックを、それを呼び出すアプリケーションサービスと並んで、トポロジーマップおよびAPMビューでファーストクラスのサービスとして即座に可視化します。
機密データの完全な制御のために、TrueFoundryゲートウェイの「リクエストデータ除外」トグルは、エクスポート前にスパン属性からプロンプトと完了コンテンツを削除します。トークン数、レイテンシー、モデルメタデータは保持されるため、ユーザー入力を外部システムに公開することなく、完全な運用可視性を維持できます。厳格なネットワークエグレス要件を持つ組織の場合、ゲートウェイエクスポーターは、エンドポイントURL以外の変更を必要とせずにMiddlewareに転送する自己管理型OpenTelemetry Collectorを指すこともできます。
MiddlewareとTrueFoundryの連携の仕組み

MiddlewareとTrueFoundry AI Gatewayの連携
MiddlewareとTrueFoundry AI Gatewayは連携し、推論パスに複雑さを加えることなく可観測性を提供します。
トレースフローの仕組み
- お客様のアプリケーションはTrueFoundry AI Gatewayに推論リクエストを送信します。ゲートウェイは認証、モデル解決、ルーティングをすべてメモリ内で処理するため、 クリティカルパスで外部呼び出しは発生しません。
- ゲートウェイは、設定されたLLMプロバイダー( リクエストパスにおける唯一の外部呼び出し )にリクエストを転送し、すぐにアプリケーションに応答を返します。
- 応答が配信された後、ゲートウェイは非同期で完全なトレースイベントを内部NATSバスに公開します。エクスポートはリクエストパスの完全に外側で行われるため、推論レイテンシがOTELエンドポイントの可用性や遅延によって影響を受けることはありません。
- 専用のOTELエクスポータープロセスがNATSバスから読み取り、スパンをprotobufエンコードされたOTLP/HTTPペイロードとしてシリアル化し、AuthorizationヘッダーにMiddleware APIキーを含めて、https://<your-domain>.middleware.io:443/v1/tracesにあるMiddlewareテナントエンドポイントに送信します。
- MiddlewareはOTLPインジェストレイヤーでペイロードを受信し、相関テレメトリーバックエンドにスパンを保存します。そこでは、ログ、インフラストラクチャメトリクス、およびスタックの残りのAPMデータと相関付けて、すぐにクエリ可能です。
設定も同様に簡単です。TrueFoundryダッシュボードで「AI Engineering」→「Settings」→「OTEL Config」に移動し、MiddlewareテナントエンドポイントとAPIキーを入力し、プロトコルをprotobufエンコーディングのHTTPに設定すれば、準備完了です。
フルスタックAI可観測性を始める
AI可観測性は、複雑なインストルメンテーション作業を意味する必要はありません。MiddlewareがTrueFoundry AI Gatewayに統合されることで、設定が保存された瞬間から、推論トラフィック全体が可視化されます。 インフラストラクチャシグナルと相関付けられ、モデル名やトークン数でフィルタリング可能で、ライブサービスとポロジーにマッピングされます 。これは、カスタムエンジニアリングプロジェクトというよりもスイッチを切り替えるように簡単に設定できる、完全な本番環境対応の可観測性です。
詳細については、以下をご覧ください Middlewareドキュメント および TrueFoundry連携リファレンス をご覧になり、AIアプリケーションのフルスタック可視性をいかに簡単に実現できるかを確認してください。
準備はできましたか?今すぐTrueFoundryゲートウェイをMiddlewareに接続し、すべての推論リクエストを構造化されたクエリ可能な可観測性イベントに変えましょう。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


















.webp)
.webp)


.png)

.png)














