1 pontos por GN⁺ 2025-06-05 | 1 comentários | Compartilhar no WhatsApp
  • Com o suporte oficial (GA) a GPU no Cloud Run, ficou ainda mais fácil executar workloads de IA
  • O uso de GPU agora também está disponível em Cloud Run jobs, trazendo novas possibilidades para processamento em lote e tarefas assíncronas
  • Ambiente otimizado para trabalhos em lote em grande escala, como processamento de imagens, análise de linguagem natural e conversão de mídia

Cloud Run GPU: disponibilidade oficial e principais mudanças

Início do suporte a GPUs NVIDIA em Cloud Run jobs

  • O recurso de GPU do Cloud Run era usado anteriormente em serviços orientados a requisições, como inferência em tempo real
  • Agora, o suporte a GPU em Cloud Run jobs foi oficializado, tornando possíveis novos casos de uso
    • Fine-tuning de modelos: é possível reentreinar com facilidade modelos pré-treinados para conjuntos de dados específicos
    • Inferência de IA em lote: ideal para trabalhos em grande escala, como análise de imagens, processamento de linguagem natural e geração de recomendações
    • Processamento massivo de mídia: transcodificação de vídeo, geração de miniaturas e conversão de imagens podem ser feitos com eficiência usando GPU
  • Um Cloud Run job com GPU reduz os recursos automaticamente após a conclusão da tarefa, minimizando a carga de gerenciamento

Experiências reais das empresas que adotaram cedo

  • vivo: o Cloud Run acelerou a velocidade de iteração no desenvolvimento de aplicações de IA e reduziu significativamente os custos operacionais e de manutenção. O recurso de autoescalonamento de GPU impulsionou de forma expressiva a eficiência da adoção de IA em mercados internacionais
  • Wayfair: a GPU L4 oferece alto desempenho e preço competitivo ao mesmo tempo e, combinada com o autoescalonamento rápido do Cloud Run, proporcionou uma redução de custos de cerca de 85%
  • Midjourney: o Cloud Run GPU é extremamente útil para processamento de imagens em larga escala e, graças ao ambiente de desenvolvimento simples e direto, permite focar na inovação sem a carga de gerenciar infraestrutura. A escalabilidade de GPU facilita a análise e o processamento de milhões de imagens

Como começar e recursos

Conclusão

  • O suporte oficial a GPU no Cloud Run oferece um grande potencial de expansão para diversos workloads especializados, como IA, processamento em lote em grande escala e conversão de mídia
  • Empresas reais já comprovaram os benefícios em custo, eficiência operacional e escalabilidade
  • Com configuração simples e diversos materiais de aprendizado, qualquer pessoa pode começar facilmente a executar workloads de GPU na nuvem

