Ray: Distributed Python Without the Pain

Ray occupies a specific and increasingly important niche: it is the distributed runtime that lets you write ordinary Python and scale it to hundreds of GPUs and thousands of CPU cores without porting your code to a different execution model. That claim is not unique to Ray — Dask makes a version of it, and Spark has PySpark — but Ray backs it up with a scheduling architecture that handles heterogeneous hardware, stateful long-running processes, and fine-grained task parallelism in ways the others do not. In practice, this makes Ray the substrate under a surprising amount of modern LLM infrastructure: OpenAI uses it to coordinate ChatGPT training, vLLM uses its executor model for multi-GPU inference, and frameworks like OpenRLHF lean on it for distributed reinforcement learning from human feedback pipelines. Ray joined the Linux Foundation in September 2025, signaling that the project’s governance has matured beyond a single commercial backer.

The thesis of this post is that Ray is genuinely excellent for ML workloads — training, hyperparameter search, and online serving — but it is not a drop-in Spark replacement, it has real production rough edges, and the right choice between Ray, Dask, and Spark depends on what your workload actually is. We will cover the core primitives from first principles, the distributed object store, the scheduling architecture, the high-level libraries (Data, Train, Tune, Serve), KubeRay on Kubernetes, and then the honest failure modes.

Core primitives: tasks and actors

Ray exposes two building blocks. Everything else is built on top of them.

Remote tasks are stateless functions decorated with @ray.remote. When called with .remote(), they are submitted to the Ray scheduler, which assigns them to a worker process somewhere on the cluster. The return value is not the function’s result — it is an ObjectRef, a future-like handle to a value that may or may not be computed yet. You pass ObjectRefs directly into other .remote() calls without materializing them, and the scheduler tracks the dependency graph automatically.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

import ray

ray.init()   # connects to a running cluster or starts a local one

@ray.remote
def load_shard(path: str) -> list:
    import json
    with open(path) as f:
        return json.load(f)

@ray.remote
def tokenize(records: list, vocab_size: int) -> list:
    # CPU-bound work runs in a worker process, not your driver
    return [hash(r) % vocab_size for r in records]

# Submit without blocking
shards = [load_shard.remote(f"/data/shard_{i}.json") for i in range(16)]

# Chain: tokenize receives ObjectRefs, Ray resolves them automatically
tokens = [tokenize.remote(shard, vocab_size=32000) for shard in shards]

# Block only when you actually need the results
results = ray.get(tokens)

ray.get(refs) blocks the caller until all referenced objects are ready and returns the deserialized values. ray.wait(refs, num_returns=k) returns as soon as k of the futures are done — useful for streaming results or implementing work-stealing patterns. ray.put(obj) manually places an object into the distributed object store and returns an ObjectRef; useful when you want to broadcast a large read-only object (a model checkpoint, a vocabulary) to many workers without re-serializing it for each call.

Actors are stateful workers — classes decorated with @ray.remote. Each actor instance runs in its own dedicated worker process, and its methods execute serially on that process (unless you use async actors). Actors retain state between calls, which makes them the right primitive for parameter servers, replay buffers, database clients that maintain connection pools, or any long-lived service that would be expensive or incorrect to recreate per task.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

@ray.remote
class TokenizerServer:
    def __init__(self, vocab_path: str):
        from tokenizers import Tokenizer
        self.tok = Tokenizer.from_file(vocab_path)  # loaded once, reused

    def encode(self, texts: list[str]) -> list[list[int]]:
        return [self.tok.encode(t).ids for t in texts]

    def batch_encode(self, batch: list[str]) -> list[list[int]]:
        return self.tok.encode_batch(batch, add_special_tokens=True)

# Create one actor per GPU node, each holding its own tokenizer in memory
servers = [TokenizerServer.remote("/models/tokenizer.json") for _ in range(4)]
futures = [s.encode.remote(chunk) for s, chunk in zip(servers, text_chunks)]
encoded = ray.get(futures)

The distinction matters operationally. Tasks are scheduled freely across the cluster; actors are pinned to one worker. Tasks can be retried automatically on failure (configurable with max_retries); actor state is lost if the actor crashes and must be explicitly reconstructed. For fault-tolerant checkpointed training, Ray Train handles this above the actor layer.

The distributed object store

