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

Um modelo prático para comparar LLM self-hosted e API pela carga real da equipe, além do preço de GPU ou Token.

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árioExecuções/diaConcorrência de picoInput / OutputTempo permitidoCritério de qualidade
Classificaçãoschema valid
Revisão de códigoteste aprovado
Busca internafontes confirmadas

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

Em 23 de agosto de 2026, os dados públicos da BetterToken para claude-sonnet-5 no grupo Claude mostravam $1.36 por milhão de Token de entrada e $6.80 por milhão de saída. Sem cache, 100.000 de entrada e 20.000 de saída custariam $0.272. O exemplo está preso ao modelo, grupo e data: confira novamente a página vigente antes do piloto e calcule cache read/write com a schema e os preços atuais. 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étricaSelf-hosted: normal / picoAPI: 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

Quer otimizar seu fluxo de trabalho com LLMs?

Conecte modelos por uma única API, gerencie chaves e controle os gastos com IA.