Construindo um cluster de armazenamento para pré-treinamento com discos rígidos de 30 petabytes

• Para o pré-treinamento de modelos voltados à resolução de tarefas de uso de computador, foi realizado o desenvolvimento direto de um cluster de armazenamento no centro de São Francisco, com a meta de armazenar dados de vídeo equivalentes a 90 milhões de horas
• Foi escolhida uma abordagem on-premises, tornando possível operar uma infraestrutura de 30 PB por $354 mil por ano (cerca de 500 milhões de won). Na AWS, o custo seria de $12 milhões (cerca de 17 bilhões de won), o que representa uma redução de custos de aproximadamente 34 vezes
• Ao contrário da maioria das nuvens públicas, o foco não está em alta disponibilidade e integridade, e sim em uma estratégia que tolera perda de dados, devido à natureza dos dados de treinamento
• A operação é feita com software simples baseado em Rust e Nginx e, em vez de sistemas complexos como Ceph ou MinIO, a gestão é feita com um programa próprio de 200 linhas
• Ao longo do projeto, foram adquiridos vários aprendizados práticos e enfrentadas tentativas e erros relacionados a disposição física, configuração de rede e organização de cabos

---

Introdução e contexto

• O pré-treinamento de modelos para uso de computador exige grandes volumes de dados em vídeo
• Um LLM textual comum (como o LLaMa-405B) pode funcionar com cerca de 60 TB de dados, mas o treinamento baseado em vídeo exige 500 vezes mais espaço de armazenamento
• Ao usar uma nuvem pública como a AWS, o custo anual seria de US$ 12 milhões, mas com aluguel de colocation e construção própria foi possível reduzir isso drasticamente para cerca de US$ 354 mil
• Ao manter internamente grandes volumes de dados, foi possível resolver o problema em que o custo dos dados era a principal restrição

Por que construir por conta própria

• A nuvem foca em alta confiabilidade, redundância e integridade dos dados, mas dados para pré-treinamento não são tão críticos a ponto de impedir, por exemplo, 5% de perda
• Graças a essa característica, foi possível adotar requisitos de confiabilidade muito mais flexíveis do que os de empresas comuns (aplicando 2 noves em vez de 13 noves)
• O preço do armazenamento é muito mais alto do que o custo real
• Como os dados são o maior componente de custo, concluiu-se que construir um datacenter local era mais vantajoso dentro de uma faixa suficientemente previsível

Comparação de custos: nuvem vs. construção própria

• Custo recorrente mensal: internet $7.500 + eletricidade $10.000 = total de $17.500
• Custos únicos: discos rígidos $300.000, chassis $35.000, nós de CPU $6.000, instalação $38.500, mão de obra $27.000, rede e outras instalações $20.000 → total de $426.500
• Considerando depreciação em 3 anos, o custo fixo mensal foi calculado em $29.500
• AWS: $1.130.000/mês, Cloudflare R2: $270.000/mês, construção própria: $29.500/mês
  • AWS: cerca de $38 por TB/mês
  • Cloudflare: cerca de $10 por TB/mês
  • Construção própria: $1 por TB/mês
• Em treinamento de modelos em larga escala, até mesmo a Cloudflare apresentou problemas de rate limit por forte carga sobre os sistemas internos, mas no ambiente próprio isso foi resolvido com um link dedicado de 100 Gbps

Construção e processo

• Para uma implantação rápida, foi planejado o Storage Stacking Saturday (S3), com ajuda de conhecidos e contratação de profissionais especializados
• Em 36 horas, 2.400 discos rígidos foram montados nos racks, concluindo o hardware de 30 PB
• O software é composto por Rust (responsável pela escrita, 200 linhas) + nginx (responsável pela leitura) + SQLite (rastreamento de metadados)
  • Ceph, MinIO, Weka e Vast não foram usados por questões de complexidade/custo (complexidade, desnecessidade, carga de manutenção etc.)
  • Todos os discos foram formatados com XFS

Feedback do projeto e lições aprendidas

O que funcionou bem

• O trade-off entre redundância e desempenho foi aplicado de forma adequada, permitindo utilizar quase toda a capacidade da rede 100G
• A instalação foi feita fisicamente perto da equipe, garantindo facilidade de depuração e manutenção
• Os fornecedores foram encontrados no eBay, mas as compras reais foram feitas diretamente com fornecedores individuais, com ênfase na importância da garantia
• O link de internet de 100G trouxe muitas vantagens, e também facilitou a depuração de problemas de rede internamente
• A organização de cabos de alta qualidade ajudou muito na resolução posterior de problemas
• Em vez de sistemas de armazenamento open source complexos, foi aplicado o princípio da simplificação, minimizando a carga de manutenção
• As previsões de tempo e custo de trabalho também foram precisas, e o efeito da economia pôde ser claramente comprovado