Ray’s object store is the part most competitors don’t replicate well. On each node, Ray runs a shared-memory segment (historically called the Plasma store, derived from Apache Arrow’s Plasma project) that all worker processes on that node map into their address space. When a task produces a large output — say, a 2 GB NumPy array — the result is placed into this shared memory region. Another task on the same node reading that ObjectRef gets a zero-copy memory-mapped view. No deserialization, no copying. The latency is on the order of microseconds.

Cross-node transfers happen over the network via Ray’s distributed object transfer protocol. A worker that needs an object currently on a different node triggers a pull; the owning node streams the serialized bytes, the receiving node materializes them into its local Plasma segment, and subsequent reads on that node are again zero-copy. Objects are serialized using pickle5 (supporting the buffer protocol for zero-copy numpy/Arrow round-trips) plus cloudpickle for arbitrary Python objects that don’t implement __reduce__ in a pickle-compatible way.

When the object store fills up — which happens in practice during large training jobs with many in-flight tensors — Ray spills objects to disk. Spilling is automatic and transparent to application code, but it wrecks performance: a spill-and-reload cycle turns a microsecond memory read into hundreds of milliseconds of disk I/O. The fix is to either increase object_store_memory in ray.init(), add more nodes, or structure your pipeline to release references (del ref, or use ray.internal.free) as soon as you are done with them. Relying on garbage collection alone is unreliable here because Python’s reference counting does not track ObjectRefs that have been passed into .remote() calls.

Scheduling and the cluster model

                         Ray Cluster
 ┌──────────────────────────────────────────────────────────┐
 │  Head Node                                               │
 │  ┌─────────────────────────────────────┐                 │
 │  │  Global Control Service (GCS)       │                 │
 │  │  - actor registry, node membership  │                 │
 │  │  - placement groups, resource table │                 │
 │  └─────────────────────────────────────┘                 │
 │  ┌───────────┐  ┌───────────┐  ┌─────────────────────┐  │
 │  │  Raylet   │  │  Object   │  │  Dashboard /        │  │
 │  │  (sched)  │  │  Store    │  │  State API server   │  │
 │  └───────────┘  └───────────┘  └─────────────────────┘  │
 └──────────────────────────────────────────────────────────┘
          │                │
          ▼                ▼
 ┌─────────────────┐  ┌─────────────────┐
 │  Worker Node 1  │  │  Worker Node 2  │  ...
 │  ┌───────────┐  │  │  ┌───────────┐  │
 │  │  Raylet   │  │  │  │  Raylet   │  │
 │  │  (sched)  │  │  │  │  (sched)  │  │
 │  └───────────┘  │  │  └───────────┘  │
 │  ┌───────────┐  │  │  ┌───────────┐  │
 │  │  Object   │  │  │  │  Object   │  │
 │  │  Store    │  │  │  │  Store    │  │
 │  └───────────┘  │  │  └───────────┘  │
 │  Worker Workers │  │  Worker Workers │
 │  (Python procs) │  │  (Python procs) │
 └─────────────────┘  └─────────────────┘

Each node runs a raylet — a C++ daemon that acts as a local scheduler and object manager. When a task is submitted, the driver first tries to schedule it locally (via its node’s raylet). If local resources are insufficient, the raylet forwards the request to the Global Control Service (GCS) for global scheduling. Placement groups allow you to request co-located resources (e.g., “I need 8 CPUs and 1 GPU, all on the same node”) for gang-scheduled training jobs.

The critical architecture insight is that Ray is designed to run the same code on a laptop (ray.init() with no arguments starts a local cluster) and on a 1,000-node cloud cluster (ray.init("ray://head:10001") or via KubeRay). The task graph, the object store references, the actor handles — all of these work identically. There is no “local mode” with different semantics. This is why teams can develop on a workstation and promote the exact same code to a GPU cluster without a rewrite. It also means you find cluster bugs in development before they become production incidents.

The head node SPOF problem. The GCS runs on the head node. By default, if the head node crashes, the entire cluster crashes — actors lose state, in-flight tasks are lost, and you must restart from the last checkpoint. Ray 2.x introduced GCS fault tolerance via an external Redis backend: the GCS persists its state to Redis, and a restarted head node can recover cluster state without losing running actors or work. In KubeRay deployments this is configured via gcsFaultToleranceOptions in the RayCluster spec pointing to a Redis Sentinel or Redis Cluster. Without this, the head node is a genuine single point of failure and should be treated as one: keep your checkpointing granular.

