Gonka Node Manager — автоматическое развёртывание, обновления и мониторинг нод

Резюме

Для работы узлов Gonka в настоящее время требуется ручная установка, настройка и постоянное обслуживание на основе CLI. У опытных операторов первоначальная настройка обычно занимает несколько часов на каждый узел. Для менее опытных участников процесс часто растягивается на один или два дня — или приводит к отказу еще до запуска узла.

Эти трения активно отфильтровывают потенциальных операторов, концентрируя власть среди технически продвинутых пользователей и замедляя органическую децентрализацию.

Gonka Node Manager запрашивает эквивалент 80 000 долларов США из пула сообщества для создания готового к эксплуатации MVP, который автоматизирует развертывание узлов, обновления и мониторинг.

Примечание. Голосование по управлению в сети (расходы пула сообщества) будет представлено как отдельная транзакция после развертывания контракта. В этом выпуске отслеживается техническое предложение и план реализации.

Постановка задачи

Текущая работа узла требует:

Ручная настройка CLI занимает от нескольких часов до нескольких дней на каждый узел

• Доступ по SSH и настройка на уровне сервера для каждого обновления.

• Нет автоматического мониторинга или видимости состояния здоровья.

• Нет оптимизированного процесса подключения узлов ML к сетевым узлам.

Это фактически ограничивает участие узкой группы технически продвинутых пользователей, концентрируя операционную власть и замедляя органическую децентрализацию.

Предлагаемое решение

Gonka Node Manager — унифицированный инструмент, который позволяет операторам узлов:

• Развертывайте сеть и узлы машинного обучения согласованным и автоматизированным способом.

Поддерживайте актуальность узлов без ручного вмешательства

• Подключайте и управляйте узлами ML вместе с сетевыми узлами.

• Наблюдайте за базовым состоянием и работоспособностью узла без входа на серверы.

Система работает поверх предоставленной пользователем инфраструктуры (физической или виртуальной) и естественным образом вписывается в модель децентрализованной сети.

Обзор архитектуры

Компоненты

Основные пользовательские потоки

• Начальная загрузка узла — пользователь добавляет узел в пользовательский интерфейс → агент устанавливается один раз на сервере → узел доступен

• Развертывание и обновления — автоматизированы с помощью заранее настроенного пути стабильного выпуска, без вмешательства пользователя.

• Присоединение к сети/ML — узел ML подключен к сетевому узлу, правила брандмауэра применяются автоматически, подключение проверено.

• Рабочий процесс с теплым ключом — теплый ключ генерируется локально на узле, доступен только открытый ключ, подпись холодным ключом остается за оператором

Модель безопасности

• Доступ по SSH остается полностью под контролем оператора — плоскость управления никогда не сохраняет учетные данные и не использует SSH.

На узлах не требуются входящие порты управления

• Агент выполняет только утвержденные, заранее определенные операции — никаких произвольных удаленных команд.

Пакеты стека проверяются перед применением

Холодные клавиши никогда не покидают устройство оператора

Это сохраняет суверенитет узла и соответствует принципам децентрализации Gonka.

Объем MVP

Включено

Агент узла уровня хоста

Развертывание сети и узлов машинного обучения

• Автоматические обновления через предварительно настроенный путь стабильного выпуска.

Подключение к сети/ML с автоматизацией брандмауэра

Рабочий процесс генерации теплых ключей и привязки

Базовая отчетность о состоянии и состоянии здоровья

Явно вне области видимости

Расширенные стеки метрик и наблюдаемости

Произвольное удаленное выполнение команд

Выбор версии вручную или несколько каналов обновления

Управление доступом на основе ролей

Автоматизированные механизмы отката (кроме рекомендованных разработчиками Gonka)

Обеспечение обновлений внутри сети

Удаленный административный доступ

План реализации

Этап 1. Установка MVP (45–50 % бюджета)

Результат: узлы сети и машинного обучения могут быть развернуты и работать непрерывно.

• Агент узла: развертывание, подключение, работоспособность — 160–200 часов.

• Основные API плоскости управления — 80–100 часов.

• Архитектура и основной дизайн — 40–60 часов.

• Минимальный интерфейс — 40–60 часов.

Интеграционное тестирование — 40–60 часов

Этап 2. Автоматические обновления MVP (20–25 % бюджета)

Результат: работающие узлы обновляются автоматически.

• Версионирование и подписи пакета — 40–60 часов.

• Логика обновления агента — 40–60 часов.

• Координация обновления плоскости управления — 20–30 часов.

• Тестирование обновлений — 20–30 часов.

Этап 3 — Мониторинг MVP (15–20 % бюджета)

Результат: операторы могут наблюдать за состоянием и работоспособностью узла.

• Отчет о состоянии агента — 30–40 часов.

Агрегация статуса бэкенда — 20–30 часов

• Просмотр статуса пользовательского интерфейса — 40–50 часов.

Этап 4 — Стабилизация и технический долг (10–15% бюджета)

Результат: стабильный, документированный, готовый к производству MVP.

Исправления ошибок и крайние случаи

Усиление безопасности

Документация

Финальное тестирование

Общие предполагаемые трудозатраты: 650–880 инженерно-часов.

Бюджет

Запрошено: эквивалент 80 000 долларов США (единовременно, из пула сообщества)

Финансирование выделяется поэтапно, в зависимости от завершения этапа. Перерасход средств команда покрывает за свой счет — никаких запросов на компенсацию обратной силы не подается.

