一键导入
molgpu
Reference guide for the MolGPU shared GPU cluster. Machine specs, SSH setup, shared filesystem, conda/mamba, multi-GPU training tips, and common commands.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Reference guide for the MolGPU shared GPU cluster. Machine specs, SSH setup, shared filesystem, conda/mamba, multi-GPU training tips, and common commands.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
MIT Engaging cluster reference. SLURM job scheduling, Coley group nodes, filesystem layout, Python environments, and common commands. Use when working with the Engaging HPC cluster.
Verifies that bibliography references exist and have accurate metadata. Use when the user asks to "check references", "verify a bibliography", "validate citations", "check for hallucinated citations", "check a .bib file", or mentions auditing a BibTeX file for accuracy. Looks up each entry against Crossref and arXiv, then spawns web-search subagents for non-indexed sources, flagging missing DOIs, wrong years, title mismatches, venue mismatches, and broken URLs.
VASP on MIT Engaging. VASP 6.4.2 (GCC/OpenMPI, Rocky 8 compatible), module loading, SLURM submission, POTCAR paths. Use when setting up or running VASP calculations on Engaging.
MassSpecGym benchmark reference — dataset schema, Python API, transforms, evaluation metrics, retrieval pipeline, and common patterns. Use when working with MassSpecGym data, models, or evaluation.
Machine learning workflows for molecular data. Use when building ML models with molecules, splitting datasets, selecting fingerprints for ML, avoiding data leakage, or doing scaffold-based train/test splits. Covers common pitfalls in molecular ML.
Python package and environment management using uv and mamba. Use when installing packages, creating virtual environments, setting up new projects, or managing dependencies. NOT for general Python coding questions.
| name | molgpu |
| description | Reference guide for the MolGPU shared GPU cluster. Machine specs, SSH setup, shared filesystem, conda/mamba, multi-GPU training tips, and common commands. |
Shared GPU cluster for the group. All nodes on private network (use MIT VPN to connect off campus).
| Node | CPUs | GPUs | VRAM/GPU | RAM | Storage |
|---|---|---|---|---|---|
| molgpu01 | 64 cores (2x AMD 3970X) | 2x RTX 3090 Ti | 24 GB | — | — |
| molgpu02 | 128 cores (2x AMD 3995WX) | 4x RTX A5000 | 24 GB | — | — |
| molgpu03 | 64 cores (AMD 3995WX) | 4x RTX A5000 | 24 GB | 512 GB | 2x 2TB SSD |
| molgpu04 | 64 cores (AMD 3995WX) | 3x RTX 3090 | 24 GB | 512 GB | 1TB + 2TB SSD (encrypted at /data) |
| molgpu05 | 32 cores (AMD 5975WX) | 2x RTX 4090 | 24 GB | 256 GB | 4TB SSD |
| molgpu06 | 32 cores (AMD 5975WX) | 2x RTX 4090 | 24 GB | 256 GB | 4TB SSD |
| molgpu07 | 128 cores (AMD 5995WX) | 4x RTX 4090 | 24 GB | 512 GB | 2TB SSD |
| molgpu08 | 52 cores (2x Xeon 6230R) | 8x RTX 2080 Ti | 11 GB | 512 GB | 1TB SSD |
| moldata01 | — (Synology DS3622xs) | — | — | — | 100TB HDD + 800GB SSD cache |
Full hostnames are molgpu01.mit.edu through molgpu08.mit.edu. Same credentials across all nodes. SSH keys set up on one node work on all others (shared home dir).
Add this to ~/.ssh/config for easy access:
Host *
AddKeysToAgent yes
UseKeychain yes # macOS only — saves key password in keychain
ForwardAgent yes
Host molgpu0?
Hostname %h.mit.edu
User <your-username>
ForwardAgent yes
IdentityFile <path/to/private_key>
This lets you ssh molgpu07 instead of ssh user@molgpu07.mit.edu -i /path/to/key. ForwardAgent means you don't need to store your private key on the server to use GitHub via SSH.
To add access from a new client, append your public key to ~/.ssh/authorized_keys on any molgpu node.
Change password with passwd (applies to all nodes, must be mixed case + numeric, 8+ chars).
All molgpu machines mount the same NFS home directory at /mnt/home/ (81.8 TB total). Files written on one machine are immediately visible on all others — no rsync needed between molgpus. Only rsync from your local machine to any one node.
Sensitive data goes on the encrypted partition at /mnt/encrypted/ (16.4 TB). Protect sensitive folders with chmod 700.
Important: Avoid reading/writing a large number of files in parallel — this slows NFS for everyone. Reduce parallel I/O workers if NFS feels slow.
Always back up code and important checkpoints. There is no guarantee storage will never fail.
Global conda is available on molgpu02–06 (no need to install your own):
/opt/miniconda3/bin/conda init
Global mamba (faster drop-in replacement for conda) on molgpu02:
# after conda init:
mamba init
uv is also available at ~/.local/bin/uv if installed per-user.
View current load across all machines: http://molgpu01:8088/
# transfer files from local machine (only need to hit one node, shared fs does the rest)
rsync -az --exclude '.venv*' --exclude '__pycache__' --exclude '.git' \
. molgpu07:~/project-name/
# check GPU availability on a node
ssh molgpu07 nvidia-smi --query-gpu=index,name,memory.used,memory.free --format=csv,noheader
# scan all machines at once
for h in molgpu0{1..8}; do echo "=== $h ===" && ssh $h nvidia-smi --query-gpu=index,memory.used,memory.free --format=csv,noheader 2>/dev/null; done
# always use tmux for long-running jobs (nohup is NOT enough — child processes get SIGHUP)
ssh molgpu07
tmux new-session -s myjob
# ... launch job ...
# detach: Ctrl-B then D
# reattach later: tmux attach -t myjob
# ONE-TIME per user per node: enable linger so the tmux server survives
# when your login session ends. without this, systemd-logind kills the
# whole user slice (including detached tmux sessions) when your last
# ssh closes.
loginctl enable-linger
loginctl show-user $USER --property=Linger # should read Linger=yes
# always redirect stderr (some frameworks log errors only to stderr)
python train.py > /tmp/train.log 2>&1
# kill orphaned GPU processes after a crash
nvidia-smi # find PIDs
kill -9 <pid>
~/.triton/cache, ~/.cache/torch/) can go stale when switching between machines. Fix: use local disk for caches (export TRITON_CACHE_DIR=/tmp/triton_cache) or nuke the cache (rm -rf ~/.triton/cache).torch.cuda.is_available() is False after a fresh install, pin torch to a cu124 build:
~/.local/bin/uv pip install --force-reinstall torch==2.5.1 \
--index-url https://download.pytorch.org/whl/cu124
Verify with python -c "import torch; print(torch.cuda.is_available())".# set HF_HUB_OFFLINE=1 to avoid HF Hub race conditions during multi-GPU load
# (download model first, then set this)
HF_HUB_OFFLINE=1 accelerate launch --num_processes=4 train.py
# QLoRA + DDP: use device_map={"": local_rank} (not None or "auto")
VLMs are especially memory-hungry. If OOM during warmup or generation, tune:
gpu_memory_utilization: lower from 0.9 to 0.35–0.7max_num_seqs: lower from 256 to 4–16enforce_eager=True: skips CUDA graphs, saves ~2 GB VRAMtensor_parallel_size: split model across GPUs| Size | bf16 VRAM | QLoRA NF4 | Min GPUs (inference) |
|---|---|---|---|
| 4B | ~8 GB | ~5 GB | 1 |
| 8B | ~16 GB | ~8-10 GB | 1 |
| 12B | ~24 GB | ~12-14 GB | 2 |
| 70B | ~140 GB | ~42 GB | 8+ |