High-level libraries: Data, Train, Tune, Serve

The four high-level libraries share a single design philosophy: they are all implemented on top of Ray Core tasks and actors, which means they compose with each other and with your own @ray.remote code without friction.

Ray Data: streaming dataset pipelines

Ray Data is the ingest and preprocessing layer. It represents a dataset as a collection of Apache Arrow RecordBatches distributed across the cluster, with a streaming execution model that pipelines reads, transforms, and writes without materializing the full dataset in memory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import ray

ds = ray.data.read_parquet("s3://my-bucket/training-data/")

# Map is lazy and pipelined — transforms run as data is consumed
def tokenize_batch(batch: dict) -> dict:
    from transformers import AutoTokenizer
    tok = AutoTokenizer.from_pretrained("meta-llama/Llama-3-8B")
    enc = tok(batch["text"], truncation=True, max_length=2048, padding="max_length")
    return {"input_ids": enc["input_ids"], "attention_mask": enc["attention_mask"]}

ds = ds.map_batches(
    tokenize_batch,
    batch_size=64,
    num_cpus=2,
    # Each map_batches call gets its own Ray task; parallelism=auto by default
)

# Materialize to a local iterator for training, or write back out
ds.write_parquet("s3://my-bucket/tokenized/")

Ray Data’s streaming model is important when datasets are larger than aggregate cluster memory. It processes data in configurable block sizes (default 128 MB per block) and pipelines I/O with compute. The integration with Ray Train means you can pass a ray.data.Dataset directly into a TorchTrainer and it handles sharding the dataset across training workers automatically.

Ray Train: distributed model training

Ray Train wraps the popular distributed training backends — PyTorch DDP, FSDP, DeepSpeed, Horovod, XGBoost, LightGBM — with a consistent launcher API. You write a training function that runs on a single worker, and Ray Train handles launching it across however many workers you specify, setting up the NCCL/GLOO communication backend, and injecting the correct MASTER_ADDR/RANK/WORLD_SIZE environment variables.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

from ray.train.torch import TorchTrainer
from ray.train import ScalingConfig, CheckpointConfig, RunConfig
import torch
import torch.nn as nn

def train_fn(config: dict):
    from ray.train.torch import get_device, prepare_model, prepare_data_loader

    model = nn.Linear(128, 10).to(get_device())
    model = prepare_model(model)  # wraps in DDP or FSDP

    optimizer = torch.optim.Adam(model.parameters(), lr=config["lr"])
    loader = prepare_data_loader(
        torch.utils.data.DataLoader(
            torch.utils.data.TensorDataset(
                torch.randn(10000, 128), torch.randint(0, 10, (10000,))
            ),
            batch_size=config["batch_size"],
        )
    )

    for epoch in range(config["epochs"]):
        for X, y in loader:
            loss = nn.functional.cross_entropy(model(X), y)
            optimizer.zero_grad()
            loss.backward()
            optimizer.step()
        # Report metrics back to the driver / Tune
        ray.train.report({"loss": loss.item(), "epoch": epoch})

trainer = TorchTrainer(
    train_fn,
    train_loop_config={"lr": 1e-3, "batch_size": 256, "epochs": 5},
    scaling_config=ScalingConfig(num_workers=8, use_gpu=True),
    run_config=RunConfig(
        checkpoint_config=CheckpointConfig(num_to_keep=2),
    ),
)
result = trainer.fit()

For LLM fine-tuning, Ray Train integrates with DeepSpeed ZeRO stages and PyTorch FSDP. You can pass a DeepSpeed config JSON directly; Ray Train handles environment setup and lets DeepSpeed’s deepspeed.initialize() work unmodified inside the training function. See the fine-tuning LLMs guide for the hardware side of multi-GPU setups; Ray Train handles the software coordination layer on top.

Ray Tune: hyperparameter search at scale

Ray Tune treats hyperparameter search as a scheduling problem: run many training trials concurrently, kill the bad ones early, allocate more resources to promising ones. It integrates with Optuna, HyperOpt, Ax, and Bayesian optimization backends, and it wraps Ray Train — a TorchTrainer is a valid Tune trainable.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from ray import tune
from ray.tune.schedulers import ASHAScheduler

