Fly.io agora tem GPUs
A Fly.io introduziu máquinas virtuais com GPU e cobrança por escala a zero, com o objetivo de facilitar a execução de workloads de IA sob demanda junto aos apps já hospedados na Fly. Os comentaristas questionam se o preço e os custos de cold start (carregamento de modelos, imagens grandes, volumes) são competitivos com alternativas como DigitalOcean, Runpod e Vast.ai, e debatem o quão útil realmente é a inferência em GPU “na edge” para workloads típicos de LLM e imagem. Uma preocupação recorrente é a maturidade da confiabilidade e do suporte da Fly.io para uso em produção, embora alguns usuários relatem experiências tranquilas e apontem recursos complementares como armazenamento compatível com S3 em desenvolvimento e controle flexível do ciclo de vida das VMs.
Preços e Concorrência
- Muitos consideram os preços de GPU da Fly altos em comparação com alguns concorrentes (DigitalOcean, AWS, várias startups de GPU de “race-to-zero”), especialmente sem compromissos de longo prazo.
- Outros observam que a oferta de GPU sob demanda é limitada em todo lugar; preços de manchete “mais baratos” muitas vezes exigem compromissos de vários anos ou, na prática, não estão disponíveis.
- Alguns comparam os custos de forma favorável com plataformas como Modal e Replicate, स्वागतando mais concorrência em inferência hospedada.
Desempenho, Cold Starts e Carregamento de Modelos
- O tempo de inicialização é menos influenciado pelo boot da VM e mais pelas imagens de GPU e pelos pesos do modelo.
- Imagens base grandes (1–3+ GB) e o download de arquivos de modelo podem adicionar 30–120 segundos; carregar modelos de vários GB na VRAM é um fator importante.
- Pesos armazenados em volumes NVMe locais podem ser reutilizados, reduzindo downloads repetidos; armazenamento remoto/de estilo de rede para modelos é considerado uma má ideia por vários comentaristas.
Escalonar para Zero e Comportamento de “Keep Warm”
- A cobrança começa quando uma máquina inicializa e termina quando ela para, sem mínimo imposto.
- As máquinas são escaladas para baixo ao sair com código 0 sob a política correta de reinicialização; “keep warm” é implementado no código do usuário por meio de saída atrasada ou lógica personalizada.
- Opções de runtime como sinais de kill e timeouts dão algum controle sobre o comportamento de desligamento.
Casos de Uso-Alvo e Mercado
- Os usuários pretendidos incluem apps existentes da Fly que precisam de GPUs, pessoas construindo plataformas de hosting/IA e workloads que se beneficiam de rajadas ocasionais de GPU e da economia de escala para zero.
- Alguns questionam o tamanho do mercado de “precisa de GPU mas também precisa de scale-to-zero” e se a inferência em GPU na edge difere de forma significativa da inferência padrão em datacenter.
Infraestrutura e Virtualização
- VMs com GPU usam Cloud Hypervisor (não Firecracker) com PCI passthrough, não vGPU.
- Operacionalmente, Cloud Hypervisor e Firecracker são descritos como semelhantes do ponto de vista da Fly.
Confiabilidade e Preocupações com Suporte
- O tópico traz forte discordância: alguns relatam uso tranquilo por vários meses ou anos; outros descrevem a Fly como “não pronta para produção”, com quedas, deploys instáveis, máquinas que não sobem e suporte fraco ou apenas via fórum.
- A própria comunicação da Fly enfatiza que sua oferta de Postgres não é totalmente gerenciada; alguns usuários ficaram surpresos e consideram isso uma desvantagem.
Storage / Substituição de S3
- A falta de um serviço compatível com S3 de primeira classe foi um bloqueio para alguns.
- Vários comentários apontam para uma substituição de S3 em beta, integrada à Fly (Tigris / object store regional).
- O licenciamento de alternativas S3 baseadas em AGPL é controverso devido a políticas corporativas contra AGPL.