Интеграция Hummingbot: маркет-мейкинг и кастомные стратегии

Что ломается в торговом контуре без интеграции Hummingbot

Самописный маркет-мейкер обычно держит состояние котировок в памяти процесса. Связь с биржей оборвалась — робот продолжает считать, что его заявки стоят, хотя часть уже отменена или исполнена. После переподключения он выставляет их заново: в стакане появляются дубли, позиция выходит за лимит, который никто не сверяет. На тонком стакане такая пара лишних заявок сама двигает цену, спред разъезжается, и следующая сделка закрывается заметно хуже расчётной.

Вторая точка отказа — ручное управление ордерами. Смену спреда, шага сетки или границ диапазона вносят правкой файла настроек и перезапуском, состояние при этом теряется, а на время перезапуска инструмент не котируется вообще. Пока этим занимается один инженер, любая его недоступность превращается в дыру в ликвидности: стакан стоит пустым ровно столько, сколько идёт поиск причины.

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

Разбираем, как это закрывается интеграцией Hummingbot в торговый контур.

Что даёт управляемый маркет-мейкинг: измеримый результат

Ручное ведение котировок держится на дежурстве: пока инженер не переставит ордера, спред живёт по вчерашней волатильности. Любой перезапуск — это окно, когда стакан пуст, и объём уходит именно в него. Управляемый контур на Hummingbot переводит такие решения в правила: лимиты на позицию, автоматический перезапуск узлов, журнал каждого действия.

Время простоя торгового контура

Узлы поднимаются как службы с проверкой живости и автоперезапуском, а ордера восстанавливаются из сохранённого состояния, а не выставляются заново вручную. Простой сокращается с часов до минут: доля времени, когда контур реально котирует, перестаёт зависеть от человеческого фактора и часового пояса дежурного.

Контроль риска позиции

Лимиты на размер позиции, максимальную просадку и экспозицию по инструменту задаются до старта, а не по факту. Превышение останавливает выставление и закрывает позицию по правилу — риск видно в мониторинге в момент приближения к границе, а не в отчёте после серии сделок.

Снижение доли ручных операций

Перестановка ордеров, смена спреда, ребалансировка и остановка стратегии уходят в расписание и условия срабатывания. Остаются задачи уровня настройки: доля ручных операций падает на порядок, а инженерное время уходит на разбор метрик, а не на дежурство у терминала.

Все три метрики снимаются с одного контура, поэтому эффект виден в динамике: сравниваем периоды до и после переноса стратегий, а не полагаемся на ощущения от торговой сессии.

Варианты интеграции Hummingbot: облако, свой сервер, гибрид

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

Ограничения биржевого интерфейса одинаковы для всех трёх схем и часто решают выбор. Лимиты на частоту запросов и вес заявок не дают выставлять котировки слишком часто, часть типов ордеров доступна только на отдельных рынках, а тестовый контур не повторяет реальную глубину стакана — на живом рынке поведение стратегии отличается.

Развёртывание на своём сервере берут там, где важны приватные ключи и предсказуемая задержка: контейнер с ботом, отдельный узел доступа к бирже, свои логи и оповещения о сбоях. Облачный запуск выигрывает на этапе проверки гипотез — задали параметры стратегии и посмотрели поведение на живом стакане. Гибрид закрывает оба сценария, но требует дисциплины в конфигурациях: разошедшиеся версии стратегии на контурах дают расхождение в отчётах.

Порядок работ: от аудита торговой логики до запуска

Работы по интеграции Hummingbot идут от аудита торговой логики к передаче в эксплуатацию, и каждый этап закрывается артефактом, который можно проверить, а не устным «готово». Порядок нарушать не стоит: стратегия, собранная до инвентаризации подключений и биржевых лимитов, обычно упирается в них уже на живом счёте.

