<code>sticky</code>-routningsstrategin kopplar varje uppringare deterministiskt till en föredragen arbetare genom att hasha uppringarens installationsidentitet, sedan API-nyckel och därefter IP, i den ordningen <a href="#ref-1">[1]</a>. Deras förfrågningar fortsätter att hamna på samma enhet, där deras modell är inläst och deras prompt-cache är varm. Det är ett fält i gateway-konfigurationen; resten av farmen är oförändrad.
Prompt-cache-lokalitet håller samtalen snabba
LLM-runtime återanvänder beräkningar över en konversation, så att hoppa mellan enheter för en användare slösar bort det arbetet och varje steg kostar på nytt <a href="#ref-1">[1]</a>. Sticky affinity håller flerstegs-samtal på samma varma bana, vilket är anledningen till att det passar assistenter och copiloter med en stabil användarbas. Statisk batchtrafik, som en embeddings-genomsökning, sprids bättre med <code>least-connections</code>.
En hash, inte en sessionstabell
Kartläggningen är en hash, inte lagrat sessionsläge, så det finns inget att replikera: den överlever en gateway-omstart och flera gateway-repliker är överens om den utan samordning <a href="#ref-2">[2]</a>. Failover är också deterministisk per uppringare, så en användares andrahandsval av arbetare är alltid samma enhet och även fel beter sig konsekvent.
Att lägga till en enhet omkartlägger nästan ingen
Eftersom strategin använder rendezvous-hashing omkartlägger tillägg eller borttagning av en arbetare bara de uppringare vars förstahandsval ändrats; alla andra behåller sin bana <a href="#ref-1">[1]</a>. En anropare utan någon identitet alls degraderas till round-robin, och affinitet kombineras automatiskt med modellmedveten dirigering genom att tillämpas inom den varma uppsättningen av arbetare.