Step 9: DePIN Engines Integration — подключаем сервер к сети

К этому моменту самое сложное уже сделано. Железо собрано, Ubuntu работает, Docker установлен, NVIDIA-драйвер видит все GPU, сеть и питание проверены. Теперь сервер нужно подключить к одной из DePIN-платформ, которая будет давать ему реальные задачи.

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

1. Что мы называем DePIN-движком

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

Например, io.net и Vast.ai могут использовать один и тот же физический GPU-сервер, но делают это через разное программное окружение и разные кабинеты.

Поэтому выбор сети — это не замена железа. Мы меняем программный слой поверх уже готового сервера.

2. Почему не нужно запускать две сети одновременно

Теоретически Linux позволяет запустить много программ сразу. Практически две DePIN-платформы начнут конкурировать за GPU, VRAM, Docker, порты и диски.

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

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

3. Сначала завершаем задания, потом переключаемся

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

Сначала в кабинете текущей платформы ждём состояния вроде Idle, Waiting или другого официального статуса, который означает отсутствие активной работы.

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

4. clear.sh — что он делает и почему требует подтверждение

Когда текущая сеть уже не выполняет задания, можно очистить Docker-окружение:

curl -fsSL https://de-pin.cloud/depin-scripts-v2/clear.sh -o /tmp/clear.sh && sudo bash /tmp/clear.sh --yes

Скрипт останавливает и удаляет Docker-контейнеры, удаляет неиспользуемые Docker-данные, выполняет Docker prune и системную очистку пакетов.

Параметр —yes обязателен не для красоты. Операция действительно разрушает текущее контейнерное окружение. Скрипт не удаляет произвольные пользовательские файлы вне Docker, но содержимое контейнеров и неиспользуемые Docker-volumes может быть удалено.

Поэтому clear.sh запускаем только когда сознательно решили покинуть текущий движок.

5. io.net — простой путь для GPU-сервера

io.net объединяет GPU-мощности в распределённую вычислительную сеть. Для владельца сервера логика выглядит понятно: зарегистрировать устройство, пройти авторизацию, убедиться, что GPU видны платформе, и перевести машину в рабочий режим.

Наш V2-скрипт не пытается подменить официальный установщик io.net. Он скачивает официальный setup-script и актуальный launch binary, после чего запускает стандартный процесс авторизации.

curl -fsSL https://de-pin.cloud/depin-scripts-v2/ionet.sh -o /tmp/ionet.sh && bash /tmp/ionet.sh

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

6. Что проверить после подключения io.net

Сервер должен отображаться в аккаунте, GPU должны определяться корректно, а статус устройства не должен постоянно прыгать между online и offline.

Если устройство исчезает, прежде чем переустанавливать всё подряд, проверяем интернет, nvidia-smi, Docker и системные логи. Нередко причина находится ниже уровня самой платформы.

7. Vast.ai — превращаем сервер в арендуемый GPU-host

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

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

curl -fsSL https://de-pin.cloud/depin-scripts-v2/vast.sh -o /tmp/vast.sh && sudo bash /tmp/vast.sh

Скрипт запрашивает ключ интерактивно, затем использует официальный Vast CLI и официальный host installer.

После установки машина должна появиться в панели Hosting. Там уже настраиваются параметры предложения, диски, сеть и доступность.

8. Почему ключ Vast не вставлен прямо в команду

Чувствительные данные не стоит хранить в истории команд или копировать в публичные инструкции.

Поэтому скрипт спрашивает ключ во время запуска. Это немного менее «магически», зато заметно правильнее с точки зрения эксплуатации.

9. Akash — это уже не просто аренда одной GPU

Akash Network ближе к распределённой облачной инфраструктуре. Provider там — более сложный объект, чем обычный GPU-worker.

Перед установкой обычно нужны домен, кошелёк Akash и подготовленный SSH-доступ.

curl -fsSL https://de-pin.cloud/depin-scripts-v2/akash.sh -o /tmp/akash.sh && sudo bash /tmp/akash.sh

Наш скрипт клонирует официальный provider-playbooks и запускает их setup_provider.sh. После этого дальнейшая настройка идёт через официальный guided flow Akash.

