AI向けRayクラスター：分散コンピューティングアーキテクチャ
2025年12月11日更新
2025年12月更新： OpenAIがChatGPTのトレーニング調整にRayを使用。RayがPyTorch Foundationに参加し、エンタープライズ採用が実証される。フレームワークはノートPCから数千のGPUまでスケーリング可能。AIパターンにおいてSparkより1桁高速なサブミリ秒レイテンシで毎秒数百万タスクを達成。CPU/GPUワークロード混在をサポートするネイティブな異種コンピュート対応。
OpenAIはChatGPTや他のモデルのトレーニング調整にRayを使用している。¹ このフレームワークはノートPCから数千のGPUを持つクラスターまでスケールし、プロジェクトごとにカスタムインフラストラクチャを必要とする分散コンピューティングの複雑さを処理する。Rayの採用は2025年を通じて急増し、フレームワークがPyTorch Foundationに参加し、Anyscaleがエンタープライズ展開を支援するための資金調達を行ったことで実証された。² Rayのアーキテクチャと展開パターンを理解することで、組織は実験から本番環境までスケールする分散AIインフラストラクチャを構築できる。
Rayは、クラスター管理の複雑さを抽象化しながらリソース割り当てのきめ細かな制御を維持する、トレーニング、チューニング、推論、データ処理といった分散AIワークロード向けの統合フレームワークを提供する。単一GPU実験からマルチノード本番システムへ移行する組織にとって、RayはスケーラブルなアIインフラストラクチャへの最も直接的な道を提供する。
AIインフラストラクチャにRayを選ぶ理由
RayはUCバークレーのRISELabから、Apache Sparkのような従来のフレームワークでは対応が難しい分散AIワークロード特有の課題に対処するために生まれた：
AIワークロードの要件
異種コンピュート： AIパイプラインはCPU集約型のデータ処理とGPUアクセラレートされたトレーニングおよび推論を混在させる。Rayはネイティブに異種リソース割り当てをサポートし、ワークロードの要求に応じてCPUとGPUにまたがってタスクをスケジューリングする。³
細粒度の並列処理： ディープラーニングのトレーニングでは、ワーカー間での勾配の調整、モデル状態の管理、障害の適切な処理が必要。Rayのタスクとアクターの抽象化は、これらのパターンに必要なプリミティブを提供する。
ステートフル計算： MapReduceスタイルのフレームワークとは異なり、AIワークロードは反復間で状態を維持することが多い。Rayのアクターは呼び出し間で状態を保持し、パラメータサーバーや強化学習エージェントのようなパターンをサポートする。
低レイテンシ： リアルタイム推論とハイパーパラメータ検索にはマイクロ秒単位のタスクスケジューリングが必要。Rayはサブミリ秒のレイテンシで毎秒数百万タスクを達成する—これらのパターンにおいてSparkより1桁高速である。⁴
代替手段との比較
Apache Spark： SQLとDataFrameによるバッチデータ処理に最適化。ETL、特徴量エンジニアリング、構造化データの分析に優れる。GPUワークロード、ステートフル計算、低レイテンシ要件にはあまり適さない。⁵
Dask： DataFrameと配列APIを持つPythonネイティブの分散コンピューティング。Sparkより軽量だが、Rayのアクターモデルやml特化ライブラリが欠けている。
Horovod： 分散ディープラーニングトレーニングに特化。純粋なトレーニングシナリオではRayより単純だが、多様なAIワークロードに対する柔軟性は劣る。
Rayの利点： 単一のフレームワークでデータ処理、トレーニング、ハイパーパラメータチューニング、推論サービングを処理。チームは複数のシステム管理とそれらの間の統合の複雑さを回避できる。
本番環境での採用
主要な組織がRayを本番環境で稼働させている：⁶
- OpenAI： ChatGPTトレーニングの調整
- Uber： 分散MLプラットフォーム
- Instacart： MLインフラストラクチャの基盤
- Shopify： 本番MLワークロード
- Ant Group： 大規模金融ML
Rayクラスターは公式に最大2,000ノードをサポートし、最先端モデルのトレーニングと大量の推論に必要なスケールを可能にする。
Rayアーキテクチャ
コア抽象化
Rayは分散計算のための2つの基本的な抽象化を提供する：
タスク： リモートで実行されるステートレス関数。Rayは利用可能なワーカー間でタスクを自動的にスケジューリングし、障害を処理し、結果を返す。
import ray
ray.init()
@ray.remote
def process_batch(data):
# 利用可能な任意のワーカーで実行
return transform(data)
# 並列実行
futures = [process_batch.remote(batch) for batch in batches]
results = ray.get(futures)
アクター： クラスター全体に分散されたステートフルオブジェクト。各アクターはメソッド呼び出し間で状態を維持し、モデルサービング、パラメータサーバー、ゲーム環境などのパターンを可能にする。
@ray.remote
class ModelServer:
def __init__(self, model_path):
self.model = load_model(model_path)
def predict(self, input_data):
return self.model(input_data)
# アクターインスタンスを作成
server = ModelServer.remote("model.pt")
# メソッドをリモートで呼び出し
prediction = ray.get(server.predict.remote(data))
クラスターアーキテクチャ
Rayクラスターはヘッドノードとワーカーノードで構成される：
ヘッドノード： クラスター状態を管理するGlobal Control Store（GCS）、データの場所を追跡するオブジェクトディレクトリ、タスク配置を調整するスケジューラを実行する。
ワーカーノード： タスクとアクターを実行。各ワーカーはローカルスケジューリングとオブジェクト管理を処理するRayletデーモンを実行する。
オブジェクトストア： 同一ノード上のタスク間でゼロコピーデータ受け渡しを可能にし、ノード間で効率的なシリアライゼーションを行う分散共有メモリ。
リソース管理
Rayは異種リソースを明示的に管理する：
@ray.remote(num_cpus=4, num_gpus=1)
def train_step(model, data):
# 4 CPUと1 GPUが保証される
return model.train(data)
カスタムリソースにより細粒度のスケジューリングが可能：
# 特定のハードウェアを要求
@ray.remote(resources={"TPU": 1})
def tpu_inference(data):
return run_on_tpu(data)
Ray AIライブラリ
Rayには一般的なAIワークロード向けに構築されたライブラリが含まれる：
Ray Train
PyTorch、TensorFlow、その他のフレームワークをサポートする分散トレーニング抽象化：
from ray.train.torch import TorchTrainer
from ray.train import ScalingConfig
def train_func():
# 標準的なPyTorchトレーニングコード
model = MyModel()
for epoch in range(10):
train_epoch(model)
trainer = TorchTrainer(
train_loop_per_worker=train_func,
scaling_config=ScalingConfig(
num_workers=8,
use_gpu=True
),
)
result = trainer.fit()
主な機能：⁷ - 2行のコード変更で単一GPUからマルチノードクラスターへスケール - 自動分散データロードと勾配同期 - チェックポイント管理と障害復旧 - PyTorch Lightning、Hugging Face Transformers、DeepSpeedとの統合
Ray Tune
分散ハイパーパラメータ最適化：
from ray import tune
from ray.tune.schedulers import ASHAScheduler
def training_function(config):
model = build_model(config["learning_rate"], config["batch_size"])
for epoch in range(100):
loss = train_epoch(model)
tune.report(loss=loss)
analysis = tune.run(
training_function,
config={
"learning_rate": tune.loguniform(1e-4, 1e-1),
"batch_size": tune.choice([32, 64, 128])
},
scheduler=ASHAScheduler(metric="loss", mode="min"),
num_samples=100,
)
Ray Tuneが提供するもの： - クラスター全体での並列トライアル実行 - ASHA、Population-Based Training、その他のスケジューラによる早期停止 - Optuna、HyperOpt、その他の最適化ライブラリとの統合 - チェックポイントと再開
Ray Serve
オートスケーリング機能を持つ本番モデルサービング：
from ray import serve
@serve.deployment(num_replicas=2, ray_actor_options={"num_gpus": 1})
class LLMDeployment:
def __init__(self):
self.model = load_llm()
async def __call__(self, request):
prompt = await request.json()
return self.model.generate(prompt["text"])
serve.run(LLMDeployment.bind())
Ray Serveの機能：⁸ - リクエストレートに基づくオートスケーリング - ゼロダウンタイムデプロイメント - マルチモデル構成とリクエストルーティング - LLMサービング向けOpenAI互換API - プレフィックス対応ルーティングによるtime-to-first-tokenの60%削減⁹
Ray Data
分散データロードと前処理：
import ray
ds = ray.data.read_parquet("s3://bucket/data/")
ds = ds.map(preprocess)
ds = ds.filter(lambda x: x["label"] > 0)
# PyTorch DataLoaderに変換
train_loader = ds.iter_torch_batches(batch_size=32)
Ray Dataが提供するもの： - 大規模データセット向けストリーミング実行 - GPUアクセラレートされた前処理 - 分散トレーニング向けRay Trainとの統合 - 画像、テキスト、表形式データのネイティブサポート
KubeRayによるKubernetesデプロイメント
本番Rayデプロイメントは通常、公式Kubernetesオペレーターであるを使用してKubernetes上で実行される：¹⁰
KubeRayコンポーネント
RayCluster CRD： ヘッドノードとワーカーノードの仕様、オートスケーリングポリシー、リソース要件を含むクラスター構成を定義。
apiVersion: ray.io/v1
kind: RayCluster
metadata:
name: ml-cluster
spec:
headGroupSpec:
rayStartParams:
dashboard-host: '0.0.0.0'
template:
spec:
containers:
- name: ray-head
image: rayproject/ray:2.52.0-py310-gpu
resources:
limits:
nvidia.com/gpu: 1
workerGroupSpecs:
- replicas: 4
minReplicas: 2
maxReplicas: 10
groupName: gpu-workers
rayStartParams: {}
template:
spec:
containers:
- name: ray-worker
image: rayproject/ray:2.52.0-py310-gpu
resources:
limits:
nvidia.com/gpu: 1
RayJob CRD： 自動プロビジョニングされたクラスターにジョブを送信。KubeRayはクラスターを作成し、ジョブを実行し、オプションで完了時にクラスターを削除する。
RayService CRD： ゼロダウンタイムアップグレードとヘルスチェックを備えたマネージドRay Serveデプロイメント。
本番環境のベストプラクティス
コンテナイメージ： 実行時にインストールするのではなく、依存関係を公開されたDockerイメージにベイクする。これにより再現性と高速な起動が保証される。¹¹
オートスケーリング： Rayオートスケーリング（クラスター内のワーカーのスケーリング）とKubernetesオートスケーリング（クラスターノードのスケーリング）の両方を有効にする：
spec:
enableInTreeAutoscaling: true
autoscalerOptions:
upscalingMode: Default
idleTimeoutSeconds: 60
ストレージ： チェックポイント用の永続ボリュームと大規模データセット用の共有ストレージを使用：
volumes:
- name: shared-storage
persistentVolumeClaim:
claimName: ml-data-pvc
モニタリング： 可観測性のためにPrometheusとGrafanaと統合：
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
クラウド固有のデプロイメント
GKE： Ray on GKEアドオンは、自動プロビジョニングとGoogle Cloudサービスとの統合を備えたマネージドRayクラスターを提供。¹²
EKS： ノードスケーリング用のCluster AutoscalerまたはKarpenterとともにKubeRayをデプロイ。FSx for Lustreとの統合により高性能共有ストレージを提供。
AKS： MicrosoftとAnyscaleは、Azure Portalからアクセス可能なファーストパーティサービスとしてAnyscale on Azureを提供。¹³
Anyscaleマネージド Ray
Rayの作成者が設立したAnyscaleは、マネージドRayデプロイメントを提供：
Anyscale Platform
マネージドクラスター： インフラストラクチャ管理なしで自動スケーリング、耐障害性、モニタリングを備えた本番グレードのRayクラスター。
RayTurboランタイム： オープンソースRayと比較して、より高い回復力、より高速なパフォーマンス、より低いコストを実現する独自のパフォーマンス改善。¹⁴
エンタープライズ機能： ロールベースのアクセス制御、監査ログ、VPCピアリング、コンプライアンス認証。
クラウドパートナーシップ
CoreWeave： Anyscale BYOC（Bring Your Own Cloud）はCoreWeave Kubernetes Service経由でCoreWeave顧客アカウントに直接デプロイ。¹⁵
Azure： ネイティブ統合を備えたファーストパーティAnyscaleサービスがAzure Portalで利用可能。
AWS： Anyscaleは既存のAWSサービスとの統合とともにAWS上で運用。
Anyscaleを使用すべき場合
**Anyscaleを検討
