Pare de comparar preço por token com hora de GPU. Meça a inferência por tarefa concluída, nas horas pagas
Uma GPU que deu prejuízo na semana, um agente 29x mais barato no mesmo modelo, um modelo de decisão que só cobra a entrada. Nosso framework para escolher como comprar inferência.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.

Quanto custa para a sua empresa uma unidade de trabalho de IA concluída?
Não um token, não uma hora de GPU: uma tarefa feita corretamente, como um caso triado, um documento conciliado ou um formulário preenchido. Poucas empresas sabem responder, porque os números que elas comparam estão em unidades diferentes. Uma API hospedada cobra em dólares por milhão de tokens. Uma GPU, em dólares por hora. Uma plataforma, por licença. Comparar tudo isso diretamente é como os times se convencem da arquitetura errada, nos dois sentidos.
Três resultados publicados na mesma semana mostram por quê.
Três números de uma semana
Uma GPU que pagou de manhã e perdeu na semana. Um engenheiro da Microsoft rodou um modelo de pesos abertos numa H100 Spot no Azure. Nas três horas mais cheias, ela produziu US$ 24,35 em tokens com US$ 4,65 de compute. Na semana, produziu US$ 86 em tokens com cerca de US$ 98 de compute, porque configuração, carga, tempo ocioso e despejos também são pagos. Mesmo hardware, mesmo modelo, conclusões opostas, dependendo só de quais horas você conta.
Um workflow 29 vezes caro demais no mesmo modelo. O agente de navegador da Asana custava pelo menos US$ 36,21 por execução; corrigir como ele fazia cache e cortava o próprio histórico levou o mesmo modelo a US$ 1,24. Um orçamento de contexto maior também levou a parcela de execuções concluídas de 3 em 18 para 18 em 18. Uma configuração mais barata que não termina não é mais barata.
Uma decisão com preço separado da geração. O Microsoft-Decision-1 cobra US$ 0,042 por milhão de tokens de entrada e nada pela saída, porque pontua opções em vez de escrever texto. Chamadas que na verdade são decisões agora têm a própria curva de preço.
Cada resultado é estreito, e dois foram publicados por fornecedores. Juntos, dizem a mesma coisa: o preço da tabela explica menos da conta do que a utilização, o desenho do contexto e a taxa de conclusão.
A unidade: custo por tarefa concluída
Nossa proposta é uma unidade única para todas as opções:
O gasto total num período, incluindo capacidade ociosa e as pessoas que operam o sistema, dividido pelo número de tarefas concluídas corretamente nesse período.
As duas metades importam. O numerador precisa incluir as horas que você paga e não usa, e o tempo de engenharia que mantém o sistema de pé. O denominador deve contar só tarefas que terminaram e passaram no seu critério de aceite, não requisições atendidas. Com essa unidade, um modelo auto-hospedado com baixa utilização e uma API de fronteira com uma política de contexto perdulária aparecem tão ruins quanto são.
Isso amplia uma visão que defendemos desde que argumentamos que a IA agora é um portfólio de modelos e que hora economizada é capacidade, não valor: a medida precisa seguir o trabalho, não o componente.
Quatro formas de comprar inferência
| Forma de compra | Você paga por | O tempo ocioso custa | Costuma ganhar quando |
|---|---|---|---|
| API gerenciada, por token | Tokens processados | Nada | O tráfego é irregular ou desconhecido; a barra de qualidade é alta |
| Capacidade gerenciada dedicada | Throughput reservado | Tudo o que você reservou | O volume é estável e previsível; você precisa de SLA |
| Pesos abertos auto-hospedados | Horas de GPU, mais operação | Tudo, incluindo carga e despejos | O tráfego é estável com prefixos longos compartilhados; a custódia exige |
| Combinação roteada | Várias das anteriores, mais o roteador | Depende da combinação | As tarefas variam muito; muitas chamadas são pequenas decisões |
A tabela é menos uma recomendação do que uma lista de quem carrega o risco de uma hora vazia. Numa API por token, quem carrega é o fornecedor. Com capacidade reservada ou auto-hospedada, é você, e o argumento a favor dela depende de mantê-la ocupada.
Quatro medições antes de escolher
Utilização por hora. Desenhe as requisições esperadas por hora ao longo de uma semana, não a média diária. Uma GPU precisa de um piso constante de trabalho; no experimento do Azure, ela precisava ficar ocupada cerca de um quarto do tempo só para empatar com preços Spot.
Parcela de prefixo e taxa de acerto do cache. Tráfego de agentes reenvia históricos longos. Se a maior parte da entrada se repete, a entrada em cache é barata em qualquer plataforma, e a opção que faz melhor cache, não a mais barata por token, pode ganhar. No teste do Azure, a entrada em cache respondeu por 52% do valor servido.
Taxa de conclusão por configuração. Meça a parcela de tarefas concluídas corretamente para cada modelo e política de contexto em avaliação. Os números da Asana mostram que isso pode variar seis vezes no mesmo modelo.
Horas de operação. Conte o tempo de engenharia para aplicar patches, monitorar, escalar e reiniciar uma stack auto-hospedada, e o peso do plantão. Costuma ser a maior linha ausente nos business cases de self-hosting.
Com esses quatro números, a comparação vira aritmética. Sem eles, é um debate entre uma tabela de preços e o preço de uma GPU, e perde quem nunca testou as próprias premissas.
Nossa expectativa, e é uma visão, não um fato: à medida que modelos de decisão, cache de prompt e roteamento amadurecem, o preço por token dos modelos de fronteira vai pesar menos nos orçamentos de IA das empresas do que a parcela de horas, tokens e execuções que não produz nada. Os times que medirem essa parcela primeiro vão escolher a infraestrutura com evidência. Os outros vão escolher pela tabela de preços.