Otimizar o custo para cargas de trabalho de IA no Azure

Este artigo mostra às equipes de startups em estágio inicial como identificar e reduzir custos em cargas de trabalho de IA no Microsoft Azure. Foi escrito para o fundador, o CTO ou o primeiro engenheiro contratado que é responsável pela fatura da nuvem e pelo conjunto de avaliação (eval) ao mesmo tempo. Abrange o uso de tags e as boas práticas de orçamento, as quatro alavancas do caminho da requisição (cache, processamento em lote, roteamento e seleção de modelo), o dimensionamento adequado de GPUs para inferência auto-hospedada, padrões de recuperação para múltiplos locatários e um ciclo seguro de mudanças que você pode executar sem uma equipe de plataforma dedicada. Cada seção é marcada com o estágio do guia de arquitetura Azure para inicializações em que ela se aplica (Explorar, Expandir ou Extrair), para que você possa evitar a otimização para problemas que você ainda não tem.

Neste artigo, você aprenderá a:

  • Identifique os drivers de custo superior em uma carga de trabalho de IA em Azure.
  • Alinhe as alavancas de otimização de custos à fase da sua startup.
  • Aplique cache de prompts, cache semântico, processamento em lote, roteamento de modelos e dimensionamento adequado.
  • Projete padrões multitenant de recuperação de dados e de banco de dados que escalem de forma linear com a receita, e não com o uso.
  • Encapsular alterações de custo em um portão de avaliação, alertas de orçamento e limites de taxa por locatário.
  • Reconheça os primeiros sinais de que uma abordagem de faça-você-mesmo para gerenciar custos já não é suficiente para você.

Prerequisites

  • Uma assinatura do Azure com pelo menos uma carga de trabalho de IA em execução em produção, homologação ou como protótipo funcional.
  • Permissões de proprietário ou colaborador nos recursos que você deseja medir.
  • Facilidade ao abrir o portal do Azure. Nenhuma experiência prévia com o Gerenciamento de Custos ou Azure Monitor é necessária. Este artigo aponta para as páginas relevantes.
  • Um pequeno conjunto de avaliação para seu recurso de IA, contendo de 10 a 50 prompts representativos e comportamentos esperados. Se você ainda não tiver um, consulte a seção Artigos relacionados. Você pode criar a primeira versão em uma tarde.

Por que isso é importante para startups

Para uma inicialização em estágio inicial, o custo de IA é um risco operacional. A inferência mais barata libera horas de engenharia para o próximo experimento, e um custo estável por usuário ativo permite que você planeje além do próximo marco de financiamento em vez da próxima fatura. Os padrões neste artigo são deliberadamente pequenos. Cada um deles é alcançável por um engenheiro fundador durante um fim de semana, sem nenhuma plataforma ou equipe finops necessária.

Importante

Você não precisa de uma equipe dedicada do FinOps para começar. Os primeiros 80% da redução de custos vêm de aplicar tags em tudo desde o primeiro dia, designar uma pessoa responsável por uma revisão semanal de gerenciamento de custos e aplicar as alavancas deste artigo na ordem das etapas. Traga ferramentas e processos formais do FinOps somente depois que os gastos excederem cerca de US$ 50.000 por mês ou cobrirem mais de cinco cargas de trabalho distintas.

Por que o custo de IA aparece de forma diferente do custo de nuvem tradicional

Em uma aplicação web tradicional, sua fatura mensal é composta principalmente por VMs, bancos de dados e tráfego de saída. Normalmente, você pode prever dentro de 10% sabendo quantos usuários você atende. As cargas de trabalho de IA contradizem essa intuição. O mesmo usuário pode custar US$ 0,001 em um minuto e US$ 0,40 no próximo, dependendo do comprimento do contexto, da profundidade de recuperação e para qual modelo a solicitação foi roteada.

