Hardware and capacity

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.

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

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

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

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

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.