La strategia di instradamento <code>sticky</code> associa ogni chiamante in modo deterministico a un worker preferito, calcolando l'hash dell'identità di installazione del chiamante, poi della chiave API, poi dell'IP, in quest'ordine <a href="#ref-1">[1]</a>. Le loro richieste continuano a essere gestite dalla stessa macchina, dove il loro modello è caricato e la cache dei prompt è calda. È un campo nella configurazione del gateway; il resto del cluster rimane invariato.
La località della cache dei prompt mantiene le chat veloci
I runtime LLM riutilizzano i calcoli durante una conversazione, quindi spostare un utente tra macchine fa perdere quel lavoro e ogni turno paga nuovamente il costo <a href="#ref-1">[1]</a>. L'affinità sticky mantiene le chat multi-turno sulla stessa corsia calda, motivo per cui è adatta ad assistenti e copiloti con una popolazione utente stabile. Il traffico batch senza stato, come una scansione di embeddings, è meglio distribuito tramite <code>least-connections</code>.
Un hash, non una tabella di sessione
La mappatura è un hash, non uno stato di sessione memorizzato, quindi non c'è nulla da replicare: sopravvive a un riavvio del gateway e più repliche del gateway concordano su di esso senza coordinamento <a href="#ref-2">[2]</a>. Il failover è deterministico per ogni chiamante, quindi il worker di seconda scelta di un utente è sempre la stessa macchina e anche i guasti si comportano in modo coerente.
Aggiungere una macchina rimappa quasi nessuno
Poiché la strategia usa il rendezvous hashing, aggiungere o rimuovere un worker rimappa solo i chiamanti il cui primo preferito è cambiato; tutti gli altri mantengono la loro corsia <a href="#ref-1">[1]</a>. Un chiamante senza alcuna identità degrada a round-robin, e l'affinità si compone automaticamente con il routing consapevole del modello applicandosi all'interno del set caldo di lavoratori.