Научный сотрудник считает модель трое суток на ноутбуке: сервер под расчёты

MAATRIX

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

Почему ноутбук — плохое место для многочасовых расчётов

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

Есть и более обидная проблема: пока модель считается, ноутбук занят. Открыть тяжёлый Excel, склеить видео для лекции, запустить вторую задачу параллельно — рискованно, любое дополнительное потребление CPU или памяти либо замедлит расчёт, либо (если памяти не хватит) уронит процесс, и придётся начинать заново. Добавьте сюда бытовые риски: ноутбук закрыли по привычке — и часть систем ушла в сон, ноутбук унесли на встречу — процесс оборвался вместе с Wi-Fi или разрядкой батареи, случайно перезагрузили — потеряли трое суток счёта.

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

Что меняется, когда расчёт переезжает на сервер

Идея простая: вычисление запускается не локально, а на отдельной машине, к которой вы подключаетесь по SSH. Вы стартуете процесс, отключаетесь от сервера — а он продолжает считать сам по себе, потому что живёт в собственной сессии, независимой от вашего подключения. Ноутбук в это время свободен: можно закрыть крышку, уехать домой, работать над другими задачами — расчёт это никак не почувствует.

Практический эффект для научной работы такой:

• Ноутбук возвращается в личное пользование сразу после того, как расчёт запущен, а не после того, как он закончился.
• Сервер работает непрерывно и предсказуемо — это его штатный режим, а не аварийный, как для ноутбука.
• Обрыв домашнего интернета, разрядка батареи или перезагрузка личного устройства больше не обрывают процесс — сервер и ваш ноутбук физически разделены.
• Результат можно забрать в любой момент: зашли, посмотрели прогресс, отключились, вернулись через несколько часов.

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

Как понять, какой сервер нужен именно вам

Прежде чем арендовать что-то конкретное, стоит честно ответить на несколько вопросов о задаче.

Сколько ядер реально использует ваш код. Многие расчётные скрипты на R или Python по умолчанию однопоточные — им физически всё равно, сколько ядер на сервере, если код явно не написан для параллельного исполнения (multiprocessing, parallel, foreach %dopar% и подобное). В этом случае брать сервер с большим числом ядер бессмысленно: узкое место — частота одного ядра, а не их количество. Если же расчёт векторизован или явно распараллелен по образцам/итерациям — здесь дополнительные ядра дают реальный выигрыш, и стоит смотреть в сторону конфигураций с их запасом.

Сколько нужно оперативной памяти. Правило простое: сервер должен вмещать в память не только сам датасет, а датасет плюс все промежуточные структуры, которые ваш код создаёт по ходу работы (копии массивов, промежуточные матрицы, кэш). Если на ноутбуке расчёт уже упирается в своп и жутко тормозит — на сервере памяти должно быть заметно больше, чем было на ноутбуке, а не «столько же для скорости».

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

Нужен ли GPU. Если расчёт — это классическое численное моделирование, статистика, эконометрика или обработка табличных данных, GPU почти наверняка не нужен, и переплата за него бессмысленна. GPU оправдан, если код explicitly использует CUDA/cuDNN — обучение нейросетей, некоторые виды байесовской оптимизации, обработка изображений через фреймворки глубокого обучения. Про выбор конфигурации с GPU подробно разобрано в статье про GPU в выделенном сервере — если ваш случай подходит под неё, идите смотреть туда.

Ориентировочно для «типового» научного расчёта на CPU (статистическая модель, обработка эксперимента среднего объёма) стартовой точкой обычно служит конфигурация с несколькими ядрами и памятью в разы больше, чем занимает сам датасет в оперативке на ноутбуке — но это ориентир, а не готовая цифра: у одной и той же научной группы соседние задачи (например, обработка временных рядов и байесовская модель с MCMC) могут требовать совершенно разных ресурсов. Если не уверены — возьмите конфигурацию с запасом на первый расчёт, посмотрите фактическое потребление через htop и free -h, и на следующий раз скорректируйте выбор осознанно.

Как запустить расчёт так, чтобы он пережил отключение

Это ключевой навык, без которого аренда сервера не даёт ничего нового по сравнению с ноутбуком. Подключение по SSH создаёт сессию, и если её закрыть (закрыли терминал, легла сеть, ноутбук ушёл в сон), все процессы, запущенные в этой сессии напрямую, обычно завершаются вместе с ней. Есть три рабочих способа этого избежать.

