Implantar um LLM em GPU Serverless: 5 Plataformas, Preços Reais, Cold Starts Honestos

Implantar um LLM em GPU Serverless: 5 Plataformas, Preços Reais, Cold Starts Honestos

A RunPod cobra $2,72/h por uma A100 80GB. Seu endpoint recebe doze requisições antes do almoço. A GPU fica ociosa nas outras 23 horas, cobrando o tempo todo. Implante um LLM em GPU serverless e você paga só enquanto uma requisição roda. Cinco plataformas fazem isso. Elas cobram em cinco unidades diferentes. Ninguém normaliza nada.

Uma GPU ociosa custa exatamente o mesmo que uma GPU ocupada.

Principais conclusões

• A GPU serverless cobra apenas enquanto uma requisição roda e escala para zero entre elas.
• Uma GPU por instância no Cloud Run; modelos de 70B precisam de múltiplas GPUs, então o serverless geralmente não consegue hospedá-los.
• Os pesos do modelo ficam na imagem, em um volume de rede ou são baixados de novo a cada cold start.
• Cold start são três coisas: boot do container, carga dos pesos, inicialização do engine. Só a primeira é rápida.
• Abaixo de umas 47.000 requisições por dia, escalar para zero sai mais barato que uma GPU alugada 24/7.

O que "GPU serverless" realmente significa para um LLM?

Uma plataforma de GPU serverless roda seu container de inferência em hardware de GPU compartilhado, sobe a instância quando uma requisição chega e escala para zero quando o tráfego para. Você paga por segundo (ou por minuto, ou por hora, dependendo do fornecedor) só enquanto o container está vivo. Sem conta de ociosidade. Sem instância reservada.

A unidade de cobrança varia por fornecedor, e é por isso que a próxima seção normaliza tudo para $/GPU-hora.

Duas restrições pegam as pessoas de surpresa. Primeiro, o Google Cloud Run permite no máximo uma GPU por instância. Isso limita seu teto de VRAM a uma única placa. Segundo, "serverless" não significa estado persistente. Não existe um processo de longa duração segurando seus pesos na RAM entre requisições. Quando o container morre, tudo que está na memória morre junto. Esse único fato determina a decisão de armazenamento na seção de pesos do modelo abaixo.

Serverless não significa sem servidor. Significa sem servidor entre as suas requisições, e é exatamente aí que os pesos do seu modelo desaparecem.

Qual plataforma de GPU serverless escolher? (preços de 2026, lado a lado)

Não vendemos nenhuma dessas plataformas e não recebemos receita de afiliados de nenhuma delas. Dos sete artigos que competem por essa busca e suas variações próximas, quatro são publicados por uma empresa que vende GPU serverless. Esta tabela não é.

Todas as tarifas foram lidas das próprias páginas de preços dos fornecedores em 30/07/2026. Preços mudam; confira de novo antes de se comprometer.

A conta de normalização, mostrada uma vez para você poder auditar: o A100 80GB da Modal a $0,000694/s multiplicado por 3600 segundos dá $2,4984/h. Beam: $0,000625 vezes 3600 dá $2,25/h. Baseten: $0,06667/min vezes 60 dá $4,00/h. Essa diferença de 1,8x entre Beam e Baseten para a mesma A100 é real, e ela se esconde à vista de todos porque ninguém publica a mesma unidade.

Três ressalvas. A página de preços da Beam afirma explicitamente que não cobra pelo spin-up do servidor nem pela carga da imagem do container. O FAQ de preços da Baseten responde à pergunta "Eu pago por tempo ocioso na Baseten?" com "Não, você não paga por tempo ocioso" e depois acrescenta que o tempo faturável é "o tempo em que seu modelo está ativamente fazendo deploy, escalando para cima ou para baixo, ou fazendo previsões", então o medidor cobre mais do que o tempo de previsão, que é a parte que vale a pena colocar no orçamento. A RunPod publica tarifas por hora e nenhum número de cold start na sua página de preços.

Se a Modal for a sua escolha, escrevemos o passo a passo completo da Modal separadamente.

Seu modelo cabe aí? VRAM, limite de uma GPU e cota

Dá para rodar um modelo de 70B em uma GPU serverless? Geralmente não. Em FP16, 70B precisa de ~140 GB de VRAM. O Cloud Run limita a uma GPU por instância (96 GB no máximo na RTX PRO 6000). A conta não fecha sem quantização (FP8/GGUF) ou uma plataforma multi-GPU.

