Cluster Self-Hosted para Treino de LLMs

Kubernetes, Slurm, InfiniBand/RoCEv2, storage distribuído, orquestração de GPUs. Atualizado em abril de 2026.


Visão Geral

Treinar LLMs em escala requer mais do que GPUs — requer um cluster com networking de alta performance, storage distribuído e orquestração eficiente.

Este documento cobre como montar e operar um cluster self-hosted para treino de LLMs, do hardware à configuração de software.


Topologia de Cluster

Arquitetura típica

──────────────────────────────────────────────────────────────┐
│                     Cluster de Treino LLM                      │
│                                                               │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐           │
│  │   Node 1    │  │   Node 2    │  │   Node N    │           │
│  │  4× A100    │  │  4× A100    │  │  4× A100    │           │
│  │  2× CPU     │  │  2× CPU     │  │  2× CPU     │           │
│  │  512GB RAM  │  │  512GB RAM  │  │  512GB RAM  │           │
│  ──────┬──────┘  └──────┬──────┘  └──────┬──────┘           │
│         │                │                │                    │
│         └────────────────┼────────────────┘                    │
│                          │                                     │
│                   ┌──────▼──────┐                              │
│                   │  Switch IB  │  ← InfiniBand NDR/XDR        │
│                   │  (32/64 port)│    200/400 Gbps              │
│                   └──────┬──────┘                              │
│                          │                                     │
│                   ┌──────▼──────┐                              │
│                   │  Storage    │  ← Lustre / Ceph / WekaIO    │
│                   │  (100TB+)   │    Parallel filesystem        │
│                   └─────────────┘                              │
│                                                               │
│  ┌─────────────┐                                              │
│  │  Head Node  │  ← Kubernetes master / Slurm controller      │
│  │  (CPU only) │                                              │
│  └─────────────┘                                              │
└──────────────────────────────────────────────────────────────┘

Networking

InfiniBand vs Ethernet

Tecnologia Velocidade Latência Custo Uso em LLM
InfiniBand NDR 200 Gbps ~0.5µs Alto Padrão-ouro para treino
InfiniBand XDR 400 Gbps ~0.3µs Muito alto State-of-art
RoCEv2 (RDMA over Ethernet) 100–400 Gbps ~2–5µs Médio Alternativa viável
Ethernet 100GbE 100 Gbps ~10µs Baixo Só para inferência

Para treino distribuído de LLMs: InfiniBand é essencial. O all-reduce (sincronização de gradients entre GPUs) domina o tempo de treino, e a latência do InfiniBand é 10–20× menor que Ethernet.

Topologia de rede

Fat-Tree topology (padrão para clusters GPU):

  GPU Nodes          Spine Switches        Leaf Switches
  ┌──┐ ┌──┐          ┌── ┌──┐            ┌──┐ ┌──┐
  │N1│─│N2│──────────│S1│─│S2│────────────│L1│─│L2│
  └──┘ └──          └──┘ └──            └──┘ └──┘
  ┌──┐ ┌──┐          ┌──┐ ┌──┐            ┌──┐ ┌──┐
  │N3│─│N4│──────────│S3│─│S4│────────────│L3│─│L4│
  └──┘ └──┘          └──┘ └──┘            └── └──┘

  Bisection bandwidth: non-blocking (cada nó tem banda total)

Regra prática: Para um cluster de 16–64 GPUs, usar 1 switch InfiniBand de 32 portas. Para 64–256 GPUs, fat-tree com 2 níveis de switches.


Storage

Requisitos

Treino de LLMs precisa de storage com:

  • Throughput alto: 10+ GB/s para carregar datasets
  • Baixa latência: para checkpointing frequente
  • Parallel I/O: múltiplos nós lendo/escrevendo simultaneamente
  • Capacidade: 50–200TB para datasets + checkpoints

Opções de storage

Sistema Tipo Throughput Complexidade Custo
Lustre Parallel filesystem 100+ GB/s Alta Alto
WekaIO Parallel filesystem 50+ GB/s Média Alto
Ceph Distributed object/block 10–30 GB/s Alta Médio
NFS Network filesystem 1–5 GB/s Baixa Baixo
Local SSD NVMe em cada nó 3–7 GB/s por nó Baixa Médio

Recomendação:

  • Cluster pequeno (≤ 16 GPUs): NFS + SSD local para checkpoints
  • Cluster médio (16–64 GPUs): WekaIO ou Ceph
  • Cluster grande (64+ GPUs): Lustre