Терминальный мультиплексор (рекомендуемый способ). Программы tmux или screen создают на сервере отдельную виртуальную сессию, которая живёт независимо от вашего SSH-подключения. Вы заходите внутрь неё, запускаете расчёт, отключаетесь от сервера — сессия и процесс внутри неё продолжают работать.

# на сервере
tmux new -s calc
# внутри сессии tmux — запускаем расчёт как обычно
python3 run_model.py --config experiment.yaml

# отключиться от сессии, не убивая процесс: Ctrl+b, затем d
# позже — вернуться и увидеть тот же терминал с тем же выводом
tmux attach -t calc

Разница между tmux и screen в основном в удобстве и синтаксисе — для расчётов подходит любой из них, подробное сравнение есть в статье про мультиплексоры терминала.

nohup и отсоединение процесса от терминала. Более простой вариант для одноразового запуска без интерактивного контроля:

nohup python3 run_model.py --config experiment.yaml > calc.log 2>&1 &
disown

Здесь nohup не даёт процессу завершиться при закрытии терминала, > calc.log 2>&1 направляет весь вывод и ошибки в файл, а disown отвязывает процесс от текущей оболочки. Минус подхода — если нужно посмотреть, что происходит «вживую», а не через лог, придётся заново разбираться, как к нему подключиться; tmux в этом смысле удобнее.

Systemd-юнит для длинных или повторяющихся задач. Если расчёт запускается не разово, а регулярно (например, пересчёт модели после каждого обновления данных), разумнее оформить его как сервис:

# /etc/systemd/system/model-calc.service
[Unit]
Description=Научный расчёт модели

[Service]
Type=simple
WorkingDirectory=/home/researcher/project
ExecStart=/usr/bin/python3 run_model.py --config experiment.yaml
Restart=on-failure
User=researcher

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl start model-calc
sudo systemctl status model-calc

Плюс такого подхода — сервис переживёт даже перезагрузку сервера (если она случится, например, для обновления системы) и автоматически перезапустится при сбое, если это включено через Restart=on-failure.

Как следить за прогрессом и не потерять результат

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

# посмотреть последние строки лога в реальном времени
tail -f calc.log

# сколько памяти и CPU реально занимает процесс
htop

# сколько свободного места осталось на диске
df -h

# сколько занято оперативной памяти и есть ли своп
free -h

Если расчёт пишет чекпоинты — промежуточные состояния, из которых можно продолжить в случае сбоя, — стоит проверить, что они действительно сохраняются на диск с той периодичностью, которую вы задавали в конфиге, а не только в теории. Один реальный сбой (сервер перезагрузили для планового обновления, процесс упал по нехватке памяти) стоит меньше, если можно продолжить с последнего чекпоинта, а не с нуля.

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

# скопировать папку с результатами с сервера на ноутбук
rsync -avz researcher@server-ip:/home/researcher/project/results/ ./results/

# или для одного файла
scp researcher@server-ip:/home/researcher/project/output.csv ./output.csv

rsync предпочтительнее scp для больших папок с результатами: если соединение оборвётся на середине, повторный запуск докачает только недостающее, а не начнёт копирование заново.

Если хочется не проверять прогресс руками, а получить уведомление по завершении, самый простой вариант — добавить в конец скрипта отправку сообщения (например, через Telegram-бота или обычное письмо) сразу после того, как расчёт записал финальный результат. Это несложная добавка в несколько строк, но она снимает необходимость периодически подключаться и смотреть на лог.

Сколько это стоит по сравнению с альтернативами

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

Аренда сервера особенно оправдана в трёх ситуациях: когда институтский кластер занят или доступ к нему сложно получить срочно; когда задача разовая и нет смысла выбивать постоянный доступ к общей инфраструктуре; когда вы работаете не в штате учреждения (например, как приглашённый исследователь или на аутсорс-проекте) и институтских ресурсов у вас просто нет.

Важное практическое отличие от покупки железа: сервер арендуется на то время, пока он реально нужен, а не становится капитальной покупкой, которая потом простаивает между расчётами. Оплатить сервер из России можно картой или криптовалютой — для сервера в Великобритании порядок оплаты и нюансы разобраны в статье про оплату сервера в Великобритании из России.

Частые вопросы