1 comentários

 
GN⁺ 2025-06-05
Opiniões do Hacker News
  • Gosto muito do Google Cloud Run e costumo recomendá-lo com convicção como a melhor opção. Ainda assim, acho difícil recomendar o Cloud Run GPU. A cobrança por instância é ineficiente, e as opções de GPU também são limitadas. Como há perda de desempenho ao carregar/descarregar modelos da memória da GPU, existe a limitação de ele ser lento em ambientes serverless. Comparando o custo real, se a utilização passar de 30% do dia, a combinação de VM+GPU já sai mais econômica. (link do blog relacionado)

    • Vice-presidente do Google. Obrigado pelo feedback. Concordo, de forma geral, que na estrutura de preços atual, quando a capacidade do serviço precisa ficar quase fixa, pré-provisionar VMs é mais eficiente em custo. Por outro lado, vejo o Cloud Run GPU como ideal para ambientes com custo ocioso mínimo, inicialização muito rápida e tráfego raro e irregular, como produtos novos ou apps de IA com picos súbitos de demanda

    • Tenho a impressão de que o Cloud Run é realmente um serviço excelente. Na minha experiência, ele é muito mais fácil de lidar do que o ECS/Fargate da AWS

    • O maior problema é que não dá para confiar no uso de VMs na GCP. Todos os grandes provedores de nuvem têm esse tipo de problema. Na AWS, não dá para conseguir GPUs de 80GB sem reserva de longo prazo, e o preço é absurdo. Na GCP acontece o mesmo: caro e com baixa disponibilidade. As grandes empresas dizem que são amigáveis a startups, mas a experiência real não é essa. Nuvens mais novas como runpod, nebius e lambda oferecem um serviço muito melhor. Tenho a impressão de que as grandes nuvens estão acomodadas com a demanda fixa e cometendo um erro que vai prejudicar muito o crescimento de longo prazo ao não considerar startups

    • Tive uma experiência oposta no Cloud Run. Por causa de scale-out/reinicializações sem causa conhecida, acabei até comprando suporte pago para perguntar diretamente, mas não consegui encontrar a resposta. No fim, migrei para VMs autogerenciadas. Não sei se isso melhorou desde então

    • Sobre a opinião de que o Cloud Run é o melhor, eu gostaria de ver os números por conta própria. Para projetos de brincadeira é bom, mas no trabalho vira um poço de custos. Em um projeto, problemas de autoscaling aconteciam continuamente. scale to zero parece ótimo na teoria, mas na prática, durante o aquecimento, muitas vezes vários contêineres sobem para uma única requisição e ficam ativos por muito tempo. Também continuam cobrando por contêineres misteriosos sem uso visível de CPU ou rede. Em projetos Java ou Python, a velocidade de cold start é seriamente lenta; em Go/C++/Rust não sei dizer porque não tenho experiência

  • Além da complexidade das grandes nuvens, ainda há a preocupação com cobrança YOLO ilimitada, com o risco de o cartão de crédito ser esvaziado durante a noite. A conclusão é que vou continuar com Modal e vast.ai

    • Do ponto de vista de usuários individuais ou de projetos pequenos, não oferecer um limite de gastos (CAP) é uma grande fraqueza da GCP. No caso do Cloud Run, dá para conter custos indiretamente por meio de limites de concorrência e de número de instâncias. Ainda assim, isso não equivale a um CAP de verdade

    • Lembro de ter pago caro na AWS por esquecer de desligar uma instância, então o scale to zero e a cobrança por segundo do Cloud Run são grandes vantagens. Se a inicialização for realmente rápida, tenho certeza de que seria perfeito para minha carga de trabalho

    • No Cloud Run, dá para limitar indiretamente o custo máximo configurando o número máximo de instâncias. O “hard cap” da época do App Engine causava, na prática, o efeito colateral de o serviço simplesmente parar de funcionar no momento em que decolava (por exemplo, quando aparecia no HN). Pessoalmente, acho melhor gerenciar orçamento com base em alertas

    • Esse é exatamente o motivo de eu ter abandonado o Datadog em produção. Fico em dúvida se vale a pena para as plataformas aceitar a impressão negativa criada quando o usuário é cobrado além do esperado por engano

    • Não está claro para mim como Modal ou vast.ai evitam esse tipo de cobrança YOLO. Fico curioso se é um modelo pré-pago ou se oferecem um CAP direto

  • Comparando os preços diretamente, a impressão é de que realmente não há uma vantagem clara. Organizei em uma tabela as tarifas por hora do Google, runpod.io e vast.ai:

      1x L4 24GB:  google: $0.71, runpod.io: $0.43, spot: $0.22  
      4x L4 24GB:  google: $4.00, runpod.io: $1.72, spot: $0.88  
      1x A100 80GB: google: $5.07, runpod.io: $1.64, spot: $0.82, vast.ai $0.880, spot: $0.501  
      1x H100 80GB: google: $11.06, runpod.io: $2.79, spot: $1.65, vast.ai $1.535, spot: $0.473  
      8x H200 141GB: google: $88.08, runpod.io: $31.92, vast.ai $15.470, spot: $14.563
    

    O preço do Google parece ser pensado para rodar 24/7 durante um mês, enquanto runpod.io e vast.ai cobram por segundo. Não consegui encontrar o preço spot das GPUs do Google

    • Dá para ver o preço spot direto em “Criar instância de computação”. Por exemplo, no GCP, 1xH100 spot custa $2.55 por hora, com descontos conforme o uso se prolonga. Clientes corporativos de verdade ainda conseguem desconto sobre esse valor. Só usuários comuns pagam esse preço cheio

    • Fiquei curioso sobre a fonte do preço da vast.ai. No site, a opção 8xH200 parece ficar em geral acima de $21.65 por hora

    • Queria entender com base em quê se diz que o preço do Google pressupõe 24/7. Na página oficial de preços do Cloud Run, a cobrança é feita apenas pelo uso real em blocos de 100 milissegundos, e a autoscaling também diz que instâncias ociosas são reduzidas automaticamente após 15 minutos de espera (PM do Cloud Run)

    • Não é o caso de o Cloud Run GPU permitir apenas 1xL4?

    • Se o Google também cobra por segundo, então para uso inferior a 20 minutos talvez ele até seja mais vantajoso

  • Sou um grande fã do Modal e uso há bastante tempo GPUs serverless com scale-to-zero. Dá para escalar facilmente para grandes volumes quando necessário, e ao mesmo tempo a carga de desenvolvimento é muito menor. É interessante ver um grande provedor entrando nesse mercado. Um dos motivos de eu ter migrado para o Modal foi justamente porque os grandes provedores não ofereciam esse tipo de funcionalidade antes (na AWS Lambda, por exemplo, não havia suporte a GPU). Fico curioso se agora todas as grandes nuvens vão seguir nessa direção de serviço

    • O Modal é realmente excelente. Também me impressionou a tecnologia aprofundada do solver de LP (programação linear) que eles divulgaram. Se você for desenvolvedor Python, também recomendo o Coiled. Não é tão rápido quanto o Modal, mas permite subir VMs com GPU facilmente, e tudo roda dentro da sua própria conta de nuvem. Também oferece um gerenciamento de pacotes conveniente, incluindo sincronização de drivers CUDA e bibliotecas Python. (Obs.: trabalho no Coiled, mas a recomendação é sincera)

    • Também foi uma vantagem inesperada o fato de suportar cargas de trabalho em conformidade com HIPAA

    • O Modal tem a velocidade de cold start mais rápida para modelos acima de 10GB

    • Também me impressiona como a documentação do Modal é muito bem organizada

  • O maior motivo para o Cloud Run ser melhor do que outros serviços é o autoscaling e o scale-to-zero. Quando não há uso real, o custo efetivamente vai para zero, e também dá para controlar de forma estável o custo máximo definindo o número máximo de instâncias. Porém, isso considerando apenas a versão com CPU; ela é muito confiável e fácil de usar

    • Ainda assim, mesmo o Cloud Run comum muitas vezes tem tempo de boot de cold start longo (cerca de 3 a 30 segundos), então há problema de latência ao usar scale-to-zero
  • O pequeno provedor europeu de nuvem com GPU DataCrunch (sem relação comigo) oferece VMs com GPU Nvidia mais baratas do que o RunPod e outros

    1x A100 80GB 1,37 euro/hora
    1x H100 80GB 2,19 euro/hora

    • Na lambda.ai, uma VM com 1x H100 80GB é oferecida por $2.49 por hora. Pelo câmbio, dá exatamente 2,19 euros. Fico curioso se isso é coincidência ou se existe algum teto invisível do setor

    • Na Vast.ai, dá para usar 2x A100 em modelo P2P por $0.8/hora (ou seja, $0.4/hora por A100). Sou apenas um usuário satisfeito, nada além disso. É preciso prestar atenção à velocidade de rede. Alguns hosts compartilham largura de banda, então a velocidade real pode ser diferente da anunciada. É bom ter cuidado ao mover grandes volumes de dados

  • VP/GM responsável por Cloud Run/GKE. Estou disponível para responder perguntas sobre isso. Obrigado pelo grande interesse

  • Gosto do Cloud Run e esse novo recurso também parece interessante. Mas um ponto frustrante foi não conseguir rodar self-hosted GitHub runners por questões de permissão root. E também a nova funcionalidade de worker pool, que na prática exigia implementar o scaler manualmente, em vez de ser algo embutido

    • Eng Manager responsável por Serverless e Worker Pools Autoscaling. Estamos definindo ativamente o roadmap, e seria de grande ajuda se vocês pudessem enviar por e-mail exemplos de uso de cargas de trabalho reais. Aguardamos opiniões sobre workloads que precisem de worker pools e scaling
  • Depois de deixar um modelo em execução para teste no vertex.ai e esquecer de desligá-lo, recebi uma cobrança de $1000. Por isso, desta vez o Cloud Run provavelmente vai se tornar meu serviço padrão. Há anos opero microsserviços de produção e projetos de hobby no Cloud Run, e estou satisfeito tanto com a simplicidade quanto com a eficiência de custo

  • Se entendi corretamente, parece que dá para criar uma API servindo um modelo arbitrário como no Hugging Face e, embora não haja cobrança por token, se a carga de uso for baixa pode sair bastante barato de operar. Se for realmente isso, é uma grande inovação. A maioria dos provedores existentes exige uma assinatura mensal para rodar modelos customizados

    • A explicação é basicamente essa. Porém, o cold start pode ser muito lento (30 a 60 segundos). É a desvantagem do scale to zero. Também vale notar que há algumas pequenas cobranças mensais, como armazenamento de contêiner

    • Existem várias alternativas que suportam inferência serverless com GPU, como Runpod, vast, coreweave e replicate