Estrutura de storage

/storage/
├── datasets/               ← Datasets de treino (read-only para workers)
│   ├── code/
│   ├── text/
│   └── multimodal/
├── checkpoints/            ← Checkpoints de treino (write-heavy)
│   ├── run_001/
│   │   ├── step_1000/
│   │   ├── step_2000/
│   │   └── ...
│   └── run_002/
── logs/                   ← Logs de treino
├── models/                 ← Modelos finais exportados
└── scratch/                ← Dados temporários (por job)

Orquestração

Kubernetes vs Slurm

Fator Kubernetes Slurm
Curva de aprendizado Alta Média
Flexibilidade Alta (qualquer workload) Média (focado em HPC)
GPU scheduling Bom (device plugin) Excelente (nativo)
Networking CNI (Calico, Cilium) InfiniBand nativo
Storage CSI drivers Lustre/NFS nativo
Comunidade ML Crescente Estabelecida
Multi-tenant Excelente Bom
Ferramentas ML Kubeflow, Volcano PyTorch + MPI nativo

Recomendação:

  • Se já tem equipe Kubernetes: usar Kubernetes com Volcano (batch scheduler)
  • Se é novo em orquestração: Slurm é mais simples para ML
  • Se precisa de multi-tenant: Kubernetes

Kubernetes para ML

# Exemplo de job de treino no Kubernetes
apiVersion: batch/v1
kind: Job
metadata:
  name: llm-training-run-001
spec:
  parallelism: 8
  completions: 8
  template:
    spec:
      containers:
      - name: trainer
        image: pytorch/pytorch:2.3.0-cuda12.1
        command: ["python", "train.py", "--config", "llm_7b.yaml"]
        resources:
          limits:
            nvidia.com/gpu: 1
            memory: 128Gi
            cpu: "32"
        volumeMounts:
        - name: datasets
          mountPath: /storage/datasets
        - name: checkpoints
          mountPath: /storage/checkpoints
      volumes:
      - name: datasets
        persistentVolumeClaim:
          claimName: datasets-pvc
      - name: checkpoints
        persistentVolumeClaim:
          claimName: checkpoints-pvc
      restartPolicy: Never

Ferramentas Kubernetes para ML:

  • Volcano — batch scheduler com gang scheduling (todos os pods sobem juntos)
  • Kubeflow Training Operator — PyTorchJob, MPIJob, XGBoostJob
  • Kueue — queueing e quota management
  • NVIDIA GPU Operator — drivers, device plugin, MIG

Slurm para ML

#!/bin/bash
#SBATCH --job-name=llm-training
#SBATCH --nodes=8
#SBATCH --gpus-per-node=4
#SBATCH --ntasks-per-node=4
#SBATCH --cpus-per-task=32
#SBATCH --mem=512G
#SBATCH --time=72:00:00
#SBATCH --partition=gpu

srun python train.py --config llm_7b.yaml

Vantagens do Slurm:

  • Simples de configurar para ML
  • InfiniBand nativo (MVAPICH2, OpenMPI)
  • Checkpoint/restart nativo
  • Comunidade HPC estabelecida

Provisionamento de GPUs

Configuração por nó

Componente Especificação
GPUs 4× NVIDIA A100 80GB ou H100 80GB
CPU 2× AMD EPYC 7763 (64 cores cada) ou Intel Xeon Platinum
RAM 512GB–1TB DDR5
Storage local 2× NVMe 4TB (RAID 1 para OS, RAID 0 para scratch)
Network 1× InfiniBand NDR (200 Gbps) + 1× Ethernet 25GbE (management)
PSU 2× 2000W (redundante)

Servidores prontos

Modelo GPUs Preço aprox.
Dell PowerEdge XE9680 8× H100 $350K
Supermicro AS-4125GO 8× H100 $300K
Gigabyte G493-Z83 8× H100 $280K
Lambda Hyperplane 8× H100 $320K
NVIDIA DGX H100 8× H100 $400K

Para 16 GPUs (4 nós): ~$1.2–1.6M em hardware.


Configuração de Software

Stack de software

Nível 1: Sistema operacional
  → Ubuntu 22.04 LTS ou Rocky Linux 9

Nível 2: Drivers e runtime
  → NVIDIA Driver 550+
  → CUDA 12.4
  → cuDNN 9.x
  → NCCL 2.20+ (comunicação GPU-GPU)

