Готовый образ: make vast-vm

Быстрый путь — make vast-vm HOST=class1 из checkout репозитория, с VAST_TOKEN и SSH-ключом в .env. Команда арендует Vast VM через API, запускает на ней готовый образ colloq-vast (тот же образ, что colloq-server) под управлением colloq-host и печатает адрес занятия и ссылку владельца. Каждая комната получает свой контейнер ядра на Docker этой VM. Адрес занятию обычно даёт ваш relay; настройки — токен relay, ключ ИИ, COLLOQ_IMAGE — заполните один раз в backups/vast-onstart.sh. На самой VM обслуживание — colloq-host status, backup, update — такое же, как на сервере в вузе; подробности аренды — в deploy/vast/README.md. Данные живут на диске VM и пропадают вместе с арендой: уносите копии до её удаления.

Для GPU-комнат или посылок на GPU арендуйте карты и диск, которые нужны образам CUDA: make vast-vm HOST=class1 GPUS=2 GPU_RAM=24 DISK=100 просит не меньше двух карт по 24 ГБ и 100 ГБ диска, потому что на VM лежат base-gpu (около 9,9 ГБ) и kaggle-gpu (ещё около 2,8 ГБ). Оба публикуются с каждым выпуском командой make kernel-publish (RELEASING.md), и VM скачивает их, если они перечислены в KERNEL_PRELOAD; сама она собирает их, только если GPU-ядра её версии ещё не опубликованы или их списки на ней изменили. Для любого занятия make vast-vm берёт только предложения с Max CUDA 13.0 и выше: torch 2.14.1 из GPU-окружений собран под CUDA 13.0 и требует драйвер NVIDIA 580 или новее. DISK= и MAX_PRICE= заменяют значения из .env для одной аренды, а OFFER= арендует предложение с этим номером, где бы на рынке оно ни стояло. В backups/vast-onstart.sh задайте KERNEL_PRELOAD=base,base-gpu,kaggle-gpu, а когда занятие поднимется, отдайте посылкам карты в панели, см. видеокарту для посылок.

Машины для посылок: make vast-runner

VM на Vast можно арендовать и не под занятие, а как машины для посылок другого сервера Colloq: они берут его посылки соревнований и считают тетради, а ответы и метрика остаются на сервере. Код подключения выпускает владелец этого сервера («Ресурсы» → «Машины» → «Подключить машину» или colloq-host runner-code); дальше — из checkout репозитория, с тем же VAST_TOKEN и SSH-ключом в .env:

make vast-runner COUNT=3 CODE=<код> URL=https://colloq.example.edu
make vast-runner COUNT=2 GPU="RTX 4090" GPUS=2 DISK=150 CODE=<код> URL=https://colloq.example.edu DESTROY_UNJOINED=1

make runners-update URL=https://colloq.example.edu   # после обновления сервера: машины на код его версии
make runners-down URL=https://colloq.example.edu     # машины уходят с сервера, их VM удаляются

make vast-runner арендует COUNT VM, от 1 до 16, с теми же фильтрами и тем же порогом Max CUDA 13.0, что make vast-vm; диск по умолчанию — 120 ГБ. В on-start каждой VM — только адрес сервера и код, без токена relay: машина сама приходит к серверу по HTTPS и не открывает ни одного адреса. Машины помечаются меткой colloq-runner, по ней их находят make runners-update и make runners-down, а URL= оставляет только машины этого сервера. VM, которая арендовалась, но не подключилась, тарифицируется как любая другая: команда называет её в конце, а DESTROY_UNJOINED=1 её удаляет. runners-update сначала до минуты ждёт от каждой машины свежего слова её сервера и не трогает те, чей код совпадает с кодом сервера (FORCE=1 — обновить всё равно). runners-down ждёт ухода машины, только пока её сервер отвечает: после 10 минут его молчания VM всё равно удаляется, и команда говорит об этом. С NOW=1 обе команды не ждут начатых посылок, и те считаются заново, без траты попыток участников. Машины для посылок — не развёртывания: make vast-up, make vast-down и make vast-status их не берут (vast-status только называет, сколько их арендовано), а имя развёртывания, которое дало бы VM их метку (NAME=runner, runner-…), отклоняется. Подробно — в разделе «Машины для посылок и занятий».

Подготовка до аренды

Путь k3s использует полную Vast VM с systemd, а не обычный Docker instance. VM содержит один узел k3s. Проверьте доступность VM-предложений, рабочий NVIDIA-драйвер, зарегистрированный SSH-ключ, цену и дисковое пространство.

На доверенной операторской машине нужны манифест выпуска и клон публичного репозитория github.com/colloq-edu/colloq, в котором есть его точный sourceCommit. vast-up упаковывает инструменты именно из этого коммита. Приложение не получает ключ аккаунта Vast.

