Pull to refresh
1
Alexander@ff_m

User

Send message

Привет! Сначала - искренне снимаю шляпу.

Реализация сама по себе впечатляет. ~280K строк, рабочая self-hosted платформа, визуальный редактор стратегий, генетический поиск, мультибиржевое исполнение, Redis pub/sub fan-out для рыночных данных - и всё это соло + с ИИ примерно за год. Это серьёзный инженерный результат.

Отдельное уважение за open-source (да ещё под AGPL). Позиция «убить SaaS-модель, выложив бесплатно то, за что берут $50-100/мес» - смелая и достойная.

И это продуманный проект, а не набор скриптов: архитектура, режимный «оракул» на GMM, DCA-сетки, «динамические связи» по плотности стакана - за этим видно настоящее проектное мышление.

Теперь - ложка дёгтя, по делу и, надеюсь, конструктивно (поправьте, если я неверно прочитал код):

Главное: для торговой системы не опубликовано ни одной метрики результативности - ни Sharpe, ни доходности, ни OOS-кривой, ни периода бэктеста. При 280K строк это самое заметное упущение: без этого невозможно отличить «работает» от «красиво выглядит».

Генетический поиск в текущем виде - это, по сути, машина переобучения:

  • Судя по коду, оптимизация и отбор идут на одной и той же выборке (in-sample). Walk-forward (split_data_into_windows) в репозитории есть, но в основном пути не вызывается, а «Phase 2» по тестовым активам выполняется после отбора - то есть это проверка постфактум, а не OOS-отбор.

  • ~1000 бэктестов за прогон (по умолчанию 50 особей × 20 поколений) без поправки на множественное тестирование. При таком числе часть стратегий пройдёт фильтры просто случайно.

  • Нет дефлированного Шарпа (Bailey, López de Prado), нет PBO (probability of backtest overfitting), нет штрафа за сложность/число испытаний; fitness - Calmar-подобный, на «сырой» доходности.

  • ИИ-генерация (в т.ч. со скриншота TradingView) + визуальный конструктор + генетика = огромное пространство гипотез почти без трения против оверфита. Классический исход: бэктест блестит - на проде стратегия умирает.

Справедливо отметить в плюс: комиссия и проскальзывание в бэктестере заложены (≈0.12% / 0.06% по умолчанию) - это лучше, чем у многих. И инференс GMM-оракула выглядит причинным (предсказание по последней точке, фичи на скользящих окнах назад), без заглядывания в будущее - но валидации его предсказательной точности в коде нет.

Конструктивно: инструментарий отличный - не хватает слоя валидации, который превращает «инженерную демку» в систему, которой можно доверить деньги. Минимум: OOS/holdout как гейт отбора (а не постфактум), walk-forward в основном пути, дефлированный Шарп + PBO, и публикация метрик уже с учётом издержек. Без этого, при любом качестве кода, генетический поиск остаётся генератором переобученных кривых.

В любом случае - большое спасибо за работу и за то, что выложили в открытый доступ. Пишу как человек, который строит в той же области (тоже соло + ИИ), так что это коллегиальный фидбек, а не критика ради критики. Удачи проекту!

Спасибо за статью, тема близкая. Добавлю свои замеры — они скорее подтверждают ваш тезис о жизнеспособности локального инференса, просто на другом железе.

Конфигурация:

  • Apple M5 Max, 128 ГБ unified memory, 40-ядерный GPU

  • LM Studio, формат MLX, локальный сервер

  • Модель: Qwen3-Coder-Next — 80B MoE, 3B активных параметров, 4bit (44.86 ГБ), контекст до 256k, KV-cache 8bit

  • temperature 0, фиксированный seed

Скорость генерации:

Тест Вход Выход Время Генерация ───────────────────────────────────────────────── Короткая 29 ток 187 ток 2.3 с ~83 ток/с

Средняя 32 ток 511 ток 5.8 с ~89 ток/с

Длинная 57 ток 1023 ток 12.5 с ~82 ток/с

80B-модель устойчиво держит ~82–89 ток/с генерации. Отдельно замерил обработку входа (prefill) на большом промпте: 20 695 токенов на входе обработались за ~10 с, т.е. порядка ~2000 ток/с — но это другая метрика, не генерация: вход обрабатывается параллельно и потому в разы быстрее, чем последовательная выдача токенов на выходе.

Ключевую роль играет связка «много unified memory + MoE»: 128 ГБ хватает на саму модель, а малое число активных параметров (3B) держит скорость высокой.

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

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

Information

Rating
6,276-th
Location
Frankfurt am Main, Hessen, Германия
Registered
Activity