1. Аудит торговой логики и текущего контура. Смотрим правила входа и выхода, способ учёта позиции, источники котировок, то, как выставляются и снимаются заявки. На выходе — карта узких мест: где логика держится на ручных действиях и где возможны дубли ордеров.
2. Схема и целевые параметры. Фиксируем пары, размер спреда, шаг переставления заявок, лимиты на позицию и на число активных ордеров, поведение при обрыве связи с биржей. Это спецификация, по которой собирается конфигурация.
3. Сборка стратегии и подключений. Готовим конфигурационные файлы, ключи доступа заводим с минимально необходимыми правами, без вывода средств, отдельно задаём ограничения по частоте запросов к бирже.
4. Проверка на исторических данных. Прогоняем логику на записанных рядах котировок и стакана: смотрим просадку, долю отменённых заявок, поведение на пропущенных свечах и на тонком рынке.
5. Тестовый контур малым объёмом. Дублируем прогон на биржевом тестовом окружении или на минимальном реальном объёме, сверяя фактические исполнения с расчётными.
6. Передача в эксплуатацию. Отдаём конфигурации, описание стратегий, журналы прогонов и регламент: как менять параметры, как останавливать бота и как откатываться на предыдущую версию стратегии.

Что остаётся у команды: конфигурации, схемы, регламенты

После интеграции Hummingbot команда остаётся не с «чёрным ящиком», а с набором артефактов, по которым контур можно развивать, передать другому инженеру или восстановить после сбоя. Ниже — минимальный состав, который мы закрываем на каждом проекте маркет-мейкинга.

• Конфигурации стратегий — рабочие файлы параметров: спреды, размеры и глубина котировок, лимиты позиции, интервалы пересчёта, а рядом журнал правок с пояснением, какое изменение к какому поведению привело.
• Схема торгового контура — потоки котировок и ордеров по узлам, точки отказа, поведение при обрыве связи с биржей и порядок перезапуска без ручной правки параметров.
• Матрица доступов — кто и с каких адресов меняет параметры, кто видит только показатели, как выдаются, ротируются и отзываются ключи при уходе инженера.
• Регламент реагирования на сбои — что считаем инцидентом, кто и как останавливает стратегию, как откатиться на предыдущий набор параметров и за какое время.
• Пакет документации — логика стратегии, инструкция запуска с нуля, порядок вывода из эксплуатации, история изменений и принятых решений.
• Набор показателей и порогов — по каким значениям видно, что стратегия уходит от ожидаемого поведения, и когда нужен ручной разбор.

Каждый артефакт мы отдаём с проверкой на стороннем инженере: если по нему нельзя поднять контур без нас — он написан недостаточно.

Практика: как ушёл класс отказов на волатильном рынке

Маркет-мейкер на нескольких биржах уходил в ручной режим при каждом всплеске волатильности: котировки расходились с эталонным спредом, часть заявок зависала между отправкой и подтверждением, а разрыв связи с биржей оставлял открытые позиции без присмотра. На резких движениях расхождение доходило до нескольких процентов от целевого спреда, до десятой части заявок зависало, а восстановление контура занимало 20–30 минут ручного разбора.

Что изменили

В основе осталась стратегия на Hummingbot, но состояние позиции перестало жить только внутри торговой логики. Появился независимый учёт со сверкой с биржей при каждом переподключении, а каждая заявка получила клиентский идентификатор: повторная отправка после обрыва больше не создаёт дублей и не удваивает позицию.

Отдельно закрыли котирование по устаревшему стакану: при выходе рынка за заданный коридор стратегия снимает заявки и уходит в паузу вместо того, чтобы выставляться по неверной цене. Переподключение идёт с нарастающей паузой, а при потере связи контур сначала снимает заявки и только потом восстанавливается.

Что стало

Доля зависших заявок упала с десятой части до долей процента, расхождение котировок вернулось в границы целевого спреда, а восстановление контура после разрыва связи занимает меньше минуты и идёт автоматически. Ручных вмешательств за период наблюдения — ноль: класс отказов «котируем по устаревшей цене после обрыва» ушёл вместе с ручными разборами.

