Мои инженерные результаты

14 августа 2026, 10:34
|
bascomo

Решил, что надо подвести какой-то профессиональный итог всей этой возни с вашим глупым алготрейдингом. И вот, что получилось.

Мои инженерные результаты:
— спроектировал и реализовал с нуля платформу алготрейдинга на C#/.NET 9 — от загрузки котировок до исполнения ордеров: 67 проектов, 77 тыс. строк кода, 773 автотеста, 28 задокументированных архитектурных решений;
— поднял пропускную способность верификации стратегий с 1-5 до 2 500 вариантов в секунду на воркер (в 500 раз), в том числе за счёт покрывающего индекса, ускорившего выборку в 525 000 раз по вводу-выводу;
— снизил пиковое потребление памяти вычислительного ядра со 117 ГБ до 2,6 ГБ (в 45 раз), сохранив побитовую идентичность результата на 33,3 млн строк;
— построил генетический поиск стратегий по ~640 бинарным признакам на 383 инструментах трёх площадок, обработав ~167 млн минутных свечей;
— развернул распределённые вычисления в Kubernetes (~12 узлов, автомасштабирование KEDA до 120 подов, scale-to-zero) и хранилище S3 + Parquet с прореживанием — экономия 97% объёма;
— реализовал портфельный отбор: TOPSIS и HRP с очисткой корреляционной матрицы 383x383 методом Марченко-Пастура — из ~96 тыс. кандидатов отбирается ~420 систем;
— построил торговый движок с семиуровневой защитой капитала: обработка свечи менее 1 мс, путь от сигнала до ордера менее 10 мс (p99);
— провёл out-of-sample валидацию на 30 инструментах за 45 дней; нейросетевая модель (ONNX) даёт преимущество +8,33 п.п. на тестовой выборке;
— написал автономного торгового бота для Bybit на 75 инструментов с собственным риск-движком: 3 451 сделка за три недели на демо-счёте, доля прибыльных 83,9%, Profit Factor 2,12;
— нашёл и устранил гонку потоков в параллельном вычислительном ядре, сделав расчёты детерминированными; корректность подтвердил A/B-валидацией;
— реализовал интеграции с площадками: Binance Futures (REST и WebSocket), Bybit, MOEX через Finam (протокол Transaq), Tinkoff Invest API, Bybit V5.

Торговля: 24 918 закрытых сделок по 293 инструментам на собственном счёте, три года из четырёх положительные.

Стек: C# 13/.NET 9, Python, MS SQL Server (T-SQL, columnstore), Kubernetes и KEDA, Docker, S3 + Parquet, DuckDB, ONNX Runtime, xUnit, Serilog, Git; генетические алгоритмы, TOPSIS, HRP, Марченко-Пастур, DSR/CPCV/PBO.

Последние 10 сделок + нарастающий итог за прошлые сутки (13.08, столбцы — день.время открытия, время закрытия, тикер, прибыль на сделку и нарастающий итог с начала суток с учётом комиссии, валюта — USDT):

08.06:39  18:39  TUT      +326  +3 958
12.12:54  19:49  VIRTUAL   +74  +4 120
13.10:17  19:00  XMR        +8  +3 966
13.15:58  20:51  CAP      +163  +4 284
13.16:40  18:19  LINK       −3  +3 633
13.17:03  18:22  OP         −3  +3 630
13.17:22  19:14  ONDO      +17  +3 983
13.17:34  18:33  TAO        +2  +3 632
13.18:31  19:27  BNB        +2  +3 985
13.18:47  19:31  TUT       +61  +4 046

Статистика с начала торгов (27.05) по конец вчерашнего дня:
Процесс: ALIVE pid 3800, лог 23:41:08, ошибок 0, диск 62.5GB
— Сегодня закрыто: 151, ✅124 / ❌27 (82%)
— PnL за сутки: gross 4 824 − комиссия 573 = net 4 251 USDT
Счёт (USDT):
114 188 старт
+ 157 731 реализовано по вчера
+ 4 251 реализовано сегодня
— (4 823) funding
= 157 159 сейчас
в т.ч. комиссия за всё время: (63 414) — уже в «реализовано»
— Свободно: 36 669 USDT
— Задействованная маржа: 79 080 (пик дня 90 764) USDT
— Плечо: 5
— Экспозиция: 394 127 USDT
— Открыто: 45 (33L / 12S)

Данная публикация является личным мнением автора. Мнение владельца сайта может не совпадать с мнением автора.

3К | ★7

5 комментариев

Здравствуйте, не могли бы Вы ответить на следующие вопросы:

Каково среднее время жизни сделок? Интересует горизонт торговли на генерируемых системах (краткосрок, среднесрок, долгосрок).
640 бинарных признаков — это, грубо говоря, 640 кусочков стратегии? То есть отдельных условий входов/выходов? Условия для входа и выхода собираются независимо и потом комбинируются?
«Реализовал портфельный отбор: TOPSIS и HRP с очисткой» — это про то, что вообще попадёт в портфель? В портфеле есть какая-либо кластеризация по корреляции или по другому признаку?
Вы упомянули минутный ТФ. У вас все стратегии работают только на нём, или он как база, а из него уже строятся старшие ТФ?
Вероятно, у вас есть проблема, что части стратегии используют один и тот же индикатор. Если так, то как-то подготавливаются расчёты заранее или при переборе постоянно считается заново?
Если я правильно понимаю, воркер, когда получает задание, тянет историю с базы. Успевает ли база отдавать историю на множество воркеров?

