Strategia routingu <code>sticky</code> deterministycznie przypisuje każdego rozmówcę do preferowanego pracownika, haszując kolejno tożsamość instalacji rozmówcy, klucz API, a następnie IP <a href="#ref-1">[1]</a>. Ich żądania trafiają na ten sam serwer, gdzie załadowany jest ich model i pamięć podręczna promptów jest gorąca. To jedno pole w konfiguracji gateway; reszta farmy pozostaje bez zmian.
Lokalność pamięci podręcznej promptów przyspiesza rozmowy
Środowiska LLM ponownie wykorzystują obliczenia w trakcie rozmowy, więc przenoszenie użytkownika między serwerami powoduje utratę tych obliczeń i każda kolejna tura wymaga ponownego przetworzenia <a href="#ref-1">[1]</a>. Sticky affinity utrzymuje rozmowy wieloetapowe na tej samej rozgrzanej ścieżce, dlatego jest idealna dla asystentów i kopilotów z ustabilizowaną populacją użytkowników. Ruch bezstanowy w partiach, taki jak przeszukiwanie embeddingów, lepiej rozdziela się za pomocą <code>least-connections</code>.
Hash, nie tabela sesji
Mapowanie to hash, a nie przechowywany stan sesji, więc nie ma nic do replikacji: przetrwa restart gateway i wiele replik gateway zgadza się co do niego bez koordynacji <a href="#ref-2">[2]</a>. Failover jest również deterministyczny dla każdego rozmówcy, więc drugi wybór pracownika użytkownika to zawsze ten sam serwer, a nawet awarie zachowują się spójnie.
Dodanie serwera niemal nikogo nie przekierowuje
Ponieważ strategia używa rendezvous hashing, dodanie lub usunięcie pracownika przekierowuje tylko tych rozmówców, których preferencje się zmieniły; pozostali zachowują swoją ścieżkę <a href="#ref-1">[1]</a>. Wywołujący bez żadnej tożsamości przechodzi do trybu round-robin, a afinitet łączy się automatycznie z trasowaniem świadomym modelu, stosując się w ramach rozgrzanego zestawu pracowników.