Phase 17 - Lesson 27

FinOps para LLMs — Economia Unitária e Atribuição Multi-Tenant

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

O FinOps tradicional falha nos gastos com LLMs. Os custos são transações de tokens, não tempo de atividade de recursos (uptime). As tags não se mapeiam — uma chamada de API é uma transação, não um ativo. Decisões de engenharia (design de prompt, janela de contexto, tamanho da saída) são decisões financeiras. O manual de 2026 possui três dimensões de atribuição para instrumentar no primeiro dia: por usuário (user_id) para precificação de assentos e expansão, por tarefa (task_id + route) para custo de superfície do produto e priorização, por inquilino (tenant_id) para economia unitária e renovação. Quatro camadas de tokens — prompt, ferramenta, memória, resposta — um único balde oculta os gastos. Escada de aplicação (enforcement) para produtos multi-tenant: limites de taxa por inquilino (2-3x o pico esperado, 429 claro + retry-after); teto de gastos diários (1.5-3x o limite contratado; aciona aperto no limite de taxa + alerta); chaves de desligamento (kill switches) quando o z-score de gastos for > 4 (auto-pausa + notificação de plantão). Padrões de atribuição: marcar e agregar (tag-and-aggregate), junção de telemetria (telemetry-joiner: ID de rastreamento → faturamento; maior precisão), amostragem e extrapolação, alocação baseada em modelo, event-sourced, streaming em tempo real. Métrica unitária: custo por consulta resolvida, custo por artefato gerado — não $/M tokens. A marcação retroativa sempre falha; instrumente na criação da requisição.

Tipo: Learn Linguagens: Python (stdlib, simulador simples de atribuição de custo com chave de desligamento) Pré-requisitos: Fase 17 · 13 (Observabilidade), Fase 17 · 14 (Caching) Tempo: ~60 minutos

Objetivos de Aprendizado

• Explicar por que o FinOps tradicional (tags + níveis) falha nos gastos com LLMs e nomear as três novas dimensões de atribuição.
• Enumerar as quatro camadas de tokens (prompt, ferramenta, memória, resposta) e por que o faturamento em balde único oculta o custo.
• Projetar uma escada de aplicação (limite de taxa → teto de gastos → chave de desligamento) para um produto multi-tenant.
• Escolher uma métrica unitária (custo por consulta resolvida / artefato) em vez de $/M tokens.

O Problema

Sua fatura indica $40.000. Você não sabe:

• Qual inquilino gastou isso.
• Qual funcionalidade do produto impulsionou o gasto.
• Se algum usuário individual foi abusivo.
• Se o culpado foi o inchaço do prompt, chamadas de ferramentas ou amplificação de memória.

A marcação e agregação no lado do provedor funciona para recursos em nuvem (EC2, S3) onde as tags se propagam para os itens de linha. As chamadas de API de LLM não fazem marcação automática — você precisa registrar o usuário/tarefa/inquilino no local da chamada e carregar esses dados adiante. A atribuição retroativa sempre perde casos extremos.

O Conceito

Três dimensões de atribuição

Por usuário (user_id): quem está custando o quê. Direciona a precificação de assentos, conversas de expansão e identifica usuários avançados.

Por tarefa (task_id + route): qual superfície do produto custa o quê. Direciona a priorização de funcionalidades e decisões de desativação de recursos caros.

Por inquilino (tenant_id): qual cliente é lucrativo. Direciona a economia unitária, preços de renovação e limites de faixas (tiers).

Instrumente todos os três no local da chamada desde o primeiro dia. O retroativo é sempre pior.

Quatro camadas de tokens

Agrupar todas as quatro camadas impossibilita a otimização focada. Separe-as no seu esquema de atribuição.

Escada de aplicação

1. Limite de taxa (Rate limit) por inquilino. 2-3x o pico esperado. Retorne 429 com Retry-After. O inquilino percebe o atrito; sem faturas surpresa.

2. Teto de gastos diários (Daily spend cap) por inquilino. 1.5-3x o teto contratado. Gatilho: estreitar o limite de taxa + alertar o customer success.

