Задержка алгоритмического исполнения на Binance: как измерить и сократить разрыв

Бэктест исходит из того, что вы заходите ровно по той цене, которую увидел сигнал. В реальной торговле так не бывает. Промежуток между срабатыванием сигнала и фактическим исполнением ордера на бирже — это место, где розничные алгоритмы тихо теряют 0,5-2% на сделке, чего достаточно, чтобы прибыльный бэктест превратился в убыточную стратегию вживую. Этот промежуток измерим, и большую его часть можно устранить без экзотической инфраструктуры.

Что такое задержка на самом деле

Полная задержка исполнения у типичного розничного крипто-алгоритма складывается из четырёх компонентов:

• Задержка обнаружения — время от момента, когда рыночное условие выполнилось, до момента, когда его распознал ваш код.
• Задержка решения — время на вычисление того, действовать ли по обнаруженному сигналу.
• Сетевая задержка — время, за которое ваш ордер доходит от вашего сервера до движка сведения заявок Binance.
• Задержка биржи — время, за которое Binance подтверждает, ставит в очередь и исполняет ордер.

На типичной розничной облачной VM сквозная задержка в сумме даёт 600–1500 миллисекунд. У институционального деска с colocation рядом с Binance она составляет 5–15 миллисекунд. Разница в два порядка. Розничный трейдер не закроет бо́льшую часть этого разрыва, но закроет достаточную его часть, чтобы системные стратегии оставались жизнеспособными.

Задержка обнаружения: где теряет большинство розницы

Это промежуток от момента, когда «рыночное условие выполнилось», до момента, когда «об этом узнал ваш код». Большинство розничных стратегий опрашивают REST API каждые несколько секунд, а значит ваша минимальная задержка обнаружения равна интервалу опроса: обычно от 1000 до 5000 мс.

Решение: стримы WebSocket. Binance отдаёт WebSocket-фиды в реальном времени для kline, aggTrade, depth, mark price и forceOrders. Подписка на WebSocket означает, что ваш код видит те же данные, что и Binance, в реальном времени, без задержки опроса.

Конкретно: подписка на kline через WebSocket отдаёт закрытую минутную свечу в пределах 100 мс после закрытия. Опрос тех же данных через REST, даже в быстром цикле, отстанет на 1500–3000 мс. Переход с REST-опроса на WebSocket сокращает задержку обнаружения на порядок.

Для детекции на основе агрегированных сделок WebSocket отдаёт каждую сделку по мере исполнения: меньше 100 мс от сведения. Это самый чистый источник сигнала для любой краткосрочной стратегии.

Задержка решения: лёгкая победа

Это промежуток между приходом данных и отправкой ордера. Логика решения у большинства розничных ботов простая: проверить пару порогов, рассчитать размер позиции, отправить ордер. Сквозняком это заметно меньше 10 мс, если код написан вменяемо.

Где задержка решения подкрадывается:

• Обращения к базе данных за историческим состоянием. Если вы делаете запрос в MongoDB или PostgreSQL на каждый сигнал, добавляется 5-50 мс.
• Внешние HTTP-вызовы внутри пути принятия решения. Всё, что тянет свежие данные из другого API прямо по ходу решения, добавляет как минимум время round-trip.
• Паузы сборки мусора в интерпретируемых рантаймах. Node.js или Python под нагрузкой могут вставать на 50-200 мс во время GC.

Решение: держите состояние в памяти, подгружайте зависимые данные заранее, до события-триггера, минимизируйте аллокации внутри пути решения. Большинство розничных ботов тратят здесь впустую 20-50 мс, которые могли бы быть 1-2 мс.

Сетевая задержка: география имеет значение

Основной движок сведения заявок по фьючерсам у Binance находится в AWS Tokyo (ap-northeast-1). Сетевую задержку оттуда определяют скорость света плюс неэффективность маршрутизации.

Типичное время round-trip у розничных VPS-провайдеров:

• AWS Tokyo: 1-3 мс (лучшее возможное без colocation)
• AWS Singapore: 60-90 мс
• AWS Frankfurt: 220-260 мс
• AWS US-East: 160-200 мс
• Hetzner Helsinki: 250-300 мс

Если ваш бот работает на VPS во Франкфурте, а Binance в Токио, у вас постоянный минимум round-trip в 250 мс. Никакая оптимизация кода этот разрыв не закроет.

