Latencia de ejecución algorítmica en Binance: medir y reducir el intervalo

Un backtest asume que te llenas al precio exacto que vio tu señal. El trading en real no funciona así. El intervalo entre que salta la señal y la orden se llena de verdad en el exchange es donde los algoritmos retail pierden en silencio un 0,5-2% por operación: suficiente para convertir un backtest rentable en una estrategia perdedora en real. Ese intervalo se puede medir, y casi todo se puede corregir sin infraestructura exótica.

Qué es realmente la latencia

La latencia total de ejecución de un algoritmo cripto retail típico es la suma de cuatro componentes:

• Latencia de detección — tiempo desde que la condición de mercado se cumple hasta que tu código la reconoce.
• Latencia de decisión — tiempo dedicado a calcular si actuar sobre la detección.
• Latencia de red — tiempo que tarda tu orden en viajar desde tu servidor hasta el motor de emparejamiento de Binance.
• Latencia del exchange — tiempo que Binance tarda en confirmar, encolar y ejecutar la orden.

De extremo a extremo en una VM cloud retail típica, esto suma 600–1500 milisegundos. De extremo a extremo en una mesa institucional con colocation junto a Binance: 5–15 milisegundos. Dos órdenes de magnitud de diferencia. El retail no puede cerrar la mayor parte de ese intervalo, pero sí lo suficiente como para que las estrategias sistemáticas sean viables.

Latencia de detección: donde pierde la mayoría del retail

Este es el intervalo desde que «la condición de mercado se cumplió» hasta que «tu código se entera». La mayoría de estrategias retail consultan la REST API cada pocos segundos, lo que significa que tu latencia mínima de detección es tu intervalo de sondeo: normalmente de 1000 a 5000 ms.

La solución: streams de WebSocket. Binance publica feeds WebSocket en tiempo real para kline, aggTrade, depth, mark price y forceOrders. Suscribirte al WebSocket significa que tu código ve los mismos datos que Binance, en tiempo real, sin retardo de sondeo.

En concreto: una suscripción kline por WebSocket entrega la vela de 1 minuto cerrada dentro de los 100 ms del cierre. Un sondeo REST de esos mismos datos, incluso en un bucle rápido, irá 1500–3000 ms por detrás. Pasar de sondeo REST a WebSocket reduce la latencia de detección en un orden de magnitud.

Para la detección basada en aggregate trades, el WebSocket entrega cada operación según se ejecuta: menos de 100 ms desde el match. Es la fuente de señal más limpia para cualquier estrategia de horizonte corto.

Latencia de decisión: fácil de ganar

Este es el intervalo entre la llegada de los datos y el envío de la orden. La mayoría de la lógica de decisión retail es simple: comprobar unos cuantos umbrales, calcular el tamaño de posición, enviar la orden. De extremo a extremo, bastante menos de 10 ms si el código está razonablemente escrito.

Dónde se dispara la latencia de decisión:

• I/O de base de datos para consultar estado histórico. Si consultas MongoDB o PostgreSQL en cada señal, sumas 5-50 ms.
• Llamadas HTTP externas dentro de la ruta de decisión. Cualquier cosa que traiga datos frescos de otra API a mitad de decisión suma al menos el tiempo de ida y vuelta.
• Pausas de garbage collection en runtimes interpretados. Node.js o Python pueden pausar 50-200 ms durante el GC bajo carga.

Solución: mantén el estado en memoria, precarga los datos dependientes antes del evento disparador, minimiza las asignaciones dentro de la ruta de decisión. La mayoría de los algos retail desperdician aquí 20-50 ms que podrían ser 1-2 ms.

Latencia de red: la geografía importa

El motor de emparejamiento principal de futuros de Binance está en AWS Tokio (ap-northeast-1). La latencia de red desde ahí la fija la velocidad de la luz más la ineficiencia de enrutado.

Tiempos típicos de ida y vuelta retail desde proveedores de VPS:

• AWS Tokio: 1-3 ms (lo mejor posible sin colocation)
• AWS Singapur: 60-90 ms
• AWS Fráncfort: 220-260 ms
• AWS US-East: 160-200 ms
• Hetzner Helsinki: 250-300 ms

Si tu bot corre en un VPS en Fráncfort y Binance está en Tokio, tienes un suelo permanente de latencia de 250 ms de ida y vuelta. Ninguna optimización de código puede cerrar ese intervalo.

