Прогоны на серверах

Где список серверов, и почему не здесь

general/servers.md в хранилище Obsidian — единственный список: какие машины есть, сколько карт, что на них занято. Здесь его нет нарочно: он меняется, а копия устарела бы молча. Читать перед выбором машины, править после изменения.

Индексы CUDA не совпадают с физическими. На части машин cuda:0 это не первая карта в корпусе, и соответствие записано там же. Брать карту «по номеру» не глядя — значит однажды встать на чужой прогон.

У проекта свой список. Если в <работа>/.claude/CLAUDE.md есть раздел ## SSH Servers, работать только с этими машинами и не спрашивать, какую взять. Нет раздела и владелец не сказал — показать загрузку по всем подходящим и спросить.

Код на сервере

Соглашение о путях: локально ~/brainlab/<направление>/<тема>/<работа>/code/<код>/, на сервере ~/<код>/ — то же имя папки, клонированное в домашний каталог. Отсюда запуск всегда вида ssh <машина> "cd <код> && <команда>".

rsync -avz --exclude='.git' --exclude='__pycache__' ~/brainlab/<направление>/<тема>/<работа>/code/<код>/ <машина>:<код>/
ssh <машина> "nvidia-smi --query-gpu=index,memory.used,memory.free --format=csv,noheader"

Долгий прогон — только в tmux, иначе он умрёт вместе с ssh:

ssh <машина> "tmux new-session -d -s <имя> 'cd <код> && <команда>'"
ssh <машина> "tmux attach -t <имя>"

Что прогон обязан записать о себе

Числа и настройки пишет код, а не человек, — это правило базы (run-is-written-by-code), и обычный wandb на сервер лаборатории https://wandb-radfan.ru делает это сам, а в базу прогон переносит lab wandb <ссылка>. Здесь только то, чего W&B не знает.

Сид фиксируется целиком, а не одним вызовом. random, numpy, torch, torch.cuda, и отдельно PYTHONHASHSEED в окружении: без последнего порядок обхода множеств плавает между запусками. Детерминизм cudnn включается осознанно — он стоит скорости.

Окружение записывается вместе с числами. Версия torch, версия CUDA, модель карты, их число. Прогон, у которого это не записано, через полгода невоспроизводим: «та же команда» на другой версии даёт другие числа, и понять это постфактум нечем.

Снимок зависимостей кладётся рядом с результатами, а не в общий requirements.txt репозитория: pip freeze > outputs/<прогон>/requirements.txt.

Hydra складывает конфиг сама — outputs/<дата>/<время>/.hydra/config.yaml с разрешёнными значениями и overrides.yaml с тем, что передали в командной строке. Отдельно логировать конфиг при Hydra не нужно, это дублирование.

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

Куда идёт результат

Пока прогон идёт и за ним следят, у него своя папка в работе, runs/<E-код>/, с таблицей снимков и графиком сходимости, который перерисовывается на каждом шаге слежения: навык obsidian-experiment-log.

Прогон становится знанием только в базе лаборатории: claims/<H-код>/runs/<E-код>.md. Правила записи — навык lab-knowledge и свод в его references/canon.md. Папка с выводом на сервере знанием не является и переживает ровно до следующей чистки диска.