Compute configurations
A compute configuration defines the virtual hardware used by a cluster. These resources make up the shape of the cluster and the cluster's setup for running applications and workloads in a distributed computing environment. If you are familiar with a Ray cluster.yaml
, an Anyscale compute config is a superset of that comprehensive configuration.
Compute configs are specific to an Anyscale Cloud. This association ensures that for a given compute config, Anyscale always launches workloads in the same Anyscale cloud.
A compute config allows you to control the following:
- Instance types: Virtual machine instance types for head and worker nodes.
- Network settings: Network interfaces, including subnet settings, security groups, regions, and private/public IP options.
- Storage options: Node-attached storage, including disk types and sizes.
- Tags: Add custom tags to your instances, for example for custom tracking of usage and spending.
- Scaling parameters: Minimum and maximum worker node counts to determine scaling behavior based on workload.
- Spot instance configuration: Spot instances for cost savings, and related enhancements (for example, fallback to on-demand instances when spot instances are not available).
- Auto-select worker nodes: beta feature allows defining the accelerator type in the Ray application. Instead of manually specifying instance types and counts, the Anyscale autoscaler dynamically chooses the best-fit instances based on resources requests, instance cost, and availability.
- Advanced features: Advanced options such as node ranking strategy, cross-zone scaling, etc.
- Cloud-specific configurations: Configurations specific to an Anyscale Cloud. Anyscale Clouds deployed on different stacks (EC2, GCE, Kubernetes, or on-premises) have different configurations for features like capacity reservations, subnet control, and so on.
Create a compute config
You can create a compute config with one of three options: the console UI, CLI, or the Python SDK. The CLI requires a YAML file, which allows you to version control compute configurations over time.
Versions
Anyscale supports versioning of compute configs, allowing easy updating of the compute resource requirements for a workload over time.
Supported instance types
When deployed on cloud VM's, Anyscale supports a wide variety of instance types. For a full list, visit Supported Machine Types.
On machine pool and Kubernetes deployments, instance types are defined & managed by cloud administrators.
Cloud specific configurations
Cloud specific configurations are only available with self-hosted Anyscale Clouds.
- AWS (EC2)
- GCP (GCE)
- Kubernetes
Common configurations for AWS are listed below. For a complete reference on what might be configurable, see the AWS docs and contact Anyscale support.
Managing capacity reservations
Securing certain instance types from cloud providers can sometimes be challenging due to high demand or limited availability. With Anyscale, you can leverage your cloud provider capacity reservations, ensuring the availability of required node types for your workloads. To configure capacity reservations for a specific worker node type, modify the advanced configuration through the console UI or by editing the compute config YAML file.
To add a reservation with the console UI, navigate to a worker node and expand the Advanced config section. Under the Instance config tab, input the following JSON, substituting in your specific reservation ID:
{
"CapacityReservationSpecification": {
"CapacityReservationTarget": {
"CapacityReservationId": "RESERVATION_ID"
}
}
}
Expand for a sample YAML file that you can use with the Anyscale CLI/SDK
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_ACCELERATED
min_nodes: MIN_NODES
max_nodes: MAX_NODES
advanced_instance_config:
CapacityReservationSpecification:
CapacityReservationTarget:
CapacityReservationId: RESERVATION_ID
For additional details on utilizing capacity reservations on AWS, see the AWS Documentation.
Changing the default disk size
The default disk size for all nodes in an Anyscale cluster is 150 GB. You can change the default disk size for the entire cluster or an individual worker node type.
To modify the default disk size from the console UI, use the Advanced configuration section for the Worker node or the Advanced settings section for the entire cluster. This example increases the default to 500 GB.
{
"BlockDeviceMappings": [
{
"Ebs": {
"VolumeSize": 500,
"VolumeType": "gp3",
"DeleteOnTermination": true
},
"DeviceName": "/dev/sda1"
}
]
}
Expand for a sample YAML file that you can use with the Anyscale CLI/SDK
This sample YAML will modify the disk for all nodes in the Anyscale cluster.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_ACCELERATED
min_nodes: MIN_NODES
max_nodes: MAX_NODES
advanced_instance_config:
BlockDeviceMappings:
- Ebs:
- VolumeSize: 500
VolumeType: gp3
DeleteOnTermination: true
DeviceName: "/dev/sda1"
NVMe configuration
Anyscale supports Non-Volatile Memory Express (NVMe) interface to access SSD storage volumes, which provides additional temporary storage to the instances. This enables higher performance, lower latency, scalability, and support for versatile use cases across a variety of workloads. Anyscale exposes /mnt/local_storage
as the mount path in the Ray container by default. For instance types that don't have NVMe, /mnt/local_storage
just falls back to the root disk.
You can choose EC2 instance types that have NVMe. See AWS instance store documentation for more details. Anyscale then automatically detects these devices, formats them, and mounts them when the Ray Container starts.
Anyscale configures EC2 instance types that have multiple NVMe devices with a software RAID (RAID 0), which maximizes disk performance.

