De <code>sticky</code> routeringsstrategie koppelt elke beller deterministisch aan een voorkeursworker, door eerst de installatiedentiteit van de beller te hashen, daarna de API-sleutel, en vervolgens het IP-adres, in die volgorde <a href="#ref-1">[1]</a>. Hun verzoeken komen steeds op dezelfde machine binnen, waar hun model geladen is en hun promptcache warm is. Het is één veld in de gatewayconfiguratie; de rest van de farm blijft ongewijzigd.
Promptcache-lokaliteit houdt chats snel
LLM-runtime hergebruikt berekeningen binnen een gesprek, dus het heen en weer schakelen van een gebruiker tussen machines verliest die berekeningen en elke beurt kost opnieuw tijd <a href="#ref-1">[1]</a>. Sticky affinity houdt multi-turn chats op dezelfde warme lijn, wat het geschikt maakt voor assistenten en copiloten met een stabiele gebruikerspopulatie. Stateless batchverkeer, zoals een embeddings-scan, wordt beter verspreid via <code>least-connections</code>.
Een hash, geen sessietabel
De mapping is een hash, geen opgeslagen sessiestatus, dus er is niets te repliceren: het overleeft een gateway-herstart en meerdere gateway-replicas zijn het er zonder coördinatie over eens <a href="#ref-2">[2]</a>. Failover is ook deterministisch per beller, dus de tweede keuze worker van een gebruiker is altijd dezelfde machine en zelfs storingen gedragen zich consistent.
Een machine toevoegen verandert bijna niemand
Omdat de strategie rendezvous hashing gebruikt, zorgt het toevoegen of verwijderen van een worker er alleen voor dat de bellers wiens topkeuze verandert worden herverdeeld; iedereen houdt zijn eigen lijn <a href="#ref-1">[1]</a>. Een beller zonder enige identiteit degradeert naar round-robin, en affinity wordt automatisch gecombineerd met modelbewuste routering door toepassing binnen de warme set van werkers.