Ray
Ray is an open-source framework for scaling Python and AI workloads, pairing a general-purpose distributed execution core with libraries for data, training, tuning, serving, and reinforcement learning.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hostedManagedHybrid
PricingFreeSubscription
Operational complexityHigh
WorkloadBatch
LanguagePython
Use it when
- The workload is arbitrary Python (training, simulation, embedding generation, inference) that does not decompose into DataFrame operations.
- You want one substrate for the ML lifecycle: Data, Train, Tune, Serve, and RLlib share a cluster and a code style.
- Accelerators are central: fractional GPUs, device pinning, and TPU, AMD, and Gaudi support are first-class scheduling resources.
- The same code must run on a laptop, VMs, or Kubernetes, autoscaled from demand.
Think twice when
- The job is tabular ETL; Spark's relational engine and ecosystem fit better, and many organizations run both for exactly this split.
- Operating it is real work: a head node, GCS, autoscaler, and KubeRay are high-complexity infrastructure, with Anyscale as the managed relief.
- Fault tolerance has edges: actors do not restart unless configured to, and application exceptions do not retry.
How it runs
A head node running the global control store and autoscaler coordinates workers; deploy with KubeRay on Kubernetes, the VM cluster launcher, or managed Anyscale. Tasks and actors schedule ordinary Python directly; Ray Data streams through the object store and spills to disk, so datasets need not fit in cluster memory.
Details
CompareHow Ray answers the questions Batch Compute turns on.
Batch Compute
| How it works | |
| APIs | Ordinary Python functions and classes, tasks and actors |
| Data model | Arbitrary Python objects; Ray Data adds tabular and multimodal, images, video, audio |
| Execution model | Task and actor scheduling on a distributed runtime |
| Larger than memory | The object store spills to disk by default and Ray Data executes as a stream, so a dataset need not fit in cluster memory |
| Running it | |
| Runtime | Native Python |
| GPU support | The strongest here: num_gpus with fractional shares, accelerator_type pinning, and TPUs, AMD, Intel and Gaudi beyond NVIDIA |
| What you run | A Ray cluster: a head node running the GCS and autoscaler, plus workers; KubeRay on Kubernetes or the VM cluster launcher |
| Scaling | The autoscaler adds nodes from pending task and actor demand rather than utilisation, and removes idle ones |
| Failure recovery | Tasks retry three times on system failures but not on application exceptions; actors do not restart unless max_restarts is set; lost objects rebuild from lineage while their owner lives |
| Connections | |
| Table formats | Iceberg, Delta Lake, Hudi and Lance, with Unity Catalog and Delta Sharing; Parquet, ORC, Avro, CSV and JSON underneath |
Alternatives to Ray
