Custo de LLM Auto-Hospedado por Milhão de Tokens: Um Modelo Reproduzível de Custos de GPU

Custo de LLM Auto-Hospedado por Milhão de Tokens: Um Modelo Reproduzível de Custos de GPU

A maneira confiável de calcular o custo de LLM auto-hospedado por milhão de tokens é dividir o custo de serving totalmente carregado pelos tokens que sua carga de trabalho realmente aceita — não pelo pico de throughput anunciado de uma GPU.

Essa distinção é importante. Uma GPU pode ter bom desempenho em benchmarks, mas ser cara em produção quando passa tempo pago ociosa, processa prompts excepcionalmente longos, repete solicitações que falharam ou gera saídas que seu produto rejeita. Este guia fornece um modelo repetível para o custo de LLM auto-hospedado por milhão de tokens, uma planilha, um exemplo prático e uma forma justa de comparar um endpoint autogerenciado com uma API gerenciada.

Atualizado em 16 de outubro de 2026. Todos os valores em dólares e throughputs abaixo são dados ilustrativos, não cotações de provedores nem alegações de desempenho.

A fórmula para o custo de LLM auto-hospedado por milhão de tokens

Para uma visão por token de saída, use:

custo por 1M de tokens de saída aceitos =
  custo horário de serving totalmente carregado
  / (tokens de saída/segundo na janela ativa × 3.600 × utilização do tempo pago × taxa de sucesso × taxa de aceitação)
  × 1.000.000

Onde:

O denominador é o ponto-chave. O custo de LLM auto-hospedado por milhão de tokens deve ser um custo por unidade útil, não um custo por benchmark de GPU.

A regra de não contar duas vezes

Use um destes dois caminhos de medição:

1. Meça o throughput da janela ativa e, em seguida, multiplique pela utilização do tempo pago.
2. Meça os tokens aceitos durante todo o intervalo pago e, em seguida, defina a utilização como 1, pois o tempo ocioso já está incluído na observação.

Não faça ambos. Aplicar um fator de utilização ao throughput de tempo de parede que já inclui tempo ocioso faz o custo de inferência de LLM por token parecer pior do que é. Deixar a utilização fora de um benchmark de janela ativa faz com que ele pareça melhor do que é.

Uma planilha copiável de custo de GPU por milhão de tokens

Coloque uma linha em sua planilha para cada modelo, topologia de hardware, região e formato de carga de trabalho. Não misture um benchmark de chat curto com uma carga de trabalho de produção de contexto longo.

A planilha torna o cálculo do custo de LLM auto-hospedado por milhão de tokens auditável: outro operador deve conseguir substituir as entradas, executar novamente a janela de medição e reproduzir o resultado.

Este é um cálculo ilustrativo, não uma tabela de preços para qualquer GPU. Substituir as cinco entradas por valores medidos produz seu próprio custo de GPU por milhão de tokens.

Exemplo prático: por que a utilização muda a resposta

Mantenha constantes o custo horário totalmente carregado de $4.07 do endpoint hipotético e os 900 tokens de saída/segundo na janela ativa. Pequenas mudanças nas entradas alteram acentuadamente o custo unitário.

A lição não é comprar um acelerador específico. A lição é que a precificação de LLM auto-hospedado é um modelo de operações e capacidade de processamento. Um custo horário mais alto por nó pode resultar em um custo menor por saída aceita se houver memória suficiente, margem para processamento em lote e demanda para sustentar mais trabalho útil. Uma tarifa horária mais baixa pode perder quando a capacidade ociosa e as novas tentativas entram no denominador.

Separe o prefill do decode antes de realizar benchmarks

O serving de LLM não é uma carga de trabalho homogênea. A inferência tem uma fase de processamento de contexto (prefill) e uma fase de geração (decode); o guia TensorRT-LLM da NVIDIA trata explicitamente essas fases como separadas e enfatiza o ajuste específico para a carga de trabalho. Consulte o guia de ajuste de desempenho do TensorRT-LLM antes de considerar qualquer número de destaque de tokens por segundo como representativo.

• Prompts longos, contexto de recuperação e anexos grandes pressionam o prefill e o cache KV.
• Respostas longas, geração de código e raciocínio de agentes pressionam a capacidade de decode e o tempo por token de saída.
• Alta concorrência faz do comportamento do agendador, do processamento em lote, da residência em cache e da margem de memória partes do modelo de preço.

Registre separadamente as distribuições de prompts e de saídas. Para um assistente com uso intensivo de recuperação, com 20,000 tokens de entrada e 300 tokens de saída, a economia baseada apenas na saída pode não captar o verdadeiro gargalo. Para um fluxo de trabalho de programação com 2,000 tokens de entrada e 4,000 tokens de saída, o decode pode predominar.