3. Chave de desligamento (Kill switch) quando o z-score de gastos for > 4 em relação à linha de base do inquilino. Pausa automática do inquilino; aciona o plantão (page); encaminha para operações + CS.

Padrões de atribuição

• Marcar e agregar (Tag-and-aggregate): carimba cabeçalhos de metadados; agrega mais tarde. Simples; impreciso.
• Junção de telemetria (Telemetry joiner): associa rastreamentos ao faturamento via IDs de rastreamento. Maior precisão. É o que equipes maduras fazem.
• Amostragem + extrapolação: coleta amostragem de 5-10%, multiplica. Custo-benefício bom para gastos aproximados; perde o comportamento de cauda.
• Alocação baseada em modelo: regressão para inferir o direcionador de custo. Para dados legados sem tags.
• Baseado em eventos (Event-sourced): custo como eventos em um fluxo (Kafka / Kinesis). Em tempo real.
• Streaming em tempo real: atualizações de painel em menos de um segundo.

Custo por X é a métrica unitária

$/M tokens é jargão de fornecedor. Métricas de produto:

• Custo por ticket de suporte resolvido.
• Custo por artigo gerado.
• Custo por tarefa de agente bem-sucedida.
• Custo por minuto de sessão de usuário.

Aloque o custo a um resultado de produto. Caso contrário, a otimização fica sem âncora.

Formato do rastreamento de atribuição de custo

trace_id: abc123
  user_id: u_42
  tenant_id: t_7
  task_id: task_classify_doc
  route: model_haiku
  layers:
    prompt_tokens: 1800
    tool_tokens: 600
    memory_tokens: 400
    response_tokens: 150
  cost_usd: 0.0135
  cached_input: true
  batch: false

Emita em cada chamada. Armazene em um data lake. Agregue por dimensão. A stack de observabilidade da Fase 17 · 13 é onde isso reside.

A stack de economia composta

Stack: cache + lote (batch) + rota (route) + gateway. Com os quatro:

• Cache L2 (Fase 17 · 14): entrada ~10x mais barata.
• Lote / Batch (Fase 17 · 15): 50% de desconto.
• Rota para modelo barato (Fase 17 · 16): redução de 60% no custo.
• Eficiência do gateway (Fase 17 · 19): redundância + tentativas.

Melhor caso combinado: ~5-10% da linha de base simples. A maioria das equipes tem 2 a 3 alavancas ativas; poucas combinam as quatro.

Números que você deve lembrar

• Dimensões de atribuição: por usuário, por tarefa, por inquilino.
• Quatro camadas de tokens: prompt, ferramenta, memória, resposta.
• Chave de desligamento (Kill switch): z-score de gastos > 4.
• Métrica unitária: custo por consulta resolvida, não $/M tokens.
• Otimizações combinadas: ~5-10% da linha de base é possível.

Use It

O arquivo code/main.py simula um serviço de LLM multi-tenant com a escada de aplicação de três níveis. Injeta um inquilino abusivo e demonstra o acionamento da chave de desligamento.

Ship It

Esta lição produz outputs/skill-finops-plan.md. Com base no produto e na escala, projeta o esquema de atribuição e a escada de aplicação.

Exercícios

1. Execute code/main.py. Em qual z-score a chave de desligamento é acionada? Como você escolhe o limite?
2. Projete um painel de custos por inquilino e por tarefa. Quais são as 5 primeiras visualizações que você construiria?
3. Seu maior inquilino tem economia unitária negativa. Proponha três intervenções ordenadas pelo impacto no cliente.
4. Calcule o custo por ticket resolvido para um produto de suporte: 3M de tokens/ticket, ~800 tickets/dia, taxa com cache do GPT-5.
5. Discuta se a marcação retroativa pode funcionar em algum caso. Quando ela é aceitável?

Termos-Chave

Leituras Recomendadas

• FinOps Foundation — FinOps for AI Overview
• FinOps School — Cost per Unit 2026 Guide
• Digital Applied — LLM Agent Cost Attribution 2026
• PointFive — Managed LLMs in Azure OpenAI