Александр

14 августа 2026, 12:06
Ответить

1. Среднее время жизни сделок / горизонт

Внутридневной, краткосрочный. Горизонт измеряется в свечах (не в абсолютном времени), а таймфрейм всегда минутный, поэтому 1 свеча = 1 минута.

1. Среднее время жизни сделок / горизонт

— В генерируемых системах длину сделки сверху ограничивает ген MaxDurationCandles ∈ {60, 120, 240, 480, 960, 1920} свечей — то есть 1 / 2 / 4 / 8 / 16 / 32 часа (жёсткий предел ×1.5, дефолт — 8 часов). Но это верхняя граница: большинство сделок закрывается заметно раньше по trailing-стопу.
— Живой пример (бот на Bybit, 9 719 закрытых сделок): медиана удержания ~1 час, среднее ~4.6 ч (среднее перекошено редкими многодневными «хвостами»). 55% сделок закрываются за час, 87% — за 4 часа, 95% — за ~14 часов.

Итог: скальпинг-внутридневной диапазон, максимум ~1–2 суток.

2. 640 бинарных признаков — это «кусочки стратегии»? Вход и выход собираются независимо?

Не совсем. ~636–640 бинарных флагов — это словарь только для условий ВХОДА (бинарные предикаты состояния рынка, вычисленные из 19 индикаторов: RSI, ATR, MACD, Bollinger, ADX, DeepExtremum и т.д.). Стратегия = подмножество этих флагов, объединённых по AND-логике, как правило входа.

Выход флаги не использует вообще. Это отдельный параметрический механизм trailing-стопа: 5 дискретных параметров (начальный стоп, макс. длительность, шаг сужения, закрытие на конце дня / выходных) — всего 2520 комбинаций.

Вход и выход эволюционируют раздельно (скрещивание и мутация обрабатывают флаги и exit-параметры отдельно), но оцениваются всегда вместе — PnL сделки зависит и от входа, и от выхода, отдельно «вход без выхода» не измерить.

3. TOPSIS и HRP «с очисткой» — про то, что попадёт в портфель? Есть кластеризация по корреляции?

Да, это отбор в боевой портфель, в два модуля:

— Селектор (индивидуальный отбор): фильтрация (Sharpe OOS, покрытие инструментов, число сделок, защита от переобучения по decay IS→OOS, сложность) → ранжирование (TOPSIS или взвешенная сумма) → дедупликация по схожести флагов (Jaccard) → диверсификация (лимит алгоритмов на инструмент, баланс бирж) → корреляционный фильтр (убирает более слабого из пары с высокой корреляцией equity-кривых).
— Комбинатор (портфель): HRP (Hierarchical Risk Parity, Лопес де Прадо) — да, тут кластеризация по корреляции присутствует по построению: корреляционная матрица → расстояние → иерархическая кластеризация (дендрограмма) → квазидиагонализация → рекурсивное деление весов по обратной дисперсии. Плюс Score-Weighted HRP — веса домножаются на качество системы.

4. Минутный ТФ — все стратегии только на нём, или это база для старших ТФ?

Только минутка (M1), везде. Загрузка данных жёстко на 1m (Binance interval=1m, MOEX M1), enriched-данные и весь конвейер Loader→Researcher→Trader — на M1. Механизма агрегации 1m→старшие ТФ в коде нет — минутка не база для построения старших, а единственный используемый таймфрейм. Живой бот тоже на M1 (tf=1min).

5. Части стратегии используют один индикатор — расчёты готовятся заранее или считаются заново при переборе?

Заранее, полностью. Индикаторы считаются один раз в Загрузчике и сохраняются как упакованные битовые флаги в Parquet-файлы в S3 (640 флагов в ulong[], 80 байт на свечу). Генетический поиск индикаторы не пересчитывает вообще — воркер читает готовые флаги один раз на задачу и для каждой особи генома гоняет по ним побитовые маски (AND). Никакого пересчёта формул в переборе нет, плюс внутрипроцессный кеш (одна загрузка на файл). Проблема «дублирующихся расчётов одного индикатора» тут в принципе не возникает.

6. Воркер тянет историю из БД — успевает ли БД отдавать на множество воркеров?

Историю воркер берёт не из SQL, а из S3 (Parquet). SQL-сервер историю не отдаёт вообще — он используется только для координации (атомарный захват одного задания, один короткий UPDATE на задачу) и каталога флагов (один SELECT на процесс, кешируется). Каждый под грузит свою историю из S3 один раз за всю задачу (не на эпоху и не на генома). Поэтому БД — не узкое место при десятках-сотнях воркеров; потенциальное узкое место (если возникнет) — это S3 при холодном старте пода, а не SQL. Масштаб — до ~120 подов (KEDA).

bascomo

15 августа 2026, 20:03
Ответить

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

Александр