Если вы впервые работаете с DePIN-серверами, Akash логично осваивать после более простых GPU-hosting платформ.

10. Render Network — почему наш скрипт здесь только проверяет готовность

Не каждая сеть позволяет честно автоматизировать весь onboarding одной командой.

Для Render Network наш V2-скрипт выполняет preflight — предварительную проверку сервера.

curl -fsSL https://de-pin.cloud/depin-scripts-v2/render.sh -o /tmp/render.sh && bash /tmp/render.sh

Он проверяет Ubuntu, NVIDIA GPU и драйвер, RAM, дисковое пространство, Docker и NVIDIA Container Toolkit.

Если проверки проходят, дальше пользователь продолжает через официальный onboarding Render. Мы намеренно не скачиваем выдуманный worker binary и не обещаем регистрацию там, где её должен выполнять официальный портал.

11. Aethir — та же честная логика

Файл скрипта исторически называется aether.sh, но относится к платформе Aethir.

curl -fsSL https://de-pin.cloud/depin-scripts-v2/aether.sh -o /tmp/aether.sh && bash /tmp/aether.sh

Он проверяет Ubuntu, тип окружения и наличие NVIDIA GPU. После этого дальнейший Cloud Host/Checker onboarding выполняется только через официальный процесс Aethir.

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

12. Clore.ai — ещё один рынок GPU-мощности

Для Clore нужен аккаунт и Server Token из кабинета хостинга.

curl -fsSL https://de-pin.cloud/depin-scripts-v2/clore.sh -o /tmp/clore.sh && sudo bash /tmp/clore.sh

Скрипт запрашивает токен во время запуска, использует официальный installer Clore, проверяет появление host-компонента и инициализирует его.

После установки полезно перезагрузить сервер и проверить статус в личном кабинете.

13. Как выбирать сеть на практике

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

Смотрите, поддерживается ли ваша модель GPU, нужен ли большой VRAM, насколько востребован конкретный регион, какие требования к интернету и диску, как устроены выплаты и насколько стабильно приходят задания.

Один и тот же сервер в разные месяцы может быть выгоднее в разных сетях. Именно поэтому мы строим универсальную платформу и отделяем железо от движка.

14. После установки всегда возвращаемся к базовым проверкам

Независимо от сети смотрим nvidia-smi, Docker, температуру, загрузку GPU, диск и интернет.

Если сервер появился в кабинете, но через десять минут исчез, это ещё не означает, что «платформа плохая». Нужно проверить, не перегревается ли карта, не падает ли драйвер, не рвётся ли сеть.

15. Victron — подготовка будущей энергетической автоматики

Для связи энергетической системы с сервером есть отдельный скрипт:

curl -fsSL https://de-pin.cloud/depin-scripts-v2/victron-sync.sh -o /tmp/victron-sync.sh && sudo bash /tmp/victron-sync.sh

Он запрашивает локальный IP Victron GX и допустимое время работы от батареи и сохраняет конфигурацию.

Это не готовый автоматический перенос заданий. Скрипт пока создаёт основу, к которой затем можно подключить официальный drain/maintenance-механизм конкретной DePIN-платформы.

16. Почему мы не обещаем автоматический перенос всех задач

У разных сетей нет одного универсального протокола «пожалуйста, передай мою работу другому серверу».

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

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

17. Что делать после успешного подключения

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

Когда машина несколько циклов заданий проходит без ошибок, можно считать интеграцию стабильной.

Что должно быть готово в конце Step 9

• Выбрана одна конкретная DePIN-платформа для активной работы.
• Перед переключением со старой платформы завершены текущие задания.
• clear.sh используется осознанно только для очистки старого Docker-окружения.
• Новый движок устанавливается через официальный flow или официальный installer.
• Сервер отображается в личном кабинете выбранной сети.
• Все GPU видны, Docker стабилен, температура и питание в норме.
• На сервере не конкурируют два активных DePIN-движка.
• Энергетическая интеграция Victron пока рассматривается как основа будущей автоматики, а не как готовый переносчик задач.

После этого сервер уже способен реально работать и зарабатывать. Step 10 посвящён следующему уровню — Solar Energy Autonomy & Grid Integration, то есть тому, как снизить стоимость энергии и повысить автономность.