> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usechamber.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Reservations

> Allocating GPU capacity from pools to teams

Reservations are the link between capacity pools and teams. They guarantee a specific amount of GPU capacity for a team.

## What is a Reservation?

A reservation:

* Allocates GPUs from a pool to a team
* Guarantees capacity for reserved workloads
* Can be adjusted or removed as needs change
* Supports the many-to-many relationship between pools and teams

## Many-to-Many Relationships

Teams and pools have a many-to-many relationship through reservations:

### One Team, Multiple Pools

A team can have reservations in multiple pools:

```mermaid theme={null}
flowchart LR
    Team["Team: ML Platform\n Total: 112 GPUs across 3 pools"]
    Team --> West["us-west-cluster\n 64 GPUs"]
    Team --> East["us-east-cluster\n 32 GPUs"]
    Team --> EU["eu-cluster\n 16 GPUs"]
```

This enables:

* Geographic distribution of workloads
* Access to different GPU types
* Redundancy across clusters

### One Pool, Multiple Teams

A pool can have reservations from multiple teams:

```mermaid theme={null}
flowchart LR
    Pool["Pool: us-west-cluster\n 256 GPUs total"]
    Pool --> ML["ML Platform\n 64 GPUs"]
    Pool --> CV["CV Team\n 48 GPUs"]
    Pool --> NLP["NLP Team\n 32 GPUs"]
    Pool --> Unreserved["Unreserved\n 112 GPUs (elastic)"]
```

## Capacity Guarantees

### Reserved Capacity

When a team has a reservation:

* Reserved workloads from that team are **guaranteed** those GPUs
* Workloads can start immediately if capacity is available within the reservation
* Other teams cannot use this capacity for reserved workloads

### Elastic Usage

Unreserved pool capacity is available for elastic workloads from any team:

```mermaid theme={null}
flowchart TD
    subgraph pool["Pool: 100 GPUs"]
        Reserved["Reserved: 60 GPUs"]
        Unreserved["Unreserved: 40 GPUs"]
    end

    subgraph runtime["At Runtime"]
        Running["Reserved running: 45 GPUs"]
        Idle["Reserved idle: 15 GPUs\n ← Elastic can use this!"]
        Elastic["Elastic running: 40 GPUs"]
    end

    pool --> runtime
```

<Info>
  Elastic workloads can use idle reserved capacity, but will be preempted if a reserved workload needs those resources.
</Info>

## Best Practices

<AccordionGroup>
  <Accordion title="Don't over-reserve">
    Reserve what teams actually need, not what they might need. Unused reserved capacity can't serve elastic workloads from other teams.
  </Accordion>

  <Accordion title="Use elastic for variable workloads">
    Teams with unpredictable demand should use smaller reservations plus elastic capacity rather than large reservations.
  </Accordion>

  <Accordion title="Review quarterly">
    Audit reservations quarterly. Teams' needs change; reservations should too.
  </Accordion>

  <Accordion title="Set up alerts">
    Configure alerts for low utilization (below 30%) and high queue depth to catch misconfigurations.
  </Accordion>
</AccordionGroup>

## Related Concepts

<CardGroup cols={2}>
  <Card title="Teams" icon="sitemap" href="/concepts/teams">
    The teams that receive reservations
  </Card>

  <Card title="Workload Classes" icon="layer-group" href="/concepts/workload-classes">
    How workloads use reserved vs elastic capacity
  </Card>
</CardGroup>