Para uma comparação rigorosa de custo de LLM auto-hospedado por milhão de tokens, mantenha pelo menos estas três visões:

Meça o denominador usando a telemetria de produção

Não infira a capacidade de processamento aceita a partir de uma especificação de hardware. A pilha de serving deve exportar as entradas que tornam o cálculo reproduzível.

Por exemplo, o vLLM documenta métricas do Prometheus para tokens de prompt, tokens gerados, conclusões de solicitações, rejeições de admissão, tempo na fila, tempo de prefill, tempo de decode, uso de cache KV, tempo até o primeiro token e latência por token de saída. Elas são suficientes para criar um registro de medição em vez de estimar com base em um benchmark. A referência de métricas do vLLM lista os nomes e significados atuais das métricas.

Capture este registro para cada execução:

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

A telemetria de hardware é útil, mas é um diagnóstico — não um denominador de custo unitário. A documentação de profiling do DCGM da NVIDIA observa que a atividade é uma média por intervalo e deve ser correlacionada com a capacidade de processamento de uma carga de trabalho representativa. Use as métricas de profiling do DCGM para investigar se a computação, a largura de banda da memória ou o comportamento da interconexão está limitando a execução; não substitua a utilização do tempo pago por uma única porcentagem de utilização da GPU.

Monte o numerador totalmente carregado

O preço de aluguel de GPU é uma entrada, não a resposta. Para calcular de forma justa o custo do serving de LLM, inclua os custos de capacidade e operações necessários para a mesma janela de medição.

Para um piloto, informe dois valores:

Custo somente de GPU por 1M de tokens
Custo totalmente carregado por 1M de tokens aceitos

A diferença não é um erro; é o custo operacional do serviço auto-hospedado. Ela torna auditável a decisão de precificação de LLM auto-hospedado.

Inclua novas tentativas e saída rejeitada

Tokens gerados não são automaticamente tokens úteis. Uma solicitação pode consumir capacidade de prefill e decodificação parcial antes de expirar, produzir JSON inválido, falhar em uma chamada de ferramenta, violar uma regra de política ou não atingir um limiar de qualidade.

Use um ajuste de aceitação que sua equipe de produto possa reproduzir:

tokens de saída aceitos =
  tokens de saída gerados
  × taxa de sucesso de execução
  × taxa de aceitação do produto

Se a aceitação for medida no nível da solicitação, registre a regra exata: versão do avaliador, conjunto de amostragem, validador de esquema, protocolo de revisão humana ou evento de sucesso da tarefa. Alterar a regra sem versioná-la torna uma tendência de custo sem significado.

É também por isso que um custo de inferência de LLM por token bruto pode ser enganoso. Uma configuração que aumenta o throughput em 30%, mas reduz o sucesso de tarefas aceitas, pode custar mais na camada de produto.

Compare a auto-hospedagem com uma API gerenciada na mesma unidade

A auto-hospedagem compra capacidade. Uma API gerenciada compra uso. Elas só se tornam comparáveis quando o numerador e o denominador correspondem.

Use esta verificação de throughput de ponto de equilíbrio quando o benchmark da API for expresso na mesma unidade:

tokens de saída por segundo na janela ativa necessários =
  custo horário de serving totalmente carregado × 1,000,000
  / (custo da API gerenciada por 1M de tokens de saída aceitos × 3,600 × utilização × taxa de sucesso × taxa de aceitação)

Antes de decidir, alinhe estes controles em ambas as opções:

• O mesmo modelo ou um modelo equivalente em qualidade explicitamente avaliado.
• A mesma distribuição de comprimento de prompts e saídas.
• O mesmo SLO de latência e perfil de concorrência.
• As mesmas regras de novas tentativas, fallback e aceitação.
• O mesmo tratamento de acertos de cache, falhas de ferramentas e trabalho cancelado.

Se o controle direto da GPU, pesos personalizados, posicionamento rígido ou uma pilha especializada de kernels forem requisitos, a auto-hospedagem pode continuar sendo a resposta certa mesmo acima da linha de base gerenciada. Se o tráfego for baixo ou irregular, os modelos mudarem com frequência ou a equipe não quiser operar infraestrutura de inferência, uma API com preço por uso poderá absorver o risco de utilização.

Para uma comparação de compra mais ampla, consulte o guia de nuvem de GPU vs. API de modelo e o guia de preços de aluguel de GPU da Flatkey. Quando o controle direto da GPU não é necessário, uma opção gerenciada é um benchmark útil: a Flatkey fornece uma API unificada de modelos e ferramentas com um único saldo, para que as equipes possam comparar uma opção gerenciada com seu cálculo auto-hospedado sem manter chaves de provedores separadas. Inicie uma linha de base da API Flatkey com o mesmo conjunto de testes e regra de aceitação.

