CS2680 Modern AI Systems: Agents and System Optimizations
CloudLab: a whole machine, when you need one

CloudLab

CloudLab provides bare-metal machines for research and teaching, free of charge, with full control over the software stack. You get the physical node, root on it, and nobody else on it.

That makes it the right choice when your project needs to touch the kernel, the network, or the storage layer, or when you need reproducible isolation that a shared HPC cannot give you — a latency measurement with no co-tenant, a scheduler you have to patch, a device you have to configure. It is the wrong choice for the everyday case: allocating a whole node to run a coding agent, or to train on a GPU that the course HPC would have handed you in one srun, is slower to set up and no better.

Getting access

Project name: TBD. CloudLab organizes people into projects, and you want to join the course project rather than start one of your own — a new project needs a faculty PI and an approval round. The course project name will be posted here.

Then, at cloudlab.us:

  1. Sign up with your Harvard email and request to join the course project.
  2. Upload an SSH public key. CloudLab does not do passwords; the key you upload is the only way onto your nodes, and it is installed on every node you instantiate afterwards.
  3. Wait for the join request to be approved. This is a person clicking a button, so it is not instant.

How it works, in the four terms you need

  • Profile — a reusable description of a topology: how many nodes, which hardware type, which disk image, what runs on boot. Start from an existing profile (small-lan and the Ubuntu single-node profiles cover most needs) and write your own once you know what you want. A profile is also how a result becomes reproducible: publishing yours lets a reader instantiate the same machines you measured on.
  • Experiment — a running instance of a profile. You pick a cluster, it provisions real hardware, and a few minutes later you have SSH.
  • Cluster — Utah, Wisconsin, Clemson, Massachusetts and others, each with different node types. Availability differs per cluster and per hardware type; the list shows what is free before you commit.
  • Expiration — experiments expire, by default in hours, and you extend them from the experiment page with a reason. Extensions are granted, not automatic.
An expired experiment is wiped. When the clock runs out the nodes are reclaimed and reimaged, and whatever was on local disk is gone with them — measurements, logs, the one plot you had not copied off yet. Push results to a repository or to your laptop as you go, and treat the node's disk as scratch space.

Two more habits. Extend before you need it, because you cannot extend an experiment that has already expired. And terminate when you are done: the hardware is genuinely scarce, it is shared with researchers who are not in this course, and holding idle nodes is the one thing that gets a project's access questioned.