Dificuldades e tentativas e erros

• O uso de front loaders tornou trabalhoso instalar manualmente, um por um, os 2.400 HDDs
• Faltou densidade de armazenamento; se uma densidade maior tivesse sido adotada no desenho inicial, haveria potencial para reduzir trabalho
• Daisy chain provoca gargalos de velocidade; o ideal é conectar um HBA separado a cada chassis
• Em componentes de rede, a compatibilidade entre marcas é importante, especialmente em transceptores ópticos
• Houve gasto de tempo com experimentação/configuração da rede; em vez de DHCP/NAT, a configuração foi orientada por desempenho e conveniência, aplicando apenas requisitos mínimos de firewall/secure link
• Ficou evidente a importância da acessibilidade física e do cabeamento de monitor/teclado durante a configuração

Ideias que vale a pena tentar

• Uso de KVM e IPMI para tornar a administração remota mais eficiente
• Recomenda-se configurar uma rede Ethernet separada para gerenciamento
• Overprovisioning de rede (por exemplo, considerar também uma malha interna de 400G)
• Com servidores de maior densidade (Supermicro de 90 discos / HDDs de 20 TB etc.), seria possível obter vantagens como
  redução do número de racks, economia de energia e melhor concentração de CPU

Como montar isso por conta própria

Configuração de armazenamento

• 10 nós de CPU head (Intel RR2000 etc., com recomendação de dual Intel Gold 6148 / 128 GB ECC DDR4 RAM por servidor)
  • Para funções com alta carga de CPU (como ZFS), é possível escolher equipamentos mais potentes
• 100 chassis DS4246 (cada um com 24 HDDs)
• 2.400 HDDs de 3,5" (de preferência discos SAS, por vantagem de velocidade)
  • Combinação de várias capacidades (12 TB, 14 TB etc.); quanto maior a capacidade, mais vantajosa tende a ser a disposição e o valor de revenda
• Trilhos/brackets para montagem física, além de fiação e cabos do equipamento
• Vários crash carts (monitor + teclado) para depuração de problemas de rede

Infraestrutura de rede

• Switches 100GbE (Arista usados etc., com portas QSFP28)
• HBA por servidor (recomendado: Broadcom 9305-16E etc.), além do método de conexão entre portas HBA e chassis
• Placas de rede (Mellanox ConnectX-4 etc., obrigatoriamente em modo Ethernet)
• Cabos DAC/AOC — considerando a distância entre racks, o DAC tem vantagem de compatibilidade
• Ao comprar nós head de CPU, recomenda-se aproveitar fornecedores que já instalem HBA/NIC previamente
• Cabos seriais e uma rede Ethernet separada para gerenciamento (como alternativa, adaptador sem fio para backup + mini switch)

Requisitos do datacenter

• Consumo de 3,5 kW por gabinete, assumindo uma configuração de 4U×10 + 2U×1 com base em 42U
• 3 PB por gabinete, com 1 gabinete 42U extra para switches ou substituição por chassis 1U
• Cross-connect dedicado de 100G (normalmente um par de fibras ópticas QSFP28 LR4), sendo essencial verificar antecipadamente a compatibilidade de form factor e marca
• Recomenda-se uma localização próxima ao escritório (colocation), pois permite resposta física rápida em caso de problemas e otimiza a produtividade de depuração e operação

Dicas de configuração inicial

• Após a configuração inicial do switch via console local, valide primeiro a configuração da porta de uplink 100GbE e a compatibilidade do transceptor óptico
  • Se necessário, conecte a fibra do ISP diretamente à NIC para confirmar o link-up e depois migre para o switch
• Durante a instalação do Ubuntu, costuma ser mais fácil concluir a configuração de rede dos nós com o Netplan
• Após conectar os nós à internet, siga a sequência conectar 1 cabo a cada DS4246 → formatar/montar → verificar o estado, para detectar cedo problemas de cabeamento ou discos com defeito

Cuidados com desempenho, estabilidade e segurança

• Sob a premissa de segurança de que se trata de dados dedicados ao treinamento, a operação foi simplificada com IP público direto + firewall de portas + nginx secure_link
  • Ao lidar com dados de clientes, a mesma configuração é inadequada, e DHCP/NAT/firewall segmentado são indispensáveis