Quatro modelos de custo se repetem na maioria dos produtos de IA no Azure:

  • O consumo de tokens aumenta conforme o tamanho do contexto, não o número de usuários. Um prompt de RAG (geração aumentada por recuperação) simplista pode saltar de 800 para 12.000 tokens após uma mudança no produto.
  • O tempo de ociosidade da GPU é o maior custo oculto em inferência auto-hospedada. Um A100 deixado rodando de um dia para o outro custa mais do que um mês de um pequeno banco de dados Postgres.
  • O fan-out de recuperação de bancos de dados de busca e vetoriais se intensifica. Cada turno do chat pode gerar de três a oito consultas ocultas que você nunca vê nos seus logs.
  • A saída e o armazenamento avançam lentamente por meio de artefatos de modelo, inserções, logs de auditoria e índices por locatário.

Cada fator de custo tem um conjunto conhecido de alavancas. As seções restantes descrevem essas alavancas em ordem de prioridade, indicando a fase da startup em que cada uma se aplica, para que as equipes não compliquem demais as soluções para problemas que ainda não enfrentam.

Dica

Use as diretrizes de otimização de custos do Azure Well-Architected Framework em sua arquitetura para sustentar e melhorar seu ROI (retorno sobre o investimento).

O mapa dos estágios: quais alavancas se encaixam em cada etapa

O guia de arquitetura Azure para startups descreve três estágios de desenvolvimento de produtos: Explorar, Expandir e Extrair. As alavancas de otimização de custo neste artigo se alinham a esses estágios. Use a tabela a seguir para definir o escopo de quais seções se aplicam à sua equipe hoje e quais adiar.

Stage Números de funcionários Meta de custo primário Fatores que geram retorno
Explorar 1 a 10 engenheiros Opcionalidade e velocidade Marcação, cache de prompts, modelo padrão barato
Expanda 10-50 engenheiros Acabe com os custos lineares atrelados à receita Cache semântico, escalonamento para zero, roteamento, API de processamento em lote
Extrair Mais de 50 engenheiros Margem, previsibilidade, FinOps Reservas, índices dedicados, quantização, preços por locatário

Identificar seus principais drivers de custo

Antes de otimizar qualquer coisa, tenha uma visão simples de onde o dinheiro está realmente indo. Em Azure, o caminho mais rápido é o Gerenciamento de Custos, agrupado por serviço e marca, nos últimos 30 dias.

Marcar tudo desde o primeiro dia

O uso de tags é a prática de maior impacto para dar visibilidade aos custos. Sem marcas consistentes, você não pode atribuir gastos a um locatário, um recurso ou um ambiente. A arquitetura de referência Startup Scale Landing Zone (SSLZ) impõe a aplicação de tags no nível da política da zona de aterrissagem. Use a mesma abordagem para recursos de IA.

costCenter = product | platform | research
tenant     = <customer-id> | shared
workload   = inference | embedding | training | eval
env        = prod | staging | dev
team       = <owning-team>

Onde procurar primeiro

Driver de custo Onde encontrá-lo Parcela típica da conta
Tokens (API de LLM) Métricas do Azure OpenAI > Tokens processados de prompt/conclusão 30-60%
GPUs Horas de nós de VM/AKS por SKU (famílias ND, NC e NV) 20-50%
Busca vetorial Unidades de consulta de pesquisa de IA, RU/s do Cosmos DB 5 a 20%
Armazenamento Armazenamento de Blobs, Arquivos do Azure e Registro de Contêiner do Azure para artefatos de modelo 3-10%
Egress Largura de banda fora da região, especialmente chamadas entre nuvens 2-15%

Exporte a gestão de custos diariamente para uma conta de armazenamento e conecte-a ao seu stack de análise existente. Um gráfico semanal de custo por usuário ativo é um sinal confiável de que uma otimização teve o efeito pretendido.

Alavanca 1: Cache, envio em lote, roteamento e seleção de modelo

