HN divulgado: conexão de GPU virtual via TCP

• Ao contrário de CPU, armazenamento, rede e memória, a GPU ainda não foi virtualizada como um recurso abundante, e a Thunder Compute quer resolver isso na camada de sistema
• O foco em ampliar a oferta não está apenas em fabricar mais chips, mas em usar melhor, via software, as GPUs que já foram implantadas
• Enquanto as otimizações existentes ficaram na camada de workload, como batching de inferência ou enfileiramento de jobs de treinamento, a virtualização de GPU mira uma área de sistema relativamente menos explorada
• É possível usar uma NVIDIA H100 a partir de US$ 1,38 por hora no VS Code, CLI e navegador, com promessa de 80% de economia frente à AWS, sem contrato, sem custo de egress e com armazenamento escalável
• Após 4 anos em modo stealth, a empresa criou um protótipo de pesquisa e quer implantar melhorias de capacidade de GPU em datacenters por meio de sua própria nuvem e de parceiros corporativos

---

Melhorando a baixa utilização com virtualização de GPU

• A Thunder Compute avalia que vários recursos escassos da computação acabaram se tornando abundantes, mas que as GPUs ainda não passaram pela mesma transição
• Tornar GPUs abundantes não depende apenas de produzir mais chips, mas também de software para usar melhor os chips já implantados
• Hoje, as GPUs muitas vezes não são plenamente aproveitadas, e as soluções existentes se concentram principalmente na camada de workload
  • Batching de requisições de inferência
  • Enfileiramento de jobs de treinamento em várias frotas de servidores
• CPU, armazenamento, rede e memória já têm virtualização amplamente difundida, mas as GPUs ainda não alcançaram o mesmo nível
• Tratar essa lacuna na camada de sistema é a abordagem central da Thunder Compute

Abordagem do produto e plano de implantação

• A Thunder Compute se apresenta como um laboratório de sistemas com foco comercial, buscando levar pesquisas recentes em virtualização de GPU para ambientes de produção
• A equipe é descrita como formada por especialistas em infraestrutura e pesquisadores de sistemas vindos de Citadel Securities, Aquatic e AWS
• Após 4 anos em modo stealth, criou um protótipo de pesquisa e agora está implantando os resultados por meio de sua própria nuvem e de parceiros corporativos
• Segundo a descrição do produto, uma NVIDIA H100 pode ser usada a partir de US$ 1,38 por hora
  • Acesso por VS Code, CLI e navegador
  • Promessa de 80% de economia em relação à AWS
  • Sem contrato, sem custo de egress e com armazenamento escalável
• O objetivo é melhorar gradualmente a capacidade de GPU dos datacenters

[GN⁺]

Opiniões no Hacker News

• Bem interessante. Um tempo atrás, precisei de GPU-over-IP apenas para transcodificação de vídeo
  Meu servidor de homelab tinha uma GPU AMD fraca, que derrubava o kernel sempre que eu tentava codificar vídeo, enquanto meu PC de jogos tinha uma NVIDIA RTX 3080. Então criei https://github.com/steelbrain/ffmpeg-over-ip, rodei o servidor na máquina Windows e o cliente no servidor de mídia (Plex, Emby, Jellyfin etc.), e funcionou perfeitamente

  • Se você ainda não publicou isso como Show HN, seria bom considerar
    https://gist.github.com/tzmartin/88abb7ef63e41e27c2ec9a5ce5d...
    https://news.ycombinator.com/showhn.html
    https://news.ycombinator.com/item?id=22336638
  • Pelo título, era mais ou menos isso que eu esperava. Fiquei decepcionado porque a submissão em si era um serviço de nuvem pago, não uma ferramenta genérica útil; como sempre, o conteúdo de verdade estava nos comentários
    Também fico curioso se há usos para GPU-over-network além de codificação de vídeo. Com a latência maior, imagino que machine learning ou tarefas graficamente intensivas fiquem difíceis
  • Interessante. Fico curioso se também suporta conversões com múltiplos arquivos, como quando são gerados vários arquivos em fatias de tempo no HLS

• Se isso opera na fronteira CPU/GPU, fico confuso se não haveria um enorme gargalo de I/O em datasets que não cabem na VRAM
  Posso estar entendendo errado como funciona, mas, se ele intercepta a entrada/saída da GPU, isso significaria ter que transmitir o dataset inteiro para a máquina remota a cada época, o que soa desperdício

  • Seu entendimento do sistema está correto. Implementamos várias otimizações para reduzir o custo de I/O e torná-lo prático
    O desempenho de inferência do BERT pode ser visto aqui: https://youtu.be/qsOBFQZtsFM?t=69
    Treinamento tem mais overhead do que inferência, e estamos implementando otimizações adicionais para chegar mais perto do desempenho nativo

• Para quem está curioso sobre como isso realmente funciona, parece ser uma arquitetura que injeta uma biblioteca no processo, faz hooking destas funções[1] e as encaminha para o serviço
  [1] https://pastebin.com/raw/kCYmXr5A

  • Fico curioso para saber como descobriram que essas funções foram hookadas. Imagino que exista alguma flag de ld/ldd que indique quais símbolos estão sendo rebinding
    Também achei que, para um símbolo ser rebinding, ele precisaria ser um símbolo fraco, mas a NVIDIA dificilmente exporia símbolos fracos; então suponho que isso seja, na prática, uma abordagem de LD_PRELOAD
  • Eu esperava que houvesse algum método mágico para encaminhar o dispositivo PCIe inteiro