Um teste de aquisição em sete etapas

Use esta estrutura de custo de LLM auto-hospedado por milhão de tokens como um artefato de aquisição, e não apenas como um benchmark de engenharia. Ela deve mostrar exatamente quais premissas de carga de trabalho, capacidade e qualidade alteraram o resultado.

1. Defina a unidade: token de entrada, token de saída, token combinado, resposta aceita ou tarefa aceita.
2. Meça o throughput da janela ativa sob tráfego com perfil de produção, e não com um único prompt sintético.
3. Meça a utilização do tempo pago em cada réplica paga e nó de reserva quente.
4. Adicione todos os custos operacionais ao numerador horário.
5. Versione as regras de sucesso e aceitação e, em seguida, calcule a saída aceita.
6. Execute a mesma carga de trabalho por meio de uma linha de base de API gerenciada.
7. Revise custo, latência p95, confiabilidade, qualidade e esforço de engenharia em conjunto antes de reservar capacidade.

Erros comuns em um modelo de custo de LLM auto-hospedado

Usar o throughput máximo do benchmark. O pico é útil para comparar uma configuração controlada. Não é o throughput esperado da sua combinação de produção.

Chamar a utilização da GPU de utilização de capacidade. Uma GPU ocupada ainda pode estar conectada a um endpoint superdimensionado para a demanda paga. Use a utilização do tempo pago para a economia unitária e use a telemetria de hardware para diagnosticar o motivo.

Aplicar a utilização duas vezes. Escolha o throughput da janela ativa mais a utilização, ou o throughput em tempo de relógio que já inclui o tempo ocioso.

Ignorar os tokens de prompt. Um contexto longo aumenta a pressão de prefill e do cache KV, mesmo quando o produto cobra principalmente pela saída.

Tratar cada token gerado como aceito. Tentativas repetidas, argumentos de ferramenta inválidos, falhas de esquema e rejeições por qualidade são trabalho pago.

Comparar apenas uma fatura de GPU com o preço de tabela da API. Engenharia, suporte, armazenamento, rede, observabilidade e capacidade mantida aquecida devem fazer parte do mesmo cálculo.

Para a decisão completa (quando a auto-hospedagem compensa, dimensionamento de memória de GPU, ferramentas e uma configuração passo a passo do servidor), consulte nosso guia de LLM auto-hospedado.

Perguntas frequentes

Como calculo o custo de um LLM auto-hospedado por milhão de tokens?

Divida o custo horário totalmente carregado de serving pelos tokens aceitos por hora paga e, em seguida, multiplique por 1.000.000. Use a vazão medida com perfil de produção, a utilização do tempo pago, a taxa de sucesso e a taxa de aceitação — não o pico teórico da GPU.

O custo de GPU por milhão de tokens é o mesmo que o custo de inferência de LLM por token?

O custo de GPU por milhão de tokens pode ser uma métrica de infraestrutura apenas de GPU. O custo de inferência de LLM por token deve incluir o numerador operacional relevante e um denominador claramente definido. Para uma decisão de produto, o custo por resposta ou tarefa aceita costuma ser a métrica complementar mais segura.

Devo usar tokens de saída ou tokens totais?

Use ambos quando os custos de prompt e de saída tiverem gargalos diferentes. Os tokens de saída são fáceis de comparar em cargas de trabalho generativas; tokens totais ou ponderados representam melhor cargas de trabalho de recuperação com contexto longo. Mantenha a unidade idêntica ao comparar a auto-hospedagem com uma API.

Quando a auto-hospedagem economiza dinheiro?

É mais provável que economize dinheiro quando a demanda é estável, a capacidade permanece bem utilizada, o modelo e a implantação são estáveis e o controle direto agrega valor. É menos provável que economize dinheiro quando o tráfego é irregular, a seleção de modelos muda com frequência ou a sobrecarga operacional supera a economia de capacidade.

Conclusão

O número defensável de custo de LLM auto-hospedado por milhão de tokens é a capacidade paga totalmente carregada dividida pela vazão aceita. Meça prefill e decode separadamente, contabilize o tempo ocioso uma única vez, versione sua regra de aceitação e compare uma referência gerenciada na mesma unidade. Isso transforma uma cotação de GPU em um modelo de custos pronto para decisões.

Referências técnicas

• referência de métricas do vLLM
• guia de ajuste de desempenho do NVIDIA TensorRT-LLM
• documentação de profiling do NVIDIA DCGM