How access works.
What happens between getting in touch and your first job running, what you get, and who to talk to when something breaks.
Four steps,
usually inside a week.
We work out every allocation by hand. One conversation is usually enough to tell whether you need a few hours or a node to yourself, and it stops people paying for more than they need.
Tell us what you’re running
A couple of sentences: what you are training or running, roughly how big the model and data are, and when you need it by. If you do not know yet, working that out is part of what we do.
We work out what fits
A short call, or coffee on campus. We figure out which node suits the job, how long it will realistically take, and whether you need us at all — sometimes a free tier elsewhere will do the job, and we will say so.
You get keys
An SSH key pair, a JupyterHub login, and a container with your storage mounted. CUDA, PyTorch and the usual toolchain are already there. Bring your own Docker image if you would rather.
You run, we mind the hardware
The job is yours. Thermals, drivers, disks and power are ours, including when something falls over at an inconvenient hour.
A machine, not a queue slot.
Root within your container
Install whatever you need. No approved-package list, no ticket to get a library added, no shared environment quietly rotting under your project.
Persistent storage
Datasets and checkpoints stay put on NVMe between sessions, so you are not re-uploading eighty gigabytes to pick a run back up.
The whole GPU
When a node is yours it is yours — all 96 GB on TROY-1, all 128 on SPARK-1. No time-slicing against somebody else’s inference server, no unexplained throughput cliffs.
Data locality
The disks are in Troy. For work under grant conditions, an NDA or a data-use agreement, you can point at a building and name who has keys to it.
Direct support
A chat channel and someone on campus, rather than a ticket queue. Hardware problems go straight to the people who built the machine.
No lock-in
Your data is yours and leaves in the format you put it in. No egress charges, no proprietary storage layer, nothing holding you in place.
Three kinds
of people.
What you pay and how fast you get on depends on which you are. We work that out in the first conversation.
Students, graduate researchers and faculty
We hold capacity back for RPI coursework, theses and grant-funded research, priced for people who do not have a budget. Apply for RPI access →
Startups, labs and engineering firms
Reserved blocks, an agreed turnaround, and someone local who picks up. For teams who need training capacity without standing up a cluster of their own. Discuss a requirement →
Self-serve rental
Spare capacity goes on the public GPU marketplaces, self-serve and no conversation needed. Convenient, but you lose the local support and the data-locality guarantee.
Before you ask.
What does it cost?
It depends on the node, how long you need it, and whether you are a student, a grant-funded researcher or a company. The spread across those is wide enough that one published number would mislead more people than it helped. Tell us the shape of the job and you get a straight figure in the first reply, not a quote process.
How fast can I get on?
If a node is free and the job is straightforward, the same week. RPI applications get reviewed in batches, so allow a bit longer. Anything needing a custom environment or a data agreement takes as long as those take.
What happens to my data?
It sits on encrypted NVMe in our rack in Troy and is not copied anywhere else. We do not train on it, read it, or hand it to anyone. When you are done we wipe the volume on request and confirm in writing. We will sign an NDA or data-use agreement if you need one.
What happens if a node fails mid-run?
Checkpoint often — that advice holds everywhere. Beyond that: the GPUs are under warranty, the rack is on a UPS, and the second node can pick up smaller jobs while the first is down. We are two machines, not a region with failover, and you should know that going in.
Could we just buy our own server?
Often the better answer. If you would keep it busy, owning beats renting inside a year. We spec, source, build and burn in machines and hand over the full documentation with them. See the reference builds →
Do I need to know CUDA?
No. If you can use SSH and a Python environment you can use the machines. If you cannot, getting your stack running is something we do — it is a common reason people come to us instead of a marketplace listing.
Ready when you are.
Tell us roughly what you are running and we will tell you which node fits and how long it should take.