• O daisy chain facilita gerenciamento e cabeamento, mas provoca gargalos de largura de banda; sempre que possível, recomenda-se HBA dedicado por chassis
• Transceptores ópticos têm forte lock-in por marca; é possível comprar em paralelo na FS.com e na Amazon, mas é fundamental verificar cuidadosamente especificações e compatibilidade de marca

Conclusão e significado

• Com um armazenamento próprio ultrabarato no nível de $1/TB-mês, tornou-se viável o pré-treinamento em vídeo de 30 PB, alcançando uma redução de custos de 10 a 38 vezes em comparação com a nuvem
• A arquitetura simples e a facilidade de acesso físico reduziram tempo e risco, enquanto o link dedicado de 100G eliminou os gargalos de I/O
• Na era dos grandes modelos multimodais e de vídeo, a infraestrutura de dados de grande volume e baixo custo é uma vantagem competitiva essencial, e essa abordagem oferece uma referência prática que pode ser implementada até mesmo por equipes pequenas

Encerramento e convite à colaboração

• Caso alguém tenha construído um cluster de armazenamento semelhante com base neste texto, seria desejável compartilhar melhorias e experiências
• Há contratação aberta para pesquisa em IA ligada a pré-treinamento em larga escala de modelos de uso de computador, generalização e alinhamento com valores humanos (contato: [e-mail])

[GN⁺]

Comentários do Hacker News

• Quando comecei minha carreira, on-premises era o ambiente padrão. Hardware durável acaba recebendo muito cuidado, e cada servidor vai acumulando histórico e estado. Com o tempo, quando o desempenho do hardware já não basta, é preciso escolher novo hardware da lista existente por meio da equipe interna e ainda conseguir aprovação de custo adicional, o que é trabalhoso. O projeto às vezes também atrasa no processo de substituir hardware ou de separar cuidadosamente equipamentos estimados como se fossem pets para migrar para equipamentos novos. Quando a nuvem apareceu, passei a pensar: “agora é nuvem de qualquer jeito”. Só que, com o tempo, você e a organização esquecem como gerenciar hardware diretamente e, no fim, se não recuperar essa habilidade, a nuvem — que era uma boa escolha — vai ficando cada vez menos atraente. Então, obrigado por ajudar a desenvolver essa habilidade de novo.

  • Nosso caso é meio incomum. Desde o começo, não tínhamos como bancar o custo operacional de hyperscale cloud, então fomos obrigados a desenvolver nossa própria capacidade técnica. Não é tão difícil quanto parece e pretendemos continuar assim por enquanto. Dito isso, o problema de acúmulo de estado mencionado realmente começa a aparecer.

  • Na minha memória, on-premises sempre foi mais barato. Havia a conveniência de remover vários obstáculos logísticos e ficar com uma fatura só. Na época em que a nuvem estava em alta, o conselho era sempre usar on-premises e recorrer à nuvem só quando o tráfego variasse de forma repentina. Mas o uso temporário para expansão foi virando uso permanente, e os desenvolvedores passaram a depender apenas de subir novas máquinas imediatamente. Agora todo mundo trata a nuvem como estado padrão. Nesse processo, perdemos a base para perceber corretamente o custo real, e a diferença de custo entre nuvem e on-premises foi aumentando cada vez mais.

  • Docker é uma ferramenta excelente para fazer com que servidores deixem de ser pets. O servidor no rack vira apenas mais um nó de K3 ou K8, então você deixa de tratá-lo como pet. Isso é muito bom. Dá para dizer algo parecido sobre VMs, mas no fim a própria VM vira o pet. Claro, dá para criar imagens ou snapshots, mas a mudança sentida com Docker é diferente.

  • Uma pergunta em tom de brincadeira: será que eu tento um desafio desses mais uma vez?

• Uma startup que tem dinheiro suficiente para comprar sem pensar um domínio .inc de duas letras tem capital demais. É o mesmo fenômeno de contar quantas cadeiras Aeron havia no escritório da startup antigamente. Não é um bom sinal.

  • Domínios .inc de duas letras ainda não usados estão sendo vendidos por US$ 2.300 por ano. Isso não chega nem a 5% do custo de um desenvolvedor.

  • Fico em dúvida se nomes de domínio .inc têm algum valor real.

• Texto divertido. Foi gostoso ler e viver isso por tabela. Para deixar esse tipo de experiência ainda mais divertida, eu queria ver mais fotos.

  • Se os autores comentarem, eu gostaria de perguntar diretamente o que a Standard Intelligence PBC faz. É Public Benefit Corporation? Ou em que projeto eles estão trabalhando?

