Clusters Ray para IA: Arquitetura de Computação Distribuída

Atualizado em 11 de dezembro de 2025

Atualização de dezembro de 2025: OpenAI usando Ray para coordenar o treinamento do ChatGPT. Ray entrando na PyTorch Foundation validando a adoção empresarial. Framework escalando de laptop a milhares de GPUs. Alcançando milhões de tarefas por segundo com latência inferior a milissegundos—uma ordem de magnitude mais rápido que Spark para padrões de IA. Suporte nativo a computação heterogênea permitindo mistura de cargas de trabalho CPU/GPU.

A OpenAI usa Ray para coordenar o treinamento do ChatGPT e outros modelos.¹ O framework escala de um laptop a clusters de milhares de GPUs, lidando com a complexidade de computação distribuída que, de outra forma, exigiria infraestrutura personalizada para cada projeto. A adoção do Ray explodiu ao longo de 2025, validada pela entrada do framework na PyTorch Foundation e pela captação de capital da Anyscale para apoiar implantações empresariais.² Entender a arquitetura do Ray e os padrões de implantação ajuda organizações a construir infraestrutura de IA distribuída que escala da experimentação à produção.

O Ray fornece um framework unificado para cargas de trabalho de IA distribuída—treinamento, ajuste, inferência e processamento de dados—que abstrai a complexidade do gerenciamento de clusters enquanto mantém controle refinado sobre alocação de recursos. Para organizações que estão indo além da experimentação com uma única GPU para sistemas de produção multi-nó, o Ray oferece o caminho mais direto para infraestrutura de IA escalável.

Por que Ray para infraestrutura de IA

O Ray surgiu do RISELab da UC Berkeley para abordar os desafios específicos de cargas de trabalho de IA distribuída que frameworks tradicionais como Apache Spark não lidam bem:

Requisitos de cargas de trabalho de IA

Computação heterogênea: Pipelines de IA misturam processamento de dados intensivo em CPU com treinamento e inferência acelerados por GPU. O Ray suporta nativamente alocação de recursos heterogêneos, agendando tarefas entre CPUs e GPUs conforme as cargas de trabalho demandam.³

Paralelismo de granularidade fina: O treinamento de deep learning requer coordenação de gradientes entre workers, gerenciamento de estado do modelo e tratamento gracioso de falhas. As abstrações de tarefas e atores do Ray fornecem as primitivas necessárias para esses padrões.

Computação com estado: Diferente de frameworks no estilo MapReduce, cargas de trabalho de IA frequentemente mantêm estado entre iterações. Atores do Ray persistem estado entre invocações, suportando padrões como servidores de parâmetros e agentes de aprendizado por reforço.

Baixa latência: Inferência em tempo real e busca de hiperparâmetros requerem agendamento de tarefas em microssegundos. O Ray alcança milhões de tarefas por segundo com latência inferior a milissegundos—uma ordem de magnitude mais rápido que Spark para esses padrões.⁴

Comparação com alternativas

Apache Spark: Otimizado para processamento de dados em lote com SQL e DataFrames. Excelente em ETL, engenharia de features e análises em dados estruturados. Menos adequado para cargas de trabalho GPU, computação com estado e requisitos de baixa latência.⁵

Dask: Computação distribuída nativa de Python com APIs de DataFrame e array. Mais leve que Spark, mas carece do modelo de atores do Ray e bibliotecas específicas para ML.

Horovod: Focado especificamente em treinamento distribuído de deep learning. Menos flexível que Ray para cargas de trabalho diversas de IA, mas mais simples para cenários de treinamento puro.

Vantagem do Ray: Um único framework lida com processamento de dados, treinamento, ajuste de hiperparâmetros e serviço de inferência. Equipes evitam gerenciar múltiplos sistemas e a complexidade de integração entre eles.

Adoção em produção

Grandes organizações executam Ray em produção:⁶

• OpenAI: Coordenação do treinamento do ChatGPT
• Uber: Plataforma de ML distribuído
• Instacart: Backbone de infraestrutura de ML
• Shopify: Cargas de trabalho de ML em produção
• Ant Group: ML financeiro em larga escala

Clusters Ray oficialmente suportam até 2.000 nós, permitindo a escala necessária para treinamento de modelos de fronteira e inferência de alto volume.

Arquitetura do Ray

Abstrações principais

O Ray fornece duas abstrações fundamentais para computação distribuída:

Tarefas: Funções sem estado executadas remotamente. O Ray automaticamente agenda tarefas entre workers disponíveis, lida com falhas e retorna resultados.

import ray

ray.init()

@ray.remote
def process_batch(data):
    # Executa em qualquer worker disponível
    return transform(data)

# Executa em paralelo
futures = [process_batch.remote(batch) for batch in batches]
results = ray.get(futures)

Atores: Objetos com estado distribuídos pelo cluster. Cada ator mantém estado entre chamadas de métodos, permitindo padrões como serviço de modelos, servidores de parâmetros e ambientes de jogos.

@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)

# Cria instância do ator
server = ModelServer.remote("model.pt")
# Chama métodos remotamente
prediction = ray.get(server.predict.remote(data))

Arquitetura do cluster

Clusters Ray consistem em um nó principal e nós workers:

Nó principal: Executa o Global Control Store (GCS) gerenciando estado do cluster, diretório de objetos rastreando localizações de dados e scheduler coordenando posicionamento de tarefas.

Nós workers: Executam tarefas e atores. Cada worker executa um daemon Raylet lidando com agendamento local e gerenciamento de objetos.