Palco: Explore por meio do Extract. Comece com cache no Explore, adicione roteamento e Batch no Expand e adicione seleção granular de modelos por tenant no Extract.

Dica

Armazene embeddings em cache usando a hash do conteúdo de origem como chave e use um modelo menor e mais barato, como o GPT-4o mini ou um modelo de pesos abertos de 7B a 13B, para classificação ou extração na primeira etapa. Escalone para um modelo de fronteira apenas nas solicitações em que o modelo pequeno é incerto. Esse padrão por si só geralmente reduz o custo de inferência em 60 a 80% sem perda de qualidade mensurável em consultas de rotina.

Caching

  • Cache de prompts: O Azure OpenAI oferece desconto automaticamente para prefixos repetidos em prompts de pelo menos 1.024 tokens, com suporte para os modelos GPT-4o e posteriores. Os primeiros 1.024 tokens devem ser idênticos para atingir o cache, portanto, mantenha os prompts do sistema e as definições de ferramenta estáveis.
  • Semantic cache: Armazene os pares de incorporação e resposta no Cache do Azure para Redis ou no Cosmos DB. Retorne a resposta em cache quando uma nova consulta tiver similaridade de cosseno superior a aproximadamente 0,95.
  • Cache de saída: Para endpoints não personalizados, como perguntas frequentes e ferramentas determinísticas, um cache simples com TTL (tempo de vida) reduz o tráfego em 30 a 80%.

Processamento em Lotes

Os trabalhos de inserção e classificação são os candidatos óbvios. A API de Lote do Azure OpenAI oferece um desconto de 50% em comparação com o processamento em tempo real para tarefas que podem esperar até 24 horas, como atualizações noturnas de índice, execuções de avaliadores e sumarização assíncrona.

Routing

A maioria dos produtos não precisa do modelo mais caro em cada chamada. Um roteador, baseado em regras ou aprendido, pode enviar de 60 a 80% do tráfego para um modelo mais barato sem queda de qualidade mensurável.

Pattern Caminho barato Caminho caro
Classificação de intenção GPT-4o mini ou Phi-4 GPT-4o para solicitações ambíguas
Uso da ferramenta ou chamada de função Modelo de camada intermediária Modelo de primeira linha na nova tentativa
Resumo de contexto longo Janela deslizante com modelo intermediário Modelo de alto nível com contexto completo
Geração de código Modelo de nível intermediário para texto padrão Modelo de camada superior para refatorações

Seleção de modelo

Reavaliar a opção do modelo a cada trimestre. Os preços e a qualidade se movem rapidamente. Um modelo que era sua única opção há seis meses agora pode ser cinco vezes mais caro do que um SKU mais recente que pontua dentro de um a dois pontos em seus evals.

Alavanca 2: Infraestrutura de tamanho certo com dimensionamento automático

Etapa: Expandir e extrair. No Explore, use paaS (plataforma como serviço) sem servidor, como Serviço de Aplicativo, Consumo de Aplicativos de Contêiner ou Serviço OpenAI do Azure e ignore essa alavanca.

Se você hospeda por conta própria a inferência com vLLM, Triton ou Text Generation Inference (TGI) no AKS (Serviço de Kubernetes do Azure) ou no Container Apps, seu segundo fator de maior impacto é garantir que as GPUs não fiquem ociosas.

Reduzir para zero para cargas de trabalho ociosas

Defina minReplicas: 0 no Container Apps com um perfil de carga de trabalho de GPU ou use o Horizontal Pod Autoscaling (HPA) ou o KEDA no AKS para dimensionar os pools de nós para zero quando não houver solicitações em andamento. As inicializações a frio geralmente levam dezenas de segundos. Teste o desempenho com seu modelo e mantenha uma réplica ativa durante o expediente se a latência percebida pelo usuário for importante.

Dimensione o SKU da GPU de acordo com o tamanho do modelo