analysis = tune.run(
    train_fn,    # same function from above, or a Trainer
    config={
        "lr": tune.loguniform(1e-5, 1e-2),
        "batch_size": tune.choice([64, 128, 256, 512]),
        "epochs": 20,
    },
    num_samples=50,          # 50 random trials
    scheduler=ASHAScheduler(
        metric="loss", mode="min", grace_period=3, reduction_factor=2
    ),
    resources_per_trial={"cpu": 4, "gpu": 1},
)
print(analysis.best_config)

ASHA (Asynchronous Successive Halving) is the right default scheduler for most workloads: it runs all 50 trials from epoch 0, stops the worst-performing half after 3 epochs, stops the worst half of survivors after 6 epochs, and so on. This means you get nearly the same best result as running 50 full trials while consuming a fraction of the GPU-hours.

Ray Serve: online model serving

Ray Serve is a production serving framework built on Ray actors. Each deployment is a class whose replicas are Ray actors. Serve handles HTTP routing, request batching, health checking, and autoscaling. Deployments can call each other via DeploymentHandles, enabling model pipelines (preprocessing → model → postprocessing) without an external message queue.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

from ray import serve
from ray.serve.handle import DeploymentHandle

@serve.deployment(
    num_replicas=2,
    ray_actor_options={"num_gpus": 1},
    autoscaling_config={
        "min_replicas": 1,
        "max_replicas": 8,
        "target_ongoing_requests": 5,
    },
)
class LLMDeployment:
    def __init__(self, model_name: str):
        from vllm import LLM, SamplingParams
        self.llm = LLM(model=model_name, tensor_parallel_size=1)
        self.sampling = SamplingParams(temperature=0.7, max_tokens=512)

    async def __call__(self, request):
        data = await request.json()
        outputs = self.llm.generate(data["prompts"], self.sampling)
        return {"texts": [o.outputs[0].text for o in outputs]}


app = LLMDeployment.bind("meta-llama/Llama-3-8B-Instruct")
serve.run(app, host="0.0.0.0", port=8000)

Ray Serve’s autoscaler works by monitoring the number of ongoing requests per replica and adjusting replica count to keep the average near target_ongoing_requests. Scale-up is fast (Ray actors start in seconds on warm nodes); scale-to-zero is supported but has cold-start latency proportional to model load time. The vLLM integration is first-class — Ray Serve LLM provides prefix-aware routing that routes requests with matching prefixes to the same replica, exploiting vLLM’s KV cache prefix reuse for significant latency reduction.

Running on Kubernetes with KubeRay

KubeRay is the official Kubernetes operator for Ray. As of version 1.6 (current as of mid-2026), it provides four CRDs:

• RayCluster: a long-lived cluster with a head node pod and one or more worker groups
• RayJob: submits a job to a cluster (creating a temporary RayCluster if needed) and deletes the cluster on completion
• RayService: wraps a RayCluster with Ray Serve deployments and provides zero-downtime upgrade semantics
• RayCronJob: scheduled job execution (added in KubeRay 1.x)

A minimal RayCluster for GPU training:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

apiVersion: ray.io/v1
kind: RayCluster
metadata:
  name: train-cluster
spec:
  rayVersion: "2.55.1"
  gcsFaultToleranceOptions:
    enabled: true
    redisAddress: "redis-sentinel:26379"
  headGroupSpec:
    rayStartParams:
      dashboard-host: "0.0.0.0"
      num-cpus: "0"          # head node does no work, only schedules
    template:
      spec:
        containers:
        - name: ray-head
          image: rayproject/ray-ml:2.55.1-gpu
          resources:
            requests:
              cpu: "4"
              memory: "16Gi"
            limits:
              cpu: "4"
              memory: "16Gi"
  workerGroupSpecs:
  - replicas: 4
    minReplicas: 1
    maxReplicas: 8           # autoscaler can grow to 8
    groupName: gpu-workers
    rayStartParams: {}
    template:
      spec:
        containers:
        - name: ray-worker
          image: rayproject/ray-ml:2.55.1-gpu
          resources:
            requests:
              cpu: "8"
              memory: "64Gi"
              nvidia.com/gpu: "1"
            limits:
              cpu: "8"
              memory: "64Gi"
              nvidia.com/gpu: "1"