Object store: Memória compartilhada distribuída permitindo passagem de dados zero-copy entre tarefas no mesmo nó e serialização eficiente entre nós.

Gerenciamento de recursos

O Ray gerencia recursos heterogêneos explicitamente:

@ray.remote(num_cpus=4, num_gpus=1)
def train_step(model, data):
    # Garantido 4 CPUs e 1 GPU
    return model.train(data)

Recursos personalizados permitem agendamento de granularidade fina:

# Solicita hardware específico
@ray.remote(resources={"TPU": 1})
def tpu_inference(data):
    return run_on_tpu(data)

Bibliotecas de IA do Ray

O Ray inclui bibliotecas construídas especificamente para cargas de trabalho comuns de IA:

Ray Train

Abstração de treinamento distribuído suportando PyTorch, TensorFlow e outros frameworks:

from ray.train.torch import TorchTrainer
from ray.train import ScalingConfig

def train_func():
    # Código de treinamento PyTorch padrão
    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()

Capacidades principais:⁷ - Escala de GPU única para clusters multi-nó com alteração de 2 linhas de código - Carregamento de dados distribuído automático e sincronização de gradientes - Gerenciamento de checkpoints e recuperação de falhas - Integração com PyTorch Lightning, Hugging Face Transformers e DeepSpeed

Ray Tune

Otimização de hiperparâmetros distribuída:

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 fornece: - Execução paralela de trials pelo cluster - Early stopping com ASHA, Population-Based Training e outros schedulers - Integração com Optuna, HyperOpt e outras bibliotecas de otimização - Checkpointing e retomada

Ray Serve

Serviço de modelos em produção com autoscaling:

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())

Capacidades do Ray Serve:⁸ - Autoscaling baseado em taxa de requisições - Implantações sem downtime - Composição de múltiplos modelos e roteamento de requisições - API compatível com OpenAI para serviço de LLM - Redução de 60% no time-to-first-token com roteamento consciente de prefixo⁹

Ray Data

Carregamento e pré-processamento de dados distribuídos:

import ray

ds = ray.data.read_parquet("s3://bucket/data/")
ds = ds.map(preprocess)
ds = ds.filter(lambda x: x["label"] > 0)

# Converte para PyTorch DataLoader
train_loader = ds.iter_torch_batches(batch_size=32)

Ray Data fornece: - Execução em streaming para grandes datasets - Pré-processamento acelerado por GPU - Integração com Ray Train para treinamento distribuído - Suporte nativo para dados de imagem, texto e tabulares

Implantação em Kubernetes com KubeRay

Implantações Ray em produção tipicamente rodam em Kubernetes usando KubeRay, o operador oficial do Kubernetes:¹⁰

Componentes do KubeRay

RayCluster CRD: Define configuração do cluster incluindo especificações de nós principal e worker, políticas de autoscaling e requisitos de recursos.

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: Envia jobs para clusters provisionados automaticamente. KubeRay cria o cluster, executa o job e opcionalmente deleta o cluster ao completar.

RayService CRD: Implantações gerenciadas do Ray Serve com upgrades sem downtime e verificação de saúde.

Melhores práticas para produção

Imagens de container: Incorpore dependências em imagens Docker publicadas em vez de instalar em tempo de execução. Isso garante reprodutibilidade e inicialização mais rápida.¹¹

Autoscaling: Habilite tanto autoscaling do Ray (escalando workers dentro de um cluster) quanto autoscaling do Kubernetes (escalando nós do cluster):

spec:
  enableInTreeAutoscaling: true
  autoscalerOptions:
    upscalingMode: Default
    idleTimeoutSeconds: 60

Armazenamento: Use volumes persistentes para checkpoints e armazenamento compartilhado para grandes datasets:

volumes:
- name: shared-storage
  persistentVolumeClaim:
    claimName: ml-data-pvc

Monitoramento: Integre com Prometheus e Grafana para observabilidade:

metadata:
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"

Implantações específicas por cloud

GKE: O add-on Ray on GKE fornece clusters Ray gerenciados com provisionamento automático e integração com serviços do Google Cloud.¹²

EKS: Implante KubeRay com Cluster Autoscaler ou Karpenter para escalamento de nós. Integração com FSx for Lustre fornece armazenamento compartilhado de alto desempenho.

AKS: Microsoft e Anyscale oferecem Anyscale on Azure como serviço first-party acessível pelo Azure Portal.¹³

Ray gerenciado pela Anyscale

A Anyscale, empresa fundada pelos criadores do Ray, oferece implantações Ray gerenciadas:

Plataforma Anyscale

Clusters gerenciados: Clusters Ray de nível produção com escalamento automático, tolerância a falhas e monitoramento sem gerenciamento de infraestrutura.

Runtime RayTurbo: Melhorias de desempenho proprietárias entregando maior resiliência, desempenho mais rápido e menor custo versus Ray open-source.¹⁴

Recursos empresariais: Controle de acesso baseado em funções, logging de auditoria, VPC peering e certificações de compliance.

Parcerias com clouds

CoreWeave: Anyscale BYOC (Bring Your Own Cloud) implanta diretamente em contas de clientes CoreWeave via CoreWeave Kubernetes Service.¹⁵

Azure: Serviço Anyscale first-party disponível no Azure Portal com integração nativa.

AWS: Anyscale opera na AWS com integração em serviços AWS existentes.

Quando usar Anyscale

**Considere Anysc