Ray, a distributed computing tool, has made large language model data processing and serving generally available. Development teams should check both the features' release status and the changed default for authentication on local clusters that run multiple tasks together.

1. Language model APIs reach general availability

In this release, published on October 1, 2026, Ray Data LLM and Ray Serve LLM reached general availability. They handle language model data processing and model serving, respectively. This does not mean the entire data processing and serving products are becoming generally available for the first time.

The underlying inference engine was upgraded to vLLM 0.27.0. The data processing module now defers loading the heavy engine. However, no figures were provided on how general availability or this change affects actual startup time or processing speed.

2. Local authentication also depends on how the cluster starts

A token acts as a shared key presented when connecting to a cluster. Calling ray.init() without an address enables authentication and creates a token at ~/.ray/auth_token for reuse if none exists. Users do not need to manually create a new token for every local run.

By contrast, ray start --head enables authentication only when a token is already available. If no token is found in environment variables or a token file, it warns that startup occurred without authentication. Do not assume both startup methods behave identically just because local authentication is described as the default.

Authentication can also be disabled. The source provides the following environment variable setting.

RAY_AUTH_MODE=disabled

Default behavior for remote and multi-node clusters does not change in this release.

Serving clients and API calls were improved to pass tokens through the entire call path.

3. Data shuffling gains a disk-based path

Shuffling redistributes related data to the same processing destination before joins or aggregations. The new shuffle implementation adds a disk-based external mode, also supported by joins and aggregations. Integration with execution plans is included as well.

The strategy was renamed from hash_shuffle_v2 to shuffle_v2. Configurations that explicitly use the old name need checking during migration. Compression settings were also renamed, so checks should not stop after updating the strategy name.

The addition is a processing path that uses disk, and its storage capacity and I/O need checking. Rather than assuming it guarantees lower memory use or faster execution, review resource allocation for your own workload.

4. Request rejection can be distinguished from failure

Serving responses for requests rejected because the queue exceeds its limit can now be configured per deployment. BackpressureConfig can return 429 instead of 503 and optionally include a retry delay in a header. The default is unchanged.

This distinguishes a service unable to respond because of a failure from one deliberately rejecting requests to avoid overload. It matters when configuring request distribution and retry policies to distinguish these situations.

5. Separate authentication convenience from token distribution work

Local users gain automatic token creation and reuse, while remote operators need to prepare token distribution. The release notes plan default authentication for all clusters, including remote and multi-node clusters, in Ray 2.61. Each cluster node and connecting client will then need the same token.

The source recommends that remote cluster operators arrange token distribution before upgrading to that version. Alongside feature testing, adoption plans should include procedures for distributing tokens and keeping them consistent.

Ray 2.59 calls for reviewing both language model API general availability and authentication defaults, with adoption decisions based on startup methods and token distribution readiness.