Associe a classe de GPU ao número de parâmetros. T4 ou L4 é suficiente para modelos abaixo de aproximadamente 13B parâmetros. A100 ou H100 só compensam para modelos com mais de aproximadamente 34 bilhões de parâmetros ou uma alta taxa sustentada de consultas por segundo (QPS). Atualmente, a GPU serverless do Container Apps oferece suporte a T4 e A100. L4 e H100 exigem AKS.

Treinamento de intermitência e trabalhos em lotes para detectar

Execute as avaliações noturnas, inserindo atualizações e resumo offline em pools de nós spot, que normalmente são 60 a 80% mais baratos do que sob demanda. Mantenha a inferência de produção na capacidade dedicada. A tabela a seguir resume as estratégias de dimensionamento automático e suas economias típicas.

Caution

A capacidade Spot pode ser encerrada com apenas 30 segundos de aviso prévio. Use apenas o spot para o trabalho que pode ser verificado ou reiniciado de forma limpa, como avaliações em lote, atualizações de inserção, resumo offline e ajuste fino com pontos de verificação frequentes. Nunca coloque inferência ou trabalhos voltados para o usuário sem reiniciar a lógica no local.

Strategy Como Economia típica
Escala para zero minReplicas: 0 em Aplicativos de Contêiner com perfil de carga de trabalho de GPU. As inicializações a frio geralmente levam dezenas de segundos. Faça um benchmark com seu modelo. Até 90%
KEDA com base na profundidade da fila Escale com base no Barramento de Serviço ou nas mensagens da fila, não no uso da CPU. 30-60%
SKU com dimensionamento adequado T4 ou L4 para modelos com menos de 13B parâmetros. A100 ou H100 somente para modelos com mais de 34B parâmetros ou QPS alto. Atualmente, o suporte a GPUs sem servidor no Container Apps oferece suporte apenas às T4 e A100. L4 e H100 exigem AKS. 40-70%
Capacidade de spot Conjuntos de nós spot para processamento em lote e avaliação. Capacidade sob demanda para produção. 40-80%
Quantização Quantização de 4 bits com AWQ ou GPTQ para acomodar modelos maiores em GPUs menores. Colocar 30B em 16 GB

Note

Escalar para zero na interface de chat adiciona latência visível de inicialização a frio. Um padrão comum é manter uma a duas réplicas quentes durante o horário comercial e dimensionar para zero durante a noite.

Alavanca 3: Padrões multitenant sem picos no custo de recuperação

Estágio: Expansão e extração tardias. No Explore, você quase certamente tem um locatário: você mesmo. Ignore esta seção até ter pelo menos três clientes reais.

Os produtos de IA multilocatários falham em escala quando os padrões de recuperação e de banco de dados foram escolhidos para o protótipo de locatário único. Três padrões são recorrentes.

Um índice por locatário versus índice compartilhado com filtros

Um índice de busca por IA dedicado para cada locatário oferece isolamento completo, mas há cobrança por cada índice, mesmo quando está ocioso. Um índice compartilhado com um filtro de locatário é muito mais barato em escala pequena e média. Alterne para dedicado somente para o nível empresarial ou quando um locatário exceder um limite de tamanho predefinido.

Escolha do banco de dados vetor

Escolha seu repositório de vetores com base na infraestrutura e na escala existentes. A tabela a seguir resume quando cada opção se encaixa.

Warning

Excluir um índice de vetor ou seu repositório subjacente é irreversível, e a reinserção de um corpus grande pode custar centenas a milhares de dólares em chamadas de modelo mais horas de tempo de engenharia. Antes de qualquer alteração destrutiva em um repositório vetorial, faça um snapshot dos documentos de origem e verifique se o pipeline de re-embedding funciona de ponta a ponta em um pequeno subconjunto.

