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 | State |
| *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 metricsNCCL — 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 classMonitoring 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 procedimentosAlternativa: 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 mesesReferê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 |