Colocar el clasificador en el mismo rack que el motor de emparejamiento baja la latencia hasta los microsegundos, pero cambia por completo la forma de operar. Ya no hay margen para un reintento silencioso ni para un ciclo de despliegue cómodo: cada decisión del modelo ocurre dentro del mismo presupuesto temporal que la propia ejecución de la orden.
El primer límite aparece en el hardware. Una tarjeta dedicada en el chasis del servidor de bolsa tiene memoria acotada y un número fijo de hilos de cómputo. Eso obliga a elegir entre un modelo más profundo con mejor detección o un modelo más pequeño que quepa con holgura en la ventana de inferencia. En la práctica se dimensiona por encima del pico medido, no del promedio, porque las ráfagas de cancelaciones llegan agrupadas y el acelerador no puede esperar.
Versionar pesos sin detener el flujo
Actualizar un modelo en caliente exige cargar los pesos nuevos en una partición separada y hacer el cambio de puntero entre dos mensajes del feed. Si la carga tarda más que el intervalo entre eventos, la cola se llena y el propio mecanismo de defensa introduce el bloqueo que pretendía evitar. Por eso los operadores exigen ventanas de mantenimiento declaradas, versiones firmadas y un rollback inmediato si la métrica de falsos positivos se sale del rango acordado.
Los acuerdos de nivel de servicio suelen fijar tres cosas: latencia máxima de inferencia, tasa de falsos positivos tolerable y tiempo de reversión. Cuando el modelo se degrada por deriva de datos, el respaldo es un clasificador más simple con umbrales conservadores, no la desactivación total del filtro.
- Presupuesto de memoria y cómputo reservado antes de elegir la arquitectura de red.
- Carga de pesos en partición paralela y conmutación de puntero entre eventos del feed.
- Umbrales de deriva y rollback automático si la tasa de falsos positivos sube.
- Respaldo con reglas simples cuando el modelo principal pierde fiabilidad.