La estrategia de enrutamiento <code>sticky</code> asigna determinísticamente a cada llamante un trabajador preferido, calculando el hash de la identidad de instalación del llamante, luego la clave API y después la IP, en ese orden <a href="#ref-1">[1]</a>. Sus solicitudes siguen llegando al mismo equipo, donde su modelo está cargado y su caché de indicaciones está activa. Es un campo en la configuración del gateway; el resto de la granja permanece sin cambios.
La localidad de la caché de indicaciones mantiene las conversaciones rápidas
Los entornos de ejecución LLM reutilizan el cálculo a lo largo de una conversación, por lo que cambiar a un usuario entre equipos descarta ese trabajo y cada turno se paga de nuevo <a href="#ref-1">[1]</a>. La afinidad fija mantiene las conversaciones de múltiples turnos en la misma vía activa, por eso es adecuada para asistentes y copilotos con una población de usuarios estable. El tráfico por lotes sin estado, como un barrido de embeddings, se distribuye mejor con <code>least-connections</code>.
Un hash, no una tabla de sesiones
La asignación es un hash, no un estado de sesión almacenado, por lo que no hay nada que replicar: sobrevive a un reinicio del gateway y múltiples réplicas del gateway coinciden en ella sin coordinación <a href="#ref-2">[2]</a>. La conmutación por error también es determinista por llamante, por lo que el trabajador de segunda opción de un usuario siempre es el mismo equipo e incluso las fallas se comportan de manera consistente.
Agregar un equipo casi no reasigna a nadie
Debido a que la estrategia usa hashing de rendezvous, agregar o eliminar un trabajador solo reasigna a los llamantes cuyo primer candidato cambió; todos los demás mantienen su vía <a href="#ref-1">[1]</a>Un llamante sin identidad alguna se degrada a round-robin, y la afinidad se compone automáticamente con el enrutamiento consciente del modelo aplicándose dentro del conjunto activo de trabajadores.