SF Compute: 512 H100s para startups por menos de US$ 2 por hora
(sfcompute.org)- Várias startups e institutos de pesquisa compram conjuntamente um cluster de GPUs para garantir em conjunto os recursos computacionais necessários para treinar modelos grandes
- Em vez de cada uma comprar individualmente N GPUs, K startups se unem para comprar juntas um cluster na escala de N×K
- Um escalonador de jobs distribui a computação de forma justa, proporcionalmente à participação de cada uma, e aloca capacidade extra quando há ociosidade
- Em vez de manter 128 A100 ocupadas o mês inteiro, é possível fazer burst com 512 A100 por uma semana, treinando modelos mais rapidamente
- Uma estrutura que oferece às startups o modelo de alocação em burst antes disponível apenas em grandes laboratórios de pesquisa como OpenAI e Deepmind
Ideia principal
- Em vez de K startups comprarem separadamente clusters com N GPUs cada, elas compram juntas um cluster com N×K GPUs
- Há um escalonador de jobs que distribui a computação de forma justa, proporcionalmente à participação de cada startup
- Quando há capacidade ociosa, o escalonador a aloca normalmente, então, com sorte, é possível usar mais computação do que a sua própria participação
- Em vez de manter 128 A100 sempre ocupadas por um mês, é possível fazer burst de até 512 A100 por uma semana para obter modelos mais rápido
- Grandes laboratórios como OpenAI e Deepmind têm clusters grandes que oferecem alocação em burst para seus pesquisadores
- Já as startups, até agora, só conseguiam garantir clusters muito pequenos com contratos de prazo muito longo, enfrentando meses de espera e precisando mantê-los sempre ocupados
- O objetivo é chegar a cerca de US$ 2,00 por H100 com alocação em burst e contratos de curto prazo
- Startups interessadas em participar podem preencher o formulário de inscrição; dúvidas podem ser enviadas para evan@roomservice.dev
Entrada, saída e expansão
- Como em uma hacker house, para sair do cluster (por exemplo, para montar seu próprio cluster), é preciso avisar com um ou dois meses de antecedência para que outra pessoa possa ocupar a vaga
- Novas startups são adicionadas ao grupo em lotes (batches), e novos H100 são incorporados ao cluster a cada poucos meses
- O mesmo vale para quem já está no grupo e quer expandir seu uso de computação
- Há consideração por um pequeno overprovisioning — por exemplo, se um amigo quiser alguns nós para um experimento pequeno, eles podem ser oferecidos imediatamente a um bom preço
- Com 10% de overprovisioning, o preço por H100 por hora sobe 10%
Finanças
- Há um caminho promissor para colocar 512 H100 em operação em 4 a 6 semanas
- Se a demanda ultrapassar isso, é possível garantir H100 adicionais em cerca de 8 semanas
- Como é possível diluir com boas condições bancárias o custo de compra do cluster, dá para manter contratos de curto prazo e alocação em burst, alcançando cerca de US$ 2,00 por H100
Infraestrutura
- Será compartilhada uma mailing list/Slack de depuração de infraestrutura, para que o grupo possa fazer perguntas quando surgirem problemas com InfiniBand e afins
- Se alguém já tiver lidado com o mesmo problema, poderá ajudar os demais
1 comentários
Opiniões no Hacker News
Torço para que dê certo. O TPU Research Cloud (TRC) tentou algo assim em 2019, e foi o que me permitiu começar
Em 2023, é difícil conseguir uma única TPU por mais de uma hora, mas naquela época era literalmente possível receber centenas delas. Eu acreditava no TRC e achava que, se ele escalasse e criasse um continente de TPUs, o problema seria resolvido, mas no fim o tempo de TPU foi diminuindo, com prioridade para pesquisadores internos. O mundo mudou a ponto de que, se hoje você propuser treinar GPT para jogar xadrez em H100s, vão rir de você
Este projeto tem um otimismo jovem que eu espero que não se perca, e no longo prazo talvez seja assim que se vença. Espero que aceitem quando alguém aparecer pedindo um pedacinho minúsculo de H100 para uma ideia maluca. Esse foi o único motivo pelo qual pude me tornar alguma coisa
E, claro, pretendemos aceitar pedidos malucos por um pedacinho de H100
A lista recente de artigos apoiados pelo TRC pode ser vista em https://sites.research.google/trc/publications/
A demanda por Cloud TPU está muito forte, então, ao usar capacidade preemptiva, interrupções podem aparecer com mais frequência, mas capacidade reservada também está disponível. Vale a pena entrar em contato com a equipe de suporte do TRC
A comparação não é totalmente equivalente, mas o TRC era muito difícil de usar, tive acesso a TPUv3 apenas uma vez, e nem houve tempo suficiente para aprender o básico. Entendi que a situação muda bastante dependendo de qual endereço de e-mail você usa e de quão famosa é sua conta no Twitter
Fico curioso se você é afiliado à academia. Se não for, não sei por que foram mais generosos comigo, e meus projetos eram, no máximo, apenas um pouco interessantes. Dito isso, é verdade que ficaram muito mais restritivos com Pods grandes do que antes
“Em vez de cada uma das K startups comprar separadamente clusters de N GPUs, elas compram juntas um cluster de NK GPUs e distribuem a computação com um escalonador de tarefas” parece, em teoria, quase igual ao modelo de provedores de nuvem como AWS e Azure
A estrutura é: “em vez de todo mundo comprar hardware fixo individualmente, nós compramos um enorme pool de hardware e fazemos compartilhamento por tempo”. Além do fato de os provedores de nuvem precisarem elevar preços para obter margem líquida, fico me perguntando se há mais alguma coisa que esteja sendo perdida a ponto de tornar necessário um projeto desses
Primeiro, investidores de nuvens públicas esperam uma certa estrutura de margens, então é difícil competir com as margens da Lambda ou da Fluidstack. Segundo, as grandes nuvens também têm certa desvantagem em networking para treinamento de grandes modelos de linguagem. Pelo que sei, só a Azure tem InfiniBand; a Oracle tem 3200 Gbps, mas não é InfiniBand, e imagino que a AWS seja parecida. Não tenho certeza sobre o GCP, mas lembro que a velocidade de rede das A100 era 100 Gbps, não 1600 Gbps. Em contraste, Lambda, Fluidstack e CoreWeave têm InfiniBand. Terceiro, a Nvidia não aloca às grandes nuvens tanto volume quanto elas gostariam
Em segundo lugar, há aqui o problema fundamental de compartilhamento de recursos. Mesmo neste projeto de Evan e do AI Grant, surge a pergunta: se uma equipe tem dinheiro para ocupar o cluster inteiro continuamente, por que impedi-la? A questão é qual é o critério exato de uso justo. Em redes, há algoritmos de compartilhamento de largura de banda como a justiça do TCP, mas eles não se encaixam bem nesse tipo de trabalho em blocos
Nos próximos meses, AWS e outras provavelmente tentarão lançar serviços de fila para alocar temporariamente blocos de computação, e é bem possível que venham com pagamento antecipado e custo alto. Pode até ser mais caro que a tarifa sob demanda
Elas mesmas fazem esse pooling e não querem entregar a relação com o cliente nem o lucro a intermediários ou clientes
Como alguém que já operou infraestrutura em várias colocation facilities na CA, se possível é melhor colocar em outro lugar. O custo de energia na Califórnia e outros custos de infraestrutura são muito mais altos do que no AZ ou em NV
Vi a frase “nenhum provedor de nuvem no mundo disponibilizaria 100 mil dólares em computação por apenas algumas semanas”; nunca comprei computação muito grande, mas achei que esse fosse o ponto central da nuvem
Fico curioso sobre como isso é diferente de https://lambdalabs.com/.
Hoje é bem fácil conseguir algumas A100/H100, e a Lambda também é excelente para esse uso. Mas é muito difícil conseguir 24 ou mais a um preço razoável, algo em torno de US$ 2 por hora. Mesmo que você só queira rodar um treinamento de 8 horas em H100, muitas vezes exigem um compromisso de mais de 6 meses.
Para corretores de GPU, preferir reservas de longo prazo faz sentido do ponto de vista de negócios, e nós também poderíamos agir assim se estivéssemos nessa posição. Mas nosso objetivo é diferente. É armar os rebeldes. Queremos permitir que alguém que não seja a BigCorp também consiga treinar modelos.
A abordagem do post original se parece mais com comprar o direito de colocar jobs na fila de trabalho de um cluster de 512 GPUs, então um job que precise de 256 GPUs não seria um problema. Porém, você pode ter que esperar atrás de alguém rodando um job em 512 GPUs.
Não sei qual é a capacidade real da Lambdalabs. Fico curioso se alguém sabe o quão fácil é subir mais de 2 ou 3 instâncias lá.
Pessoalmente, tenho muito interesse em IA e venho me envolvendo com isso há alguns anos, mas nunca vi uma escassez de GPUs como a atual. Para quem quer experimentar aprendizado de máquina como hobby, recomendo muito a vast.ai.
Para GPUs que não sejam A100/H100, há vast, TensorDock e também RunPod.
Atualmente eles revendem AWS e GCP e também têm A100, mas por enquanto uma T4 basta.
Entendo que há overhead em AWS/GCP/Azure e por que muitas empresas escolhem bare metal em produção. Pessoalmente, acho que raramente vale o tempo e o esforço, mas aceito que, em grande escala, a economia pode ser significativa.
Mas, se mesmo em treinamento de IA as clouds públicas não são competitivas para demanda em rajadas, então suas margens são muito maiores do que eu imaginava. Fico curioso sobre qual é a base de comparação para a redução de custo de 10 a 20 vezes citada no post original. É em relação à AWS?
Como alguém que gosta de SF, fico curioso se há algo interessante sobre o nome. O hardware vai ficar fisicamente em SF? Há planos de organizar meetups ou reunir clientes para interagirem?
Ainda não desaparecemos como a Xerces blue; ainda existimos.
https://en.wikipedia.org/wiki/Xerces_blue
Mas acho que uma boa parte dos clientes estará por aqui. SF provavelmente ainda é o melhor lugar para criar uma startup. Há muita gente resolvendo problemas técnicos difíceis. Em todos os lugares onde morei em SF, havia outra startup no andar de cima ou de baixo.
Organizar eventos presenciais também é uma boa ideia.
Gosto da ideia de um ativo comunitário. Será que isso pode ser o início de uma cooperativa de GPUs?
https://cloud.vast.ai/host/setup
Pode ser espaço em rack, VMs, contêineres, conectividade, qualquer coisa. Basicamente, o Twitter estaria regredindo para uma empresa de colocation do fim dos anos 90.
Para quem não percebeu: é uma piada.
Fico curioso sobre como conseguiram dinheiro para comprar 512 H100.