Cluster self hosted

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 *luster*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
*nfiniBand NDR* 200 Gbps ~0.5µs Alto Padrão-ouro para treino
*nfiniBand XDR* 400 Gbps ~0.3µs Muito alto Stateofart
*oCEv2 (RDMA over Ethernet)* 100–400 Gbps ~2–5µs Médio Alternativa viável
*thernet 100GbE* 100 Gbps ~10µs Baixo Só para inferência

*ara 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)

*egra 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:

  • *hroughput alto:*10+ GB/s para carregar datasets
  • *aixa latência:*para checkpointing frequente
  • *arallel IO:*múltiplos nós lendoescrevendo simultaneamente
  • *apacidade:*50–200TB para datasets + checkpoints

Opções de storage

Sistema Tipo Throughput Complexidade Custo
*ustre* Parallel filesystem 100+ GB/s Alta Alto
*ekaIO* Parallel filesystem 50+ GB/s Média Alto
*eph* Distributed object/block 10–30 GB/s Alta Médio
*FS* Network filesystem 1–5 GB/s Baixa Baixo
*ocal SSD* NVMe em cada nó 3–7 GB/s por nó Baixa Médio

*ecomendação:*

  • *luster pequeno (≤ 16 GPUs):*NFS + SSD local para checkpoints
  • *luster médio (16–64 GPUs):*WekaIO ou Ceph
  • *luster 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
*urva de aprendizado* Alta Média
*lexibilidade* Alta (qualquer workload) Média (focado em HPC)
*PU scheduling* Bom (device plugin) Excelente (nativo)
*etworking* CNI (Calico, Cilium) InfiniBand nativo
*torage* CSI drivers Lustre/NFS nativo
*omunidade ML* Crescente Estabelecida
*ulti-tenant* Excelente Bom
*erramentas ML* Kubeflow, Volcano PyTorch + MPI nativo

*ecomendação:*

  • *e já tem equipe Kubernetes:*usar Kubernetes com Volcano (batch scheduler)
  • *e é novo em orquestração:*Slurm é mais simples para ML
  • *e 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

*erramentas Kubernetes para ML:*

  • *olcano*— batch scheduler com gang scheduling (todos os pods sobem juntos)
  • *ubeflow Training Operator*— PyTorchJob, MPIJob, XGBoostJob
  • *ueue*— queueing e quota management
  • *VIDIA 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

*antagens 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
*PUs* 4× NVIDIA A100 80GB ou H100 80GB
*PU* 2× AMD EPYC 7763 (64 cores cada) ou Intel Xeon Platinum
*AM* 512GB–1TB DDR5
*torage local* 2× NVMe 4TB (RAID 1 para OS, RAID 0 para scratch)
*etwork* 1× InfiniBand NDR (200 Gbps) + 1× Ethernet 25GbE (management)
*SU* 2× 2000W (redundante)

Servidores prontos

Modelo GPUs Preço aprox.
*ell PowerEdge XE9680* 8× H100 $350K
*upermicro AS-4125GO* 8× H100 $300K
*igabyte G493-Z83* 8× H100 $280K
*ambda Hyperplane* 8× H100 $320K
*VIDIA DGX H100* 8× H100 $400K

*ara 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)

*onfiguraçã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

*FU 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.
*ínimo* 2 nós, 4× A100 80GB cada, 200Gb IB $250K
*ecomendado* 4 nós, 4× A100 80GB cada, 200Gb IB $500K
*deal* 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

Source: ../home/koder/dev/koder/meta/docs/ia/compendium/11-infraestrutura/cluster-self-hosted.md