<code>sticky</code> ルーティング戦略は、コーラーのインストールID、次にAPIキー、次にIPの順でハッシュ化し、すべてのコーラーを決定的に優先ワーカーにマッピングします。 <a href="#ref-1">[1]</a>。彼らのリクエストは同じボックスに着地し続け、そのボックスには彼らのモデルがロードされ、プロンプトキャッシュがホットな状態です。これはゲートウェイ構成の1つのフィールドであり、ファームの他は変更されません。
プロンプトキャッシュの局所性がチャットを高速化
LLMランタイムは会話全体で計算を再利用するため、ユーザーをボックス間で移動させるとその作業が破棄され、各ターンで再度計算が必要になります。 <a href="#ref-1">[1]</a>。スティッキーアフィニティはマルチターンチャットを同じウォームレーンに留めるため、安定したユーザー人口を持つアシスタントやコパイロットに適しています。ステートレスなバッチトラフィック（例：埋め込みスイープ）は、<code>least-connections</code> による分散が適しています。
ハッシュでありセッションテーブルではない
マッピングはハッシュであり、保存されたセッション状態ではないため、複製するものはありません：ゲートウェイの再起動に耐え、複数のゲートウェイレプリカが調整なしに同意します。 <a href="#ref-2">[2]</a>。フェイルオーバーもコーラーごとに決定的であり、ユーザーの第二候補ワーカーは常に同じボックスであり、障害時も一貫した動作をします。
ボックスを追加してもほとんど誰もリマップされない
この戦略はランデブーハッシュを使用しているため、ワーカーを追加または削除してもトップチョイスが変わったコーラーのみがリマップされ、それ以外は自分のレーンを維持します <a href="#ref-1">[1]</a>まったく識別情報のない呼び出し元はラウンドロビンに劣化し、アフィニティはウォームセット内のワーカーに適用されるモデル認識ルーティングと自動的に組み合わされます。