The autoscaler embedded in the head pod watches pending tasks and actor placement group requests. When there are more pending tasks than available worker resources, it signals the Kubernetes cluster autoscaler (or Karpenter) to provision more nodes and then starts Ray worker pods on them. Scale-down happens after idle workers pass a configurable grace period.

For production MLOps workflows, RayJob is cleaner than RayCluster because the cluster’s lifecycle is tied to the job:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: ray.io/v1
kind: RayJob
metadata:
  name: finetune-llama
spec:
  entrypoint: "python /app/finetune.py --model llama-3-8b --epochs 3"
  shutdownAfterJobFinishes: true
  ttlSecondsAfterFinished: 3600
  runtimeEnvYAML: |
    pip:
      - transformers==4.45.0
      - deepspeed==0.15.0
    env_vars:
      HF_TOKEN: "$(HF_TOKEN)"
  rayClusterSpec:
    # same spec as above, inline

Dependency management deserves a callout here. Ray’s RuntimeEnv system can install pip packages per-job or per-actor at startup time. This is convenient but fragile: a worker that starts on a new node must run pip install before it can execute tasks, which adds 30–120 seconds of cold-start latency depending on package count. The practical solution is to bake your heavy dependencies into the container image and use RuntimeEnv only for lightweight job-specific overrides. The Ray + uv integration introduced in 2025 improves this significantly — uv’s dependency resolution and installation is much faster than pip on cold nodes.

For those who prefer bare-metal or VM deployments over Kubernetes, Ray’s cluster launcher (ray up) uses a YAML config to provision and configure nodes via SSH. This works well for static clusters on cloud VMs, HPC systems, or on-prem servers. See Kubernetes basics for the Kubernetes side; the GPU infrastructure considerations for Ray training clusters are covered in GPU infrastructure for ML.

The honest trade-offs

Serialization with cloudpickle. When a task argument is a Python object, Ray serializes it with cloudpickle before putting it in the object store. Cloudpickle can serialize lambdas, closures, and most dynamic Python objects — but it is not infallible. Objects with C extension state that don’t implement __reduce__ correctly (some database cursors, certain TensorFlow sessions, objects with open file handles) fail silently or with confusing errors. The error messages from nested cloudpickle failures are notoriously hard to read; a single serialization error can appear buried under several levels of Ray’s own exception wrapping. The practical rule: always verify that your task arguments can cloudpickle.dumps(obj) successfully before running at cluster scale.

Object store memory and spilling. The shared-memory object store is bounded. On a node with 256 GB RAM and object_store_memory set to the default (30% of system memory), you have ~76 GB of shared object store. Large tensors accumulate quickly during training — each forward pass in a 7B parameter model at fp16 is 14 GB, and if you have multiple in-flight training steps the store fills fast. When spilling kicks in, task latency jumps unpredictably. Monitor object store utilization via the Ray dashboard (ray start --include-dashboard=true) and set explicit limits in production.

Debugging distributed failures. The Ray dashboard and ray logs are useful, but finding the root cause of a failure across 100 worker actors is still tedious. The exception you see in the driver is typically a RayTaskError wrapping the real exception, which is sometimes many layers deep. Ray’s ray list tasks --state=FAILED CLI and the distributed tracing integrations (OpenTelemetry support was added in 2.x) help, but you will still spend time correlating logs across nodes. The local debugging workflow — running ray.init(local_mode=True) to execute tasks in-process — is helpful for logic errors but masks all distributed behavior, so it does not reproduce most real cluster bugs.

Version and dependency skew. Every node in the cluster must run the same Ray version. If your cluster has nodes with Ray 2.40 and your driver has Ray 2.55, tasks will fail. The RuntimeEnv system gives per-job package installation, but the Ray binary itself must match. In containerized deployments this is managed by pinning the image tag; in VM-based clusters it is the operator’s problem. Related: custom @ray.remote classes and functions are serialized with cloudpickle and sent to workers. If a worker doesn’t have the same package installed as the driver, the deserialization of that class fails at execution time, not submission time.