Подотчетность

• Весь прогресс отслеживается в одном общедоступном репозитории GitHub.

• Progress.md обновляется после каждого этапа с письменным резюме, результатами и ссылками на артефакты.

Код, документация, примечания к выпуску и демонстрационные материалы, зафиксированные на каждом этапе

• URL-адрес репозитория объявляется сразу после утверждения предложения.

Ожидаемый результат

Упрощенная регистрация для новых операторов узлов

Увеличенное количество независимых узлов

Сокращение времени простоя, вызванного ручной настройкой

• Более сильная и устойчивая децентрализация сети Gonka.

Эй! Вы проверили, что уже построили эти ребята в этом направлении? https://gonka.gg/node-setup

Что вы думаете об их реализации?

Наше предложение фокусируется на другом наборе эксплуатационных требований:

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

Централизованная видимость. Цель состоит в том, чтобы предоставить панель мониторинга, на которой состояние сети и узлов ML можно отслеживать в одном месте, а не проверять журналы отдельных серверов.

Логика оркестровки: мы автоматизируем правила подключения и брандмауэра, необходимые для присоединения узлов ML к сетевым узлам, что в настоящее время включает несколько шагов вручную.

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

Также обратите внимание на бота Telegram для мониторинга узлов: @GonkaHubBot.

Я уже месяц пытаюсь настроить свой узел.

Это не совсем простая установка — 8 × A100 40 ГБ. После одного из недавних изменений кода использование этих графических процессоров было практически ограничено. Но я уже оплатил сервер на месяц, поэтому теперь использую его для полного тестирования и доводки процесса развертывания ноды.

Специально для этого я даже оформил платную подписку на Cursor. Очень надеюсь, что мне удастся заставить все работать правильно.

Если мне это удастся, я обязательно поделюсь всем опытом с другими.

Тем не менее, я не совсем уверен, можно ли реально превратить настройку узла в «услугу в один клик». Существует так много крайних случаев и нюансов — может ли сервис действительно учитывать все это?

На мой взгляд, модель, основанная на ИИ-агенте, который глубоко понимает инфраструктуру и имеет доступ ко всей актуальной документации, кажется более масштабируемой, чем создание жесткой службы настройки.

Но я могу ошибаться.

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

Кстати, весь свой путь я документирую в Базе знаний: https://gonka-data-base.gitbook.io/gonka-data-base-en/hosts/node.-testing

Возможно, что-то из этого может быть полезно для вашего проекта.

Задача «одного щелчка» — это именно то, почему наше предложение переходит от простых сценариев к архитектуре Node Agent.

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

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

Проблема "работы в один клик" — именно поэтому в нашем предложении мы отходим от простых скриптов в пользу архитектуры Node Agent. Статическая настройка часто дает сбой при изменении оборудования или зависимостей. Наш подход использует агент в качестве локального уровня управления для обработки среды, стеков Docker и подключения. Цель этой архитектуры — предоставить систему, которая учитывает нюансы инфраструктуры и поддерживает работу узлов при обновлениях, а не просто выполняет первоначальную установку. Проект призван автоматизировать эти ручные процессы и обрабатывать нестандартные ситуации, которые обычно возникают при длительном обслуживании узлов.