La mayor mejora individual de latencia que puede hacer la mayoría de los algos retail es mover el bot a AWS Tokio (ap-northeast-1). Un t4g.small de 20 $/mes en Tokio te da la misma latencia de red hacia Binance que un servidor con colocation de 20.000 $/mes, con un margen de unos pocos milisegundos. El intervalo restante está en la cola interna del exchange, y eso no se compra con dinero.

Latencia del exchange: lo que no puedes controlar

Desde que la orden llega al borde de Binance hasta que se confirma suele haber 5-20 ms. Desde la confirmación hasta la ejecución real (fill o resto en libro) hay otros 1-50 ms según el tipo de orden. Esto queda en gran parte fuera de tu control, pero tiene implicaciones.

La implicación: la cola de Binance no es FIFO para todos los usuarios. Las cuentas de mayor nivel (VIP-1, VIP-2, etc.) tienen carriles de ejecución más rápidos. Si eres un usuario retail sin verificar, tus órdenes hacen cola detrás de las de usuarios VIP en momentos de tráfico intenso. No hay forma de saltarse esto salvo operar suficiente volumen para llegar tú mismo a VIP-1 (unos 50 M$/mes).

Esto importa para las estrategias sensibles al tiempo. Las estrategias event-driven sensibles a la latencia, donde la calidad de la operación depende de ser más rápido que el siguiente usuario lento de tier inferior, pueden ser sensibles a los carriles de ejecución por nivel de usuario. Para estrategias de horizonte más largo (nuestros modelos direccionales y de reversión a la media), esa diferencia de unos cientos de milisegundos apenas importa.

Medir tu propia latencia

Instrumenta cada paso. Para cada orden:

• t1 — marca de tiempo del evento de mercado (cierre de kline, fill de aggTrade, etc.). Del timestamp del mensaje WebSocket.
• t2 — marca de tiempo en que tu código recibió el mensaje. De tu reloj local.
• t3 — marca de tiempo en que tu código despachó la orden. De tu reloj local justo antes del envío HTTP.
• t4 — marca de tiempo en que Binance confirmó la orden. De la respuesta de la orden.
• t5 — marca de tiempo en que Binance llenó la orden. De la notificación de fill.

Delta t2−t1 es tu latencia de red/WebSocket desde Binance hasta ti. Delta t3−t2 es tu latencia de decisión. Delta t4−t3 es tu latencia de envío de orden + ack de Binance. Delta t5−t4 es el tiempo dentro del motor de emparejamiento de Binance. Registra las cinco en cada operación. Tras una semana, tienes una imagen clara de dónde vive la latencia.

La mayoría de los bots retail que nunca han medido esto descubren que su mayor contribuyente de latencia es algo que no esperaban: normalmente latencia de decisión por una consulta a base de datos que olvidaron que estaba en la ruta caliente.

Lo que conseguimos de verdad a nivel interno

Nuestra infraestructura corre en Hetzner Fráncfort (somos una firma con base en la UE; el coste de latencia es el precio de la jurisdicción europea). Latencia típica de extremo a extremo desde el disparo de la señal hasta el ACK de la orden en Binance en el libro de la firma: 280-340 ms.

Desglose: 0 ms de detección (WebSocket); ~5 ms de decisión; ~250 ms de ida y vuelta de red; ~25 ms de ACK de Binance. Los 250 ms de red son el precio de operar en la UE en vez de Tokio. Mover la infraestructura a Tokio recortaría eso a unos 20 ms de ida y vuelta total.

Para las estrategias event-driven sensibles a la latencia —donde la velocidad es el edge— esto es genuinamente demasiado lento. Llevamos tiempo migrando esa estrategia concreta a Tokio. Para nuestros modelos, donde el edge está en el trabajo analítico previo a la operación y no en la velocidad de ejecución, la infraestructura en la UE está bien.

La conclusión honesta

La optimización de latencia tiene rendimientos decrecientes. Las primeras victorias fáciles (suscripción WebSocket, VPS en Tokio) te dan el 80% de lo posible sin inversión seria. El 20% restante cuesta órdenes de magnitud más (servidores con colocation, red con kernel bypass, matching por FPGA) y solo merece la pena para estrategias donde la velocidad es el edge.

La mayoría de los algoritmos retail pueden llegar a una ejecución «suficientemente buena» con 50 $/mes de infraestructura y unos días de trabajo. Las estrategias que necesitan más o bien tienen una sensibilidad temporal específica (y deberían invertir en consecuencia) o bien tienen un edge que de entrada no depende de la velocidad, en cuyo caso la obsesión con la latencia es esfuerzo desperdiciado.