Otimização de custos do Databricks Genie: como rastrear e controlar o que ele dispara

TL;DR

O Genie tem dois custos, e só um deles é fácil de controlar. Os budgets do Unity AI Gateway cuidam do lado do uso de LLM. O compute que o Genie dispara, SQL warehouses e jobs serverless, não tem controle equivalente nem tag do Genie nos seus dados de billing. A solução não é um relatório melhor. É dar aos workloads do Genie um compute próprio e aplicar tags de forma consistente, para que a atribuição já venha embutida desde o início, em vez de ser reconstruída depois que a fatura chega.

Otimização de custos no Databricks geralmente significa fazer right-sizing de clusters ou corrigir políticas de auto-termination. O Genie adiciona uma complicação que esses playbooks não cobrem: um workload capaz de disparar compute de verdade sem nunca aparecer como um item que você consiga buscar na fatura. Apresentamos as quatro ferramentas do Genie no primeiro post desta série e mostramos quanto o Genie realmente custa no segundo, incluindo um teste real em que o uso de IA era fácil de medir e o compute não. Este post é sobre fechar essa lacuna antes que ela custe mais caro do que um simples exercício de pesquisa.

Essa lacuna não é algo que o Databricks deve fechar por conta própria. A maioria das respostas do Genie Agent e a maioria das sessões do Genie Code geram SQL ou código e depois o executam, e executar coisas é justamente para isso que o compute serve, mas nem sempre: um Genie Agent às vezes consegue responder a uma pergunta geral sem tocar em nenhuma tabela, e o Genie Code frequentemente gera código sem executá-lo. Quando a execução acontece, o uso de IA que a gerou recebe um rótulo claro. A execução em si, não. Essa divisão reflete como o Databricks projetou o produto, não um descuido, e significa que a solução também precisa ser arquitetural.

Por que você não consegue simplesmente olhar a fatura e ver o custo do Genie?

O Databricks marca explicitamente o uso de LLM do Genie. Cada registro carrega billing_origin_product = 'GENIE', então você pode filtrar, agrupar e totalizar sem adivinhar. O compute que o Genie dispara não recebe esse tratamento. A fatura de um SQL warehouse diz que um warehouse executou queries. Ela não diz se foi uma pessoa que digitou aquele SQL ou se um Genie Agent o gerou.

O Gartner prevê que, até 2027, 40% das empresas vão rebaixar ou desativar agentes de IA autônomos depois que lacunas de governança só vierem à tona quando algo já tiver dado errado em produção. Visibilidade de custos faz parte dessa mesma lacuna de governança. Deixar para resolver a atribuição só quando o financeiro fizer uma pergunta que você não consegue responder é o jeito caro de aprender essa lição.

O que o controle do lado do LLM realmente cobre?

Os budgets do Unity AI Gateway, com escopo de conta, workspace, grupo de usuários ou usuários individuais e marcados com a tag databricks-product: genie, dão a você um controle real sobre o gasto de LLM do Genie. Genie One, Agents e Code são todos medidos pelo mesmo mecanismo, então um único budget cobre a família inteira. Tags são aditivas, então adicionar mais tags não quebra o rastreamento. Só dá uma visão mais granular do mesmo gasto com o Genie.

Esse é um problema resolvido, e vale dizer com todas as letras: se você só configurar budgets para o Genie e parar por aí, cobriu talvez metade do risco. A metade maior continua em aberto.

Por que a metade do compute é tão mais difícil?

Os Genie Agents executam SQL no warehouse para o qual estiverem apontados, geralmente o mesmo que todo o resto do workspace já usa. O Genie Code inicia compute serverless para executar o código que escreve. Nenhum dos dois recebe uma tag específica do Genie por padrão. Se você for procurar o custo de compute do Genie depois que tudo já aconteceu, vai acabar correlacionando system.billing.usage com system.query.history e system.compute.warehouse_events, tentando alinhar timestamps e torcendo para que nada mais estivesse rodando no mesmo momento. Isso funciona para um teste isolado. Desmorona no instante em que mais de um workload toca o mesmo warehouse, ou seja, em qualquer ambiente real.

A McKinsey descobriu que 93% das organizações que rodam workloads de IA já estouraram seus orçamentos de IA, e compute não rastreado contribui diretamente para esse padrão. Não dá para gerenciar um número que você só consegue reconstruir a posteriori.

Foi exatamente nesse muro que batemos quando testamos o Genie por conta própria. Nosso ebook, Databricks Genie Explained, detalha o teste completo, incluindo a query que usamos para extrair o uso real de DBUs do Genie direto das tabelas de billing.

Como tornar o compute do Genie atribuível?

Dê ao Genie um compute próprio sempre que possível, em vez de compartilhar um warehouse com dashboards, SQL ad hoc e todo o resto. Um SQL warehouse dedicado para os Genie Agents transforma uma pergunta sem resposta em uma conta simples: warehouse do Genie, vezes sua taxa de DBU, é igual ao custo de SQL relacionado ao Genie. Sem correlação, sem alinhamento de timestamps, sem adivinhação.

Aplique tags nesse compute do mesmo jeito que faria com qualquer outra coisa que precise rastrear: tags de warehouse consistentes e tags de budget policy serverless, aplicadas antes de o workload rodar, não reconstruídas depois. A prática de alocação da FinOps Foundation trata tagging e convenções de nomenclatura no nível do recurso como o mecanismo básico para atribuir custos compartilhados ou ambíguos, e o compute do Genie é exatamente o tipo de custo ambíguo que essa prática existe para resolver. Compute dedicado isola o workload. As tags o identificam. Você quer os dois, não um no lugar do outro.

Nem todo Agent precisa do próprio warehouse. Reserve isso para os de alto volume ou críticos para o negócio, em que a visibilidade de custos realmente importa, e deixe Agents menores e ocasionais compartilharem espaço até que o próprio uso justifique um warehouse dedicado.