# Hardware and capacity

## Available hardware[​](#available-hardware "Direct link to Available hardware")

| Request               | Machine                 | Memory | Typical use                                       |
| --------------------- | ----------------------- | ------ | ------------------------------------------------- |
| `l40`                 | NVIDIA L40 or L40S      | 48 GB  | Default for training, inference and most GPU work |
| `a100`                | NVIDIA A100 80 GB       | 80 GB  | Larger models, memory-bound workloads             |
| `h100`                | NVIDIA H100 80 GB       | 80 GB  | Fastest option for large training runs            |
| `cpu-d3-4vcpu-16gb`   | AMD EPYC, 4 vCPU        | 16 GB  | Small CPU jobs, builds, smoke tests               |
| `cpu-d3-96vcpu-384gb` | AMD EPYC, 96 vCPU       | 384 GB | Large simulations, compilation, data processing   |
| `cpu-e2-4vcpu-16gb`   | Intel Ice Lake, 4 vCPU  | 16 GB  | Small CPU jobs                                    |
| `cpu-e2-48vcpu-192gb` | Intel Ice Lake, 48 vCPU | 192 GB | Large CPU jobs                                    |
| `cpu-n1-4vcpu-4gb`    | 4 vCPU                  | 4 GB   | Smoke tests                                       |
| `cpu-n1-16vcpu-32gb`  | 16 vCPU                 | 32 GB  | Medium CPU jobs                                   |

Prices and availability change hourly. Current values:

```
c3 list            # classes with price range and availability
c3 list --all      # every profile with its provider and exact price
```

The same view is at [cthree.cloud/status](https://cthree.cloud/status).

## Choosing hardware[​](#choosing-hardware "Direct link to Choosing hardware")

In `.c3`:

```
hardware: l40                 # a class: C3 picks the cheapest available machine in it
hardware: h100-80gb           # an exact profile, from c3 list --all
hardware: cpu-d3-96vcpu-384gb # CPU machines are always requested by exact profile
provider: nebius              # optional: only use this provider
regions: [eu-north1]          # optional: only these provider regions
```

Omit `hardware` entirely and C3 picks from the `l40` class. `c3 deploy -p <provider>` pins a provider for one run. `c3 deploy --dry-run` shows the route, rate and availability without submitting.

## CPU jobs[​](#cpu-jobs "Direct link to CPU jobs")

Request an exact CPU profile. `hardware: cpu` is rejected because `cpu` is a group, not a machine. CPU machines have no CUDA or NVIDIA drivers, so Docker images must declare `requires_accelerator: none`:

```
hardware: cpu-d3-96vcpu-384gb
docker:
  image: ubuntu:24.04
  requires_accelerator: none
```

CPU capacity is experimental: usable and billed normally, but the profiles and images may change. There is no multi-node MPI launcher; MPI runs within one machine.

## Availability[​](#availability "Direct link to Availability")

`c3 list` shows `HIGH`, `MEDIUM` or `LOW` for each row. This is a coarse signal derived from recent provisioning, not a stock count. `LOW` can also mean the price is stale. Exact stock, provider regions and native machine names are not shown before a job is matched; after submission, `c3 squeue <job-id>` shows the provider, region and profile the job landed on.

## How long before my job starts[​](#how-long-before-my-job-starts "Direct link to How long before my job starts")

If a compatible machine is already warm, your script starts within seconds of submission. Otherwise C3 provisions a new machine, which takes minutes and varies by provider and hardware. `PENDING` means C3 is waiting for a machine; `SCHEDULING` means one is assigned and being prepared. Neither state is billed.

## When capacity is unavailable[​](#when-capacity-is-unavailable "Direct link to When capacity is unavailable")

If the selected provider reports it is out of stock, the job stays `PENDING` with reason `PROVISIONING_BLOCKED` and C3 keeps retrying the same pool. Two fields control this:

```
capacity:
  on_unavailable: wait     # wait (default) or fail
  max_wait_minutes: 60     # 1 to 360
```

* `wait` retries until the deadline, then fails the job with `PROVIDER_CAPACITY_UNAVAILABLE`.
* `fail` fails immediately instead, so you can resubmit with different hardware.

Separately, every job that is still `PENDING` after six hours fails with `QUEUE_DEADLINE_EXCEEDED`. In all of these cases no compute ran and the reserved credit is refunded in full. C3 does not move a job to a different provider or hardware on its own; resubmit with a different `hardware` or `provider` instead.

Routing details

* A pinned provider goes through the same stock, inventory and spend checks as auto-routing, so a pin can be rejected while auto-routing succeeds elsewhere.
* Submitting to an out-of-stock pool is only allowed when both `provider` and `hardware` are set; other requests are rejected at submit time with `GPU_OUT_OF_STOCK`.
* Ambiguous provider responses and repeated provisioning failures are treated as blocked and wait for `max_wait_minutes` even when `on_unavailable` is `fail`.