# Ray

> Distributed execution for Python, from laptop to cluster

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.

Website: https://www.ray.io

## 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

### General

| Attribute | Value |
| --- | --- |
| License | Open source (permissive) |
| SPDX identifier | Apache-2.0 |
| Deployment | Self-hosted, Managed, Hybrid |
| Workload | Batch |
| Operational complexity | High |
| Pricing | Free, Subscription |
| Language | Python |
| Repository | https://github.com/ray-project/ray |
| Documentation | https://docs.ray.io |
| Stars | 43.9k |

### Batch Compute

| Attribute | Value |
| --- | --- |
| APIs | Ordinary Python functions and classes, tasks and actors |
| Data model | Arbitrary Python objects; Ray Data adds tabular and multimodal, images, video, audio |
| Table formats | Iceberg, Delta Lake, Hudi and Lance, with Unity Catalog and Delta Sharing; Parquet, ORC, Avro, CSV and JSON underneath |
| Runtime | Native Python |
| 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 |
| 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 |

## Capabilities

- [Batch Compute](https://matca.io/capabilities/batch-compute)

---

Source: https://matca.io/ray
Last updated: 2026-08-31T11:40:47.907Z