• Gostei porque o conteúdo técnico está escrito em detalhes. Tenho curiosidade sobre como foi o processo de conseguir espaço de colocation: usaram broker? Quanto o preço realmente pago diferiu da cotação inicial após negociação?

  • Pedimos cotação para a maioria dos provedores de colocation em San Francisco e Fremont. Não houve diferença entre a cotação e o preço final pago, mas negociamos condições e custos pontuais.

• O post de blog do Discord linkado também é interessante. Em geral ele é sério, mas tinha umas partes divertidas, como o fato de que, quando saía um gol na Copa do Mundo, o dado aparecia imediatamente nos gráficos de monitoramento, então os membros da equipe podiam fingir que estavam vendo futebol na reunião por motivos de trabalho. Também foi citado como base para dizer que o Discord armazena mensagens com armazenamento “abaixo de petabyte”, algo como uso real do sistema. Pelo que imagino, calculando com o tamanho e a quantidade de nós deste texto, o cluster antigo daria 708 TB e o novo setup algo em torno de 648 TB, incluindo margem de crescimento.

• Armazenamento em si é muito barato. Mas não entendi a parte do setup de treinamento e rede. Em outro comentário, disseram que as GPUs não ficam todas em um só lugar; nesse caso, os dados de treinamento teriam de trafegar entre vários sites a apenas 100 Gbps. Fico preocupado se isso não viraria gargalo no processo de pré-treinamento.

  • No momento, temos apenas um link de 100 gigas e, por enquanto, os clusters de GPU também só conseguem processar entrada e saída de dados nesse nível. Vamos aumentar tanto a largura de banda quanto o armazenamento conforme expandirmos. Como referência, temos várias 4090 no colo, e elas foram extremamente úteis para particionamento de dados e trabalhos de embedding.

• Para uma carga de trabalho desse porte, dá para conseguir cotações privadas com a AWS ou outras nuvens. No caso do S3, a partir de 0,5 PB já dá para receber proposta separada. Isso não significa necessariamente que o custo total fique menor do que operar tudo por conta própria, mas comparar o preço de varejo de um CSP com equipamento comprado no eBay + trabalho gratuito (tirando o custo de pizza) não é uma comparação completa.

  • Na AWS e em outras nuvens, o custo de egress é realmente o ponto central. Mesmo tentando negociar, eles não cedem nada nessa parte. Para treinamento de IA, fica em um nível praticamente inutilizável. A cotação da Cloudflare é uma das mais baratas entre armazenamentos gerenciados em bucket de objetos. Quando você monta seu próprio cluster, a diferença para o serviço gerenciado até diminui. Fazer sua própria infraestrutura também dá poder de negociação. Ainda assim, buckets gerenciados são exageradamente superdimensionados para armazenamento simples de pré-treinamento. O Glacier tem boa relação custo-benefício para arquivamento, mas ainda não existe um produto que se encaixe exatamente para uso em ML.

  • Em termos concretos, que tipo de acordo dá para conseguir? É possível desconto de mais de 50%?

• Foi divertido ajudar a instalar os drives. Trabalhar de verdade com esse volume de dados é uma das experiências mais empolgantes que existem :P

• Não houve menção à taxa de falha dos discos. Fico curioso sobre como as coisas estão alguns meses depois.

  • É um relato antigo, mas quando subi vários arrays de disco, já tive uma onda grande de falhas de drives. Montei o rack numa sexta à tarde e deixei um teste simples de leitura/gravação de dados rodando durante o fim de semana com um shell script, sem mexer em nada. Quando voltei na segunda, quase metade dos discos tinha morrido sem deixar log algum. Não havia como saber se foi problema no processo de striping, se quebrou no stress test, ou o quê. Era um lote com defeito de fábrica, e vários clientes da mesma empresa reclamaram. O fabricante trocou tudo, e só houve atraso para colocar em produção. Depois disso, não houve nenhuma falha por um ano.

  • A taxa de falha de discos caiu muito em comparação com 10 anos atrás. Antes eu trocava mais de 10 por semana; agora é algo raro. Acho que basta olhar as estatísticas de HDD da Backblaze.

  • Disseram que esse cluster usa drives enterprise, mas tentar economizar nisso pode sair muito caro depois. Quando usei drives usados em home server, a variação de desempenho era tão grande que não gostei.

  • Boa observação.