When Ray’s overhead is not worth it. Ray has a task dispatch overhead of roughly 1–5 ms per task (network round-trip through the scheduler). For tasks that complete in microseconds — processing small lists, quick dictionary lookups — the overhead exceeds the work. Ray is the wrong tool for parallelizing tight inner loops over small data; use Python’s concurrent.futures or numpy vectorization instead. The sweet spot is tasks that take at least tens of milliseconds and produce or consume data measured in megabytes or more.

Ray vs Dask vs Spark

The practical decision tree: if your workload looks like SQL or you are running on a managed Spark platform (Databricks, EMR) and most of your work is structured ETL, stay with Apache Spark. Spark’s Catalyst optimizer and mature SQL support are not matched by either Ray or Dask for tabular analytics, and its lineage-based fault tolerance requires no external state store. If your team is Python-native and you want to scale pandas-shaped workloads — groupby aggregations, rolling windows, big-but-tabular analysis — Dask’s API compatibility with the Python scientific stack is a genuine advantage. Note that Polars (which competes with Dask on single-node and multi-node dataframe speed) is gaining ground in 2026 and is worth evaluating before reaching for Dask for purely analytical workloads.

If your workload involves ML training, model serving, heterogeneous hardware (mixed CPU/GPU jobs), custom distributed algorithms, or you need stateful long-running workers, Ray is the right choice. Dask does not natively model actors, and wiring up GPU training across nodes in Dask requires considerably more manual work than Ray Train provides out of the box. The end-to-end story — Ray Data for ingest, Ray Train for distributed training, Ray Tune for hyperparameter optimization, Ray Serve for deployment, all sharing the same cluster and object store — is genuinely competitive with any other open-source ML platform stack. For the broader MLOps context around experiment tracking and model registries that sits around this compute layer, see MLOps fundamentals.

Verdict

Ray has earned its position as the default distributed compute layer for serious Python ML workloads. The core model — tasks as futures, actors as stateful workers, zero-copy shared memory across the cluster — is sound engineering, not marketing, and it runs the same code from a laptop to a multi-thousand-GPU cluster without a rewrite. KubeRay has matured to the point where running production Ray on Kubernetes is operationally tractable, and the GCS fault-tolerance story with Redis is a real answer to the head-node SPOF problem, even if it requires extra infrastructure.

The rough edges are real: cloudpickle serialization will bite you on complex objects, object-store spilling will surprise you on memory-constrained nodes, debugging multi-actor failures is painful, and dependency management across the cluster requires discipline. None of these are unsolvable, but they all require operational awareness that is not obvious from the tutorials. Ray is not the right tool for pure SQL workloads, and it is overkill for anything that fits in a single process.

What Ray gets right that the alternatives do not: it treats GPU scheduling, stateful actors, and low-latency task dispatch as first-class concerns. When OpenAI, Anthropic, and DeepMind all converge on the same distributed Python runtime for their training infrastructure, that is a strong signal about where the state of the practice has landed.

Sources

• Ray documentation — Ray 2.55.1
• What’s Ray Core — Ray 2.55.1
• Ray memory management
• Object spilling — Ray 2.55.1
• Ray serialization — Ray 2.55.1
• Node fault tolerance — Ray 2.55.1
• GCS fault tolerance — Ray 2.55.1
• GCS fault tolerance in KubeRay
• Ray on Kubernetes — Ray 2.55.1
• KubeRay GitHub repository
• RayJob Quickstart — Ray 2.55.1
• Environment dependencies — Ray 2.55.1
• uv + Ray: Pain-Free Python Dependencies in Clusters — Anyscale
• Ray Serve autoscaling — Ray 2.55.1
• Ray Serve architecture — Ray 2.55.1
• Get Started with DeepSpeed — Ray 2.55.1
• Ray use cases — Ray 2.55.1
• Announcing Ray 2.4.0: Infrastructure for LLM training — Anyscale
• Components of an Open Source AI Compute Tech Stack — Anyscale
• Accelerating RLHF with vLLM — vLLM Blog
• Ray vs Dask vs Spark for Distributed ML Training: 2026 Comparison — Reintech
• When to use Spark vs. Ray — Databricks
• Ray Fault Tolerance on Kubernetes: GCS, Workers, and HA Redis Sentinel (Feb 2026)
• Ray Clusters for AI: Distributed Computing Architecture — Introl Blog
• The Plasma In-Memory Object Store — Ray Blog