Самое крупное единичное улучшение задержки, доступное большинству розничных ботов, — перенос бота в AWS Tokyo (ap-northeast-1). t4g.small за 20 $/мес в Токио даёт ту же сетевую задержку до Binance, что и сервер с colocation за 20 000 $/мес, плюс-минус несколько миллисекунд. Оставшийся разрыв сидит во внутренней очереди биржи, а её за деньги не купишь.

Задержка биржи: то, что вам не подконтрольно

От прихода ордера на границу инфраструктуры Binance до его подтверждения обычно проходит 5-20 мс. От подтверждения до фактического исполнения (fill или постановка в стакан) уходит ещё 1-50 мс в зависимости от типа ордера. Это по большей части вне вашего контроля, но последствия у этого есть.

Вывод: очередь Binance не работает по FIFO для всех пользователей. Аккаунты более высоких уровней (VIP-1, VIP-2 и т. д.) получают более быстрые полосы исполнения. Если вы неверифицированный розничный пользователь, при высоком трафике ваши ордера стоят в очереди позади ордеров VIP. Обойти это можно только одним способом: наторговать достаточный объём, чтобы самому дойти до VIP-1 (около 50 млн $/мес).

Это важно для стратегий, чувствительных ко времени. Событийные стратегии, чувствительные к задержке, где качество сделки зависит от того, обгоняете ли вы более медленного пользователя нижнего уровня, могут зависеть от полос исполнения по уровню аккаунта. Для стратегий с более длинным горизонтом (наши направленные модели и модели возврата к среднему) разница в пару сотен миллисекунд почти не имеет значения.

Как измерить собственную задержку

Инструментируйте каждый шаг. Для каждого ордера:

• t1 — метка времени рыночного события (закрытие kline, fill по aggTrade и т. д.). Берётся из timestamp сообщения WebSocket.
• t2 — метка времени, когда ваш код получил сообщение. Берётся с локальных часов.
• t3 — метка времени, когда ваш код отправил ордер. Берётся с локальных часов прямо перед HTTP-отправкой.
• t4 — метка времени, когда Binance подтвердил ордер. Берётся из ответа на ордер.
• t5 — метка времени, когда Binance исполнил ордер. Берётся из уведомления о fill.

Дельта t2−t1 даёт вашу сетевую/WebSocket-задержку от Binance до вас. Дельта t3−t2 даёт задержку решения. Дельта t4−t3 — это отправка ордера плюс ack от Binance. Дельта t5−t4 — время внутри движка сведения Binance. Логируйте все пять на каждой сделке. Через неделю у вас будет ясная картина того, где живёт задержка.

Большинство розничных ботов, которые это никогда не мерили, обнаруживают, что главный источник их задержки — что-то неожиданное: обычно задержка решения из-за запроса в базу, про который забыли, что он в горячем пути.

Чего мы реально добиваемся у себя

Наша инфраструктура работает в Hetzner Frankfurt (мы базируемся в ЕС; задержка — это плата за европейскую юрисдикцию). Типичная сквозная задержка от срабатывания сигнала до ACK ордера на Binance по торговой книге фирмы: 280-340 мс.

Разбивка: 0 мс на обнаружение (WebSocket); ~5 мс на решение; ~250 мс round-trip по сети; ~25 мс на ACK Binance. Эти 250 мс сети — плата за работу в ЕС вместо Токио. Перенос инфраструктуры в Токио срезал бы это примерно до 20 мс round-trip суммарно.

Для событийных стратегий, чувствительных к задержке, где скорость и есть эдж, это действительно слишком медленно. Эту конкретную стратегию мы постепенно переносим в Токио. Для наших моделей, где эдж в аналитической работе до входа, а не в скорости исполнения, инфраструктуры в ЕС вполне достаточно.

Честный вывод

У оптимизации задержки убывающая отдача. Первые лёгкие победы (подписка на WebSocket, VPS в Токио) дают 80% возможного без серьёзных вложений. Оставшиеся 20% стоят на порядки дороже (серверы с colocation, сеть с kernel bypass, матчинг на FPGA) и оправданы только для стратегий, где скорость и есть эдж.

Большинство розничных алгоритмов доходят до «достаточно хорошего» исполнения на 50 $/мес инфраструктуры и паре дней работы. Стратегиям, которым нужно больше, либо присуща конкретная чувствительность ко времени (и тогда стоит вложиться), либо у них эдж, который изначально не зависит от скорости, и в этом случае одержимость задержкой оборачивается впустую потраченными силами.