Ray is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.
43.5K stars7.9K forksPythonApache-2.0data-sciencedeep-learningdeploymentdistributedhyperparameter-optimizationhyperparameter-searchlarge-language-modelsllmkeyword: Ray distributed computingkeyword: Ray framework
Ray Data: In this Ray release, we've enabled DataSourceV2 by default (#64821), so readparquet and friends use the new scan/listing infrastructure with row-group-aware chunking and predicate splitting. Hash Shuffle V2 eliminates the aggregat
HashShuffleV2 supports join (#63598, #64538, #64687). This lets shuffles reuse standard map/reduce scheduling, backpressure, and resource accounting.
Ray Serve: The HAProxy ingress is now distributed as the ray-haproxy PyPI package instead of being compiled into images, and it is the default HAProxy binary (#64141, #64163, #64164). We've also added gRPC support to the HAProxy direct-ingr
Ray Core: We've added an embedded RocksDB storage backend for GCS fault tolerance (REP-64), selectable with RAYgcsstorage=rocksdb and RAYgcsstoragepath (#63657). GCS fault tolerance no longer requires an external Redis instance. We've also
> **Stacked PR.** Fourth in a chain: #65456 (pin ReDoc) → #65457 (spec validity) → #65458 (declare 3.0.3) → this. It's independent in substance and touches only `doc/requirements-doc.txt`, so it can be retargeted to `master` if you'd rather take it on its own. ## Why this change is needed The `setuptools==80.9.0` pin in `doc/requirements-doc.txt` exists beca
> **Stacked PR.** Targets `doc-1513-declare-openapi-303` (#65458), which targets #65457. Review order is #65457 → #65458 → this. GitHub retargets automatically as each merges. > > **Conflicts with #65456 by design.** That PR pins `redoc_uri` to a specific ReDoc version; this one deletes `redoc_uri` entirely. If #65456 lands first I'll resolve the conflict he
## Summary Follow-up to #64458. Adds one line to `llms.txt` telling agents that the page links also serve Markdown. Read the Docs serves a Markdown rendering of any page **from that page's own `.html` URL**, under an `Accept: text/markdown` request. There is no separate `.md` file to link to — `page.md`, `page.html.md`, `/md/<page>.md`, and `?format=md` all
## Why are these changes needed? Vendors the generated KubeRay CRD API reference at `doc/source/cluster/kubernetes/references/api.md` from `ray-project/kuberay` release tag v1.6.2, pinned at commit [`0a9eabd`](https://github.com/ray-project/kuberay/blob/0a9eabde561ab59ab4bbe626072c359da9214484/docs/reference/api.md). Opened automatically. The upstream file i
Draft PR whose only purpose is to trigger the release pipeline for the multi-node arrow-rs vs PyArrow A/B (the reader from #65117, ported onto #64985's planner). This branch is stacked on unmerged #64985, so its diff includes that PR's commits — do not review or merge. Baseline arm: see the companion draft PR for `arrow-rs-ab-baseline-64985`. 🤖 Generated wit
Bumps [transformers](https://github.com/huggingface/transformers) from 4.36.2 to 5.5.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/huggingface/transformers/releases">transformers's releases</a>.</em></p> <blockquote> <h1>Release v5.5.0</h1> <!-- raw HTML omitted --> <h2>New Model additions</h2> <h3>Gemma4</h3>
## Description Move `free_object_on_nodes_async_` (gRPC free broadcast) and out-of-scope callbacks outside of `mutex_` in `ReferenceCounter::OnObjectOutOfScopeOrFreed`. Previously, when many `ObjectRefs` are freed simultaneously (e.g., LIMIT operators, UDF failures), the gRPC calls (~70% of `RemoveLocalReference` runtime) and callbacks (~7%) executed under `
## Description > Briefly describe what this PR accomplishes and why it's needed. ## Related issues > Link related issues: "Fixes #1234", "Closes #1234", or "Related to #1234". ## Additional information > Optional: Add implementation details, API changes, usage examples, screenshots, etc.
## Description When requesting multiple subslices simultaneously, it can be helpful to allow selecting specific subslices to guarantee a spread of jobs. This change adds an optional subslice_index parameter to the subslice_placement_group builder which restricts placement group selection. ## Related issues Follow on to #64578 ## Additional information n/a
## Description This PR documents the three methods available for TPU subslicing with Ray: 1. Dynamic slicing with Kueue (provisions subslices via GKE) 2. RayClusters with a subslice annotation 3. SubslicePlacementGroup from the Ray TPU driver. ## Related issues - [Dynamic slicing docs](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/dynamic-sli
## Description `TaskPoolMapOperator.min_max_resource_requirements()` reports infinite maximum demand when `max_concurrency` is unset. That is a useful capacity bound, but it is not always a useful fair-share bound: an operator with one active or queued input can run at most one task. This matters for pipelines where one task fans out into many rows. The foll
## Description When only `target_num_rows_per_block` is set, `BlockOutputBuffer` currently builds the buffered block, emits one slice, and puts the remainder into a new builder. A StreamingRepartition with a one-row target repeats that work for every output block. This PR keeps the built block and advances through it by row offset. A builder is only needed a
## Why The KubeRay guides are one of the most-visited parts of the Ray docs, but they're buried two levels down under Ray Clusters and share the global sidebar with the entire site. A reader working through RayService configuration gets every top-level Ray section in the left nav and no KubeRay-specific orientation. This promotes KubeRay to a top-level nav t