Subnets, security groups, and instance IAM role
Specify the following configurations for the entire cluster (do not specify them for individual node groups unless you have to):
-
Security groups and subnets:
- any security groups registered with the cloud.
- any subset of the security groups registered with the cloud.
-
Instance IAM role:
- any IAM role for the cluster to run with. It must have an instance profile with the same name as the role.
To modify them from the console UI, use the Advanced settings section for the entire cluster.
{
"IamInstanceProfile": {"Arn": "arn:aws:iam::<>:role/<>"},
"SecurityGroupIds": ["security-group-id"],
"SubnetId": "subnet-id",
}
Expand for a sample YAML file that you can use with the Anyscale CLI/SDK
This sample YAML will modify the security groups, subnets, and instance IAM role for all nodes in the Anyscale cluster.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_ACCELERATED
min_nodes: MIN_NODES
max_nodes: MAX_NODES
advanced_instance_config:
IamInstanceProfile:
Arn: "arn:aws:iam::<>:role/<>"
SecurityGroupIds:
- "security-group-id"
SubnetId: "subnet-id"
Common configurations for GCP are listed below. For a complete reference on what might be configurable, see the GCP docs and contact Anyscale support.
Managing capacity reservations
Securing certain instance types from cloud providers can sometimes be challenging due to high demand or limited availability. With Anyscale, you can leverage your cloud provider capacity reservations, ensuring the availability of required node types for your workloads. To configure capacity reservations for a specific worker node type, modify the advanced configuration through the console UI or by editing the compute config YAML file.
To add a reservation with the console UI, navigate to a worker node and expand the Advanced config section. Under the Instance config tab, input the following JSON, substituting in your specific reservation name:
{
"instanceProperties": {
"reservationAffinity": {
"consumeReservationType": "SPECIFIC_RESERVATION",
"key": "compute.googleapis.com/reservation-name",
"values": ["RESERVATION_NAME"]
}
}
}
Expand for a sample YAML file that you can use with the Anyscale CLI/SDK
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_ACCELERATED
min_nodes: MIN_NODES
max_nodes: MAX_NODES
advanced_instance_config:
instanceProperties:
reservationAffinity:
consumeReservationType: SPECIFIC_RESERVATION
key: compute.googleapis.com/reservation-name
values: [RESERVATION_NAME]
For additional details on utilizing open reservations in Google Cloud, see the Google Cloud documentation.
Changing the default disk size
The default disk size for all nodes in an Anyscale cluster is 150 GB. You can change the default disk size for the entire cluster or an individual worker node type.
To modify the default disk size from the console UI, use the Advanced configuration section for the Worker node or the Advanced settings section for the entire cluster. This example increases the default to 500 GB.
{
"instance_properties": {
"disks": [
{
"boot": true,
"auto_delete": true,
"initialize_params": {
"disk_size_gb": 500
}
}
]
}
}
Expand for a sample YAML file that you can use with the Anyscale CLI/SDK
This sample YAML will modify the disk for all nodes in the Anyscale cluster.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_ACCELERATED
min_nodes: MIN_NODES
max_nodes: MAX_NODES
advanced_instance_config:
instanceProperties:
disks:
- boot: true
auto_delete: true
initialize_params:
- disk_size_gb: 500
NVMe configuration
Anyscale supports Non-Volatile Memory Express (NVMe) interface to access SSD storage volumes, which provides additional temporary storage to the instances. This enables higher performance, lower latency, scalability, and support for versatile use cases across a variety of workloads. Anyscale exposes /mnt/local_storage
as the mount path in the Ray container by default. For instance types that don't have NVMe, /mnt/local_storage
just falls back to the root disk.
You need to manually specify the number of NVMe devices to attach to the instance. See GCP local SSD documentation for more details. Note that each local SSD has 375 GB. Specify the number of NVMe devices to attach in the Advance Configuration section of the compute config. Here is an example:

{
"instance_properties": {
"disks": [
{
"boot": true,
"type": "PERSISTENT",
"initializeParams": {
"diskSizeGb": 150
}
},
{
"type": "SCRATCH",
"interface": "NVME",
"autoDelete": true,
"initializeParams": {
"diskType": "local-ssd"
}
},
{
"type": "SCRATCH",
"interface": "NVME",
"autoDelete": true,
"initializeParams": {
"diskType": "local-ssd"
}
}
]
}
}
Subnets and service accounts
Specify the following configurations for the entire cluster (do not specify them for individual node groups unless you have to):
- Subnets:
- any subnet registered with the cloud.
- Service accounts:
- any service account for the cluster to run with. It must have permissions specified for a Ray Cluster service account in the cloud deployment documentation
To modify them from the console UI, use the Advanced settings section for the entire cluster.
{
"instance_properties": {
"service_accounts": [
{
"email": "service-account-to-use",
"scopes": [
"https://www.googleapis.com/auth/cloud-platform"
]
}
],
"network_interfaces": [
{
"subnetwork": "subnetUrl",
"access_configs": [
{
"type": "ONE_TO_ONE_NAT"
}
]
}
]
}
}
Expand for a sample YAML file that you can use with the Anyscale CLI/SDK
This sample YAML will modify the service account and subnets for all nodes in the Anyscale cluster.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_ACCELERATED
min_nodes: MIN_NODES
max_nodes: MAX_NODES
advanced_instance_config:
instance_properties:
service_accounts:
- email: service-account-to-use
scopes:
- "https://www.googleapis.com/auth/cloud-platform"
network_interfaces:
- subnetwork: subnetUrl
access_configs:
- type: ONE_TO_ONE_NAT
For Kubernetes cloud deployments, visit compute configuration options.
Advanced features
Adjustable downscaling
The Anyscale platform automatically downscales worker nodes that have been idle for a given period. By default, the timeout period ranges from 30 seconds to 4 minutes and is dynamically adjusted for each node group based on the workload. For example, short, bursty workloads have shorter timeouts and more aggressive downscaling. Adjustable downscaling allows users to adjust this timeout value at the cluster-level based on their workload needs.
- Console
- CLI
To adjust the timeout value from the Anyscale console, use the Advanced features tab under the Advanced settings for the cluster. This example sets the timeout to 60 seconds for all nodes in the cluster.
{
"idle_termination_seconds": 60
}
To adjust the timeout value from the Anyscale CLI, use the flags
field. This example YAML sets the timeout value to 60 seconds for all nodes in the cluster.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_WORKER
min_nodes: MIN_NODES
max_nodes: MAX_NODES
flags:
idle_termination_seconds: 30
Cross-zone scaling
Cross-zone scaling is a feature that allows Anyscale to launch your Ray cluster across multiple availability zones. By default, all worker nodes are launched in the same availability zone. With cross-zone scaling enabled, Anyscale first attempts to launch worker nodes in existing zones, but if that fails, then tries the next-best zone (based on availability).
Use this feature if:
- You want to maximize the chances of provisioning desired instance types.
- You want to spread Serve app replicas across multiple zones for better resilience and availability.
- Your workloads have no heavy inter-node communication or the incurred inter-availability zone cost is acceptable.
- Console
- CLI
To enable or disable this feature from the Anyscale console, use the "Enable cross-zone scaling" checkbox under the Advanced settings for the cluster.
To enable or disable this feature from the Anyscale CLI, use the enable_cross_zone_scaling
field. This example YAML enables cross-zone scaling for all nodes in the cluster.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_WORKER
min_nodes: MIN_NODES
max_nodes: MAX_NODES
enable_cross_zone_scaling: true
Resource limits
Cluster-wide resource limits allow you to define minimum and maximum values for any resource across all nodes in the cluster. There are two common use cases for this feature:
- Specifying the maximum number of GPUs to avoid unintentionally launching a large number of expensive instances.
- Specifying a custom resource for specific worker nodes and using that custom resource value to limit the number of nodes of those types.
- Console
- CLI
To set the maximum number of CPUs and GPUs in a cluster from the Anyscale console, use the "Maximum CPUs" and "Maximum GPUs" fields under the Advanced settings for the cluster.
To set other resource limits, use the Advanced features tab under the Advanced settings for the cluster. To add a custom resource to a node group, use the Ray config tab under the Advanced config section for that node group.
This example limits the minimum resources to 1 GPU and 1 CUSTOM_RESOURCE
and limits the maximum resources to 5 CUSTOM_RESOURCE
.
{
"min_resources": {
"GPU": 1,
"CUSTOM_RESOURCE": 1
},
"max_resources": {
"CUSTOM_RESOURCE": 5,
}
}
To set resource limits for a cluster from the Anyscale CLI, use the min_resources
and max_resources
fields. This example YAML adds a custom resource to a worker node, limits the minimum resources to 8 CPU and 1 CUSTOM_RESOURCE
, and limits the maximum resources to 1 GPU and 5 CUSTOM_RESOURCE
.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_WORKER
resources:
CUSTOM_RESOURCE: 1
min_nodes: MIN_NODES
max_nodes: MAX_NODES
min_resources:
CPU: 8
CUSTOM_RESOURCE: 1
max_resources:
GPU: 1
CUSTOM_RESOURCE: 5
Workload starting and recovering timeouts
The workload starting timeout allows you to configure how long a workload should attempt to acquire the minimum resources when it first starts, before Anyscale terminates it.
After a workload is running, it may enter the RECOVERING
state if it's attempting to recover the minimum resources, for example, due to spot preemption. The workload recovering timeout allows you to configure how long a workload may remain in the RECOVERING
state, to avoid the cost of idling existing nodes.
By default, Anyscale sets both timeouts to 25 minutes.
These timeouts only apply to jobs and workspaces, not services.
- Console
- CLI
To configure the workload starting and recovering timeouts from the Anyscale console, use the Advanced features tab under the Advanced settings for the cluster. This example increases the workload starting timeout to 1 hour and decreases the workload recovering timeout to 10 minutes.
Valid time units are: s
, m
, and h
. For example, 1h30m
.
{
"workload_starting_timeout": "1h",
"workload_recovering_timeout": "10m"
}
To configure the workload starting and recovering timeouts from the Anyscale CLI, use the flags
field. This example increases the workload starting timeout to 1 hour and decreases the workload recovering timeout to 10 minutes.
Valid time units are: s
, m
, and h
. For example, 1h30m
.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_WORKER
flags:
workload_starting_timeout: 1h
workload_recovering_timeout: 10m
Worker group ranking
The worker group ranking feature is in developer preview.
Some workloads may require prioritizing specific worker groups over others. This could involve utilizing on-demand capacity reservations before scaling out to use spot instances, or influencing the utilization of a particular node type before another.
Anyscale's default ranking prioritizes CPU-only worker groups above GPU worker groups, spot above on-demand, and availability of the instance type. With the instance ranking feature, you can instead specify a custom ranking order for the worker groups. In addition, with node replacement enabled, Anyscale automatically replaces lower-ranked nodes with higher-ranked nodes when they become available.
When you provide multiple rankers, Anyscale prioritizes earlier rankers over later rankers. If an ordering in a later ranker conflicts with an earlier ranker, Anyscale ignores the conflicting ranking in the later ranker.
- Console
- CLI
To specify a custom worker group ranking from the Anyscale console, use the Advanced features tab under the Advanced settings for the cluster. This example specifies a ranking for 3 worker groups named spot-worker-1
, spot-worker-2
, and on-demand-worker
, where Anyscale prioritizes both spot groups over the on-demand group, but the two spot groups have equal priority.
{
"instance_ranking_strategy": [
{
"ranker_type": "custom_group_order",
"ranker_config": {
"group_order": [
["spot-worker-1", "spot-worker-2"],
"on-demand-worker"
]
}
},
]
}
To specify a custom worker group ranking from the Anyscale CLI, use the flags
field. This example specifies a ranking for 3 worker groups named spot-worker-1
, spot-worker-2
, and on-demand-worker
, Anyscale prioritizes both spot groups over the on-demand group, but the two spot groups have equal priority.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- name: spot-worker-1
instance_type: INSTANCE_TYPE_WORKER_1
market_type: SPOT
- name: spot-worker-2
instance_type: INSTANCE_TYPE_WORKER_2
market_type: SPOT
- name: on-demand-worker
instance_type: INSTANCE_TYPE_WORKER_3
market_type: ON_DEMAND
flags:
instance_ranking_strategy:
- ranker_type: custom_group_order
ranker_config:
group_order:
- - spot-worker-1
- spot-worker-2
- on-demand-worker
Node replacement
The node replacement feature is in developer preview. To enable this feature, contact Anyscale support.
When providing a custom worker group ranking, if the best worker group isn't available, Anyscale may select a lower-ranked worker group instead. With Anyscale's node replacement feature, if a better worker group later becomes available, the Anyscale Autoscaler attempts to replace nodes from lower-ranked worker groups with nodes from higher-ranked worker groups. In addition, you can configure the replacement threshold, the duration a worker node must run for before Anyscale can replace it, to match your workload checkpointing.
Note that the Anyscale Autoscaler only attempts to launch a replacement node that is at least as large as the existing node, taking into account CPUs, GPUs, memory, accelerator type, and any user-defined custom resources, to ensure that any workload running on the existing node is able to run on the replacement node.
One common use case for this feature is for prioritizing multiple spot worker groups over on-demand worker groups.
For example, suppose your compute config contains 2 PREFER_SPOT
node types, worker-1
and worker-2
, and you have a workload that checkpoints after 30 minutes that you would prefer to run on the spot workers, only using the on-demand workers if necessary.
With the below configuration, the Anyscale Autoscaler attempts to launch the spot workers before the on-demand workers, and attempts to replace any on-demand workers with spot workers after 30 minutes. Anyscale doesn't replace the spot workers with each other, or replace the on-demand workers with each other either.
- Console
- CLI
To configure node replacement from the Anyscale console, specify a custom group order with enable_replacement
set to true
and the replacement_threshold
, using the Advanced features tab under the Advanced settings for the cluster.
Valid time units for the replacement threshold are: s
, m
, and h
. For example, 1h30m
.
{
"replacement_threshold": "30m",
"instance_ranking_strategy": [
{
"ranker_type": "custom_group_order",
"ranker_config": {
"enable_replacement": true,
"group_order": [
["worker-1/spot", "worker-2/spot"],
["worker-1/on-demand", "worker-2/on-demand"]
]
}
},
]
}
To configure node replacement from the Anyscale CLI, specify a custom group order with enable_replacement
set to true
and the replacement_threshold
, using the flags
field.
Valid time units for the replacement threshold are: s
, m
, and h
. For example, 1h30m
.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- name: worker-1
instance_type: INSTANCE_TYPE_WORKER_1
market_type: PREFER_SPOT
- name: worker-2
instance_type: INSTANCE_TYPE_WORKER_2
market_type: PREFER_SPOT
flags:
replacement_threshold: 30m
instance_ranking_strategy:
- ranker_type: custom_group_order
ranker_config:
enable_replacement: true
group_order:
- - worker-1/spot
- worker-2/spot
- - worker-1/on-demand
- worker-2/on-demand
Instance selection strategy
By default, to maximize utilization and minimize costs, the Anyscale Autoscaler uses a "force smallest fit" instance selection strategy: it always chooses the smallest possible node for your workload, even if a larger node is available, and doesn't upscale GPU worker nodes for CPU-only workloads. However, you may prefer a "relaxed" instance selection strategy for certain workloads, for example, when using a custom worker group ranking, where the Anyscale Autoscaler always attempts to launch the highest-ranked node type.
- Console
- CLI
To configure the instance ranking strategy from the Anyscale console, use the Advanced features tab under the Advanced settings for the cluster.
{
"instance_selection_strategy": "force_smallest_fit" | "relaxed",
}
To configure the instance ranking strategy from the Anyscale CLI, use the flags
field.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_WORKER
min_nodes: MIN_NODES
max_nodes: MAX_NODES
flags:
instance_ranking_strategy: force_smallest_fit | relaxed
Disabling NFS mounts
Some large-scale jobs and services workloads may need to disable NFS mounts in order to bypass cloud-provider restrictions on the number of concurrent connections. For example, Filestore on GCP allows 500 concurrent connections by default. Note that an error will be raised if this flag is set on a non job or service cluster, as NFS is required for persistence in Anyscale Workspaces.
- Console
- CLI
To disable NFS mounts from the Anyscale console, use the Advanced features tab under the Advanced settings for the cluster.
{
"disable_nfs_mount": true,
}
To disable NFS mounts from the Anyscale CLI, use the flags
field.
cloud: CLOUD_NAME
head_node:
instance_type: INSTANCE_TYPE_HEAD
worker_nodes:
- instance_type: INSTANCE_TYPE_WORKER
min_nodes: MIN_NODES
max_nodes: MAX_NODES
flags:
disable_nfs_mount: true
Best practices
Avoid scheduling on the head node
The Ray head node contains a number of important system processes such as the global control service (GCS), the Ray driver process, and the API server.
If scheduling is enabled on the head node when the cluster is under heavy load:
- The actors and tasks running on the head node contend for resources and may interrupt the operation of these system components.
- The Ray cluster may become unstable and unable to recover from failures properly.
To protect the Ray cluster from instability, head node scheduling is disabled by default for multi-node clusters when creating a new compute config. However, you can follow the instructions below to fine-tune this behavior:
- SDK
- UI
1. Single-node cluster (head node scheduling enabled by default)
If you specify the head node with an empty list of worker nodes, this cluster is considered a single-node cluster. All compute runs on the head node.
head_node:
- instance_type: m5.2xlarge
worker_nodes: []
2. Multi-node cluster (head node scheduling disabled by default)
2.1 Head node with auto-selected worker nodes
If you don't specify worker nodes, auto-selected worker nodes feature is enabled and this cluster is considered a multi-node cluster. All compute runs on worker nodes, and head node scheduling is disabled.
head_node:
instance_type: m5.2xlarge
# No worker nodes need to be specified, including the name, instance_type, etc.
2.2 Head node with manually selected worker nodes
If you manually specify worker nodes, all compute runs on worker nodes, and head node scheduling is disabled.
head_node:
instance_type: m5.2xlarge
worker_nodes:
- name: gpu-group
instance_type: p4de.24xlarge
3. Multi-node cluster (override and enable head node scheduling)
You can enable head node scheduling by specifying logical resources for the head node.
head_node:
instance_type: m5.2xlarge
resources:
CPU: 8
GPU: 0
worker_nodes:
- name: gpu-group
instance_type: p4de.24xlarge
You can enable head node scheduling by specifying logical resources for the head node.