| name | alterlab-remote-compute |
| description | Dispatch long-running GPU/CPU jobs to remote compute with a provider-agnostic submit → poll → harvest pattern across SLURM/HPC (sbatch, squeue, sacct) and managed APIs (Modal, RunPod, GCP Batch / Vertex AI). Use when submitting a batch job to a cluster, polling job status, retrieving result artifacts from a scheduler or cloud GPU provider, or writing a portable job-submission wrapper; the foundation-model skills (alterlab-alphafold, alterlab-boltz, alterlab-rfdiffusion, and siblings) dispatch their GPU work through this pattern. For Modal-specific serverless container deployment and autoscaling prefer alterlab-modal instead. Part of the AlterLab Academic Skills suite. |
| license | MIT |
| allowed-tools | Read Write Edit Bash(python:*) Bash(uv:*) |
| compatibility | Runs under `uv run python`; the portable dispatcher (`scripts/dispatch.py`) is stdlib-only. SLURM paths need `sbatch`/`squeue`/`sacct` on PATH (an HPC login node); managed backends need the provider CLI/SDK and account credentials read from environment variables (never hardcoded). No GPU is needed to submit/poll — only the remote job itself uses one. |
| metadata | {"skill-author":"AlterLab","version":"1.0.0"} |
Remote Compute
Overview
Foundation-model workloads (protein folding, backbone diffusion, single-cell models) need a
GPU and can run for minutes to hours — too long to sit in a synchronous call. This skill is
the provider-agnostic dispatch layer the GPU skills build on: a single submit → poll →
harvest contract that works the same whether the backend is a SLURM cluster, Modal, RunPod,
or GCP. You describe the job once; the dispatcher submits it, returns a handle, polls status
to a terminal state, and harvests the output artifacts.
It does not wrap any single model — each model skill (alterlab-alphafold,
alterlab-boltz, alterlab-proteinmpnn, …) describes what to run; this skill describes
where and how to run it.
When to Use This Skill
Use this skill when the user wants to:
- Submit a batch job to a SLURM/HPC cluster and track it to completion (
sbatch → sacct).
- Run a GPU job on a managed provider (Modal, RunPod, GCP Batch / Vertex AI) and retrieve results.
- Write a portable job wrapper that runs the same payload across more than one backend.
- Poll a long-running remote job's status and harvest its output files/artifacts.
Does NOT Trigger
| Scenario | Use instead |
|---|
| Deploy a serverless container / autoscaling API specifically on Modal | alterlab-modal |
| Actually fold a structure, design a sequence, or run a specific model | the model's own skill (alterlab-alphafold, alterlab-boltz, alterlab-proteinmpnn, …) |
| Local single-machine data analysis with no remote dispatch | the relevant analysis skill (alterlab-scanpy, alterlab-rdkit, …) |
| Query a database over HTTP | the database connector skill (alterlab-pdb, alterlab-uniprot, …) |
The submit → poll → harvest contract
Every backend implements three verbs. Keeping the payload backend-independent is what makes a
model skill portable across an HPC allocation and a cloud GPU:
- submit(spec) → handle — enqueue the job; return an opaque handle (SLURM job id, Modal
call id, RunPod job id, GCP operation name).
