Ray 2.59：言語モデルのデータ処理・サービングが正式リリース、ローカルクラスタのトークン認証をデフォルト化

1. 正式リリースの対象は言語モデルAPI

2026年10月1日に公開された今回のバージョンで、Ray Data LLMとRay Serve LLMが正式リリース段階に移行した。それぞれ言語モデル向けのデータ処理と、モデルをサービスとして提供する機能だ。データ処理・サービング製品全体が今回初めて正式リリースされたと解釈してはならない。

基盤となる推論エンジンはvLLM 0.27.0に更新された。データ処理モジュールでは、重いエンジンの読み込みを遅らせた。ただし、正式リリースとこの変更によって実際の起動時間や処理速度がどれほど変わるかは示されていない。

2. ローカル認証も起動方法によって異なる

トークンは、クラスタに接続する際に提示する共通の鍵に相当する。アドレスを指定せずにray.init()を呼び出すと認証が有効になり、トークンがなければ~/.ray/auth_tokenに生成して再利用する。ローカル実行のたびに利用者が新しいトークンを手動で作るという変更ではない。

一方、ray start --headで起動する場合は、利用可能なトークンがすでに存在するときにのみ認証を有効にする。環境変数やトークンファイルにトークンが見つからなければ、認証なしで起動したという警告を出す。そのため、ローカルのデフォルト認証という説明だけを見て、2つの起動方法が同じ結果になると考えてはならない。

認証を無効にする選択肢もある。原文で示された環境変数の設定値は次のとおりだ。

RAY_AUTH_MODE=disabled

リモートクラスタと複数ノードで構成されるクラスタのデフォルト動作は、今回のバージョンでは変わらない。

サービングクライアントとAPI呼び出しは、呼び出し経路の末端までトークンを渡すよう改善された。

3. データ再配置にディスクベースの経路が追加

シャッフルは、結合や集約の前に関連データを同じ処理先に集める再配置処理だ。新しいシャッフル方式にはディスクを使う外部モードが追加され、結合と集約もこのモードに対応する。実行計画への組み込みも含まれる。

戦略名はhash_shuffle_v2からshuffle_v2に変わった。従来の名前を直接指定している設定は、移行時の確認対象だ。圧縮設定の名前も変わるため、戦略名だけを直して点検を終えないほうがよい。

得られるのはディスクを活用する処理経路であり、点検対象はその経路が使うストレージ容量と入出力だ。メモリ使用量が必ず減る、あるいは高速化するという保証と捉えるのではなく、自分の処理に合うリソース配分を検討すべき変更だ。

4. リクエストの拒否を障害と区別できる

サービングでは、リクエストの待ち行列が上限を超えて拒否される際の応答をデプロイ単位で指定できる。BackpressureConfigを使うと、従来の503の代わりに429を返し、任意で再試行までの待ち時間をヘッダーに含められる。デフォルト値は変わらない。

これは、サービスの故障で応答できない場合と、過負荷を避けるために意図的にリクエストを拒否する場合を分ける仕組みだ。リクエストを分散する仕組みと再試行ポリシーが、この2つの状況を区別するよう設定する際に意味がある。

5. 認証の利便性とトークン配布の負担を分けて考える必要がある

ローカルではトークンを自動生成して再利用する利便性が得られるが、リモート運用者は今後のトークン配布を準備する必要がある。リリースノートは、Ray 2.61でリモート・複数ノードを含むすべてのクラスタにデフォルト認証を拡大する予定だとしている。その際は、クラスタの各ノードと接続クライアントが同じトークンを持つ必要がある。

原文はリモートクラスタの運用者に対し、そのバージョンへの更新前にトークン配布の仕組みを用意するよう勧めている。導入日程を組む際は機能テストに加え、トークンを配布して一致させる手順も準備項目に含めるとよい。

Ray 2.59は、言語モデルAPIの正式化と認証のデフォルト変更を併せて検討しつつ、導入の判断は起動方法とトークン配布の準備に応じて分けるべきバージョンだ。