Этот слой на стадии проектирования, в бою механики попроще (просадка + здоровье фида), так что делюсь замыслом, а не проверенной практикой.
Статический стресс-множитель («допустим, испарится половина объёма») отбросили — его не откалибровать: любой заранее выбранный коэффициент либо слишком мягок для реального хвоста, либо парализует нормальную торговлю. Вместо этого хотим стрессовать измеренной скоростью деградации: не «а что если объём исчезнет», а «объём исчезает вот с такой скоростью, экстраполяция на горизонт выхода даёт вот столько». Сужающаяся дверь важнее уже узкой. Плюс помнить, что собственный выход тоже ест стакан.
Кстати, полез посмотреть T-Invest API — понравился флаг is_consistent в стриме стакана: API сам сознаётся в деградации канала доставки, готовый вход для мониторинга допущений. Еще, в крипте дверь на выход сужает ликвидность, а на фонде её может штатно захлопнуть сама биржа — планка, дискретный аукцион, приостановка торгов. Получаем дополнительный слой рисков.
По опыту запиливания похожей системы для крипторынка, всё перечисленное — стейт-машина заявок, чужие позиции, сверка после рестарта, протухшие данные — подтверждаю как обязательный фундамент.
Про «самую неприятную ситуацию» (брокер принял, ответ потерялся). Есть вторая гонка того же класса: отмена против исполнения. Отмена не считается успешной, пока не подтверждена, и если в окне гонки пришло исполнение — побеждает исполнение. Без явной семантики «fill wins» легко получить «отменённую» позицию, которая на самом деле открылась.
Поделюсь тем, где началась следующая граница надежности:
1. Главный сдвиг мышления: перечислять не отказы, а допущения. Любой список сценариев («API не ответил», «частичное исполнение») неполон — следующий сбой будет не из списка. Вместо этого перечисляем допущения, на которых стоит корректность системы: «наблюдаемая цена отражает реальность», «ордер размещается за ограниченное время», «цена исполнения близка к наблюдаемой», «внутреннее состояние равно брокерскому», «единица учёта стабильна» — и на каждое нужен монитор. Будущее tail-событие проявится как нарушение их подмножества.
2. Отказы частичны. Криптокрах 10 октября 2025 показал: отмена работала, размещение — нет, данные шли, но глубина стакана испарилась на 98%. «API доступен/недоступен» — слишком грубая модель; полезно вести здоровье по каналам (размещение / отмена / маркет-дата / аккаунт) раздельно.
3. Охранять выход, а не убыток. Стоп по просадке смотрит назад — и в фазе испарившейся ликвидности стреляет в пустой стакан. Форвардная метрика «закрывается ли портфель прямо сейчас в пределах X% слиппеджа» велит сокращаться, пока стакан еще жив.
4. Для проектирования защитного слоя полезно задавать архитектурный вопрос - «какая общая причина отключит и слой, и то, что он защищает?». Отсюда рождаются решения вида сторожевой контур на отдельном хосте/маршруте/ключе, который умеет только сокращать и отменять и срабатывает при «робот мёртв ∧ позиции открыты ∧ биржа жива».
5. Биржевые SL/TP как страховка не работают — взводить их когда канал размещения уже деградировал бессмысленно, а постоянный взвод заранее показывает рынку вашу точку боли. Отсутствие гарантий их выполнения - постоянный источник грустных мемов)
Несколько мыслей «на подумать», исходя из собственного опыта запиливания аналогичной системы.
Про интерфейс. Интерфейсы SCADA-систем предназначены для оператора, которому нужно следить за технологическим процессом «сверху» и реагировать на отклонения — там логично наличие общей мнемосхемы с массой деталей. Но и там детали должны «говорить» визуально: всё по плану — или что-то требует внимания.
Домашняя автоматизация нацелена на другое:
а) типовые действия (включить/выключить свет и технику вручную или по сценарию, глянуть температуру);
б) уведомления и реакция на них — датчик протечки, звонок домофона и т.п.
Общую план-схему, где есть «всё», редко использует кто-либо кроме создателя системы. Более того, зрелая домашняя автоматика вообще уезжает в плоскость, где панель почти не нужна: свет работает по расписанию или датчикам движения, домофон открывается из чата или видеозвонка на телефоне, показания счётчиков скрипт сам «сдаёт» на сайт. Панель остаётся инструментом отладки и «пульта на крайний случай».
Замечу, что вы фактически прошли этот путь сами — ушли от SCADA-клиента к вебу, добавили уведомления в мессенджеры и сценарии. Но интерфейс в VIS-2.0, судя по скриншоту, воспроизводит ту же SCADA-парадигму «общей мнемосхемы», только в браузере. Подозреваю, что через пару лет эксплуатации им будете пользоваться в основном вы, и в основном для диагностики. Впрочем, тут промышленный и домашний подходы в итоге сходятся в одной точке: «управление по отклонениям» — система молчит, пока всё хорошо, и активно сигналит, когда что-то не так. К этому же идёт и high-performance HMI в промышленности.
Про оборудование. Общий дрейф идёт в сторону отказа от проприетарщины и закрытых платформ, в которых были зашиты и логика, и интерфейс связи с исполнительными устройствами, — в сторону открытых протоколов и деления системы на взаимозаменяемые элементы. Под каждую шину с устройствами нижнего уровня ставится «по вкусу» шлюз, у которого с другой стороны открытый и задокументированный интерфейс (MQTT и т.п.), а логика взаимодействия переезжает на сторону открытых программных решений.
Ваша история это, кстати, отлично иллюстрирует с обеих сторон. С одной — вам пришлось реверсить недокументированный протокол DL205 через Wireshark, чтобы избавиться от Kepware: закрытый протокол чуть не стал якорем всей системы, и повезло, что он оказался достаточно простым для разбора. С другой — Zigbee2MQTT и ioBroker встали в архитектуру без единой переделки именно потому, что стыкуются через открытые интерфейсы.
Единственное, где я бы с вами поспорил, — центральная логика в PLC. Понимаю аргумент надёжности (15 лет аптайма — веский довод), но цена этого — логика заперта в закрытой платформе с вымирающим инструментарием. Если через 15 лет контроллер всё-таки умрёт, программу придётся не мигрировать, а писать заново — уже на чём-то другом.
Kimi K3 на этих макстудиях по предварительным оценкам будет работать скорее всего в нативном квантовании MXFP8 / MXFP4 с вполне сносной скоростью для индивидуального использования. Qwen видимо влезет на 4битах или может даже выше. Ну а в остальном - не хватает появления железок с 2-4Тб быстрой памяти и размером не со шкаф.
Библиотека на Node.js, движок исполнения торговых стратегий на собственном DSL (~десятки тысяч строк: execution-ядро, grid-трейдинг, TA-индикаторы, plot/логирование, сериализация состояния).
Автор, ваши находки ложатся в более общую и простую канву, которую теперь необходимо держать в голове при организации сервисов, пересекающих виртуально-сетевую границу РФ
1) ТПСУ режет или унижает траффик по AS. Запросы из РФ в эти подсети могут не пройти вообще, могут троттлиться. В обратную сторону - без гарантии тоже, кейс с вебхуком блокированного телеграмма тому пример. Есть локации и подсети, с которыми покачто нормальная скорость и пинг, можно их использовать как релеи.
2) Оказание услуг и api-сервисов по запросам с РФ-адресом geoip может быть заблокировано, отказ может выглядеть как угодно, зависит от реализации. Антропики в этом очень упоротые.
Реальный профит у неё начинается в оркестрации параллельных агентов на длинных сессия - выполнить послойный аудит крупной кодовой базы, сформировать и согласовать батчи карточек беклога, запустить фиксы в параллельных сессиях в отдельных worktrees, слить результаты в общее дерево и пофиксить конфликты. И всё это одна сессия оркестрации плюс 6-10 параллельных субагентов на разных этапах.
Ранее такой процесс нужно было оркестрировать по частям и пилить около недели. Теперь укладывается в несколько часов
Решение глубоко проработанное с одной стороны. Однако с другой стороны мне видится неверной оценка затрат на реверс - с приходом llm на это поле время и стоимость на то, чтобы разобрать прошивку fpga уменьшится на порядки. Дело лишь в наработке инструментов и подходов. И вот тогда опция выпиливания функций саботажа и проверки активации из бинарных прошивок станет намного реалистичнее.
Как по мне, модель предельно ясно и четко объясняет в чем суть проблемы, но вы её не понимаете и приписываете ей обвинения. Думаю сошлись действительно технический фактор повтора инструкций и слишком детальная отзывчивость и наблюдательность модели.
"проект фактически направлен на закрепление монопольного положения двух разработчиков ИИ — «Сбербанка» и «Яндекса»" - как неожиданно, у нас монополисты лоббируют и закрепляют свои монополии через законодательство. Никогда такого не было, и вот опять.
Пара GB10 оказалась игрушкой, которую надо сильно доводить напильником. А нет ли опыта с парой dgx station GB300 в аналогичной задаче запуска sota open source llm?
Отсутствие конкретики по "исследованным" производителям, приборам, схемам построения ОПС указывает на фактическую низкую ценность статьи. А заявление о возможности "снять объект с охраны" натянуто сильнее бедной совы на глобус.
Конечно, дохлые батареи совершенно безопасны с точки зрения надежности и пожароопасности. А их экологичная система охлаждения в контейнерах из профлиста и сетчатыми стенками заботится об окружающей среде)
В целом похвально, главное не стать блекхетным чорношляпнегом. Еще глаз зацепился за "конечное устройство" - это такой современный сленг или автоперевод не справился с "api endpoint" ?
Не понятен пассаж про Xanbus - в combox есть modbus сервер, который отдает текущие параметры и дает возможность управления. Вы с него до смерти устройства забирали данные по работе системы?
Этот слой на стадии проектирования, в бою механики попроще (просадка + здоровье фида), так что делюсь замыслом, а не проверенной практикой.
Статический стресс-множитель («допустим, испарится половина объёма») отбросили — его не откалибровать: любой заранее выбранный коэффициент либо слишком мягок для реального хвоста, либо парализует нормальную торговлю. Вместо этого хотим стрессовать измеренной скоростью деградации: не «а что если объём исчезнет», а «объём исчезает вот с такой скоростью, экстраполяция на горизонт выхода даёт вот столько». Сужающаяся дверь важнее уже узкой. Плюс помнить, что собственный выход тоже ест стакан.
Кстати, полез посмотреть T-Invest API — понравился флаг is_consistent в стриме стакана: API сам сознаётся в деградации канала доставки, готовый вход для мониторинга допущений. Еще, в крипте дверь на выход сужает ликвидность, а на фонде её может штатно захлопнуть сама биржа — планка, дискретный аукцион, приостановка торгов. Получаем дополнительный слой рисков.
По опыту запиливания похожей системы для крипторынка, всё перечисленное — стейт-машина заявок, чужие позиции, сверка после рестарта, протухшие данные — подтверждаю как обязательный фундамент.
Про «самую неприятную ситуацию» (брокер принял, ответ потерялся). Есть вторая гонка того же класса: отмена против исполнения. Отмена не считается успешной, пока не подтверждена, и если в окне гонки пришло исполнение — побеждает исполнение. Без явной семантики «fill wins» легко получить «отменённую» позицию, которая на самом деле открылась.
Поделюсь тем, где началась следующая граница надежности:
1. Главный сдвиг мышления: перечислять не отказы, а допущения. Любой список сценариев («API не ответил», «частичное исполнение») неполон — следующий сбой будет не из списка. Вместо этого перечисляем допущения, на которых стоит корректность системы: «наблюдаемая цена отражает реальность», «ордер размещается за ограниченное время», «цена исполнения близка к наблюдаемой», «внутреннее состояние равно брокерскому», «единица учёта стабильна» — и на каждое нужен монитор. Будущее tail-событие проявится как нарушение их подмножества.
2. Отказы частичны. Криптокрах 10 октября 2025 показал: отмена работала, размещение — нет, данные шли, но глубина стакана испарилась на 98%. «API доступен/недоступен» — слишком грубая модель; полезно вести здоровье по каналам (размещение / отмена / маркет-дата / аккаунт) раздельно.
3. Охранять выход, а не убыток. Стоп по просадке смотрит назад — и в фазе испарившейся ликвидности стреляет в пустой стакан. Форвардная метрика «закрывается ли портфель прямо сейчас в пределах X% слиппеджа» велит сокращаться, пока стакан еще жив.
4. Для проектирования защитного слоя полезно задавать архитектурный вопрос - «какая общая причина отключит и слой, и то, что он защищает?». Отсюда рождаются решения вида сторожевой контур на отдельном хосте/маршруте/ключе, который умеет только сокращать и отменять и срабатывает при «робот мёртв ∧ позиции открыты ∧ биржа жива».
5. Биржевые SL/TP как страховка не работают — взводить их когда канал размещения уже деградировал бессмысленно, а постоянный взвод заранее показывает рынку вашу точку боли. Отсутствие гарантий их выполнения - постоянный источник грустных мемов)
Несколько мыслей «на подумать», исходя из собственного опыта запиливания аналогичной системы.
Про интерфейс. Интерфейсы SCADA-систем предназначены для оператора, которому нужно следить за технологическим процессом «сверху» и реагировать на отклонения — там логично наличие общей мнемосхемы с массой деталей. Но и там детали должны «говорить» визуально: всё по плану — или что-то требует внимания.
Домашняя автоматизация нацелена на другое:
а) типовые действия (включить/выключить свет и технику вручную или по сценарию, глянуть температуру);
б) уведомления и реакция на них — датчик протечки, звонок домофона и т.п.
Общую план-схему, где есть «всё», редко использует кто-либо кроме создателя системы. Более того, зрелая домашняя автоматика вообще уезжает в плоскость, где панель почти не нужна: свет работает по расписанию или датчикам движения, домофон открывается из чата или видеозвонка на телефоне, показания счётчиков скрипт сам «сдаёт» на сайт. Панель остаётся инструментом отладки и «пульта на крайний случай».
Замечу, что вы фактически прошли этот путь сами — ушли от SCADA-клиента к вебу, добавили уведомления в мессенджеры и сценарии. Но интерфейс в VIS-2.0, судя по скриншоту, воспроизводит ту же SCADA-парадигму «общей мнемосхемы», только в браузере. Подозреваю, что через пару лет эксплуатации им будете пользоваться в основном вы, и в основном для диагностики. Впрочем, тут промышленный и домашний подходы в итоге сходятся в одной точке: «управление по отклонениям» — система молчит, пока всё хорошо, и активно сигналит, когда что-то не так. К этому же идёт и high-performance HMI в промышленности.
Про оборудование. Общий дрейф идёт в сторону отказа от проприетарщины и закрытых платформ, в которых были зашиты и логика, и интерфейс связи с исполнительными устройствами, — в сторону открытых протоколов и деления системы на взаимозаменяемые элементы. Под каждую шину с устройствами нижнего уровня ставится «по вкусу» шлюз, у которого с другой стороны открытый и задокументированный интерфейс (MQTT и т.п.), а логика взаимодействия переезжает на сторону открытых программных решений.
Ваша история это, кстати, отлично иллюстрирует с обеих сторон. С одной — вам пришлось реверсить недокументированный протокол DL205 через Wireshark, чтобы избавиться от Kepware: закрытый протокол чуть не стал якорем всей системы, и повезло, что он оказался достаточно простым для разбора. С другой — Zigbee2MQTT и ioBroker встали в архитектуру без единой переделки именно потому, что стыкуются через открытые интерфейсы.
Единственное, где я бы с вами поспорил, — центральная логика в PLC. Понимаю аргумент надёжности (15 лет аптайма — веский довод), но цена этого — логика заперта в закрытой платформе с вымирающим инструментарием. Если через 15 лет контроллер всё-таки умрёт, программу придётся не мигрировать, а писать заново — уже на чём-то другом.
Kimi K3 на этих макстудиях по предварительным оценкам будет работать скорее всего в нативном квантовании MXFP8 / MXFP4 с вполне сносной скоростью для индивидуального использования. Qwen видимо влезет на 4битах или может даже выше.
Ну а в остальном - не хватает появления железок с 2-4Тб быстрой памяти и размером не со шкаф.
Библиотека на Node.js, движок исполнения торговых стратегий на собственном DSL (~десятки тысяч строк: execution-ядро, grid-трейдинг, TA-индикаторы, plot/логирование, сериализация состояния).
Кластер из 4 мак студио слышимо пищит-свистит на инференсе, подтверждаю. И характер звука у префилла и декода существенно отличаются.
Автор, ваши находки ложатся в более общую и простую канву, которую теперь необходимо держать в голове при организации сервисов, пересекающих виртуально-сетевую границу РФ
1) ТПСУ режет или унижает траффик по AS. Запросы из РФ в эти подсети могут не пройти вообще, могут троттлиться. В обратную сторону - без гарантии тоже, кейс с вебхуком блокированного телеграмма тому пример. Есть локации и подсети, с которыми покачто нормальная скорость и пинг, можно их использовать как релеи.
2) Оказание услуг и api-сервисов по запросам с РФ-адресом geoip может быть заблокировано, отказ может выглядеть как угодно, зависит от реализации. Антропики в этом очень упоротые.
Реальный профит у неё начинается в оркестрации параллельных агентов на длинных сессия - выполнить послойный аудит крупной кодовой базы, сформировать и согласовать батчи карточек беклога, запустить фиксы в параллельных сессиях в отдельных worktrees, слить результаты в общее дерево и пофиксить конфликты. И всё это одна сессия оркестрации плюс 6-10 параллельных субагентов на разных этапах.
Ранее такой процесс нужно было оркестрировать по частям и пилить около недели. Теперь укладывается в несколько часов
Решение глубоко проработанное с одной стороны. Однако с другой стороны мне видится неверной оценка затрат на реверс - с приходом llm на это поле время и стоимость на то, чтобы разобрать прошивку fpga уменьшится на порядки. Дело лишь в наработке инструментов и подходов. И вот тогда опция выпиливания функций саботажа и проверки активации из бинарных прошивок станет намного реалистичнее.
С такими моторами откусить пару пальцев при неудачном хвате ничего не стоит)
Ельня
Внеязыковое мышление в латентном пространстве? Как мысли, которые крутятся фоном в процессе действия.
Как по мне, модель предельно ясно и четко объясняет в чем суть проблемы, но вы её не понимаете и приписываете ей обвинения. Думаю сошлись действительно технический фактор повтора инструкций и слишком детальная отзывчивость и наблюдательность модели.
"проект фактически направлен на закрепление монопольного положения двух разработчиков ИИ — «Сбербанка» и «Яндекса»" - как неожиданно, у нас монополисты лоббируют и закрепляют свои монополии через законодательство. Никогда такого не было, и вот опять.
Пара GB10 оказалась игрушкой, которую надо сильно доводить напильником. А нет ли опыта с парой dgx station GB300 в аналогичной задаче запуска sota open source llm?
Отсутствие конкретики по "исследованным" производителям, приборам, схемам построения ОПС указывает на фактическую низкую ценность статьи. А заявление о возможности "снять объект с охраны" натянуто сильнее бедной совы на глобус.
У себя использовал вариант с mangle add routing mark на клиента или его подсеть и прописыванием маршрута для routing mark через "работающий" шлюз.
И совсем не понял, зачем тут bgp? Или это актуально только для тех, у кого своя as под рукой?
Конечно, дохлые батареи совершенно безопасны с точки зрения надежности и пожароопасности. А их экологичная система охлаждения в контейнерах из профлиста и сетчатыми стенками заботится об окружающей среде)
В целом похвально, главное не стать блекхетным чорношляпнегом.
Еще глаз зацепился за "конечное устройство" - это такой современный сленг или автоперевод не справился с "api endpoint" ?
Не понятен пассаж про Xanbus - в combox есть modbus сервер, который отдает текущие параметры и дает возможность управления. Вы с него до смерти устройства забирали данные по работе системы?