В конфигурации подготовьте VAST_TOKEN, SSH-ключ и параметры существующего relay. Для приватных образов задайте VAST_REGISTRY_CONFIG с отдельными pull-only правами и VAST_REGISTRY_READ_ONLY=1. Файл должен содержать только Docker auths, без credential helpers. Синтаксическая проверка не доказывает действительность прав — загрузку проверяет preflight.

Запуск и наблюдение

Для выпуска, чьи образы действительно доступны анонимно:

VAST_PUBLIC_IMAGES=1 RELEASE=/absolute/path/release.json \
  NAME=hse HOST=hse.example.edu make vast-up
NAME=hse scripts/vast.sh status
NAME=hse SINCE=2h scripts/vast.sh logs

Замените имя, домен и путь. VAST_PUBLIC_IMAGES=1 — явное утверждение о доступности образов, а не способ сделать приватные образы публичными. При смешанных registry оно относится к образам без переданных учётных данных.

Цели make vast-… выбирают путь по RELEASE: без него они вызывают прежний scripts/vast-legacy.sh для старых Docker-установок без k3s. Для k3s-среды вызывайте scripts/vast.sh напрямую или передавайте RELEASE=… каждой цели. Журналы приложения и ядер сохраняются в logs/hse/<дата>/.

Инструмент проверяет манифест до обращения к аккаунту, предлагает VM и требует подтверждения цены. Передаются только инструменты выпуска и разрешённая конфигурация. При обновлении удалённая конфигурация сохраняется: изменение каждого поля локального .env не обязано менять VM.

Критерий готовности GPU

HTTP-ответ приложения и вывод nvidia-smi недостаточны. Установщик проверяет RuntimeClass, allocatable GPU и исполняет реальную PyTorch CUDA-операцию в одноразовом non-root Pod. vast-up также запускает cluster smoke с независимыми комнатами.

Одна GPU-комната запрашивает одно устройство; автоматического sharing или перехода на общее ядро нет. Для GPU-проверки нужна свободная карта. Успешные локальные тесты репозитория не подтверждают работу конкретной аренды.

Проверенная конфигурация

9 сентября 2026 года проверили отдельную Vast VM с RTX 3090 (24 ГБ), Ubuntu 22.04, драйвером NVIDIA 580.95.05 и k3s v1.36.4+k3s1. На GPU-занятии два клиента получили результат матричного умножения на PyTorch 2.14.0 / CUDA 13.0 через общий ноутбук.

Также прошли проверку разделение комнат, сохранение GPU-тензора при перезапуске приложения и брокера, обновление и восстановление удалённого занятия из consistent-копии. Использовались NVIDIA Container Toolkit 1.20.0-1 и device plugin 0.19.3. Тестовая VM удалена после проверки.

Это результат для конкретной конфигурации. Другие GPU, внешние registry, публичный relay и ограничения доступа к службам узла требуют своей проверки. Обновление выпуска и восстановление копии останавливают ядра; сохранение Python-памяти при этих операциях не обещается.

Скопируйте данные с VM

# Во время работы: база и файлы не составляют атомарный снимок
NAME=hse MODE=live scripts/vast.sh sync

# Остановить всех писателей и получить согласованную копию
NAME=hse MODE=consistent scripts/vast.sh sync

# Явно разрешить возобновление после успешной копии
NAME=hse MODE=consistent RESUME=1 scripts/vast.sh sync

Архивы сохраняются в backups/hse/ на операторской машине. Архив проверяется на VM и после передачи. Он содержит секреты, конфигурацию, release/catalog и workspace; образы остаются в registry.

Данные Colloq находятся на диске VM, и удаление аренды может их уничтожить. Не рассчитывайте на автоматическое сохранение local PV или возможность подключить отдельный Vast Volume к VM: проверяйте ограничения выбранного продукта у провайдера.

Восстановление и обновление

Команды выполняются из клона репозитория на операторской машине. Обновление среды — повторный make vast-up с тем же NAME и новым RELEASE: на машине с установленным выпуском он выполняет cluster.sh update — согласованную копию, остановку ядер, новый выпуск и smoke. На новой пустой VM vast-up сам проверяет и разворачивает самую свежую копию из backups/hse/; если нужна чистая среда, заранее перенесите копии из этого каталога. Для ручного восстановления используйте процедуру portable restore с правильным именем и совместимым выпуском, затем повторите prepare и проверки комнат. Версию k3s меняйте отдельной операцией.

Старые root-service/Compose установки и неуправляемые непустые данные не мигрируют автоматически. Сохраните старую машину, выгрузите её данные подходящими ей инструментами и проверьте перенос отдельно.

Перед удалением аренды

Получите согласованную копию вне VM, проверьте её и убедитесь, что нужные образы доступны. Только затем выполняйте NAME=hse scripts/vast.sh down и подтверждайте удаление указанной аренды. Остановленный кластер не является резервной копией.

Для диагностики используйте длительности SINCE=30m или SINCE=2h. Логи уже удалённых room Pod могут быть недоступны; вывод приложений и ячеек может содержать учебные данные.