LLM ゲートウェイのレイテンシは、トークンが生成される前から決まっている。接続が再利用されないリクエストでは、DNS 35–80ms、TCP ハンドシェイク 40–90ms、TLS 1.3 ネゴシエーション 70–150ms、合計 160–350ms が最初のトークンの前に消える。

nRouter のエンジニアリング解説 nRouter の詳細解説は、事前確立した HTTP/2 セッション (RFC 9113) でこのコストを消す設計を公開している。ただし本当に難しいのは、プールを「作る」ことではなく「運用する」ことだ。解説から4つの教訓を抜き出す。

教訓1: GOAWAY は日常である

プロバイダはエッジを頻繁にデプロイし、接続終了を GOAWAY フレームで通知する。死にゆく接続に新しいストリームを割り当て続けると ERR_HTTP2_GOAWAY_ALREADY_SENT で落ちる。対処は、GOAWAY を受けたら即座にその接続を新規割当不可にし、last_stream_id まで drain し、並行して新しい接続を事前確立すること。

教訓2: アイドルタイムアウトは文書化されていない

プロバイダのアイドルタイムアウトはまちまちで、解説では Anthropic が約45秒、Azure Key Vault が60秒の例が挙がる。閉じられたソケットに書けば RST が返る。対処は、25秒アイドルで PING を送り、1,200ms 以内に応答がなければ破棄し、ソケット自体も35秒で先回りして退役させること。

教訓3: ストリーム上限には崖がある

SETTINGS_MAX_CONCURRENT_STREAMS は通常 100 か 250。1接続に300リクエストを多重化すれば、セッションごと落とされて300件全部が失敗する。対処は、上限の75%で並列接続を動的に追加する「ストライプ」方式。

教訓4: プールの停止は速くなければならない

リージョン障害でウォームプールがハングすると、トランスポートタイムアウトまで30秒以上待たされる。対処は、接続エラーと 5xx レートで作動するサーキットブレーカーで、保留中のストリームを 5ms 未満 でフォールバック先へ再ルーティングすること。

結果として、ゲートウェイ自体のオーバーヘッドは p50 で 1ms 未満、p95 で 2ms 未満 に収まる。ベンチマーク条件 (1,000 リクエスト、1,200 トークンのプロンプト、80 トークンの補完、gpt-4o-mini、20 スレッド、us-east-1) と全結果は nRouter の詳細解説にある。