Option Melhor para Perfil de custo
Pesquisa de IA do Azure  (vetorial) Busca híbrida e facetas Para cada réplica, previsível
Cosmos DB (vetor) O Teams já está usando o Cosmos DB para dados do aplicativo RU/s, dimensionamento com QPS
pgvector no Postgres Pequenas ou médias corporações, operações simples Por VM, muito barato
Banco de dados de vetor dedicado 100M+ vetores, altas necessidades de recall Por nó, caro

Evitar recuperações N+1 ocultas

Cada etapa do agente que chama search é uma consulta faturável. Registre o número de chamadas de recuperação de logs por turno do usuário e emita um alerta quando a mediana exceder seu orçamento. Uma boa meta inicial é duas recuperações ou menos por turno. Reranqueadores e reescritores são pontos em que é fácil duplicar o tráfego sem querer.

Governança: manter as alterações de custo seguras

Estágio: Todos os estágios. A versão mais leve, que inclui um orçamento, uma checagem de avaliação em uma linha antes da implantação e um único limite de taxa, deve estar no Explore desde o primeiro dia. A versão mais robusta, com gates de avaliação que bloqueiam a CI e limites de taxa por locatário no API Management, pertence à fase Expand e posteriores.

Uma otimização que quebra a qualidade não é uma otimização. É uma interrupção. Embrulhe cada alteração de custo em três guardrails. Cada guardrail pode ser configurado em menos de uma hora por um único engenheiro.

  1. Verificação de avaliação: Execute o conjunto de avaliações antes de implantar qualquer alteração de prompt, modelo ou roteamento. No estágio inicial, essa verificação pode ser um script executado manualmente. Bloqueie a implantação ou reverta a implantação se a pontuação cair além da tolerância definida, por exemplo, um ponto em uma escala de 100 pontos.
  2. Alertas de orçamento: Defina orçamentos do Gerenciamento de Custos do Azure para cada grupo de recursos com alertas de 50%, 80% e 100%. Encaminhe-os para o mesmo canal do Slack ou do Teams que recebe suas notificações de erro, para que os gastos e os incidentes sejam enviados para o mesmo lugar.
  3. Limite de taxa de solicitação: Até mesmo um único limite por IP ou por chave de API no Gerenciamento de API, no NGINX ou no gateway impede que um cliente fugitivo esvazie o saldo de crédito durante a noite. Adicione limites por locatário posteriormente quando você tiver clientes pagantes.

Tenha cuidado ao agrupar várias otimizações de custo em uma única versão. Quando o conjunto de alterações se encaixa, a atribuição se torna difícil e qualquer regressão é cara para bissectar.

O experimento de duas alavancas: como comparar antes e depois

Quando você estiver decidindo por onde começar, escolha duas alavancas das seções anteriores, envie-as atrás de um sinalizador de recurso e meça por 7 a 14 dias. Duas alavancas são suficientes para detectar movimentos significativos. Mais de dois torna a atribuição não confiável.

Primeiro par sugerido por estágio

Stage Alavanca A Alavanca B
Pré-lançamento (<100 DAU) Armazenamento de prompts em cache Roteamento de modelos com um modelo padrão de baixo custo
Tração inicial (100-10k DAU) Cache semântico Escalonamento até zero na inferência
Escala (10 mil+ DAU) API em lote para processamento assíncrono Estratégia de índice por cliente
Nível empresarial Índices dedicados às principais contas Modelos quantizados em L4 ou H100 
Baseline window:   2026-04-15 to 2026-04-28 (14 days)
Treatment window:  2026-05-01 to 2026-05-14 (14 days)
Levers shipped:    1) semantic cache on /chat
                   2) scale-to-zero on vLLM

Metrics:
  cost_per_active_user   (target: down 30%)
  p95_latency_ms         (guardrail: +<= 150 ms)
  eval_score_delta       (guardrail: >= -1.0)

Decision rule: Keep both if all guardrails hold. Otherwise, revert and ship one at a time.