A cota padrão do Cloud Run é de 3 GPUs L4 por região por projeto (a RTX PRO 6000 é concedida separadamente, como 3.000 milliGPU), distribuída em seis regiões L4: asia-southeast1, asia-south1, europe-west1, europe-west4, us-central1, us-east4. Essa é a metade Cloud Run da resposta sobre residência de dados para quem pergunta sobre GPU serverless na Europa; Modal e RunPod documentam suas próprias regiões da UE, e o FAQ tem o resto.

O passo a passo de Cloud Run do Ismaili Simba no dev.to (abril de 2025) relata que a solicitação de cota "pode levar algum tempo (até 5 dias úteis) para ser aprovada" e que "as GPUs L4 disponíveis no Cloud Run têm um limite de 16GB de RAM." Planeje esse atraso.

Para dimensionamento de VRAM modelo a modelo, veja nosso guia de requisitos de VRAM.

Onde ficam os pesos do seu modelo (e quanto isso custa)?

Um thread do Reddit de novembro de 2024 que ainda estava em 5º lugar no Google para exatamente essa busca quando verificamos em 30/07/2026 pergunta, palavra por palavra:

"Não consegui encontrar a tarifa para armazenar o modelo de 80 GB… Qual é a alternativa se eu não quiser baixar o modelo a cada chamada de API (pod provisionado na chamada e depois encerrado)? … Por que essas plataformas não listam o custo de armazenamento do modelo?"

Três respostas com score baixo, nenhuma delas uma resposta de verdade. Quando fizemos essa busca em 30/07/2026, os dez primeiros resultados ainda incluíam aquele thread de dois anos perguntando quanto custa o armazenamento do modelo. Ninguém no thread respondeu. Ambas as plataformas publicam a tarifa. Na Modal, é $0,09 por GiB por mês com o primeiro TiB grátis, então aquele checkpoint de 80 GB sai por $0,00. Na RunPod, é $0,07 por GB por mês para armazenamento de rede abaixo de 1 TB, o que coloca o mesmo checkpoint em uns $5,60 por mês.

A terceira linha é o modo de falha. Uma revisão de 2024 da TU München sobre o ServerlessLLM (arXiv 2411.15664) relata que o LLaMA-2-70B (130 GB) precisa de mais de 26 segundos para ser baixado a 5 GB/s, mais ~84 segundos para carregar em 8 GPUs, contra ~100 ms de geração de token. Esses números são citados naquela revisão, não medidos por ela.

A página de preços da RunPod tem uma seção de Storage: disco do container $0,10/GB/mês, disco de volume $0,10/GB/mês em execução e $0,20/GB/mês ocioso, armazenamento de rede $0,07/GB/mês abaixo de 1 TB e $0,05/GB/mês acima disso, armazenamento de rede de alto desempenho $0,14/GB/mês. O número existe. Ele só não está ao lado das tarifas serverless por GPU que o leitor está comparando quando a pergunta surge, nem no fluxo de configuração do endpoint. Um problema de encontrabilidade, não de sigilo, e suficiente para manter a pergunta viva dois anos depois.

# Point the Hugging Face cache at a mounted network volume
# so weights persist across cold starts (RunPod / Modal pattern)
export HF_HOME=/workspace/hf-cache
export TRANSFORMERS_CACHE=/workspace/hf-cache
export HF_HUB_ENABLE_HF_TRANSFER=1

# Alternative: bake weights into the image at build time
FROM vllm/vllm-openai:latest
COPY ./model-weights /models/qwen3-27b-fp8
ENV MODEL_NAME=/models/qwen3-27b-fp8
# Downside: 30+ GB image, full rebuild to change models

Se você ainda não escolheu um modelo, nosso roundup de pesos abertos de 2026 dimensiona cada opção para deploy.

Na prática: vLLM no RunPod Serverless, de ponta a ponta

Seis passos do zero até um endpoint chamável. Verifique cada um no procedimento de vLLM da RunPod (atualizado em 22 de junho de 2026), que não publica preços.

1. Escolha seu modelo. Escolha um modelo de pesos abertos dimensionado para a sua GPU (veja a tabela de VRAM acima). Se ele tiver acesso restrito no Hugging Face, gere um token de acesso antes.

2. Crie o endpoint serverless. No console da RunPod, selecione Serverless, escolha o template de worker vLLM e selecione o tier da sua GPU.

3. Defina as variáveis de ambiente que importam.

