Sua empresa tem dezenas de deploys de modelos. Alguém sabe quais são, de quem são e quanto custam?

Pergunte a um time de plataforma de uma grande empresa três coisas: quais modelos de IA estão implantados na organização, quem é dono de cada um e quanto cada um custou no mês passado. Em muitas empresas, a resposta honesta leva uma semana e uma planilha, porque os deploys foram criados por times diferentes, em assinaturas e regiões diferentes, para projetos diferentes, ao longo de dois anos.

O time Mission Critical da Microsoft publicou em 16 de outubro uma arquitetura de referência para responder a essas perguntas de forma contínua no Azure. Não é um produto novo e não substitui o monitoramento dentro do Microsoft Foundry. É uma forma de construir uma visão de grupo de gerenciamento ou de todo o tenant em cima de serviços que a maioria dos clientes Azure já tem. As escolhas de design são úteis muito além do Azure.

Quatro tipos de dados, mantidos separados

Quatro planos de uma visão de operações de modelos

Inventário

• Azure Resource Graph em todas as assinaturas
• Deployments API por conta
• Modelo, versão, tipo de deploy, tags de dono

Estado atual

Uso

• Métricas e logs do Azure Monitor
• Requisições, tokens, erros, utilização de PTU

Série temporal

Custo

• Consultas ou exports do Cost Management
• Cruzados por ID de recurso e tags

Dados de cobrança, podem atrasar

Cota

• Por assinatura, modelo e região

Um sinal de capacidade, não de gasto

A arquitetura trata esses dados como tipos diferentes, não como um único feed. Inventário vem do Azure Resource Graph, que consulta em todas as assinaturas, combinado com a API de deployments de cada conta: modelo, versão, tipo de deploy, capacidade, região e tags como dono, ambiente e unidade de negócio. Uso vem do Azure Monitor: requisições, tokens, erros, indicadores de latência e utilização de unidades de throughput provisionadas. Custo vem das APIs ou exports do Cost Management. Cota é acompanhada separadamente, porque é um limite de capacidade, não de gasto, e a cota do Azure OpenAI é aplicada por assinatura, não por tenant, então um resumo executivo pode esconder a assinatura que está prestes a bater no teto.

Os públicos também diferem. Engenheiros de plataforma recebem Azure Workbooks para drill-down; a área financeira recebe Power BI, com uma ressalva: o conector do Cost Management está documentado para clientes com Enterprise Agreement e Microsoft Customer Agreement direto, e os demais devem usar exports. Donos de aplicação recebem um pequeno scorecard: seus deploys, uso, custo, cota e próxima ação necessária.

Apenas metadados, de propósito

O princípio de design que vale sublinhar é o primeiro que a Microsoft declara: o dashboard não coleta prompts, completions, dados de clientes ou outros payloads, a menos que um design separado de privacidade e segurança exija isso. Um time central consegue ver cada deploy, seu dono, seu tráfego e seu custo sem ganhar acesso ao que qualquer pessoa pediu a um modelo. Isso evita que a visão de governança se torne uma nova cópia de dados sensíveis, que é a questão de custódia que a maioria dos designs de observabilidade acaba enfrentando.

A visão de higiene é a visão de governança

Das cinco visões propostas (resumo executivo, inventário, operações, alocação de custos e higiene de governança), a última é a que deve ser construída primeiro. Ela lista deploys com tags faltando, deploys sem dono, versões antigas de modelos e concentração regional.

Cada um desses itens é um risco com data marcada. Versões antigas de modelos são as migrações forçadas do próximo trimestre, do tipo que avisos recentes de desativação colocam no calendário. Um deploy sem dono é um custo que ninguém aprova e um modelo que ninguém vai migrar. Concentração regional é uma questão de resiliência e residência de dados. Uma lista de higiene transforma isso em tickets com nomes.

A Microsoft é direta sobre o pré-requisito: ‘Dashboards não criam responsabilização se os recursos não carregam metadados de dono, aplicação, ambiente e centro de custo.’ Exija as tags no momento do deploy, com Azure Policy ou o pipeline de deploy, antes de construir qualquer relatório em cima delas. Caso contrário, o número mais preciso no dashboard será a contagem de coisas que ninguém possui.

Além do Azure

Os quatro planos não são específicos do Azure. Toda cloud e todo gateway de modelos pode produzir uma visão de inventário, uso, custo e cota, e a maioria das empresas usa mais de um. A arquitetura é um bom modelo para o inventário de agentes e modelos entre fornecedores que os times de governança continuam pedindo. Três limites merecem ser ditos: inventário e contagem de tokens não dizem nada sobre se um deploy gera valor ou saída correta; algumas métricas do Azure têm restrições de exportação; e partes da orientação de monitoramento da Microsoft ainda descrevem o portal clássico do Foundry, então verifique o que se aplica ao seu ambiente antes de padronizar com base nisso.