Унифицированный стек операторов: доставка, контроль, воспроизводимость. Сочетание Node Manager (#816 (https://github.com/gonka-ai/gonka/discussions/816)) и экспортера Prometheus (#840 (https://github.com/gonka-ai/gonka/discussions/840)) с тонким слоем оркестрации (например, Воздушный поток, опционально n8n) образует единый стек, который не такой тяжелый, но удовлетворяет основные потребности оператора: доставка, контроль и воспроизводимость. Доставка: развертывание и обновление узлов через Node Manager; нет необходимости держать каждый хост в руках. Контроль: одинаковые метрики (высота блока, вес POC, статус) для всех через экспортер + Prometheus + Grafana — хосты видят то, что видим мы. Воспроизводимость: Airflow превращает процедуры в группы обеспечения доступности баз данных: проверки работоспособности, окна обновления, создание отчетов, очистка и даже шаги в стиле билетов/рабочих процессов (например, «после оповещения → создать задачу → запустить исправление»). Любой сценарий, который вы можете написать, становится повторяемым и контролируемым. Таким образом, вы получаете одно место для «как мы развертываем», «как мы отслеживаем» и «как мы реагируем и перезапускаем». Стек модульный: минимальный — экспортер + Прометей + Графана; Node Manager и Airflow (и опционально n8n для битов, управляемых событиями) добавляются сверху для тех, кому нужна автоматизация и воспроизводимость. Стоит делать? Да. Он напрямую решает проблему «хосты не могут легко настраивать и контролировать, как мы»: те же инструменты, та же видимость и та же возможность кодировать и воспроизводить сценарии вместо специальных SSH и одноразовых сценариев. Если сообщество хочет инвестировать в опыт операторов и воспроизводимость, это конкретный способ добиться этого.

Проблема "работы в один клик" — именно поэтому в нашем предложении мы отходим от простых скриптов в пользу архитектуры Node Agent. Статическая настройка часто дает сбой при изменении оборудования или зависимостей. Наш подход использует агент в качестве локального уровня управления для обработки среды, стеков Docker и подключения. Цель этой архитектуры — предоставить систему, которая учитывает нюансы инфраструктуры и поддерживает работу узлов при обновлениях, а не просто выполняет первоначальную установку. Проект призван автоматизировать эти ручные процессы и обрабатывать нестандартные ситуации, которые обычно возникают при длительном обслуживании узлов. Унифицированный стек операторов: доставка, контроль, воспроизводимость. Сочетание Node Manager (#816 (https://github.com/gonka-ai/gonka/discussions/816)) и экспортера Prometheus (#840 (https://github.com/gonka-ai/gonka/discussions/840)) с тонким слоем оркестрации (например, Воздушный поток, опционально n8n) образует единый стек, который не такой тяжелый, но удовлетворяет основные потребности оператора: доставка, контроль и воспроизводимость. Доставка: развертывание и обновление узлов через Node Manager; нет необходимости держать каждый хост в руках. Контроль: одинаковые метрики (высота блока, вес POC, статус) для всех через экспортер + Prometheus + Grafana — хосты видят то, что видим мы. Воспроизводимость: Airflow превращает процедуры в группы обеспечения доступности баз данных: проверки работоспособности, окна обновления, создание отчетов, очистка и даже шаги в стиле билетов/рабочих процессов (например, «после оповещения → создать задачу → запустить исправление»). Любой сценарий, который вы можете написать, становится повторяемым и контролируемым. Таким образом, вы получаете одно место для «как мы развертываем», «как мы отслеживаем» и «как мы реагируем и перезапускаем». Стек модульный: минимальный — экспортер + Прометей + Графана; Node Manager и Airflow (и опционально n8n для битов, управляемых событиями) добавляются сверху для тех, кому нужна автоматизация и воспроизводимость. Стоит делать? Да. Он напрямую решает проблему «хосты не могут легко настраивать и контролировать, как мы»: те же инструменты, та же видимость и та же возможность кодировать и воспроизводить сценарии вместо специальных SSH и одноразовых сценариев. Если сообщество хочет инвестировать в опыт операторов и воспроизводимость, это конкретный способ добиться этого.

Проблема "работы в один клик" — именно поэтому в нашем предложении мы отходим от простых скриптов в пользу архитектуры Node Agent. Статическая настройка часто дает сбой при изменении оборудования или зависимостей. Наш подход использует агент в качестве локального уровня управления для обработки среды, стеков Docker и подключения. Цель этой архитектуры — предоставить систему, которая учитывает нюансы инфраструктуры и поддерживает работу узлов при обновлениях, а не просто выполняет первоначальную установку. Проект призван автоматизировать эти ручные процессы и обрабатывать нестандартные ситуации, которые обычно возникают при длительном обслуживании узлов.

Одна конкретная цифра, объясняющая, почему развертывание специализации модели имеет значение для уровня кэша в PR № 859 (https://github.com/gonka-ai/gonka/pull/859):

hit_rate = повторная_фракция × (1/M) × (1 — потоковая_фракция)

M=571 (Qwen3-32B, общий для 571 узла): hit_rate = 0,000473 M=1 (уникальная модель для каждого узла через диспетчер узлов): hit_rate = 0,270

Множитель специализации: улучшение скорости попадания в кэш в 571 раз. При M=1 достигается ограничение MaxWeightFractionBps (+30 % веса эпохи).

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

Источник данных: топология живой сети, gonka.gg/api/public (1282 узла ML, измерено 5 моделей, эпоха 190).

В обсуждении Telegram некоторые люди говорят, что это улучшение, возможно, сейчас не очень актуально. Кажется, сейчас есть более насущные задачи, тем более, что альтернативные решения уже существуют. Однако нам бы очень не хотелось потерять ваше желание строить проекты для Гонки.

Возможно, вы могли бы подумать о более актуальной задаче?

Вы упомянули существующий список задач. Мы были бы рады взглянуть — не могли бы вы указать нам, где его можно найти?

Вы упомянули существующий список задач. Мы были бы рады взглянуть — не могли бы вы указать нам, где его можно найти?

Недавно мы опубликовали три новых предложения в обсуждениях GitHub и будем рады любым отзывам.

Масштабирование вывода № 801 (https://github.com/gonka-ai/gonka/discussions/801)

Многомодельный PoC № 800 (https://github.com/gonka-ai/gonka/discussions/800)

• Непрерывный PoC #802 (https://github.com/gonka-ai/gonka/discussions/802) (по этому предложению я также открыл вопрос, в котором можно обсудить идеи дизайна и реализации. Непрерывный дизайн PoC + реализация #821 (https://github.com/gonka-ai/gonka/issues/821) )

Если у вас есть мысли, проблемы или идеи по улучшению, поделитесь ими прямо в комментариях.

Кроме того, я открыл дополнительное обсуждение, чтобы выделить три ключевые области, где необходима помощь #817 (https://github.com/gonka-ai/gonka/discussions/817). Они еще не сформулированы как отдельные задачи, но указывают на три проблемы, в которых ваше участие, точка зрения и предложения будут чрезвычайно ценны.

Исследование медленных узлов № 818 (https://github.com/gonka-ai/gonka/issues/818)

• Исследование пропущенного вывода на некоторых узлах (основные причины + устранение) № 820 (https://github.com/gonka-ai/gonka/issues/820).

рост/обрезка application.db #819 (https://github.com/gonka-ai/gonka/issues/819)

Кроме того, вы можете отфильтровать проблемы с помощью метки «доступно» https://github.com/gonka-ai/gonka/issues?q=is%3Aissue%20state%3Aopen%20label%3Aup-for-grabs и посмотреть, есть ли какие-либо открытые задачи, у которых нет правопреемника.

Подробнее о баунти-программе: https://gonka.ai/FAQ/#bounty-program

Итак, вот рабочее решение с некоторыми ограничениями (все еще в разработке, поэтому текущий функционал ограничен предоставлением сети + mlnode на одном сервере) https://github.com/inc4/gonka-nop/releases/tag/v0.1.8-rc1. Загрузите двоичный файл, выполните настройку ./gonka-nop и вот мы здесь.

и вот наша дорожная карта того, что было сделано.

Этапы реализации

Этап 1: Базовая платформа CLI ✅ ЗАВЕРШЕНО

1.1 Строительные леса проекта

Инициализируйте go.mod с зависимостями

• Создайте точку входа cmd/gonka-nop/main.go.

• Создайте внутренний/cmd/root.go с помощью команды Cobra root.

Добавить версию, статус, сброс, заглушки команд gpu-info

Создайте внутренний/cmd/setup.go (команда установки с флагами)

1.2 Утилиты пользовательского интерфейса (необходимы для этапов)

Создайте внутренний/ui/output.go (цветные сообщения: Информация, Успех, Предупреждение, Ошибка)

Создайте внутренний/ui/spinner.go (обертку счетчика прогресса)

• Создайте внутренний/ui/prompt.go (оболочку опроса для интерактивных подсказок).

1.3 Управление состоянием

Создайте внутренний/config/state.go (структуру состояния)

• Реализуйте методы Save() и Load().

1.4 Фазовая система

Создайте внутренний/фазы/phase.go (интерфейс фазы + бегун)

• Создайте макеты фаз для демонстрации: 01_prequires.go (Docker, проверка CUDA — макет) 02_gpu_detection.go (обнаружение графического процессора — макет) 03_network_select.go (подсказка выбора сети) 04_key_management.go (ключевой рабочий процесс — макет) 05_config_generation.go (создание конфигураций — макет) 06_deploy.go (составление докера) - посмеялся)

01_prequires.go (Docker, проверка CUDA — высмеивается)

02_gpu_detection.go (обнаружение графического процессора — высмеивается)

03_network_select.go (подсказка выбора сети)

04_key_management.go (ключевой рабочий процесс — высмеивается)

05_config_generation.go (генерация конфигов — высмеивается)

06_deploy.go (составление докера — высмеивается)

1.5 Интеграция и демонстрация

Команда настройки проводки к фазовращателю

Проверьте полную компиляцию CLI (перейдите к сборке ./...)

Запустите демо: настройка gonka-nop (показывает полный процесс)

1.6 Команда состояния

Создайте внутренний/status/status.go (структура NodeStatus, функции выборки)

Создайте внутренний/status/display.go (форматированный вывод)

• Внедрить 3 раздела: Обзор, Блокчейн, MLNode.

Поддержка флага --mocked для демо-версии

Реализуйте команду gpu-info с помощью --mocked

Этап 2: Покрытие тестированием (сначала тесты) 🔄 В ПРОГРЕССЕ

Напишите тесты для существующего кода перед добавлением новых функций. Цель: охват 70%+.

2.1 Тестирование пакетов конфигурации (цель: 90%+)

state_test.go — NewState, Save, Load, Reset, MarkPhaseComplete

Добавить тесты крайних случаев (неверный JSON, ошибки разрешений)

2.2 Пакетные испытания этапов (цель: 80%+)

gpu_detection_test.go — рекомендацияConfig, FormatGPUSummary

preреквизиты_test.go — имитация проверок Docker/Nvidia

config_generation_test.go — проверка вывода шаблона

Phase_runner_test.go — поток выполнения фазы

2.3 Тестирование статусных пакетов (цель: 70%+)

status_test.go — имитация HTTP-ответов, проверка синтаксического анализа

display_test.go — форматирование вывода

2.4 Тестирование пакетов пользовательского интерфейса (цель: 50%+)

output_test.go — форматирование цвета

spinner_test.go — базовый функционал

Prompt_test.go — имитация ответов на опрос (сложнее протестировать)

2.5 Интеграционные тесты

интеграционный тест cmd/setup с имитацией фаз

Сквозной тест на сохранение состояния

Этап 3: графический процессор и необходимые условия (РАСШИРЯЕТСЯ в зависимости от анализа чата) ✅ ПРАКТИЧЕСКИ ЗАВЕРШЕНО

Реальное обнаружение системы заменяет ложные реализации. Проверено в основной сети (8x A100 SXM4 80 ГБ).

3.1 Обнаружение графического процессора (настоящая nvidia-smi) ✅ ЗАВЕРШЕНО

Разобрать nvidia-smi --query-gpu=index,name,memory.total,driver_version,pci.bus_id --format=csv

• Определить архитектуру графического процессора (sm_80=A100, sm_86=A40/RTX3090, sm_89=L40/RTX4090, sm_90=H100/H200, sm_100=B200/B300, sm_120=RTX5090) — GPUArchFromName() в gpu_parser.go

• Обнаружение топологии NVLink/PCIe — на основе имени (H100/H200/A100 = NVLink, другие = PCIe). Полная версия nvidia-smi topo -m еще не реализована.

Предупреждение о пропускной способности PCIe для установок с несколькими графическими процессорами без NVLink

Автоматический выбор тега изображения MLNode на основе архитектуры (стандартный/блэквелл) — selectMLNodeImage()

3.2 Проверка Docker и среды выполнения ✅ ЗАВЕРШЕНО

Проверка доступности и версии Docker — ParseDockerVersion() в gpu_parser.go

Обнаружение NVIDIA Container Toolkit ( nvidia-ctk --version )

• Проверка CUDA внутри контейнера Docker (docker run --gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi) — checkCUDAInDocker()

Проверка Docker Compose v2 (версия docker Compose) — ParseDockerComposeVersion()

3.3 Установка и проверка драйвера NVIDIA ✅ ПОЛЬЗОВАТЕЛЬНО ЗАВЕРШЕНА

Определить состояние драйвера: не установлен/установлен/несоответствие версии — checkNVIDIADriver()

• Предварительная проверка безопасности: состояние безопасной загрузки, доступные заголовки ядра, совместимость с дистрибутивом.

• Предлагайте автоматическую установку с подтверждением пользователя — installNVIDIADriver() через apt.

• Установите Fabric Manager ( nvidia-fabricmanager-570 ), если обнаружен многопроцессорный NVLink — проверьтеFabricManager() с автоматическим запуском + приглашение на установку.

• Сравните версию библиотеки пользовательского пространства с версией модуля ядра и версией Fabric Manager — трехсторонняя проверка согласованности в checkDriverConsistency()

• Обнаружение пакета автоматических обновлений и предупреждение об автоматических обновлениях драйверов NVIDIA — предлагает удерживать apt-mark nvidia-driver-*

• Проверьте совместимость версии CUDA с обнаруженным драйвером.

• Предупреждать о необходимости перезагрузки после установки/обновления модуля ядра.

3.4 Предварительные требования к системе ✅ ПРАКТИЧЕСКИ ПОЛНАЯ

Обнаружение дистрибутива Linux (Ubuntu, Debian, CentOS, Amazon Linux) — ParseOSRelease() в gpu_parser.go

• Предварительная проверка дискового пространства (предупреждение, если свободно < 250 ГБ) — ParseDiskFreeGB() , ParseLsblkJSON()

Автоматическая установка NVIDIA Container Toolkit (с подтверждением пользователя)

Конфигурация среды выполнения Docker (nvidia-ctk runtime configure --runtime=docker)

Проверка доступности портов (5000, 8000, 26657 внешние; 5050, 8080, 9100, 9200 внутренние)

Этап 4: Конфигурация (РАСШИРЯЕТСЯ для каждого анализа чата) ✅ ПРАКТИЧЕСКИ ЗАВЕРШЕНА

Создавайте готовые к использованию конфигурации с настройками безопасности и производительности по умолчанию, полученными от валидаторов. Проверено при развертывании в основной сети.

4.1 Алгоритм рекомендации TP/PP ✅ ЗАВЕРШЕНО

Расчет TP/PP с учетом модели (Qwen3-235B, Qwen3-32B, QwQ-32B) — рекомендуется Config() с 4-уровневой логикой VRAM

Рекомендация по использованию памяти gpu: 0,88–0,94 на основе запаса видеопамяти (НЕ 0,99)

расчет max-model-len на основе оставшейся видеопамяти после загрузки модели

• Автоматическое добавление --kv-cache-dtype fp8 для конфигураций с ограниченным объемом видеопамяти (например, 8x A100 40 ГБ с 235 ГБ)

• PP не установлен в аргументах vLLM — бегун MLNode автоматически рассчитывает на основе графических процессоров/TP. Нет --quantization fp8 (вызывает ошибки выравнивания MoE)

4.2 Генерация node-config.json ✅ ЗАВЕРШЕНО

Генерация на основе шаблона с помощью go:embed

проверка поля хоста (без префикса http:// – распространенная ошибка в чате)

Поле оборудования заполняется автоматически при обнаружении графического процессора

Рекомендация max_concurrent на основе конфигурации графического процессора

Выбор модели с явным объявлением (требуется для PoC v2)

4.3 Генерация config.env ✅ ЗАВЕРШЕНО

На основе шаблона с проверенными полями

Переменная среды MODEL_NAME (обязательна после версии 0.2.8)

VLLM_ATTENTION_BACKEND = FLASHINFER для ВСЕХ архитектур (стандарт 3.0.12+, старое правило FLASH_ATTN устарело)

4.4 Генерация docker-compose.yml ✅ ЗАВЕРШЕНО

На основе шаблона с помощью go:embed

• Безопасность портов: привяжите внутренние порты к 127.0.0.1 (5050, 8080, 9100, 9200).

Публичные порты: 5000 (P2P), 8000 (API через прокси), 26657 (RPC — через прокси только после защиты от DDoS)

Выбор тега изображения MLNode на основе определения архитектуры графического процессора

4.5 Настройки защиты от DDoS по умолчанию ✅ ЗАВЕРШЕНО

Конфигурация прокси-сервиса: GONKA_API_BLOCKED_ROUTES=обучение poc-пакетов

Конфигурация прокси-сервиса: GONKA_API_EXEMPT_ROUTES=вывод чата

• По умолчанию: DISABLE_CHAIN_API=true, DISABLE_CHAIN_RPC=true, DISABLE_CHAIN_GRPC=true.

Порт RPC (26657), доступный только через прокси, не доступный напрямую

4.6 Настройка синхронизации и сокращения ✅ ЗАВЕРШЕНО

• Автоматическая настройка persist_peers в config.toml с заведомо исправными узлами.

• Создайте app.toml с обрезкой: custom, Keep-recent=1000, интервал=100.

• Установите GENESIS_SEEDS и SEED_API_URL для надежных конечных точек.

Включить синхронизацию состояния по умолчанию ( SYNC_WITH_SNAPSHOTS=true )

Этап 5: Развертывание (РАСШИРЯЕТСЯ в зависимости от анализа чата) ✅ ПРАКТИЧЕСКИ ЗАВЕРШЕНО

Развертывайте контейнеры с реальной оркестровкой, усилением безопасности и мониторингом синхронизации. Проверено в основной сети + тестовой сети.

5.1 Оркестровка Docker Compose ✅ ЗАВЕРШЕНО

Обработка нескольких файлов (прозрачный -f docker-compose.yml -f docker-compose.mlnode.yml )

• Автоматический источник config.env + sudo -E для распространения переменных среды — внутренний/docker/env.go + compose.go

Получение изображения с отображением прогресса — получение файла Docker Compose

Запуск контейнера с упорядоченными зависимостями — сначала сетевой узел, затем узел ML

5.2 Настройка брандмауэра ⚠️ (из чата: Docker обходит UFW)

Обнаружение поведения iptables Docker

• Настройте правила цепочки DOCKER-USER: Разрешить установленные соединения. Разрешить общедоступные порты (5000, 8000). Занести в белый список известные исходные узлы Gonka. УДАЛИТЬ все остальные входящие соединения в контейнеры Docker.

Разрешить установленные соединения

Разрешить общедоступные порты (5000, 8000)

Белый список известных аналогов семян Gonka

• УДАЛИТЕ все остальные входящие контейнеры Docker.

• Предложите интеграцию iptables-persistent для сохранения правил.

Проверка разрешения IPv4/IPv6 для конечной точки работоспособности vLLM (предотвращение цикла перезапуска)

5.3 Управление ключами (оба рабочих процесса) ✅ ЗАВЕРШЕНО

Быстрый рабочий процесс: сгенерируйте все ключи на сервере — 04_key_management.go

• Безопасный рабочий процесс: принять публичный ключ учетной записи, сгенерировать консенсус + ключи ML — флаг --account-pubkey

автоматизация предоставления грантов-ml-ops-permissions — 07_registration.go

Руководство по резервному копированию ключей

5.4 Загрузка веса модели ✅ ЗАВЕРШЕНО

Загрузка модели HuggingFace с индикатором выполнения — отдельная команда загрузки модели gonka-nop + этап развертывания

• Возобновить поддержку прерванных загрузок — использует запуск Docker с монтированием HF_HOME.

Проверка SHA256 после загрузки

• Предварительная загрузка в HF_HOME перед запуском контейнера.

5.5 Проверка работоспособности и мониторинг синхронизации ✅ ЗАВЕРШЕНО

Проверка работоспособности контейнера (все работающие службы) — опросы /admin/v1/setup/report

• Ход синхронизации блокчейна с отображением задержки блока — опрашивает Tendermint RPC /status, показывает прогресс высоты блока, тайм-аут 30 минут

Дождитесь завершения синхронизации перед регистрацией (настраиваемый тайм-аут)

Проверка доступности порта (доступны внешние порты) — запланирована проверка доступности PUBLIC_URL

Этап 6: Операции ⚠️ НОВИНКА (из чата: день-2 — 90 % времени оператора)

Команды после развертывания для текущего управления узлами. Весь этот этап отсутствовал в первоначальном плане и основан на анализе чата валидатора, который показывает, что операторы тратят большую часть времени на операции, а не на настройку.

Статус 6.1 гонка-ноп (реальная реализация) ✅ ЗАВЕРШЕНО

• Блокчейн: высота блока, статус синхронизации, блоки позади, флаг catch_up.

• Эпоха: текущая эпоха, статус участия, вес, процент промахов.

• Эпоха: вес PoC, распределение временных интервалов, количество выводов, предстоящая эпоха, статус заявки на вознаграждение.

• MLNode: загруженная модель, загрузка графического процессора, статус PoC, предполагаемое и текущее несоответствие, актуальность статуса.

• Конфигурация узла: общедоступный URL-адрес, URL-адрес обратного вызова PoC, начальный API, версия API, задержка по высоте, план обновления.

• Безопасность: холодный ключ, теплый ключ, разрешения ML.

• Контейнеры: работающее/остановленное/неработоспособное состояние, полученное на основе проверок настройки/отчетов.

• Проверка доступности PUBLIC_URL — HTTP GET <public_url>/health , отчет PASS/FAIL с подробностями об ошибке. Критично: несоответствие порта или неправильный зарегистрированный URL = валидаторы не могут проверить доказательства PoC = узел никогда не набирает вес. Узнал из отладки тестовой сети (11 февраля 2026 г.).

• Сеть: количество одноранговых узлов (заблокировано — Tendermint RPC 26657 не доступен хосту при стандартных развертываниях)

Временная шкала частоты промахов (визуализация зелеными/красными точками)

Обновление 6.2 gonka-nop (безопасное развертывание) ✅ ЗАВЕРШЕНО (реализовано как M9.2)

• Проверьте timeslot_allocation через API администратора, чтобы найти безопасное окно.

Отключить узел ML через POST /admin/v1/nodes/:id/disable

Извлеките новый образ контейнера с прогрессом

Обновить тег изображения в файле docker-compose

Воссоздать контейнер ( --no-deps --force-recreate )

Дождитесь завершения загрузки модели (отслеживайте журналы)

• Повторно включите узел ML через POST /admin/v1/nodes/:id/enable.

Проверка работоспособности после обновления

Отличить автоматическое обновление (Космовизор: node, api) от ручного (mlnode, proxy)

6.3 сброс gonka-nop (очистка данных блокчейна)

• Сохраняйте ключи (tmkms, учетную запись, ML) и файлы конфигурации.

Запустите выведенный тендерминт unsafe-reset-all --keep-addr-book внутри контейнера

• Удалите каталог update-info.json и космовизор/.

Перезапустить контейнер узла

Отслеживание хода синхронизации после сброса

6.4 очистка gonka-nop (восстановление дискового пространства)

Рассчитать текущее использование диска (.inference/data/, резервные копии космовизора)

• Удалите старые каталоги резервных копий Космовизора.

Сообщить об освобожденном месте

• Рекомендовать настройки обрезки, если они не настроены.

6.5 gonka-nop ml-node (обертка API администратора) 🔄 ЧАСТИЧНАЯ

Список ml-узлов — GET /admin/v1/nodes (статус, распределение, модель, оборудование, вес PoC)

Добавление ml-узла — POST /admin/v1/nodes (интерактивно или из конфигурации)

Обновление ml-узла — PUT /admin/v1/nodes/:id (модель, TP/PP, max_concurrent)

ml-node включить/отключить - POST /admin/v1/nodes/:id/enable|disable

• Статус ml-узла — подробная информация: хост, порты, модель+аргументы, оборудование, статус/предполагаемое несоответствие, распределение эпохи, вес PoC, временные интервалы, актуальность статуса.

6.6 модель гонка-ноп (управление моделью)

Переключение модели через API администратора (PUT /admin/v1/nodes/:id)

Показать текущую модель и модель следующей эпохи

• Предупреждать, что изменения модели применяются только в следующую эпоху.

Проверка совместимости модели с конфигурацией графического процессора

6.7 Загрузка двоичного файла перед обновлением

• Загрузите двоичные файлы выведенных и децентрализованных API из выпусков GitHub.

SHA256-проверка

• Поместить в правильный каталог обновления Космовизора.

Проверьте разрешения (chmod +x)

Этап 7: Регистрация и ончейн

7.1 Процесс регистрации ✅ ЗАВЕРШЕНО

submit-new-участник с правильными флагами (ключ валидатора, идентификатор цепочки, URL-адрес узла)

Автоматическое получение консенсуса_pubkey из API отчета о настройке

Grant-ml-ops-permissions для ключа ML

• Проверьте формат PUBLIC_URL (без префикса http://).

7.2 Проверка PoC

Тестировать конечную точку PoC ( /api/v1/pow/init/generate )

Убедитесь, что модель загружена и отвечает

Проверьте участие в эпохе после регистрации

7.3 Управление вознаграждениями

gonka-nop претензии-вознаграждения - Упрощенный поток заявок

Получить начальное значение из конфигурации API администратора

Принудительное требование через /admin/v1/claim-reward/recover для пропущенных эпох

Показать историю невостребованных наград

7.4 Управление

gonka-nop voice — упрощенное управление голосованием

Показать активные предложения

Голосуйте с помощью ключа учетной записи

Этап 8: Продвинутый уровень и полировка 🔄 В ПРОГРЕССЕ

Пакетное управление несколькими узлами (обновление/статус на более чем 10 узлах)

Визуализация временной шкалы частоты промахов (точечное отображение ОК/пропущенных ошибок)

Совместимость с облачными провайдерами (переназначение портов Vast.ai, голое железо GCore)

• Поддержка русского языка для сообщений об ошибках и подсказок.

• Интеграция мониторинга (экспортер Prometheus + централизованная архитектура push-уведомлений) — см. M8.1.

Интеграция сравнительного анализа производительности (compressa-perf)

Механизм самообновления двоичного файла gonka-nop

Автоматизация документирования и выпуска

8.1 Централизованный мониторинг (Ansible) ✅ ЗАВЕРШЕНО

Включенный push-мониторинг для валидаторов Gonka. Развертывание на основе Ansible в подкаталоге ansible/.

Архитектура: Exporter + Prometheus на валидаторе → push_write → Central Prometheus + Grafana (управляется inc4). На узлах валидатора не открыты входящие порты.

Компоненты построены:

• роль gonka-exporter — объединяет экспортер votkon (28 метрик из 5 конечных точек API), локально создает образ Docker, развертывает через компоновку

• роль prometheus — Prometheus с условным удаленным_записью, правилами оповещений (11 правил в 2 группах), --web.enable-remote-write-receiver для центрального сервера

роль alertmanager — условные уведомления Telegram/Discord/Slack, серьезность на основе маршрута

• роль grafana — автоматически предоставляемые источники данных + 2 панели мониторинга (обзор парка, глубокое погружение в узел)

playbooks/deploy-all.yml — полный стек для центрального сервера (экспортер + prometheus + alertmanager + grafana)

playbooks/add-node.yml — добавить внутренний валидатор с помощью Remote_write в центральный

• playbooks/client-deploy.yml — автономный для внешних валидаторов (жестко закодированный центральный URL-адрес, проверяет предварительные условия, проверяет работу удаленной записи)

playbooks/client-teardown.yml — чистое удаление мониторинга из валидатора

инвентарь/client.yml.example — шаблон для внешних операторов

• README.md — ориентированная на оператора документация со схемой архитектуры, таблицей метрик, правилами оповещений, гарантиями безопасности.

• .gitignore — защищает файлы инвентаризации клиента от случайных коммитов.

Панели мониторинга:

• Обзор флота ( gonka-fleet-overview ) — обзор нескольких узлов со статусом, задержкой блока, частотой промахов, весом PoC, графическим процессором, доходом.

• Глубокое погружение узла ( gonka-node-deep-dive ) — подробности по каждому узлу с помощью переменной шаблона $instance.

Правила оповещения (11):

• Критические: GonkaMissRateHigh (>20%), GonkaNodeFailed, GonkaBlockLagCritical (>200 блоков), GonkaNodeStopped, GonkaExporterDown.

• Предупреждение: GonkaBlockLag (>50), GonkaCatchingUp, GonkaGPUUtilizationHigh (>95%), GonkaZeroWeight, GonkaZeroInferences, GonkaStatusMismatch.

Этап 9: Управление версиями ✅ ЗАВЕРШЕНО (3/4 задачи, предварительная раздача отложена)

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

Источник истины: репозиторий GitHub gonka-ai/gonka.

Основная сеть: основная ветка → Deploy/join/docker-compose.yml + docker-compose.mlnode.yml

Тестовая сеть: тестовая сеть/основная ветка → те же пути

9.1 Получение версии динамического изображения ✅ ЗАВЕРШЕНО

Структура ImageVersions с тегами для каждой службы (узел, API, tmkms, прокси, мост, mlnode, nginx)

• FetchImageVersions() извлекает необработанные URL-адреса GitHub во время установки.

• ParseComposeImageVersions() извлекает теги из YAML-файла (обрабатывает комментарии, выводы мостового дайджеста, прокси против прокси-ssl)

• Откат к жестко запрограммированным версиям, когда GitHub недоступен.

Фаза выбора сети извлекает и заполняет состояние

• При генерации конфигурации используются версии для каждой службы.

• 12 тестов, охватывающих синтаксический анализ, резервный вариант и устранение неоднозначности.

Обновление 9.2 gonka-nop (обновление безопасной версии) ✅ ЗАВЕРШЕНО

• Загрузите последние версии с GitHub и сравните с текущими файлами компоновки.

Показывать разницу изменений версий перед применением

• Для служб обновления вручную (прокси, мост, mlnode): обновите теги изображений в файлах компоновки.

• Безопасное развертывание MLNode: проверьте распределение временных интервалов → отключить → извлечь → воссоздать → дождаться загрузки модели → включить.

• Для сервисов, управляемых Cosmovisor (узел, API): сообщите пользователю об этих автоматических обновлениях в блоке обновления цепочки.

--check флаг, чтобы показывать только доступные обновления без применения

9.3 Предварительная раздача обновления «Космовизора» (во время развертывания)

• Предложения по управлению цепочкой запросов через REST API (/cosmos/gov/v1/proposals).

Обнаружение ожидающих или примененных планов обновления

• Предварительная загрузка выведенных и децентрализованных двоичных файлов API в каталоги обновления Cosmovisor.

Проверка SHA256 из поля plan.info предложения

• Предотвращает зависание узла в цикле перезапуска, если он находится в автономном режиме во время блокировки обновления.

9.4 ремонт гонка-нопа (обнаружение и исправление застрявших узлов) ✅ ЗАВЕРШЕНО

• Обнаружение цикла перезапуска «обработчик обновления отсутствует» в журналах контейнера узлов.

• Разобрать информационное поле update-info.json на наличие двоичных URL-адресов в цепочке (источник истины для репозиториев основной сети и тестовой сети)

• Загрузите и поместите двоичные файлы в правильный каталог обновления Космовизора (с проверкой SHA256).

• Обновите текущую символическую ссылку, чтобы она указывала на каталог обновления.

Перезапустить контейнер узла

• Исправлено: предпочтение URL-адресов update-info.json вместо поиска релизов GitHub (предотвращает неправильный двоичный файл в тестовой сети).

Этап 10: Поддержка нескольких MLNode (отдельные серверы) — ПЛАНИРУЕТСЯ

10.1 Команды добавления/обновления/удаления ml-узла

Добавление ml-узла — POST /admin/v1/nodes (интерактивный режим + режим флагов)

обновление ml-узла <id> — PUT /admin/v1/nodes/:id

ml-node delete <id> — УДАЛИТЬ /admin/v1/nodes/:id

10.2 Флаг типа установки (--type full|network|mlnode)

--type network — только узел цепочки + API, пропустить этапы GPU/mlnode

--type mlnode --network-node URL — только сервер GPU, новые этапы, специфичные для mlnode

--type full (по умолчанию) — текущее поведение не изменилось

10.3 Этапы настройки только MLNode

08_mlnode_config.go — генерировать только mlnode Compose + nginx

09_mlnode_deploy.go — создание докера + регистрация на сетевом узле через API администратора

Предупреждение об URL-адресе обратного вызова PoC для настроек с несколькими серверами