Skip to content

Commit b46db21

Browse files
authored
Merge branch 'main' into add/org-storage-usage-tracking
2 parents 0ddff92 + 975b2cc commit b46db21

1 file changed

Lines changed: 108 additions & 0 deletions

File tree

Lines changed: 108 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,108 @@
1+
---
2+
title: Core Concepts
3+
sidebar_position: 1
4+
---
5+
6+
# Core Concepts
7+
8+
This page defines the key terms used throughout Transformer Lab and explains how they relate to each other.
9+
10+
## Teams
11+
12+
A team is a shared workspace for multiple users. Teams provide:
13+
14+
- **Shared experiments** — collaborate on the same research
15+
- **Shared compute providers** — configured once, available to all members
16+
- **Quotas** — team-level and per-user compute time limits
17+
- **Access control** — role-based permissions (owner, member) with per-resource read/write rules
18+
19+
## Experiments
20+
21+
An experiment is the top-level container for organizing your work. It holds tasks, jobs, notes, and documents in one place. Think of it as a project folder for a line of research.
22+
23+
When you first use Transformer Lab, default experiments named `alpha`, `beta`, and `gamma` are created for you. You can create your own and name them however you like.
24+
25+
Everything you do — launching training runs, running evaluations, chatting with a model — happens inside an experiment.
26+
27+
## Tasks
28+
29+
A task is a **specification** for a piece of work. It defines what to run, what resources it needs, and where to run it.
30+
31+
Tasks are defined with a `task.yaml` file. Here's a minimal example:
32+
33+
```yaml
34+
name: fine-tune-llama
35+
resources:
36+
compute_provider: my-slurm-cluster
37+
accelerators: 'NVIDIA'
38+
num_nodes: 1
39+
envs:
40+
LEARNING_RATE: '0.001'
41+
setup: |
42+
pip install -r requirements.txt
43+
run: |
44+
python train.py
45+
```
46+
47+
This is just a sample — task.yaml supports many more fields including GitHub repo integration, hyperparameter sweeps, and resource constraints. See the [Task YAML Structure](../running-a-task/task-yaml-structure.md) page for the full reference.
48+
49+
You can create tasks by uploading a YAML file, importing from a task gallery, or writing one from scratch in the built-in editor.
50+
51+
A task is a reusable template — each time you launch it, it creates a new **job**.
52+
53+
## Jobs
54+
55+
A job is a **running instance** of a task. When you launch a task, Transformer Lab creates a job, routes it to a compute provider, and tracks it through its lifecycle:
56+
57+
```mermaid
58+
stateDiagram-v2
59+
[*] --> QUEUED
60+
QUEUED --> LAUNCHING
61+
QUEUED --> FAILED
62+
LAUNCHING --> RUNNING
63+
LAUNCHING --> FAILED
64+
RUNNING --> COMPLETE
65+
RUNNING --> FAILED
66+
RUNNING --> STOPPED
67+
```
68+
69+
- **QUEUED** — submitted, waiting for the provider
70+
- **LAUNCHING** — setup script running, dependencies installing
71+
- **RUNNING** — main command executing
72+
- **COMPLETE** — finished successfully
73+
- **FAILED** — exited with an error
74+
- **STOPPED** — stopped by the user
75+
76+
Each job produces logs and may produce artifacts like trained model weights, evaluation results, or exported files.
77+
78+
## Compute Providers
79+
80+
A compute provider is the backend that actually runs your jobs. Transformer Lab is provider-agnostic — you can configure one or more of the following:
81+
82+
| Provider | Use Case |
83+
| --------------------- | ------------------------------------------ |
84+
| **Local** | Run on the machine hosting Transformer Lab |
85+
| **Slurm** | Submit to an on-premise HPC cluster |
86+
| **SkyPilot** | Orchestrate across multiple clouds |
87+
| **Runpod** | Serverless GPU cloud |
88+
| **dstack** | Open-source distributed compute |
89+
| **Nebius** | Cloud GPU provider |
90+
| **Vast.ai** | GPU cloud marketplace |
91+
| **AWS / GCP / Azure** | Direct cloud VM provisioning |
92+
93+
When you launch a task, Transformer Lab translates your resource requirements into the provider's native format (e.g., an `sbatch` command for Slurm, a VM launch for cloud providers) and handles monitoring and log retrieval.
94+
95+
## How It All Fits Together
96+
97+
```mermaid
98+
graph TD
99+
T[Team] --> CP[Compute Providers]
100+
T --> Q[Quotas]
101+
T --> U[Users]
102+
U --> E[Experiments]
103+
E --> TK[Tasks]
104+
E --> N[Notes & Documents]
105+
TK -->|launch| J[Jobs]
106+
J -->|run on| CP
107+
J -->|produce| A[Artifacts]
108+
```

0 commit comments

Comments
 (0)