- O Fly.io, que executa apps perto dos usuários, adicionou suporte a GPU, permitindo posicionar inferência de IA perto da borda em vez de apenas em uma região central
- É possível anexar uma Nvidia A100 ao app para aproveitar CUDA e grande quantidade de VRAM, útil para reconhecimento de voz, segmentação de texto, resumo de artigos, geração de imagens e execução de modelos de assistência de código
- Apps GPU baseados em Ollama podem ser implantados definindo
vm.size = "a100-40gb" e a imagem ollama/ollama em fly.toml, depois usando fly apps create e fly deploy
- Em regiões com suporte a GPU, o mesmo programa pode rodar com o mesmo IP público e certificado TLS, e pode ser expandido para a região de Amsterdam com
fly scale count 2 --region ams
- A A100 40GB custa $2.50 por hora, a A100 80GB $3.50, e a L40s $2.50; com início e parada automáticos configurados, é possível evitar a cobrança por hora de GPU quando não houver requisições
Execução com GPU perto do usuário
- O Fly.io é uma nuvem capaz de executar apps full-stack ou plataformas de desenvolvimento baseadas na Fly Machines API perto dos usuários, e agora adicionou execução com GPU
- A GPU do Fly.io conecta uma Nvidia A100 ao app para permitir o uso de CUDA e de mais VRAM do que uma 4090 local
- As tarefas de IA/ML aplicáveis incluem:
Implantação de app GPU com Ollama
- O objetivo do Fly.io é permitir que usuários implantem seus modelos preferidos e código próprio sobre o backbone em nuvem do Fly.io
- Apps GPU baseados em Ollama podem ser executados apenas com a configuração do
fly.toml e comandos de deploy
app = "sandwich_ai"primary_region = "ord"vm.size = "a100-40gb"- A imagem de build é
ollama/ollama
- Monta um volume de
100gb em /root/.ollama
- O comando de execução é o seguinte:
fly apps create sandwich_ai && fly deploy
Inferência perto da região do usuário
- O ponto que o Fly.io destaca não é apenas oferecer GPU, mas sim inferência na borda
- O app de exemplo funciona assim: o usuário informa os ingredientes que tem na cozinha e recebe uma receita de sanduíche
- Se implantado com
primary_region = "ord", usuários perto de Chicago podem receber a receita de sanduíche rapidamente
- Usuários fora de Chicago, por exemplo em Amsterdam, podem levar mais tempo porque a requisição precisa cruzar o Atlântico
- Em regiões com suporte a GPU, o mesmo programa pode rodar com o mesmo endereço IP público e o mesmo certificado TLS
- A expansão para Amsterdam é feita com o comando abaixo
fly scale count 2 --region ams
GPU usada só quando há requisição
- GPUs são dispositivos poderosos de processamento paralelo, mas não são baratas; para apps pequenos, pode ser vantajoso pagar apenas quando houver requisições de usuários
- É possível configurar início automático e parada automática na seção
services do fly.toml
[[services]]
internal_port = 8080
protocol = "tcp"
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 0
auto_stop_machines = true e auto_start_machines = true fazem a máquina parar quando não há requisições e iniciar novamente quando necessário- Com
min_machines_running = 0, não há custo de hora de GPU quando não houver pedidos de receita de sanduíche
GPUs oferecidas e recursos padrão
- GPUs estão disponíveis em várias regiões dos EUA e da UE, além de Sydney
- Os alvos de implantação e preços são os seguintes
- Apps implantados em GPU usam por padrão 8 núcleos de CPU AMD EPYC
- É possível anexar volumes de até 500GB
- Também podem ser oferecidos descontos para instâncias reservadas e hosts dedicados
1 comentários
Opiniões no Hacker News
Tenho dúvidas se a Fly realmente acertou o básico. Ao usá-la em produção de verdade, foi decepcionante ver que o suporte nem conseguia consultar problemas da plataforma interna, e as mensagens de erro eram vagas ou simplesmente inexistentes.
Pode parecer atraente para quem tem medo de Kubernetes ou não o conhece bem, mas, usando a Fly, acabei sentindo falta do Kubernetes.
watch -n 2 curldurante o deploy; aconteceu com todas as estratégias documentadas, incluindo blue-green.Na pior das hipóteses, eu esperava que apenas as conexões existentes fossem encerradas antecipadamente e que novas conexões não caíssem; na melhor, que houvesse uma espera elegante até as conexões existentes terminarem. Na prática, porém, foi sempre uma transição com downtime total. Pensando na topologia de rede mostrada no blog, fico com a impressão de que isso nem poderia ter sido implementado corretamente desde o início.
Raramente faço comentários negativos sobre serviços, mas, mesmo enviando provas em vídeo, o suporte reagiu como se nós é que estivéssemos fazendo algo estranho, o que, para uma empresa de infraestrutura, incomodou bastante. Agora não recomendo para nada além de apps de brinquedo.
Também já construí um sistema de deploy bem grande para Kubernetes, então isso não é falta de conhecimento sobre Kubernetes. Existe claramente espaço para um deploy no estilo Heroku bem feito, mas ninguém está fazendo isso direito, ou então os recursos de computação são absurdamente limitados ou caros.
Poderia falar mais, como DBs não gerenciados embalados como se fossem gerenciados, downtimes aleatórios etc., mas saí alguns meses atrás porque não é um serviço pronto para produção.
No começo eu estava muito empolgado com a Fly e até construí um orquestrador inteiro em cima do Fly Machines, mas houve uma falha de vários dias, e também levou dias para receber uma resposta.
Kubernetes pode ser complexo, mas essa complexidade ao menos é controlável e já é um caminho bastante comprovado.
Sou o autor do post e responsável por relações com desenvolvedores na Fly.io. Se houver perguntas, posso responder. As GPUs foram lançadas oficialmente ontem e, se o deus dos algoritmos antifraude permitir, você pode experimentar à vontade.
Na verdade, me surpreendeu que o texto explicando o que uma “GPU” realmente é não tenha feito tanto sucesso aqui: https://fly.io/blog/what-are-these-gpus-really/
A vantagem do nó de fabricação e o acesso prioritário a SoC/HBM vão se manter por tempo suficiente para o software acompanhar? Equipamentos Metal avançados parecem caros, mas a comparação muda quando se olha para algo com 64 GB+ de largura de banda de memória bastante alta e unidades vetoriais FP dedicadas em relação à NVIDIA.
Se uma plataforma como
fly.iopermitir mover workloads de inferência para dentro e para fora dos dispositivos, isso pode dar muita liberdade a aplicações com forte componente de edge.Em um fluxo de trabalho de segmentação de imagens médicas, cada arquivo leva cerca de 5 minutos.
Pelo que sei, a Fly usa Firecracker para VMs. Acompanhei o Firecracker por um bom tempo e também o usei em projetos, mas ele basicamente não oferece suporte a GPU e não há planos de oferecer [1].
Tenho curiosidade sobre como a Fly resolveu o suporte próprio a GPU com Firecracker. Antes, eles publicavam posts técnicos muito detalhados sobre como implementaram certas funcionalidades, então seria ótimo se no futuro saísse um texto também sobre suporte a GPU.
[1]: https://github.com/firecracker-microvm/firecracker/issues/11...
É ótimo que consiga lidar com scale down até 0. Isso é especialmente útil para sites experimentais com poucos usuários, em que é difícil justificar até o custo de um servidor pequeno.
Seria bom ter um exemplo de quanto tempo é cobrado por uma única requisição. Claro que varia, mas queria saber se são 2 segundos ou algo como “mínimo de 60 segundos por spin-up”.
Máquinas com GPU podem precisar de cerca de 30 segundos de tempo de execução para serem úteis, dependendo do tamanho dos dados que entram na memória da GPU.
Adotamos o Fly.io no começo, mas ele não estava pronto para produção. Antes de adicionar novos recursos, deveriam consertar o básico
Exige um pouco mais de configuração e é bem mais caro, mas em produção é preciso estabilidade. Não dá para deixar clientes ligando por causa de indisponibilidade do serviço
Software pode quebrar, mas a postura da Fly na resposta a incidentes é pouco profissional e imatura. Basicamente, você paga 10 vezes mais por um serviço instável que só “parece” bom
Agora uso Hetzner + Kamal, com hardware muito melhor por um quarto do custo; funciona de forma estável, o preço é previsível e não acontece de eu pagar 25% a mais no mês seguinte pelo mesmo uso
https://news.ycombinator.com/item?id=36808296
À parte o anúncio de GPUs, eu gostaria que a Fly tivesse um serviço alternativo ao S3. No momento eles sugerem um projeto GNU Affero, o que é um obstáculo para empresas
Se eu tiver que sair da Fly por causa do armazenamento de ativos de usuários, fica difícil usar a Fly no próximo projeto. É uma pena, porque gosto da simplicidade, do custo-benefício e da VPN integrada
Também discutido aqui: https://benhoyt.com/writings/flyio-and-tigris/ e aqui: https://news.ycombinator.com/item?id=39360870
https://fly.io/docs/reference/tigris/
Se você acessa um serviço como o S3 apenas por uma API HTTPS, isso não faz com que seu código fique sujeito à AGPL
Fico curioso para saber qual é o mercado-alvo desse serviço. Seriam apps pequenos e não validados que precisam rodar algum modelo de IA, mas não usam ou não podem usar as inúmeras startups em guerra de preços que oferecem hospedagem de modelos open source?
Depois de operar muitos modelos e muito hardware diretamente, entendo a vontade de controlar tudo até o metal. Só queria saber para quem isso é voltado
Na prática, como a própria inferência demora, talvez essa diferença não importe tanto
Ter a computação de GPU no mesmo datacenter, ou pelo menos no mesmo provedor de nuvem, pode ser uma grande vantagem. Não foi raro ver A100 esgotadas em vários provedores, e passei por isso várias vezes até em grandes provedores. Se você não estiver preso a uma região específica, isso é menos problemático
Nem todos os provedores oferecem um modelo utilizável de scale-down para 0 sob demanda. Não sei quão bem isso funcionará na Fly no longo prazo, mas pode ser mais uma vantagem
Startups em guerra de preços tendem a não durar muito; a dinâmica é mais próxima de apenas uma fração minúscula entre 100 sobreviver
Se você já usa a Fly e só vai ter algumas avaliações de demos técnicos privados, GPUs na Fly podem se tornar a escolha padrão, sem muita reflexão. Claro, talvez seja mais comum usar serviços da Hugging Face
Muitas empresas não conseguem operar hardware próprio por vários motivos e, na melhor das hipóteses, alugam racks em outro datacenter, o que nem sempre tem valor para casos de uso pequenos. Há casos em que se precisa de uma A100, mas só para rodar algo raramente, como análises semanais; se for menos de 1 hora por semana, um serviço em guerra de preços pode não ser tão atraente
O exemplo de receitas, ou qualquer caso de uso de LLM, parece um péssimo exemplo para enfatizar inferência na edge, porque alguns centenas de ms a mais de latência de ida e volta não fazem muita diferença
Mas parece ser uma área com alto potencial de abuso, então ninguém ainda quer se envolver. Provavelmente será abordado no próximo texto; nesse caso, teriam que criar um GPT online próprio no estilo Perplexity. Por enquanto, parece que fizeram uma introdução propositalmente comum para ver se surgem outras ideias
Fico curioso para saber se alguém já testou o desempenho. À primeira vista, parece bem caro. Por exemplo, em comparação com uma máquina CPU da Hetzner
Até mesmo uma H100 pode ser obtida por US$ 2,24 por hora, mais barato que esse preço
Então parece um tanto caro, mas talvez seja porque a demanda dos clientes é alta e a oferta é limitada
Estou usando o plano gratuito da Fly.io para rodar o Uptime Kuma e monitorar uptime. Funciona extremamente bem, estou muito satisfeito