Quem Paga pela Computação? Unidades de Modelo e o Lado de Infra do Custo de Inferência

Um CFO pode exigir um Índice de Eficiência de Inferência. Defendemos exatamente isso no ensaio sobre o IER: tratar o custo por inferência como uma trava de lançamento, do mesmo jeito que economia unitária trava qualquer outra linha de negócio. Mas um índice só é governável se o denominador for real. Alguém precisa conseguir apontar para uma fatia de GPU e dizer “este tenant consumiu aquilo, e aqui está a conta”.

A equipe de inferência do Mosaic AI, da Databricks, publicou um relato de como serve modelos de linguagem em escala, e enterrada dentro da história de confiabilidade existe uma primitiva contábil que importa mais do que os números de uptime. Eles servem cerca de 120 trilhões de tokens por mês. Afirmam mais de 80% de economia de custo de GPU em comparação com provisionar estaticamente para o pico. Esses dois números não coexistem por acaso. Coexistem porque o sistema foi desenhado para tornar o gasto de GPU alocável.

Este é o lado da oferta na governança de custo de inferência. Custo por inferência não é apenas um número que o time financeiro calcula depois do fato. É uma decisão de design de infraestrutura tomada muito antes da primeira requisição chegar.

O Problema de Alocação Que Ninguém Nomeia

Servir LLMs em ambiente multi-tenant carrega uma falha contábil silenciosa embutida no design ingênuo. Você compra uma frota de GPUs. Muitos tenants a compartilham. As requisições chegam em rajadas que não se alinham entre tenants. Então você enfrenta o mesmo dilema de todo sistema de recurso compartilhado: provisionar para o pico e desperdiçar a maior parte da capacidade a maior parte do tempo, ou provisionar para a média e descartar requisições quando vários tenants disparam juntos.

Provisionar estaticamente para o pico é como se chega a uma conta de GPU que ninguém consegue defender. O CFO pergunta “quanto custou de fato o tenant A”, e a resposta honesta é “compramos hardware suficiente para a pior hora de todos, então a pergunta não tem resposta limpa”. Isso não é um problema de relatório. É uma arquitetura que se recusa a ser medida.

O número de 80% de economia é o indício. Você só economiza 80% contra o pico estático se parou de provisionar para o pico. E só dá para parar de provisionar para o pico com segurança se conseguir mover capacidade entre tenants rápido o bastante para que um disparo em um não deixe outro sem recurso. Essa capacidade exige uma abstração que o hardware bruto não entrega.

Unidades de Modelo: Tornando o Gasto de GPU Contável

A abstração à qual a Databricks recorre é a “unidade de modelo”. Em vez de expor os tenants às GPUs brutas, a plataforma expõe um quantum de capacidade de serviço. Um tenant recebe unidades de modelo. O sistema sabe quantas unidades um tenant possui, quantas está usando e quanto essas unidades custam. O gasto de GPU vira função de unidades consumidas, não de hardware comprado.

É este o movimento que torna honesto o denominador do IER. Quando a unidade de conta é a unidade de modelo, e não a GPU física, cada camada do stack consegue reportar contra ela:

O planejamento de capacidade acontece em unidades, então dá para dimensionar a alocação de um tenant pela sua curva de demanda, não pelo pico da frota.
O auto-escalonamento acontece em unidades, então o sistema adiciona e remove capacidade de serviço em incrementos que sabe precificar.
O faturamento acontece em unidades, então o CFO recebe um custo por tenant que rastreia até um registro real de consumo, não uma média da frota inteira borrada sobre todos.

Dois sistemas nomeados carregam isso no design. Axon é o roteador, a camada que decide qual requisição vai para qual capacidade de serviço. Dicer é descrito como um auto-sharder ciente de unidades de modelo, ou seja, o componente que divide e posiciona o serviço do modelo conhece unidades como conceito de primeira classe. O nome importa menos que o compromisso arquitetural: unidades não são um adendo de faturamento parafusado a um pool de GPUs. São o substrato sobre o qual a lógica de roteamento e sharding foi construída.

É essa a diferença entre um sistema que dá para governar e um sistema que dá apenas para faturar. Num sistema nativo em unidades, o mesmo número sobre o qual o auto-sharder raciocina é o número que o financeiro fatura. Não existe uma camada de tradução onde a história de custo diverge silenciosamente da história operacional.

A Metade de Confiabilidade Também É Uma Metade Contábil

