- A CommaAI realiza todo o treinamento de modelos e o processamento de dados em seu próprio datacenter, operando diretamente uma infraestrutura de cerca de US$ 5 milhões
- A dependência da nuvem pode levar a aumento de custos e perda de controle, enquanto operar seu próprio ambiente de computação possibilita melhor qualidade de engenharia e redução de custos
- O datacenter é composto por cerca de 450 kW de energia, 600 GPUs, 4 PB de armazenamento SSD e uma estrutura simples de refrigeração e rede
- A stack de software foi projetada com Ubuntu + Salt, armazenamento minikeyvalue (mkv), agendador Slurm, treinamento distribuído com PyTorch e computação distribuída com miniray
- Com essa arquitetura, a comma.ai automatiza completamente o treinamento de modelos de direção autônoma e alcança uma redução de custos de cerca de 5x em comparação com a nuvem
Por que operar um datacenter próprio
- Depender da nuvem gera aumento de custos e lock-in do fornecedor
- As empresas de nuvem são projetadas para tornar o onboarding fácil, mas o offboarding difícil
- Com uso contínuo, é fácil ficar preso a uma estrutura de custos elevada
- Operar sua própria infraestrutura de computação incentiva autonomia tecnológica e uma cultura de engenharia mais eficiente
- A nuvem exige gestão centrada em APIs e sistemas de cobrança, enquanto um datacenter exige resolver problemas técnicos reais centrados em energia, computação e largura de banda
- Mesmo do ponto de vista de engenharia de ML, restrições de recursos induzem otimização de código e melhorias fundamentais
- Na nuvem, costuma-se resolver o problema apenas aumentando o orçamento; em infraestrutura própria, melhorar o desempenho é obrigatório
- Em termos de custo, a comma.ai investiu cerca de US$ 5 milhões; calcula-se que executar o mesmo trabalho na nuvem exigiria mais de US$ 25 milhões
Componentes do datacenter
-
Energia
- Uso máximo de 450 kW, com custo de energia em 2025 de US$ 540.112
- Em San Diego, a tarifa de energia é de US$ 0,40/kWh, cerca de 3 vezes a média mundial
- Há menção a um plano futuro de geração própria de energia
-
Refrigeração
- Uso de refrigeração com ar externo, mais eficiente em consumo de energia do que sistemas CRAC
- Circulação de ar com 2 ventiladores de admissão e 2 de exaustão de 48 polegadas
- Loop de controle PID para ajustar automaticamente temperatura e umidade (mantida em <45%)
- O consumo de energia fica na casa de algumas dezenas de kW
-
Servidores e armazenamento
- Composto por 75 TinyBox Pro (total de 600 GPUs), fabricados internamente
- Cada equipamento tem 2 CPUs + 8 GPUs e é usado para treinamento e computação geral
- A fabricação própria facilita a manutenção
- O armazenamento é baseado em Dell R630/R730, totalizando 4 PB de SSD
- Estrutura sem redundância (non-redundant), com 20 Gbps de velocidade de leitura por nó
- A rede é composta por 3 switches Z9264F de 100 Gbps e 2 switches Infiniband
Infraestrutura de software
-
Configuração básica
- Todos os servidores usam Ubuntu + boot por PXE e são gerenciados com Salt
- Estrutura com mestre único, mantendo 99% de disponibilidade
-
Armazenamento distribuído — minikeyvalue (mkv)
- Os dados de direção para treinamento ficam armazenados em 3 PB de armazenamento sem redundância
- 1 TB/s de velocidade de leitura, permitindo treinamento direto sem cache
- Um array de 300 TB para cache e um array com armazenamento redundante guardam modelos e métricas
- Cada array é gerenciado por um servidor mestre único
-
Gerenciamento de tarefas — Slurm
- Faz o agendamento de jobs de treinamento em PyTorch e jobs distribuídos com miniray
-
Treinamento distribuído — PyTorch + FSDP
- Opera duas partições de treinamento conectadas por rede Infiniband
- Um framework de treinamento próprio automatiza o loop de treinamento
- Há um serviço de rastreamento de experimentos de modelos
-
Computação distribuída — miniray
- Agendador de tarefas open source e leve, executa código Python em máquinas ociosas
- Mais simples que o Dask, gerencia tarefas com um servidor central Redis
- Workers com GPU executam inferência de modelos com Triton Inference Server
- É possível escalar em paralelo para centenas de máquinas
- Ex.: o recorde do Controls Challenge foi alcançado com 1 hora de uso do datacenter
-
Gerenciamento de código — monorepo baseado em NFS
- Toda a base de código tem menos de 3 GB e é replicada em todas as workstations
- Ao iniciar um trabalho, o código local e os pacotes são sincronizados, concluindo em menos de 2 segundos
- Isso garante que todos os jobs distribuídos sejam executados com o mesmo código e ambiente
Pipeline integrado de treinamento
- Na comma, a tarefa mais complexa é treinar o modelo de direção no modo on-policy
- Para esse treinamento, é necessário executar uma direção simulada com os pesos mais recentes do modelo para gerar dados de treinamento
- Todo o pipeline pode ser executado com um único comando como o abaixo
./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
- Para executar esse treinamento, toda a infraestrutura descrita acima é utilizada
- É apenas um comando simples, mas ele coordena diversos componentes
Conclusão
- A comma.ai alcança redução de custos e autonomia tecnológica ao operar seu próprio datacenter
- Com a mesma abordagem, empresas ou indivíduos também podem construir sua própria infraestrutura
3 comentários
A memória está cara!
kkkkkkkkkkkkkkkkkkkk
Comentários do Hacker News
No nosso setor, propriedade vs. nuvem são os dois extremos de um espectro
① A nuvem exige pouco investimento inicial (capex) e menos equipe, mas tem custos operacionais (opex) altos e voláteis
② Managed Private Cloud é o que fazemos: gerenciamos com base em open source e sai cerca de 50% mais barato que AWS
③ Bare metal alugado é um modelo em que alguém financia o hardware por você, e fica 90% mais barato que AWS
④ Comprar diretamente e fazer colocation é o mais barato se você tiver capacidade técnica e escala
Empresas como a Hetzner operam com ROI de 3 anos, e as opções 3 e 4 são adequadas para empresas maiores ou cujo core é infraestrutura
Para startups, a opção 1 é realista; para PMEs, a 2 (lithus.eu)
O problema é que a estrutura de custos da nuvem não vem só do preço do hardware, mas do incentivo a arquiteturas complexas, o que aumenta a ineficiência
Os “serviços gerenciados” da AWS são estruturados de forma que, quanto mais o usuário melhora a eficiência dos servidores, menor é a receita da AWS
Se você simplesmente rodar 4 servidores Java sobre EC2 com um banco replicado, tudo fica muito mais eficiente
No fim, as cobranças absurdas da AWS aparecem quando se abusa de inúmeros serviços
(derek@ da Carolina Cloud) Nós também preferimos o modelo (4), mas usuários com pouca capacidade técnica acabam ficando nas opções 1 a 3 e presos à estrutura cara da nuvem pública
Dizem que é “baseado em uso”, mas na prática há taxas fixas e consumo mínimo, então sai bem mais caro (carolinacloud.io)
Hetzner é uma opção atraente
Dá trabalho ter que gerenciar serviços como Postgres ou VPN por conta própria, mas acima de US$ 10 mil a 15 mil por mês passa a valer mais a pena do que AWS
Há riscos, mas compensa assumi-los
Eu alugo um servidor bare metal de US$ 500 por mês, e o tempo de administração é de só algumas horas por ano
Talvez seja porque minhas necessidades são simples, mas acho muito melhor do que uma nuvem excessivamente complexa
Migrei para colocation há 2 anos e agora tenho mais capacidade com 30% do custo
Também existe o benefício das quedas tardias de preço de RAM/armazenamento
Só é preciso prestar um pouco mais de atenção à gestão de compliance
Antigamente, isso era chamado simplesmente de data center
É um conceito que já existia antes da nuvem e, no fim, é a repetição de possuir vs. alugar e centralização vs. descentralização
Quando uma empresa escolhe apenas um dos extremos, acaba reencontrando os mesmos problemas
O interessante é que a nuvem era atraente para o financeiro por causa do efeito de redução tributária
Mas, com legislações recentes (OBB) permitindo lançar CapEx como despesa, surgiu um vento de retorno ao on-prem
Então por que não surgem alternativas de nuvem com preço competitivo?
AWS e Azure dominam o mercado e não têm incentivo para reduzir preços, e o Google traz um risco alto de descontinuação de serviços
Antes da nuvem, a equipe interna de infraestrutura era o gargalo
A nuvem padronizou isso e simplificou tudo com um sistema único de cobrança
Além disso, fora dos EUA a aquisição de servidores era lenta, então a vantagem de velocidade da nuvem era grande
Data centers on-prem têm alto custo operacional e consomem muitos recursos de engenharia
Por isso esse debate continua se repetindo
A verdadeira inovação da nuvem foi “tornar claro o custo por serviço”
Em vez de “para quem eu preciso pedir isso?”, tudo passou a ser acessível via API
Esse contexto está bem resumido neste texto
Mesmo em regiões como San Diego, onde controlar a temperatura é fácil, resfriamento com ar externo é arriscado
Umidade e poluentes degradam os servidores rapidamente
Em vez disso, métodos como coolers com roda entálpica (kyotocooling) são eficientes e consomem pouca energia em relação à eficiência térmica
É preciso cuidado, porque resfriamento com ar externo aumenta muito o risco de reduzir a vida útil dos equipamentos
Também há casos de bons resultados com filtragem e mantendo a umidade abaixo de 45%
Eu não sabia que precisava me preocupar com esse tipo de coisa
Por isso eu simplesmente uso nuvem — dá para evitar esse tipo de “risco desconhecido”
O realista é combinar on-prem e nuvem
A infraestrutura principal fica em uma nuvem confiável, enquanto coisas como jobs do Slurm rodam em servidores próprios
Colocation continua sendo uma opção válida, e HPC para pesquisa também pode valer a pena
Na Noruega, até empresas privadas podem usar HPC de pesquisa pagando por isso
Eu operava server farms em duas regiões da Itália, gerenciadas por 5 pessoas, mantendo quase 100% de uptime
Com € 800 mil por ano, economizamos € 7 a 8 milhões em custos de nuvem
Muitos desenvolvedores acham, por engano, que não conseguem fazer hosting
Na prática é mais fácil do que parece, e resolver os problemas técnicos também é divertido
Se você alugar espaço em lugares como Equinix ou Global Switch, eles cuidam de energia, refrigeração, cabeamento etc.
Também é totalmente possível manter suas próprias salas de servidores em duas regiões
Ainda usamos Azure para serviços voltados ao usuário
Serviços web que não precisam de GPU são mais eficientes na nuvem
E o GitHub continua sendo usado como um serviço confiável
(em tom de brincadeira) Já tivemos um daemon do Postgres se enrolando num pool do Slurm e o Rust saiu disparando
No fim estabilizamos, mas do ponto de vista de um engenheiro de hardware, o mundo do software é caótico
No início do projeto, comece na AWS com US$ 250 por mês; quando chegar a US$ 30 mil por mês, migre para colocation
O ponto central é a capacidade de calcular custos — um bom engenheiro precisa conseguir usar isso para argumentar com a diretoria
Mas, além das contas, também é preciso pensar em que tipo de talento atrair e que tipo de negócio você quer construir
Se a empresa treina modelos de ML, talvez infraestrutura própria seja mais adequada
Mas, na maioria das empresas, os engenheiros não conseguem participar da escolha da plataforma
Em 99,999999% dos casos, a diretoria já decidiu e só comunica depois
No começo da carreira, nuvem parecia a escolha óbvia, mas agora on-prem voltou à moda
Daqui a 10 anos, talvez o movimento se inverta de novo
Pela minha experiência, as equipes que defendiam on-prem sempre subestimavam o desgaste da manutenção
Em lugares como startups, onde é preciso desenvolver rápido, isso acaba atrapalhando
Já em empresas que entraram em modo de manutenção, on-prem era eficiente
Conforme a gente envelhece, “terminar rápido e dentro do orçamento” passa a importar mais, e o apelo de operar a própria infraestrutura diminui
Desta vez, vejo esse movimento não como um simples ciclo tecnológico, mas como uma reação a uma sociedade em que nada pode ser possuído
Música, casa, carro — tudo virou assinatura, e as empresas também querem recuperar a soberania computacional
Esse tipo de ciclo sempre existiu
Mainframe → PC → sala de servidores → nuvem → edge computing é a repetição de centralização ↔ descentralização
No fim, quando a tecnologia e as prioridades mudam, tudo volta
Quando alguém voltar a dizer que “a rede é o computador”, é porque demos mais uma volta completa
(brincadeira) O próximo estágio talvez seja o espaço (Skynet)
A maioria das empresas evita on-prem por gestão de risco
Empresas boas concentram risco na sua competência central
A decisão não deve ser tomada só pelo custo, mas pelo custo ajustado ao risco
Mas hoje em dia fico em dúvida se as empresas ainda têm capacidade de avaliar esse risco com precisão
Afinal, competitividade de preço também é um elemento de diferenciação
O ponto principal é focar no negócio principal
Se isso não ajuda a vender melhor um produto que já vende mal, não vale desperdiçar tempo com data center
A única exceção é quando a própria infraestrutura é a vantagem competitiva do produto, como no caso do Google
No fim, na maioria dos casos, é uma disputa em que Opex vence Capex
A verdadeira vantagem do on-prem é liberdade, controle e privacidade
Não é apenas uma questão de dinheiro; é como a diferença entre possuir uma casa e alugá-la
O dogma estilo MBA dos anos 2010 era “leve tudo para a nuvem”
Transferir risco e custo para terceiros era visto como a resposta certa
Mas, na prática, nosso data center era muito mais barato, e os reajustes de assinaturas de software foram muito maiores do que os do hardware
Mas, considerando custo de pessoal e operação, comparar apenas custo bruto não faz sentido
Um único tornado pode acabar com a empresa, então no fim a decisão precisa ser tomada com base no valor em relação ao risco