• Interessante, mas o que me interessa mais é self-hosting. Já tenho várias GPUs; algumas estão rodando e outras ficam ociosas
  Gostaria de saber se existe uma opção de self-hosting para usar as GPUs que já possuo

  • Ainda não oferecemos suporte a self-hosting, mas parece que a mesma tecnologia se encaixaria bem
    Benefícios como agendamento eficiente de jobs, compartilhamento de GPU e facilidade de uso também se aplicam diretamente a ambientes self-hosted. Estamos bastante abertos a essa possibilidade no futuro
  • Se você quer uma experiência de uso parecida com PyTorch sobre suas próprias GPUs, sejam equipamentos fixos ou cloud, veja https://github.com/run-house/runhouse
  • Se você quer uma boa experiência de desenvolvimento usando suas próprias GPUs ou contas de cloud, dê uma olhada no SkyPilot
  • Com serviços como Akash Network, você pode alugar sua GPU na nuvem, e também pode alugar GPUs em thundercompute.com. É algo próximo de um caminho de administrador operando quase como self-hosting

• Não entendi muito bem. Você pode simplesmente subir a instância GPU que quiser no ECS; não sei por que subiria uma instância no ECS para usar as GPUs de vocês a partir do ECS
  Separadamente, também não vejo por que alguém iria querer usar um Nitro meia-boca em vez do Nitro de verdade

  • Bom ponto. Há algumas vantagens
    Se você está desenvolvendo algo que precisa de GPU, normalmente precisa pagar por todo o tempo em que a instância fica ligada. Com o Thunder, você paga apenas enquanto está realmente usando a GPU. Quando está rodando só código de CPU, não há custo de tempo de GPU. A alternativa é ligar e desligar instâncias manualmente, o que pode ser trabalhoso
    Também é fácil escalar o tipo e a quantidade de GPUs que você usa. Por exemplo, se estiver desenvolvendo em uma instância T4 barata e quiser rodar um job completo de treinamento de deep learning em 8 A100, pode executar um único comando e rodar imediatamente nas GPUs mais fortes, sem trocar de instância nem reconfigurar o ambiente
  • Do ponto de vista do sistema, parece mais transparente. Por exemplo, se você estiver usando um aplicativo GUI que precisa de aceleração por GPU (Matlab, SolidWorks, Blender) em um thin client, isso seria possível sem configurar ECS
    Você pode desenvolver sem GPU e, de repente, anexar uma GPU ao rodar uma simulação, e imagino que seja muito mais barato que a AWS. Essencialmente, parece resolver de uma forma mais genérica o problema que o Ray (https://www.ray.io/) resolve. Também pode permitir compartilhamento de GPU mais granular, como meia GPU, então estou bem empolgado

• Como há bastante interesse nisso, decidimos abrir instâncias T4 gratuitamente. Seria ótimo se vocês testassem e contassem o que acharam

  • Fico curioso sobre os preços de A100 e H100

• Legal. Fico curioso se daria para fazê-lo funcionar também com MIG ou vGPU

  • Não testamos com MIG ou vGPU, mas, como essencialmente são formas de particionar fisicamente a GPU, acho que funcionaria
    Um dos nossos principais objetivos no futuro próximo é permitir compartilhamento de GPU. Como vamos permitir que os usuários usem toda a memória da GPU, em vez de limitá-los a uma parte da memória, isso pode ser melhor que MIG ou vGPU

• Fico curioso para saber como é usar isso de verdade com throughput significativo. Dá para usar em quebra de hashes?
  Sempre que penso em uma GPU virtual pela rede, me vem à mente uma botnet. Especialmente o trecho em https://www.hpcwire.com/2012/12/06/gpu_monster_shreds_passwo... em que “Gosney primeiro teve que convencer o professor Amnon Barak, cofundador do Mosix, de que não estava ‘tentando transformar o mundo em uma botnet gigante’”

  • É um experimento mental interessante, mas, na prática, nosso sistema não tem GPUs distribuídas, então ele se parece mais com a AWS do que com uma botnet
    Essa tecnologia tem aplicações interessantes para criar clusters muito flexíveis dentro de datacenters, e estamos explorando essa parte

• Os engenheiros originais da SGI que desenvolveram o glx projetaram tudo com muito cuidado para usar os mecanismos do X11 no transporte de GPU, então era bem simples enviar um stream GL pela rede e renderizar na minha placa de vídeo
  Era algo como “rodar no supercomputador no fim do corredor e renderizar na workstation”. O desenvolvimento recente de drivers parece não levar isso em conta, então geralmente isso já não é mais possível. Não sei o quanto era útil na prática. Normalmente, se você tinha uma boa placa de vídeo, também tinha uma boa CPU. Ainda assim, era divertido brincar com isso, e havia algo curiosamente atraente em um programa rodando na sala de máquinas obter gráficos acelerados. Uma vez consegui rodar glquake desse jeito

• O simples fato de isso ser possível é impressionante, mas fico curioso sobre o que acontece quando a conexão de rede cai ou não é 100% estável
  Pela minha experiência, drivers não reagem bem quando uma GPU local se comporta de forma minimamente estranha