LLM self-hosted ou API: como comparar o custo total da equipe

Preço de GPU e tarifa por milhão de Token não contam a história inteira. Um modelo local exige capacidade, atualizações, observabilidade, segurança, backup e tempo de engenharia. A API reduz parte dessa operação, mas mantém custos de uso, integração, limites e dependência de um Endpoint externo. Compare as duas opções nas mesmas tarefas e com o mesmo nível de aceitação. O objetivo é encontrar uma configuração reversível para a sua equipe, não um vencedor universal.

1. Defina primeiro o workload e a qualidade

Escolha de 3 a 5 tarefas recorrentes: classificar documentos em uma schema fixa, consultar uma base interna, revisar código executando um teste, gerar relatório estruturado ou processar lotes em background. Para cada uma, anote tamanho de input e output, execuções em um dia normal, concorrência de pico, prazo aceitável e critério de aprovação. JSON válido, fontes confirmadas ou teste aprovado são limites objetivos.

Cenário	Execuções/dia	Concorrência de pico	Input / Output	Tempo permitido	Critério de qualidade
Classificação					schema valid
Revisão de código					teste aprovado
Busca interna					fontes confirmadas

Use as tarifas atuais na comparação da API. Confira os modelos e preços da BetterToken antes de levá-los ao cálculo de TCO. Ver preços atuais da BetterToken

Como ramo de API mensurável, o Dashboard da BetterToken mostra horário, modelo, status HTTP, input, output, cache Token e cobrança. Confira modelos e preços atuais, abra o Workspace e leve as métricas observadas para a planilha do piloto. A BetterToken não é uma plataforma de self-hosting; ela representa apenas uma opção de API nesta comparação.

2. TCO self-hosted vai além da GPU

Meça um ciclo operacional completo, com vários dias normais e pelo menos um pico esperado:

self_hosted_tco =
  hardware_amortization
  + hosting_and_electricity
  + storage_and_network
  + engineer_time
  + monitoring_and_security
  + backup_or_overflow
  + incident_cost

Use a configuração que seria realmente implantada, seu prazo de amortização e a memória disponível. Um valor citado online pode omitir chassi, rede, redundância, frete ou energia local. Verifique se modelo e contexto cabem sem mudar a tarefa ou baixar a qualidade. Registre horas de instalação do runtime, validação do modelo, serving, atualizações, profiling, filas, observabilidade, controle de acesso e incidentes.

Rodar localmente pode aumentar o controle sobre a localização dos dados, mas não cria segurança sozinho. Inclua patches, secrets, segmentação de rede, audit logs, backups e acesso administrativo. Conte indisponibilidade e jobs pendentes. Segundo nó, fila de recuperação ou API aprovada para overflow não sensível também entram no TCO. Se uma política impedir o envio de certos dados, trate isso como restrição obrigatória.

3. TCO da API começa nos Token

Normalize o usage pela schema real do provider e não some novamente cache Token já incluídos no input.

api_tco =
  uncached_input_cost
  + cache_read_cost
  + cache_write_cost
  + output_cost
  + retry_cost
  + integration_and_operations
  + incident_or_fallback_cost

Antes do piloto, escolha um Model ID disponível para sua key e registre na tabela as tarifas atuais dele no catálogo da BetterToken. Calcule cache read/write apenas pela usage schema real e pelas tarifas atuais indicadas separadamente; não substitua um valor ausente por zero. Some integração, tratamento de 401/429/5xx, retries limitados, filas, observabilidade e validação do resultado.

4. Meça carga normal e de pico separadamente

1. Normal: fluxo típico de uma semana de trabalho.
2. Pico: concorrência e lote definidos antes do teste, sem desativar verificações de qualidade.

Métrica	Self-hosted: normal / pico	API: normal / pico
Resultados aceitos	/	/
Tempo p50 / p95	/	/
Erros e retries	/	/
Horas de engenharia	/	/
Custo do período	/	/

Esses números descrevem somente a configuração testada; não são promessa de estabilidade futura.

5. Faça um piloto reversível

Não migre o produto inteiro de início. Escolha um cenário, mantenha uma interface comum e coloque cada provider atrás de um adaptador. Fixe inputs, qualidade e dados proibidos; rode a mesma amostra; meça normal e pico; conte Token, infraestrutura e horas no mesmo período; teste falha do nó local e da API externa; repita após mudanças. Não coloque API Key, .env, prompts privados nem resposta sensível completa no relatório.

6. Escolha e critérios de saída

Self-hosting pode fazer sentido quando a localização dos dados é obrigatória, o workload é previsível e a equipe assume operações. API pode ser melhor com carga variável, início rápido ou sem equipe para manter o runtime. Um desenho híbrido pode manter tarefas sensíveis localmente e enviar picos ou casos permitidos para a API.

• Pare o piloto self-hosted se qualidade, pico ou atualização não couberem nas horas disponíveis.
• Pare o piloto API se dados obrigatórios não puderem sair ou o custo por tarefa aceita for inviável.
• Recalcule após mudar modelo, preço, hardware ou workload.
• Não aceite um total menor obtido reduzindo qualidade ou removendo fallback.

O resultado útil é uma tabela de TCO datada, com configuração, qualidade, pico e responsável — não uma discussão abstrata entre servidor e nuvem.

Fontes

• Modelos e preços atuais da BetterToken
• Documentação da BetterToken
• BetterToken Product Fact Sheet