Nível 3: Networking
  → OFED (OpenFabrics Enterprise Distribution)
  → InfiniBand drivers
  → UCX (Unified Communication X)

Nível 4: Storage
  → Lustre client ou WekaIO agent
  → NFS client

Nível 5: Orquestração
  → Kubernetes + Volcano ou Slurm

Nível 6: ML Framework
  → PyTorch 2.3+
  → DeepSpeed / Megatron-LM / FSDP

Nível 7: Monitoring
  → Prometheus + Grafana
  → DCGM (NVIDIA Data Center GPU Manager)
  → Slurm accounting ou Kubernetes metrics

NCCL — Comunicação GPU

NCCL (NVIDIA Collective Communications Library) é o coração do treino distribuído:

import torch.distributed as dist

# Inicializar processo grupo com NCCL backend
dist.init_process_group(backend="nccl")

# All-reduce: somar gradients em todas as GPUs
torch.distributed.all_reduce(tensor, op=dist.ReduceOp.SUM)

Configuração de performance:

# Variáveis de ambiente para otimizar NCCL
export NCCL_PROTO=simple      # simple ou ll (low latency)
export NCCL_ALGO=Ring         # Ring, Tree, ou CollNet
export NCCL_SOCKET_IFNAME=eth0
export NCCL_IB_DISABLE=0      # Usar InfiniBand
export NCCL_IB_HCA=mlx5       # HCA driver
export NCCL_IB_TC=106         # Traffic class

Monitoring e Observabilidade

Métricas de hardware

Métrica Ferramenta Alerta se
GPU utilization DCGM, nvtop < 80% (ineficiência)
GPU memory usage DCGM > 95% (OOM risk)
GPU temperature DCGM > 85°C
GPU power DCGM > TDP (thermal throttling)
NVLink bandwidth DCGM < esperado
InfiniBand errors ibstat > 0
Disk I/O iostat < 50% da capacidade

Métricas de treino

Métrica O que indica
Loss curve Convergência do modelo
Gradient norm Explosão/vanishing gradients
Throughput (tokens/sec) Eficiência do treino
MFU (Model FLOPS Utilization) % do pico teórico atingido

MFU alvo: > 40% para A100, > 50% para H100. Se MFU < 30%, há problema de bottlenecks (I/O, networking, ou código).


Para o Kode

Cluster mínimo recomendado

Para treinar o Kode (modelo 7–30B):

Configuração Especificação Custo aprox.
Mínimo 2 nós, 4× A100 80GB cada, 200Gb IB $250K
Recomendado 4 nós, 4× A100 80GB cada, 200Gb IB $500K
Ideal 8 nós, 8× H100 80GB cada, 400Gb IB $2.5M

Setup passo a passo

Semana 1–2: Infraestrutura física
  → Instalar racks, cabos, switches InfiniBand
  → Configurar storage (NFS ou WekaIO)
  → Instalar OS em todos os nós

Semana 3: Software base
  → Drivers NVIDIA, CUDA, cuDNN
  → NCCL, UCX, InfiniBand stack
  → Testar comunicação GPU-GPU (NCCL tests)

Semana 4: Orquestração
  → Instalar Kubernetes + Volcano ou Slurm
  → Configurar GPU scheduling
  → Testar job distribuído

Semana 5: ML stack
  → PyTorch, DeepSpeed/FSDP, Megatron-LM
  → Configurar monitoring (DCGM, Prometheus)
  → Testar treino de modelo pequeno

Semana 6+: Otimização
  → Tuning de NCCL, I/O, parallelism
  → Benchmark de throughput
  → Documentar procedimentos

Alternativa: Cloud híbrida

Se o orçamento não permite cluster on-premise:

Fase 1: Cloud para treino (Lambda Labs / CoreWeave)
  → Alugar 8–16 A100 por semana
  → Treinar modelo
  → Custo: $5K–$15K por treino

Fase 2: On-premise para inferência
  → 2× RTX 4090 para serving
  → Custo: $5K em hardware

Fase 3: Migrar treino para on-premise quando justificar
  → Quando custo cloud > custo on-premise em 12 meses

Referências

Recurso Descrição
NVIDIA NCCL docs Documentação oficial de NCCL
Slurm docs Documentação do Slurm
Kubernetes GPU scheduling docs NVIDIA + K8s device plugin
Lambda Labs Provedor de GPU cloud
CoreWeave Provedor de GPU cloud alternativo
MLPerf Training Benchmarks de performance de treino