MODEL_NAME=Qwen/Qwen3.6-27B-FP8
MAX_MODEL_LEN=32768
GPU_MEMORY_UTILIZATION=0.90
DTYPE=auto

MODEL_NAME errado significa um 404 no boot. MAX_MODEL_LEN alto demais para a sua VRAM significa OOM antes do primeiro token. GPU_MEMORY_UTILIZATION acima de 0,95 não deixa folga para picos de KV-cache.

1. Defina workers mín/máx e timeout de ociosidade. Workers mínimos em 0 dá scale-to-zero (e cold starts). Workers mínimos em 1 elimina os cold starts, mas cobra continuamente. A seção de cold start abaixo destrincha esse trade-off.

2. Anexe o volume de rede que você decidiu na seção de pesos do modelo, ou aceite o caminho de embutir na imagem. Se você pular isso, cada cold start baixa o checkpoint de novo.

3. Dispare a primeira requisição. Leia o ID do endpoint no console e confirme que os tokens voltam.

curl -X POST "https://api.runpod.ai/v2/${ENDPOINT_ID}/runsync" \
  -H "Authorization: Bearer ${RUNPOD_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "input": {
      "messages": [{"role": "user", "content": "Explain cold starts in one sentence."}],
      "max_tokens": 60
    }
  }'

Se você está avaliando o próprio motor de serving, comparamos vLLM e SGLang em throughput e latência.

Como chamar o endpoint a partir do seu app?

Toda plataforma da lista final fala uma API compatível com OpenAI. Um snippet Python funciona em todas. Trocar de provedor é uma mudança de base_url, não uma reescrita. Isso transforma "qual provedor" de uma decisão de lock-in em uma decisão de configuração.

import os

from openai import OpenAI

ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

client = OpenAI(
    base_url=f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    api_key=os.environ["RUNPOD_API_KEY"],
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-27B-FP8",
    messages=[{"role": "user", "content": "What is scale to zero?"}],
    max_tokens=120,
)
print(response.choices[0].message.content)

# Same code, different provider. One line changes.
ENDPOINT_ID = os.environ["RUNPOD_ENDPOINT_ID"]

PROVIDERS = {
    "runpod": f"https://api.runpod.ai/v2/{ENDPOINT_ID}/openai/v1",
    "modal": "https://your-app--your-func.modal.run/v1",
    "beam": "https://your-beam-endpoint/v1",
}

client = OpenAI(base_url=PROVIDERS["modal"], api_key="your-key")

Se todo provedor fala o dialeto da OpenAI, "qual provedor de GPU serverless" deixa de ser uma decisão de arquitetura e vira uma linha de configuração.

Quando você tiver múltiplos endpoints, nosso comparativo de gateways de LLM cobre roteamento e failover. Para um setup mais leve, um proxy LiteLLM adiciona retries e logging.

Qual cold start você vai ver na prática?

Para um modelo de 7B em GPU serverless, espere 10 a 30 segundos em um cold start de verdade (boot do container mais carga dos pesos mais inicialização do engine), com base em relatos de profissionais. As documentações dos fornecedores citam 1 a 5 segundos só para o boot do container. A diferença entre esses números é o seu checkpoint atravessando a rede.

A página de produto da RunPod afirma cold starts FlashBoot abaixo de 200ms (uma afirmação do fornecedor, não uma medição). Um profissional no r/LLMDevs relata: "na minha experiência, os cold starts não são ótimos… eu diria ~ 10 - 30 s", acrescentando "mas a maior parte da minha experiência é com modelos de difusão." Os dois estão certos. Eles medem coisas diferentes.

O número do cold start são três números empilhados:

1. Boot do container. Documentação da Modal: "O boot dos containers leva cerca de um segundo." Cloud Run: instâncias com drivers pré-instalados "iniciam em aproximadamente 5 segundos."

2. Carga dos pesos. A parte que ninguém divulga. Uma revisão de 2024 da TU München sobre o ServerlessLLM (arXiv 2411.15664) coloca o LLaMA-2-70B em mais de 26 segundos para baixar, mais ~84 segundos para carregar em 8 GPUs.

3. Inicialização do engine. Captura de grafo e warm-up do vLLM. Logesh Umapathi mediu o Qwen3.6-27B-FP8 em uma A100-80GB indo de 460s de baseline para 219s com modo eager, até ~70s com sleep mode do vLLM mais snapshots de GPU da Modal. Isso é 6,5x, publicado em 17 de maio de 2026.

