Recursos/Treinamento de modelo/Teste e disponibilização de um modelo

Conceito

Serverless vs. dedicado

O serviço serverless fatura por token em capacidade compartilhada sem custo de inatividade; uma implantação dedicada reserva GPUs para o seu modelo e fatura por cada hora de existência. Qual é o mais barato depende do quanto você o utiliza.

Capítulo 93 min de leitura3 referências

O que é

Existem duas maneiras de executar um modelo treinado. O Serverless (também chamado de por token ou sob demanda) o executa em uma capacidade que o provedor compartilha entre muitos clientes: você envia solicitações e paga pelos tokens de entrada e saída, e quando não envia nada, não paga nada. Uma implantação dedicada reserva hardware exclusivamente para o seu modelo: ele está sempre carregado e pronto, e você paga por cada hora que ele existir.

ServerlessDedicado
Cobrado porTokens de entrada e saídaHoras de existência da implantação
Custo de inatividadeNenhumPreço integral por hora
InicializaçãoGeralmente imediataUm cold start de minutos no momento da criação
CapacidadeCompartilhada; sujeita a limites de taxaReservada; taxa de transferência previsível
DisponibilidadeApenas para modelos que o provedor suporta dessa formaA maioria dos modelos treinados, incluindo modelos abertos

Como os custos se comparam

o ponto de equilíbrio
serverless cost per day  = tokens per day × price per token
dedicated cost per day   = 24 × hourly price               (used or not)
break-even tokens/day    = 24 × hourly price ÷ price per token
uso (tokens por dia)custo por diaPONTO DE EQUILÍBRIOSERVERLESS MAIS BARATODEDICADO MAIS BARATOdedicado: horas × preço por horaserverless: tokens × preço
O custo do serverless cresce a cada token; uma implantação dedicada custa o mesmo por hora, quer responda a uma pergunta ou a um milhão. Abaixo do ponto de equilíbrio, o serverless é mais barato, acima dele, o dedicado é — e uma implantação dedicada ociosa fica na extrema esquerda do gráfico, pagando o valor total por nada.

A intuição: com uma implantação dedicada, o custo por token é o preço por hora dividido por quantos tokens você realmente processa nela naquela hora. Em carga total, isso pode ser mais barato que o serverless. Em carga baixa, é muito mais caro, e uma hora ociosa tem um custo infinito por token. O serverless tem o formato oposto: o preço por token é fixo, de modo que o custo acompanha o uso exatamente.

Por que nem tudo é serverless? O serviço compartilhado funciona mantendo um modelo base carregado para muitos clientes. Alguns provedores podem anexar um pequeno adaptador com ajuste fino a esse modelo compartilhado por solicitação, o que torna o serviço por token possível para modelos ajustados. Outros precisam de todo o modelo ajustado carregado em seu próprio hardware — comum para modelos abertos e para ajustes finos completos — e, nesse caso, a implantação dedicada é a única opção. Alguns provedores vão além e exigem capacidade reservada para qualquer modelo personalizado.

Exemplo prático: preços ilustrativos, três níveis de uso
  1. Suponha (valores ilustrativos, não cotações reais) o modelo serverless a $ 0,60 por milhão de tokens e uma implantação dedicada a $ 5 por hora, ou seja, $ 120 por dia.
  2. Ponto de equilíbrio: $ 120 ÷ $ 0,60 por milhão = 200 milhões de tokens por dia.
  3. Um dia de testes: 300 perguntas × 1.500 tokens = 450.000 tokens. Serverless: cerca de $ 0,27. Dedicado: $ 120 pelo dia, ou $ 10 se você excluí-lo após duas horas.
  4. Um assistente interno com alto uso: 50 milhões de tokens por dia. Serverless: $ 30. Dedicado: continua $ 120.
  5. Um produto de alto volume: 500 milhões de tokens por dia. Serverless: $ 300. Dedicado: $ 120, se uma implantação puder suportar a carga.

Como escolher

  • Use serverless quando estiver disponível e o uso for baixo, incerto ou em picos — testes, avaliação, pilotos.
  • Use dedicado quando o modelo só puder ser servido dessa forma, quando o tráfego constante estiver acima do ponto de equilíbrio, ou quando você precisar de capacidade e latência garantidas.
  • Sempre defina um horário de término em uma implantação dedicada usada para testes, e exclua-a quando terminar. Compromissos de semanas ou meses podem reduzir o preço por hora, mas removem essa opção.

Erros comuns

  • Esquecer uma implantação de teste dedicada e pagar por dias de horas ociosas.
  • Comparar um preço por hora dedicado com um preço por token serverless sem converter por meio do uso esperado.
  • Presumir que um modelo ajustado pode ser servido por token porque seu modelo base pode.
  • Assinar um longo compromisso de capacidade para um modelo que ainda está sendo iterado.

Referências e leitura complementar

Fontes externas abrem em uma nova aba.

  1. 01Increase model invocation capacity with Provisioned Throughput in Amazon BedrockAmazon Bedrock User Guide · docs.aws.amazon.comUm exemplo real de capacidade reservada: faturada por hora até ser excluída, com compromissos opcionais.
  2. 02Inference EndpointsHugging Face docs · huggingface.coEndpoints dedicados para modelos abertos, com escalonamento automático.
  3. 03Serverless computingWikipedia · en.wikipedia.orgO modelo geral de pagamento por uso e seus trade-offs, como cold starts.

Transforme semanas de trabalho especializado em minutos

Veja como o Scalata se adapta à sua equipe, aos seus dados e aos seus Controles.

Fale com vendas