あなたのAIゲートウェイはどの程度優れていますか？
本記事では、Highflame、Bifrost、LiteLLMの3つのAIゲートウェイを、最初のトークン遅延、ピーク時の同時接続、ツール呼び出しの3つの重要な瞬間で評価します。Highflameは遅延を最小限に抑え、5000の同時会話下でも100%の成功率を達成し、MCPプロキシにおいても効率的です。
AIモデルの本番環境では、ゲートウェイが不可欠なコンポーネントです。統合ルーティング、APIキー管理、使用量監視、トラフィックスキャンを提供しますが、すべてのリクエストの経路上に存在するため、そのパフォーマンスがユーザー体験を左右します。本記事では、Highflame（Rust）、Bifrost（Go）、LiteLLM（Python）の3つのゲートウェイを3つの重要な指標でテストしました。
第一の瞬間：最初のトークン遅延 ユーザーが最初のトークンを待つ時間は、アプリがハングしたかどうかを判断する瞬間です。モデル自体は約300ミリ秒で最初のトークンを生成します。Highflameはわずか2ミリ秒しか追加せず、100同時チャットでも307ミリ秒を維持し、ゲートウェイなしとほぼ同じです。Bifrostはデフォルトで応答全体をバッファリングし、モデルが完了するまで解放しないため、最初のトークンに1.3秒の遅延が発生し、UIがフリーズしたように見えます。LiteLLMは10同時チャットでは問題ありませんが、トークンごとの処理オーバーヘッドが負荷に応じて累積し、50同時チャットで約350ミリ秒、100同時チャットでは最初のトークンの中央値が6.3秒に達し、総応答時間が1.6秒から7.7秒に延びます。
第二の瞬間：ピーク時の同時接続 現実の会話は接続を開いたままにします。各リクエストは約2秒待ってから完了するため、忙しい午後には数千のソケットが同時に開かれます。5,000の同時会話を5分間保持するテストで、Highflameは572,563の全リクエストを処理し、成功率100%、p99は3.3秒、メモリ使用量は733MBでした。Bifrostも100%成功しましたが、メモリは1.5GBと2倍必要でした。LiteLLMは30%のリクエストしか処理できず、生存者の中央値待ち時間は6.2秒、p99は26.7秒、70%のリクエストが失われました。100会話では3つとも成功しますが、500会話ではLiteLLMの中央値がモデル自身の2秒を超えます。この差は、成長計画の規模で現れます。
第三の瞬間：ツール呼び出し エージェントはツールを呼び出し、MCPがその経路です。Highflameは、MCPクライアントとサーバーの間で透過的にプロキシできる唯一のゲートウェイでした。10同時セッションで17ミリ秒、100セッションで181ミリ秒（主にキューイング遅延）を追加し、スループットは毎秒260コール、成功率100%でした。極限テストでは、4コアの単一インスタンスが毎秒6,800コール（ピーク8,200）を処理し、直接接続時の1,526コールを大きく上回りました。これは、プロキシが接続プールを再利用するためです。200ミリ秒のツールに対しても、理論最大の5,000コール/秒に対し4,832コール/秒を達成。MCPプロキシは、認証、Cedarポリシー、Shieldスキャンの実行ポイントでもあります。
導入と選択 Highflameは起動時に25MB、ピーク時733MBのメモリで動作し、サイドカーとしてデプロイ可能です。一方、LiteLLMは起動時に486MBを消費しながら性能は低い。ゲートウェイ選定では、最初のトークン遅延、ピーク処理能力、ツール呼び出しのオーバーヘッドを重視すべきであり、Highflameはこれらすべてで優れています。