Nossa interpretação dos dados publicados: os números dos fornecedores cronometram o container. Os números dos profissionais cronometram a requisição inteira. Entre esses dois cronômetros estão 80 GB de pesos atravessando a rede. A coluna Tipo é o ponto.

O que fazer: sleep mode do vLLM, snapshots de GPU e ajuste da janela de scaledown. A ociosidade padrão da Modal é 60 segundos (configurável de 2s a 20min). Um worker aquecido elimina os cold starts, mas cobra como sempre ligado.

# Modal scaledown config (illustrative)
# A 60s window means you pay for 60 idle seconds per burst.
# A warm worker (min_containers=1) costs ~$2.50/hr on A100 80GB, 24/7.
@app.function(
    gpu="A100",
    scaledown_window=60,  # seconds idle before shutdown
    # min_containers=1,   # uncomment to kill cold starts; costs $60/day
)

GPU serverless é mais barata que uma GPU sempre ligada?

A GPU serverless é mais barata quando a sua GPU fica ociosa na maior parte do dia. Com 3.000 requisições/dia a uma média de 2 segundos cada em uma A100 80GB, o serverless custa uns $4,17/dia contra $65,28/dia de uma GPU alugada rodando 24/7. O ponto de cruzamento é uma questão de ciclo de trabalho, não de volume.

Premissas (nossas, declaradas para você poder refazer): A100 80GB a $2,50/h da Modal, 2 segundos de tempo médio de GPU por requisição, GPU alugada a $2,72/h da RunPod o tempo todo, API de tokens hospedada a $0,40/1M tokens (uma tarifa publicada intermediária) e ~1.000 tokens por requisição.

O ponto de cruzamento fica em torno de 47.000 requisições/dia. Abaixo disso, o serverless vence. Uma API de tokens hospedada ganha das duas em baixo volume com um modelo commodity. O ponto de equilíbrio não depende de quantas requisições você recebe. Depende de quantas horas a sua GPU passa sem fazer nada.

A análise da BentoML de agosto de 2024 enquadra bem esse trade-off, embora os exemplos de preços sejam da era do GPT-3.5-turbo e estejam dois anos defasados.

Para saber quanto custa uma API de tokens hospedada no seu volume, veja nosso comparativo de preços de APIs de LLM. Para cortar o custo por requisição no lado da inferência, prompt caching normalmente economiza 30-60% em contexto repetido.

# Break-even calculator: adjust these and re-run
REQUESTS_PER_DAY = 3000
SECONDS_PER_REQUEST = 2
SERVERLESS_RATE_HR = 2.50   # Modal A100 80GB
RENTED_RATE_HR = 2.72       # RunPod A100 80GB, 24/7

serverless_daily = REQUESTS_PER_DAY * SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR
rented_daily = RENTED_RATE_HR * 24

print(f"Serverless: ${serverless_daily:.2f}/day")
print(f"Rented 24/7: ${rented_daily:.2f}/day")
print(f"Crossover: {int(RENTED_RATE_HR * 24 / (SECONDS_PER_REQUEST / 3600 * SERVERLESS_RATE_HR))} req/day")

Quando a GPU serverless é a escolha errada

• Tráfego alto e sustentado. Acima de ~47.000 requisições/dia nessas tarifas, o ciclo de trabalho se inverte e uma GPU alugada sai mais barata por requisição.
• SLOs rígidos abaixo de um segundo em um caminho frio. Nenhum truque de snapshot torna uma primeira requisição instantânea. Mantenha um worker aquecido ou alugue a máquina.
• Modelos de 70B+ que precisam de múltiplas GPUs. Uma GPU por instância no Cloud Run encerra essa conversa.
• Residência de dados rigorosa. Seis regiões L4 é o cardápio completo no Cloud Run.
• Economia por requisição que perde para um slot de worker que você já está pagando. Se você tem folga de GPU sobrando, adicionar inferência não custa nada a mais.

Se a sua GPU fica ocupada dezesseis horas por dia, o serverless é a opção cara, e quem te disser o contrário está vendendo serverless.

Para o caminho local-first, veja nosso guia de ferramentas para LLMs locais.

Sobre o autor

Mert Batur é cofundador da Techsy.io, onde o time entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a stack de ferramentas de LLM que o time da Techsy realmente usa em produção. Conecte-se no LinkedIn.

Perguntas frequentes

O que é uma GPU serverless?