В контуре появились метрики, по которым деградация видна до потери денег: расхождение спреда, доля зависших заявок, время восстановления после обрыва связи.

Чем маркет-мейкинг на бирже отличается от арбитража?

Маркет-мейкинг — это котирование: стратегия держит заявки по обе стороны стакана и зарабатывает на спреде и вознаграждении за ликвидность. Арбитраж снимает расхождение: тот же актив покупается на одной площадке и сразу продаётся на другой. Общий у режимов только слой доступа к биржам — дальше это разные по нагрузке, риску и требованиям контуры.

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

Скорость реакции тоже разного характера. Маркет-мейкеру важнее непрерывность — разрыв в котировании виден по обороту и по упущенным сделкам. Арбитражу нужна пиковая реакция в узком окне, поэтому его контур простаивает и ждёт всплеска.

Арбитраж выбирают там, где ликвидность разнесена по площадкам, а расхождения повторяются предсказуемо. В Hummingbot оба режима собираются поверх общего слоя подключений к биржам, поэтому выбор торговой стратегии — это вопрос конфигурации и риск-лимитов, а не переписывания интеграции.

Технические вопросы, которые задают перед стартом

Перед стартом инженерные команды спрашивают не «работает ли», а про устойчивость: что будет при обрыве связи с биржей, как не задвоить ордера при переподключении, как уложиться в лимиты запросов и где лежат ключи доступа. Ниже — ответы в том виде, как эти места решаются в нашей реализации.

Как уложиться в лимиты запросов биржи?

Лимиты учитываются на уровне коннектора: очередь запросов и ограничение частоты на каждый метод с запасом под пиковую нагрузку. При приближении к порогу стратегия снижает частоту пересчёта — блокировка со стороны биржи отсекает все запросы сразу, включая те, что нужны для отмены ордеров.

Где хранятся ключи доступа к счёту?

Ключи лежат в защищённом хранилище и попадают в процесс только при запуске, через переменные окружения; в конфигурации и логах их нет. Права API ограничиваются торговлей без вывода средств, а доступ к хранилищу выдаётся ролью на стороне инфраструктуры, а не общим файлом на сервере.

Можно ли проверить стратегию до реального счёта?

Прогон идёт в три шага: исторические данные, тестовый контур биржи с реальными задержками и ответами, затем счёт с минимальным объёмом. На каждом шаге сверяются спред, доля исполненных заявок, число отмен и максимальная просадка по позиции — по ним видно, ведёт ли себя стратегия так, как задумано.

Обсудим задачу: пришлём схему, оценку и план работ

Чтобы вернуться с оценкой и планом, а не с общими формулировками, нам нужно разобрать текущий контур: где запускаются боты, какие биржи и пары подключены, как устроены ключи, лимиты и логирование сделок, какие метрики уже собираются. Для этого достаточно короткого созвона и доступа к конфигурациям — дальше схему описываем мы. Ниже — порядок, по которому идёт работа; он же становится оглавлением плана.

• Разбор контура: текущие стратегии, способы выставления заявок, частота переоценки, обработка обрывов связи и уже накопленная статистика исполнения.
• Схема интеграции: как Hummingbot встаёт рядом с вашими биржами и учётными системами, где проходят ключи, какие лимиты и предохранители ограничивают объём позиции.
• Оценка сроков: этапы с точками, на которых можно остановиться или изменить приоритеты, и явные зависимости от внешних согласований.
• Пилотный запуск: ограниченная пара и небольшой объём, сверка фактических сделок с ожидаемыми, проверка поведения при отказах и частичном исполнении.
• Кастомные стратегии: правила входа и выхода, параметры риска, логика отмены и переставления заявок, тесты на исторических данных.
• Сопровождение торгового контура: мониторинг, разбор инцидентов, корректировка параметров при изменении ликвидности и обновлениях на стороне биржи.
• Передача: конфигурации, документация по запуску и восстановлению, инструкции для вашей команды.

Опишите задачу в двух-трёх предложениях — по этим пунктам вернёмся с оценкой сроков и планом работ.