# Run GPU training jobs on-demand

Start a training run on cloud GPUs with a decorator and a function call. No cluster to set up, no instances to monitor. Beam provisions containers, streams logs to your shell, and stops billing the second the job ends.

## Why Beam

### Cloud GPU training that feels local

Keep your training loop, drop the infrastructure. Beam runs the compute and gets out of the way.

### On-demand GPUs  
T4s through H100s, provisioned when the job starts and released when it ends. Switch hardware with one argument.

### Pay only while it runs  
Per-second billing that stops at process exit. No reserved instances, no idle burn between experiments.

### Checkpoints that deploy  
Volumes keep datasets and checkpoints across runs — and an endpoint can serve straight from the same volume when training ends. Storage is included, free of charge.

### Parallel experiments  
Sweep hyperparameters by fanning one function out across many containers with .map().

### Background & long-running jobs  
Detach runs with headless mode and lift timeouts entirely for multi-day training.

### Scheduled retraining  
Turn any training function into a managed cron job with the schedule decorator — deployed and versioned like the rest of your code.

## How it works

### Start training in three steps

01  
### Decorate your function  
Add @function with the GPU, CPU, memory, and image you need. Your code stays plain Python.

02  
### Run the file  
Calling .remote() ships your working directory to a fresh container and streams logs back to your terminal.

03  
### Serve what you trained  
Checkpoints written to a volume persist after the container exits. Deploy an endpoint that mounts the same volume and your model is serving traffic — no artifact export, no second platform.

```bash
$ python train.py

=> Building image
=> Syncing files
=> Running function: <train:train>
epoch 0: loss=2.113
epoch 1: loss=1.874
...
=> Function complete

# Checkpoints persist after the run
$ beam ls checkpoints
epoch-0.pt
epoch-1.pt
```

## Frequently asked questions

### How long can a training job run?+
As long as you need. Timeouts are configurable in seconds, and setting timeout=-1 disables them entirely for multi-day runs.

### Can jobs keep running after I close my laptop?+
Yes. Set headless=True on the function and the task keeps running in the background on Beam after your local process exits.

### Where do datasets and checkpoints live?+
On persistent storage volumes mounted into the container. They survive across runs and are readable from any other Beam function or endpoint.

### Do I pay for provisioning time?+
No. Beam only charges for the time your application code is running — never for server spin-up or container image pulls.

### Can I run many experiments at once?+
Yes. Use .map() to fan a training function out over a list of configs — each run gets its own container and GPU.

### How do I serve the model once training finishes?+
Deploy an endpoint that mounts the same volume your checkpoints were written to — training and serving run on one platform, with no artifact export step in between. The fine-tuning guide walks through the full loop.

### Does it work with Weights & Biases and Hugging Face?+
Yes. Add wandb or huggingface_hub to your image, store API keys with Beam's secrets manager, and log runs as usual — Beam's fine-tuning examples track training in W&B out of the box.

### Can I train on multiple GPUs?+
Yes. The gpu_count parameter runs your job across multiple GPUs on the same machine — message us in Slack and we'll enable it on your account.