O que este artigo aborda e o que ele não aborda

Este artigo tem escopo intencional. As seções a seguir listam tópicos que estão no escopo, tópicos fora do escopo e os sinais que indicam quando adicioná-los.

Dentro do escopo

  • Marcação, orçamentos e práticas de Gerenciamento de Custos apropriadas para qualquer inicialização.
  • As quatro alavancas de caminho de solicitação: cache, envio em lote, roteamento e seleção de modelo.
  • Dimensionamento adequado de GPU e redução para zero para inferência auto-hospedada.
  • Padrões de recuperação multitenant para produtos com entre três e 100 clientes pagantes.
  • Um loop de governança de alteração segura: porta de avaliação, alertas de orçamento e limites de taxa por locatário.

Fora do escopo

Tópico Quando adicionar
Reservas e planos de economia para computação de IA O custo de inferência permanece estável por 90 dias, geralmente em meados do Expand.
Ferramentas dedicadas do FinOps, como Apptio Cloudability, Vantage e ferramentas semelhantes Os gastos com nuvem excedem aproximadamente US$ 50.000 por mês ou você opera várias nuvens. A maioria das startups em estágio inicial não precisa disso.
Cobrança personalizada baseada em token por cliente final Você vende preços baseados em uso ou um locatário excede 25% da fatura.
Otimização de custo de treinamento, como ajuste de DeepSpeed e FSDP Você treina modelos internamente. Produtos voltados para inferência não precisam disso.
Arbitragem de custo entre regiões ou várias nuvens Você está na etapa "Extract", com viabilidade econômica já comprovada em uma única região.

Quando essa abordagem não for mais suficiente

As práticas neste artigo são projetadas para equipes pequenas que executam sua própria nuvem. Em algum momento, seu negócio os supera. Os sinais a seguir não são falhas. Eles estão crescendo. Quando houver dois ou mais desses casos, planeje contar com ferramentas dedicadas ou com um responsável pela plataforma em meio período.

  • Os gastos mensais Azure excedem aproximadamente US$ 50.000, e a IA é mais de 30% dela.
  • Mais de 10 engenheiros podem enviar alterações que movem o custo em 5% ou mais.
  • Pelo menos um cliente tem uso acima de US$ 10.000 por mês e está pagando uma taxa fixa.
  • Seus investidores ou parceiros financeiros começaram a pedir uma previsão de custo mensal.
  • O produto é executado em mais de uma Azure região ou nuvem.

Até lá, o ciclo enxuto descrito neste artigo, que inclui tags, orçamentos, um gate de avaliação e uma revisão mensal, continua sendo a ferramenta certa. Resista à tentação de adotar muito cedo ferramentas FinOps de nível empresarial. Ele adiciona sobrecarga de processo antes de agregar valor.

Lista de verificação de referência

Use os itens a seguir como uma lista de verificação de revisão mensal. Cada item é mapeado para uma seção neste artigo.

  • Todos os recursos de IA são marcados com costCenter, tenante workloadenv.
  • Um painel de Gerenciamento de Custos existe, é agrupado por marca e é revisado semanalmente.
  • Os prompts do sistema são estáveis o suficiente para ocorrências de prompt-cache.
  • Tarefas assíncronas, como embeddings, avaliações e resumos, são executadas na API de Batch.
  • O roteador envia pelo menos 60% do tráfego para um modelo mais barato sem regressão de avaliação.
  • As cargas de trabalho de GPU podem ser reduzidas a zero fora do horário comercial ou usar instâncias spot para processamento em lote.
  • A contagem mediana por turno de recuperação é de dois ou menos.
  • A estratégia multitenant é escolhida explicitamente: compartilhada com filtragem ou dedicada.
  • Os orçamentos e os limites de taxa por locatário são aplicados.
  • Cada prompt, modelo ou alteração de roteamento passa pela etapa de avaliação antes de ser incorporada.
  • Last updated on