Bring your own compute (BYOC) resource classes¶
Enterprise only
Bring your own compute (BYOC) resource classes require an Enterprise plan and a registered cluster. See Plan permissions.
A resource class names a compute shape: CPU, GPU, and memory per worker, plus how many workers the cluster agent should run. BYOC classes are yours to define; Arena does not look up cloud instance types for them. Use them on self-managed Kubernetes or cloud Kubernetes such as EKS, GKE, or Nebius.
Classes belong to a registered cluster. On the Bring your own compute page, expand a cluster row under BYOC clusters to see its classes and add or edit them there.
Multiple classes for different hardware¶
You can add many resource classes on the same cluster. Each class targets its own machines: separate Add resource class, separate Worker node placement, separate entry on the experiment Resources step. The cluster agent provisions all of them, so there is no install step per class.
Use Name to label the hardware so your team can tell pools apart in the table and experiment picker — for example nvidia-l4-east and nvidia-a100-west. Optional Description can hold extra detail. Set CPUs, GPUs (count per worker), and Memory to match the workers on that pool.
Fields when adding or editing¶
Field |
Required |
Notes |
|---|---|---|
Name |
Yes |
Shown in the class table and experiment picker; use this to label the hardware pool (GPU model, site, rack) |
Enabled |
No (default on) |
Disabled classes stay listed but are not offered on new runs |
Description |
No |
Optional short text (e.g. rack location or GPU SKU) |
Enterprise cluster |
Yes |
The registered cluster that runs this class; already chosen when you add from an expanded cluster row, or when only one cluster is enabled |
Number of nodes |
Yes (≥ 1) |
How many worker nodes the cluster agent runs for this class |
CPUs |
No |
Per worker node |
GPUs |
No |
Per worker node |
Memory |
No |
Per worker node (e.g. |
VRAM per GPU (GB) |
Yes when GPUs > 0 |
Used to size models and pick batch limits for runs on this class |
Worker node placement |
Yes for new GPU classes |
Kubernetes node labels that decide which machines the class may run on |
The form groups CPU, GPU, and memory under Compute resource (per worker node). That matches what workers request, not the head node.
Validation in the UI: node count must be at least 1; name cannot be empty on save; GPU classes need VRAM per GPU and at least one node label.
Worker node placement and GPU hardware¶
A GPU count alone does not tell Kubernetes which GPUs to use. Arena requests generic nvidia.com/gpu capacity, so a cluster with mixed hardware can schedule an A100 job onto an L4 node unless you constrain it.
Worker node placement fixes that. Add the Kubernetes labels your GPU nodes already carry, for example:
Key |
Value |
|---|---|
|
|
Those labels become the worker nodeSelector, so workers only land on matching nodes. The labels must already exist on your nodes — Arena does not create or apply them. If you run the NVIDIA GPU Operator with GPU Feature Discovery, nvidia.com/gpu.product is set for you; check with:
kubectl get nodes -L nvidia.com/gpu.product
Placement is optional for CPU-only classes. Classes created before this field existed keep scheduling on GPU count alone until you add labels.
Table columns and actions¶
The class table sits inside the expanded cluster row, so the cluster is the row you expanded. Each class row shows Name, Number of nodes, Number of CPU of worker node, Number of GPU of worker node, GPU type, VRAM per GPU, Memory of worker node, Status, Setup bundle, and Actions.
Enable / Disable — in the Status column; flips whether the class is available for experiments without deleting it.
Edit — opens the same fields as add.
Delete — permanent; the confirmation dialog shows the class Name.
Setup bundle column¶
UI label |
Meaning |
|---|---|
Current |
The class deployment settings match Arena’s current training image |
Update recommended |
Arena’s training image changed since these settings were generated |
Classes on a registered cluster are rolled out by the cluster agent: keep the cluster Connected and the column returns to Current.
Using a class in an experiment¶
On the experiment wizard Resources step (first step):
Choose Number of nodes (1, 2, 4, 8, 16, or 32). This is the run’s node count for orchestration and (for cloud classes) cost display.
Pick a Resource class radio entry.
BYOC classes appear when:
The class belongs to a registered cluster that is not disabled or archived, and
The class itself is enabled.
They sort ahead of cloud classes in the list. Price shows as $0.00 per hour.
Advanced Training projects and dataset experiments list only classes with at least one GPU per worker. CPU-only BYOC classes appear on classic RL projects but not on Advanced Training.
Class node count vs wizard node count¶
Example: class gpu-pool has Number of nodes 2 (two worker nodes). On Resources, you might still choose 4 nodes for the run’s orchestration. Size the class to match the physical GPU machines in your cluster; ask your org Admin if the wizard node count should match the class.
If nothing BYOC appears, check that a cluster is registered and Connected, at least one class exists and is enabled, the org is on Enterprise, and (for Advanced Training) the class has GPUs.