プロバイダーごとに複数のキー：重み付き分散、スティッキーな紐付け、待機キーの引き継ぎ

Reddit の人気トピック：「OpenAI のキー 1 つでは RPM が足りない。複数アカウントでローテーションするには」「キーが 429 に達して業務が待たされる」「キーを切り替えるとセッションのキャッシュ親和性が失われる」。

自前でローテーションを実装すると、粘着性、重み、待機、障害時の除外を自分で扱う必要があり、相応のエンジニアリング工数がかかります。

GateLLM のアップストリーム設定は複数の API キーを受け付けます。決定論的な重み付きハッシュ（FNV-1a）が各呼び出し元を同じアップストリームキーに固定し（TTL 内で安定。キーをその場でローテーションしても粘着性は壊れません）、重みが分散比率を決めます。キーが失敗すると、ゲートウェイはそのアップストリーム内の未試行の次のキーでリトライし、元のスティッキーな紐付けを上書きしません。

weight=0 のキーは待機系で、weight>0 のすべてのキーが失敗した後にのみ有効になります。紐付け状態（binding / predicted / stale）はコンソールで行単位に確認できます。

この仕組みはロードバランサーと直交して積み重なります。Smooth WRR がエントリ間でアップストリームを選び、次にスティッキー選択がその中のキーを選びます。