La stratégie de routage <code>sticky</code> associe de manière déterministe chaque appelant à un worker préféré, en hachant d'abord l'identité d'installation de l'appelant, puis la clé API, puis l'IP, dans cet ordre <a href="#ref-1">[1]</a>. Leurs requêtes continuent d'atterrir sur la même machine, où leur modèle est chargé et leur cache de prompt est chaud. C'est un champ dans la configuration de la passerelle ; le reste de la ferme reste inchangé.
La localité du cache de prompt maintient la rapidité des conversations
Les environnements d'exécution LLM réutilisent les calculs au cours d'une conversation, donc faire passer un utilisateur d'une machine à une autre fait perdre ce travail et chaque tour est recalculé <a href="#ref-1">[1]</a>. L'affinité collante maintient les conversations multi-tours sur la même voie chaude, ce qui la rend adaptée aux assistants et copilotes avec une population d'utilisateurs stable. Le trafic batch sans état, comme un balayage d'embeddings, est mieux réparti par <code>least-connections</code>.
Un hash, pas une table de session
L'association est un hash, pas un état de session stocké, donc rien à répliquer : elle survit à un redémarrage de la passerelle et plusieurs réplicas de passerelle s'accordent dessus sans coordination <a href="#ref-2">[2]</a>. Le basculement est aussi déterministe par appelant, donc le worker de second choix d'un utilisateur est toujours la même machine et même les pannes se comportent de façon cohérente.
Ajouter une machine ne remappe presque personne
Parce que la stratégie utilise le hachage de rendez-vous, ajouter ou retirer un worker ne remappe que les appelants dont le premier choix a changé ; tous les autres conservent leur voie <a href="#ref-1">[1]</a>. Un appelant sans aucune identité revient à un mode round-robin, et l'affinité se compose automatiquement avec le routage conscient du modèle en s'appliquant au sein de l'ensemble chaud des travailleurs.