O relato da Databricks gasta a maior parte do texto em confiabilidade, e à primeira vista isso lê como uma preocupação separada do custo. Não é. Uma requisição descartada e um segundo de GPU desperdiçado são a mesma falha vista de dois lados. Ambos significam capacidade que você pagou e que não produziu um resultado governável.

Duas das lições de confiabilidade tornam o ponto concreto.

Primeiro, a correção no processamento de imagem. Eles descobriram que o PIL era cerca de 10 vezes mais lento que os processadores do Torchvision no pré-processamento de imagem. Substituí-lo rendeu mais de 3x requisições por segundo no caminho afetado. Leia isso como um número de custo, não apenas de throughput. Mesmo hardware, mesmas unidades de modelo alocadas, três vezes o trabalho servido. O custo por inferência naquele caminho caiu cerca de dois terços por causa de uma troca de biblioteca na etapa de pré-processamento. Nenhum painel de CFO teria revelado isso. Viveu num profiler, no lado da oferta, exatamente onde o denominador do IER é de fato determinado.

Segundo, a lição do travamento silencioso, que é a que a maioria dos times vai reconhecer e a maioria terá tratado de forma errada. Eles viam falsas falhas de liveness probe várias vezes por semana. Uma liveness probe responde “o processo está vivo”, e um worker de inferência travado pode passar nessa checagem sem servir nada. O processo está de pé. A porta responde. O trabalho não anda. Liveness probes sozinhas não enxergam isso, porque um travamento silencioso não é uma morte; é uma parada que parece saúde.

A correção deles foi a detecção ativa de travamento silencioso: em vez de esperar o processo morrer, o sistema verifica ativamente se o trabalho está progredindo e trata um worker parado como falho. As falsas falhas caíram de várias por semana para zero. A implicação contábil é direta. Um worker travado segurando uma unidade de modelo é uma unidade que você paga e que não serve nada, e uma probe que diz que ele está saudável é uma medição que mente para o seu modelo de custo. A detecção ativa recupera a unidade e corrige a contabilidade.

Os Dois Lados Têm Que Bater

Junte os dois ensaios e a forma fica clara. O Índice de Eficiência de Inferência é o instrumento do lado da demanda: a trava do CFO, o número que decide se um recurso vai ao ar. As unidades de modelo são o instrumento do lado da oferta: a infraestrutura que torna esse número rastreável até um registro real de consumo por tenant.

Um índice sem denominador alocável é teatro. Você pode publicar um IER calculado a partir de uma conta de GPU da frota inteira dividida pelo total de inferências, mas ele não diz nada acionável, porque você não consegue atribuí-lo, faturá-lo nem ajustá-lo tenant a tenant. A mesma armadilha aparece um nível acima na questão da saturação de hiperescala: throughput no substrato só é útil se você conseguir precificá-lo onde é consumido.

O trabalho de confiabilidade fecha o ciclo. A detecção ativa de travamento silencioso e o ganho de 3x no pré-processamento não são separados da governança de custo. São o mecanismo que mantém a unidade de modelo honesta, garantindo que uma unidade alocada seja uma unidade fazendo trabalho, e que uma unidade fazendo trabalho seja uma unidade que você fatura sem precisar disfarçar.

Faça Isto Agora

Pegue sua maior carga de inferência e faça três perguntas ao time de plataforma, não ao financeiro.

Primeira: qual é a unidade de conta abaixo da GPU? Se a resposta for “a GPU”, você não consegue alocar custo por tenant, e seu IER é uma média da frota vestida de custo por tenant. Defina uma unidade de serviço que roteamento, escalonamento e faturamento referenciem juntos.

Segunda: como você detecta um worker travado? Se a resposta for “a liveness probe”, assuma que você está pagando por unidades paradas neste exato momento. Adicione detecção ativa de progresso que trate um worker que não avança como falho, e meça quantos workers falsamente saudáveis ela recupera na primeira semana.

Terceira: faça profiling do caminho de pré-processamento. O 3x da Databricks veio de uma biblioteca no lado da entrada, não do modelo. O custo por inferência é definido pelo caminho inteiro, e a economia mais barata costuma estar a montante da GPU, no código que nenhum painel observa.

O CFO é dono do índice. O time de plataforma é dono de se o índice significa alguma coisa. Custo de inferência governável não é um relatório que você gera. É uma arquitetura que você escolhe.

Fontes

Databricks. “Reliable LLM Inference at Scale.” Maio de 2026.

A Victorino ajuda equipes a transformar custo de inferência em uma métrica governada e alocável: contato@victorino.com.br | www.victorino.com.br