Uma plataforma de GPU serverless roda o container do seu modelo em hardware compartilhado, escala para zero entre requisições e cobra apenas pela computação ativa. Você tem um endpoint de inferência sem gerenciar uma instância de GPU persistente. O trade-off é o atraso do cold start no spin-up.

Quanto custa rodar um LLM em uma GPU serverless?

Uma A100 80GB roda a $2,25/h na Beam, $2,50/h na Modal e $2,72/h na RunPod (verificado em 30/07/2026). Sua conta depende do ciclo de trabalho: 3.000 requisições/dia a 2s cada custa ~$4/dia na Modal. O armazenamento adiciona $0,09/GiB/mês, com 1 TiB grátis.

Eu pago para armazenar os pesos do modelo?

Sim, mas é barato. A Modal cobra $0,09/GiB/mês com 1 TiB/mês grátis, então um checkpoint de 80 GB não custa nada. A página de preços da RunPod lista armazenamento de rede a $0,07/GB/mês abaixo de 1 TB, uns $5,60/mês para os mesmos 80 GB.

Meu modelo é baixado de novo a cada requisição?

Só se nada estiver em cache. Pesos em um volume persistente ou embutidos na imagem sobrevivem aos cold starts. Aponte o cache do Hugging Face para armazenamento efêmero e um modelo de 130 GB será baixado de novo a cada spin-up. Esse é o modo de falha a evitar.

Quanto dura o cold start de um modelo de 7B?

Espere 10-30 segundos em um cold start de verdade, segundo relatos de profissionais (r/LLMDevs, dezembro de 2024). O container faz o boot em 1-5s (documentação da Modal e do Cloud Run). O resto é carga dos pesos e inicialização do engine. Com snapshots e sleep mode, Umapathi mediu ~70s para um modelo de 27B, contra 460s.

Dá para rodar um modelo de 70B em GPU serverless?

Geralmente não. Um modelo de 70B em FP16 precisa de ~140 GB de VRAM. O Cloud Run permite uma GPU por instância (96 GB no máximo). Você precisaria de quantização FP8 para caber em uma única placa de 80 GB, ou de uma plataforma multi-GPU. A maioria das plataformas serverless limita a uma GPU.

GPU serverless é mais barata que alugar uma GPU 24/7?

Abaixo de ~47.000 requisições/dia (a 2s/requisição em uma A100 80GB), sim. O serverless cobra apenas os segundos ativos; uma GPU alugada cobra 24 horas de qualquer forma. Acima disso, a GPU alugada vence. Uma API de tokens hospedada ganha das duas em baixo volume. Veja a tabela de ponto de equilíbrio acima.

Dá para implantar um LLM em GPU serverless de graça?

A Modal dá $30/mês em créditos grátis (Starter). A Beam dá $30/mês. O crédito de $300 para contas novas do GCP cobre o uso de GPU no Cloud Run. Suficiente para prototipar, não para rodar tráfego de produção. Nenhuma plataforma oferece um tier gratuito permanente para inferência em GPU.

Quais provedores de GPU serverless estão disponíveis na Europa?

O Cloud Run oferece GPUs L4 em europe-west1 (Bélgica) e europe-west4 (Holanda). A Modal documenta a seleção de regiões da UE (eu-west, eu-north, eu-south) com preços de 1,5-1,75x as tarifas base. A RunPod lista data centers europeus, incluindo EU-NL-1 e EU-FR-1. Fixe a região explicitamente; nenhuma delas tem a UE como padrão.

Preciso de Docker para implantar um LLM em GPU serverless?

Nem sempre. A RunPod oferece templates prontos de worker vLLM que dispensam o Docker. A Modal constrói containers a partir de uma definição de imagem Python em código. Para dependências personalizadas, você vai escrever um Dockerfile. Para serving padrão do vLLM, o caminho pronto funciona em minutos.

Conclusão

Cinco plataformas, cinco unidades de cobrança, uma tabela normalizada. A decisão é mais simples do que as páginas dos fornecedores fazem parecer:

• Escolha sua GPU pela VRAM, não pela marca.
• Coloque seus pesos em um volume, não na imagem, a menos que você nunca troque de modelo.
• Espere cold starts de 10-30 segundos e planeje em torno deles.
• Abaixo de ~47.000 requisições/dia, escalar para zero vence no custo.
• O motor de serving por trás do endpoint é substituível; o base_url é uma linha.

Você tem um endpoint chamável. Próximo passo: o que fica na frente dele quando você precisa de roteamento e failover? Nosso comparativo de gateways de LLM responde isso. Ou converse com a gente sobre o seu setup.