Otimizar custos para cargas de trabalho de IA no Azure

Este artigo mostra as equipas de startups em fase inicial como identificar e reduzir custos em cargas de trabalho de IA no Microsoft Azure. Foi escrito para o fundador, o CTO ou a primeira contratação para a engenharia que é responsável, ao mesmo tempo, pela fatura da cloud e pelo conjunto de avaliação (eval). Aborda a etiquetagem e a higiene orçamental, as quatro alavancas do percurso dos pedidos (cache, agrupamento, encaminhamento e seleção de modelos), o dimensionamento adequado da GPU para inferência autoalojada, padrões de recuperação multicliente e um ciclo de alterações seguras que pode pôr em prática sem uma equipa de plataforma dedicada. Cada secção está marcada com o estágio do guia de arquitetura Azure para startups onde se aplica (Explorar, Expandir ou Extrair), para evitar otimizar para problemas que ainda não tens.

Neste artigo, você aprenderá a:

• Identifique os principais fatores de custo numa carga de trabalho de IA no Azure.
• Ajuste as alavancas de otimização de custos à fase inicial da sua startup.
• Aplique o armazenamento em cache de instruções, o armazenamento em cache semântico, o processamento em lote, o roteamento de modelos e o dimensionamento adequado.
• Conceber padrões de pesquisa multitenant e de bases de dados que escalem linearmente com a receita, e não com o uso.
• Enquadre as alterações de custos num mecanismo de validação, em alertas orçamentais e em limites de taxa por locatário.
• Reconheça os primeiros sinais de que uma abordagem faça-você-mesmo para gerir os custos já deixou de ser suficiente.

Pré-requisitos

• Uma subscrição do Azure com pelo menos uma carga de trabalho de IA em execução em produção, em pré-produção ou num protótipo funcional.
• Permissões de Proprietário ou Contribuinte sobre os recursos que pretende medir.
• Facilidade ao abrir o portal do Azure. Não é necessária experiência prévia com Gestão de Custos ou Azure Monitor. Este artigo encaminha-te para as páginas relevantes.
• Um pequeno conjunto de avaliações para a sua funcionalidade de IA, com 10 a 50 prompts representativos e comportamentos esperados. Se ainda não tens um, consulta a secção de Artigos Relacionados. Podes construir a primeira versão numa tarde.

Por que isto é importante para startups

Para uma startup em fase inicial, o custo da IA é um risco operacional. Uma inferência mais barata liberta horas de engenharia para o próximo experimento, e um custo estável por utilizador ativo permite-lhe planear para além do próximo marco de financiamento em vez da próxima fatura. Os padrões neste artigo são deliberadamente pequenos. Cada uma é possível por um engenheiro fundador durante um fim de semana, sem necessidade de plataforma ou equipa FinOps.

Importante

Não precisa de uma equipa dedicada de FinOps para começar. Os primeiros 80 por cento dos ganhos de custos vêm de etiquetar tudo desde o primeiro dia, colocar uma pessoa responsável por uma revisão semanal de Gestão de Custos e aplicar as alavancas deste artigo por ordem de etapas. Implemente ferramentas e processos FinOps formais apenas depois de o gasto ultrapassar cerca de $50.000 por mês ou cobrir mais de cinco cargas de trabalho distintas.

Porque é que o custo da IA se manifesta de forma diferente do custo tradicional da cloud

Numa aplicação web tradicional, a sua fatura mensal é composta maioritariamente por VMs, bases de dados e tráfego de saída. Normalmente, consegue-se prever isso dentro de 10 por cento sabendo quantos utilizadores serve. As cargas de trabalho de IA quebram essa intuição. O mesmo utilizador pode custar $0,001 num minuto e $0,40 no seguinte, dependendo do comprimento do contexto, da profundidade de recuperação e do modelo para o qual o pedido foi encaminhado.

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

• O gasto em tokens escala com o comprimento do contexto, não com o número de utilizadores. Um prompt rudimentar de geração aumentada com recuperação (RAG) pode passar de 800 para 12 000 tokens após uma única alteração ao produto.
• O tempo de inatividade da GPU é o maior custo oculto na inferência auto-hospedada. Ter um A100 a funcionar durante toda a noite custa mais do que um mês de uma pequena base de dados Postgres.
• A ramificação da recuperação a partir de bases de dados de pesquisa e de vetores agrava-se. Cada turno de chat pode emitir entre três a oito perguntas ocultas que nunca vês nos teus registos.
• A saída de dados e o armazenamento infiltram-se lentamente em artefactos de modelo, incorporações vetoriais, registos de auditoria e índices por cliente.

Cada gestor de custos tem um conjunto conhecido de alavancas. As secções restantes descrevem essas alavancas por ordem de prioridade, identificadas com a fase de arranque em que cada alavanca se aplica, para que as equipas não criem soluções excessivamente complexas para problemas que ainda não têm.

Sugestão

Use as orientações de otimização de custos do Framework Azure Well-Architected na sua arquitetura para sustentar e melhorar o retorno do investimento (ROI).

Mapa das etapas: onde se enquadra cada alavanca

O guia de arquitetura Azure para startups descreve três fases do desenvolvimento do produto: Explorar, Expandir e Extrair. As alavancas de otimização de custos neste artigo alinham-se com essas fases. Use a tabela seguinte para definir quais secções se aplicam à sua equipa hoje e quais devem adiar.

Stage	Número de colaboradores	Objetivo principal de custos	Alavancas que compensam
Explorar	1-10 engenheiros	Opcionalidade e velocidade	Etiquetagem, cache de prompts, modelo padrão barato
Expandir	10 a 50 engenheiros	Acabe com os custos lineares em função da receita	cache semântica, escala até zero, encaminhamento, API de processamento em lote
Extrair	50+ engenheiros	Margem, previsibilidade, FinOps	Reservas, índices dedicados, quantização, preços por inquilino

Identifique os principais fatores de custo

Antes de otimizar qualquer coisa, tenha uma visão plana de para onde o dinheiro realmente vai. No Azure, o caminho mais rápido é a Gestão de Custos, agrupada por serviço e tag, nos últimos 30 dias.

Identifica tudo desde o primeiro dia

A etiquetagem é a prática com maior impacto para dar visibilidade aos custos. Sem etiquetas consistentes, não se pode atribuir o gasto a um inquilino, uma funcionalidade ou um ambiente. A referência da Zona de Aterragem em Escala de Arranque (SSLZ) impõe a marcação ao nível da política da zona de aterragem. 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

Fator de custo	Onde encontrá-lo	Parte típica da fatura
Tokens (LLM API)	Métricas do Azure OpenAI > Tokens de prompt/conclusão processados	30-60%
GPUs	Horas dos nós VM/AKS por SKU (famílias ND, NC e NV)	20-50%
Vetor/pesquisa	Unidades de consulta de pesquisa por IA, Cosmos DB RU/s	5-20%
Armazenamento	Armazenamento de Blobs, Ficheiros do Azure e Azure Container Registry para artefactos do modelo	3-10%
Egress	Largura de banda fora da região, especialmente chamadas entre clouds	2-15%

Exporte a Gestão de Custos para uma conta de armazenamento diariamente e ligue-a à sua stack de análises existente. Um gráfico semanal do custo por utilizador ativo é um sinal fiável de que uma otimização teve o efeito pretendido.

Alavanca 1: Cache, agrupamento, roteamento e seleção de modelos

Palco: Explora através do Extract. Comece com cache no Explore, adicione routing e Batch no Expand, e adicione seleção detalhada de modelos por tenant no Extract.

Sugestão

Armazene os embeddings em cache, indexados com base no hash do conteúdo de origem, e utilize um modelo mais pequeno e mais barato, como o GPT-4o mini ou um modelo com pesos abertos de 7B a 13B, para uma primeira fase de classificação ou extração. Escale para um modelo fronteira apenas nos pedidos onde o modelo pequeno é incerto. Este padrão por si só muitas vezes reduz o custo de inferência em 60 a 80 por cento sem perda mensurável de qualidade em consultas rotineiras.

Caching

• Cache de prompts: O Azure OpenAI aplica automaticamente descontos a prefixos repetidos em prompts com, pelo menos, 1.024 tokens, disponível no GPT-4o e em modelos mais recentes. Os primeiros 1.024 tokens devem ser idênticos para entrar na cache, por isso mantenha estáveis os prompts do sistema e as definições das ferramentas.
• Cache semântica: Armazene pares de incorporações e respostas no Cache do Azure para Redis ou no Cosmos DB. Devolva a resposta armazenada em cache quando uma nova consulta tiver uma similaridade de cosseno superior a aproximadamente 0,95.
• Cache de saída: Para endpoints não personalizados, como FAQs e ferramentas determinísticas, uma cache de tempo para viver (TTL) simples reduz o tráfego entre 30 a 80 por cento.

Processamento em Lotes

As tarefas de incorporação vetorial e de classificação são as candidatas óbvias. A API Azure OpenAI Batch oferece um desconto de 50 por cento em comparação com o tempo real para trabalhos que podem esperar até 24 horas, como atualizações noturnas de índices, execuções de avaliadores e resumos assíncronos.

Roteamento

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

Pattern	Caminho barato	Caminho caro
Classificação por intenção	GPT-4o mini ou Phi-4	GPT-4o para solicitações ambíguas
Utilização de ferramentas ou invocação de funções	Modelo intermédio	Modelo de topo em nova tentativa
Resumo de contexto extenso	Janela deslizante com modelo de gama média	Modelo de contexto completo de topo
Geração de código	Modelo de nível intermédio para modelo-base	Modelo de topo para refatorações

Seleção de modelos

Reavalie a escolha do modelo a cada trimestre. Os preços e a qualidade mudam rapidamente. Um modelo que era a sua única opção há seis meses pode agora ser cinco vezes mais caro do que um SKU mais recente que marca entre um a dois pontos nas suas avaliações.

Pilar 2: Dimensionar corretamente a infraestrutura com escalabilidade automática

Fase: Expansão e Extração. No Explorador, utilize serverless ou uma plataforma como serviço (PaaS), como o App Service, o Container Apps no escalão de consumo ou o Azure OpenAI Service, e ignore esta opção.

Se auto-hospedar inferência com vLLM, Triton ou Text Generation Inference (TGI) no Azure Kubernetes Service (AKS) ou Container Apps, a sua segunda maior alavanca é garantir que as GPUs não estão ociosas.

Reduzir para zero em cargas de trabalho inativas

Defina minReplicas: 0 em Container Apps com um perfil de carga de trabalho com GPU, ou utilize o Horizontal Pod Autoscaling (HPA) ou o KEDA no AKS para dimensionar os conjuntos de nós até zero quando não houver pedidos em curso. Os arranques a frio duram normalmente dezenas de segundos. Faz testes de referência usando o teu modelo e mantém uma réplica ativa durante o horário de trabalho, se a latência percebida pelo utilizador for importante.

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

Faça corresponder a classe da GPU ao número de parâmetros. T4 ou L4 é suficiente para modelos abaixo de aproximadamente 13B de parâmetros. O A100 ou o H100 só compensa para modelos com mais de aproximadamente 34 mil milhões de parâmetros ou com consultas por segundo (QPS) consistentemente elevadas. A GPU sem servidor do Container Apps suporta atualmente T4 e A100. L4 e H100 exigem AKS.

Formação rápida e trabalhos em lote para identificar

Execute avaliações noturnas, atualizações de embedding e resumos offline em pools de nós localizados, que normalmente são 60 a 80 por cento mais baratos do que o on-demand. Mantenha a inferência de produção numa capacidade dedicada. A tabela seguinte resume as estratégias de dimensionamento automático e as suas poupanças típicas.

Atenção

A capacidade Spot pode ser interrompida com um aviso prévio de apenas 30 segundos. Use o Spot apenas para trabalhos que possam ser checkpointeados ou reiniciados de forma limpa, como avaliações em lote, atualizações de embedding, resumo offline e ajuste fino com checkpoints frequentes. Nunca coloques inferências ou trabalhos voltados para o utilizador sem lógica de reinício no local.

Strategy	Como	Poupanças típicas
Reduzir para zero	minReplicas: 0 em Aplicações Container com perfil de carga de trabalho da GPU. Os arranques a frio duram normalmente dezenas de segundos. Faz benchmarks com o teu modelo.	Até 90%
KEDA com base na profundidade da fila	Dimensione com base nas mensagens do Service Bus ou da fila, e não na CPU.	30-60%
SKU com a dimensão adequada	T4 ou L4 para modelos com menos de 13B de parâmetros. A100 ou H100 apenas para modelos com mais de 34B parâmetros ou QPS elevado. As GPU serverless do Container Apps suportam atualmente apenas T4 e A100. L4 e H100 exigem AKS.	40-70%
Capacidade do local	Pools de nós Spot para processamento em lote e avaliação. Capacidade de produção sob demanda.	40-80%
Quantização	Quantização AWQ ou GPTQ de 4 bits para adaptar modelos maiores em GPUs mais pequenas.	Ajuste 30B em 16 GB

Note

Reduzir para zero numa interface de chat introduz uma latência visível de arranque a frio. Um padrão comum é manter uma ou duas réplicas quentes durante o horário comercial e reduzir para zero durante a noite.

Pilar 3: Padrões multitenant sem picos de custos de consulta

Fase: Expansão e extração tardias. No Explore, quase de certeza tens um inquilino: tu próprio. Ignora esta secção até teres pelo menos três clientes reais.

Os produtos de IA multicliente falham à escala quando os padrões de recuperação de dados e de base de dados foram escolhidos para o protótipo de cliente único. Três padrões repetem-se.

Um índice por inquilino vs. índice partilhado com filtros

Um índice de pesquisa de IA dedicado por tenant oferece isolamento total, mas implica custos por cada índice, mesmo quando não está a ser utilizado. Um índice partilhado com um filtro de inquilino é muito mais barato em escala pequena e média. Passe para dedicado apenas para a camada Enterprise ou quando um tenant exceder um limite de dimensão predefinido.

Escolha de base de dados vetorial

Escolha o seu armazenamento vetorial com base na infraestrutura existente e na escala. A tabela seguinte resume quando cada opção se encaixa.

Warning

Eliminar um índice vetorial ou o seu armazenamento subjacente é irreversível, e reincorporar um grande corpus pode custar centenas a milhares de dólares em chamadas de modelos, além de horas de engenharia. Antes de qualquer alteração destrutiva num armazenamento vetorial, faça snapshots dos documentos de origem e verifique se o seu pipeline de reembedding corre de ponta a ponta num pequeno subconjunto.

Option	Melhor para	Estrutura de custos
Pesquisa de IA do Azure (vetor)	Pesquisa híbrida e facetas	Por réplica, previsível
Cosmos DB (vetor)	Equipas que já usam o Cosmos DB para dados de aplicações	RU/s, aumenta com QPS
pgvector no Postgres	Corpora pequenos ou médios, operações simples	Por VM, muito barato
Base de dados vetorial dedicada	Vetores 100M+, necessidades elevadas de recordação	Por nó, dispendioso

Evitar recuperações ocultas de N+1

Cada passo do agente que invoca search é um pedido faturável. Regista o número de chamadas de recuperação por cada turno do utilizador e emite um alerta quando a mediana ultrapassar o orçamento definido. Um bom objetivo inicial é duas recuperações ou menos por turno. Os reranqueadores e os reescritores são pontos onde é fácil duplicar o tráfego sem querer.

Governação: manter as alterações de custos seguras

Fase: Todas as fases. A versão simplificada, que inclui um orçamento, uma verificação de avaliação numa única linha antes da implementação em produção e um limite único de pedidos, deve fazer parte do 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 ao Expand e às fases seguintes.

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

1. Verificação de avaliação: Executa o teu conjunto de avaliação antes de implementar qualquer indicação, modelo ou alteração de roteamento. Na fase inicial, esta verificação pode ser um script que executas manualmente. Bloquear a implementação ou reverter se a pontuação diminuir mais do que o limite de tolerância definido, por exemplo, um ponto numa escala de 100 pontos.
2. Alertas orçamentais: Defina orçamentos do Gestão de Custos do Azure para cada grupo de recursos, com alertas aos 50, 80 e 100 por cento. Encaminhe-os para o mesmo canal do Slack ou do Teams que recebe as notificações de erros, para que os gastos e os incidentes fiquem no mesmo lugar.
3. Limite de taxa de pedidos: Mesmo um único limite por IP ou por chave API na API Management, NGINX ou no seu gateway impede que um cliente descontrolado esvazie o seu saldo de crédito durante a noite. Adiciona limites por inquilino mais tarde, quando tiveres clientes pagantes.

Tenha cuidado ao agrupar várias otimizações de custos numa única versão. Quando o conjunto de mudança se junta, a atribuição torna-se difícil e qualquer regressão é dispendiosa de dividir.

A experiência das duas alavancas: como comparar antes e depois

Quando decidir por onde começar, escolha duas alavancas das secções anteriores, envie-as atrás de uma bandeira de destaque e meça durante 7 a 14 dias. Duas alavancas são suficientes para detetar movimentos significativos. Mais do que dois tornam a atribuição pouco fiável.

Primeiro par sugerido por etapa

Stage	Alavanca A	Alavanca B
Pré-lançamento (<100 DAU)	Cache de mensagens de comando	Roteamento de modelos com um modelo padrão barato
Tracção inicial (DAU 100-10k)	Cache semântico	Escala para zero na inferência
Escalabilidade (10k+ DAU)	API de processamento em lote para processamento assíncrono	Estratégia de índice por inquilino
Nível Enterprise	Índices dedicados para contas de topo	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 cobre e o que não aborda

Este artigo tem um âmbito intencionalmente limitado. As secções seguintes listam os tópicos que estão dentro do âmbito, os que estão fora do âmbito e os sinais que indicam quando os deve adicionar.

Em âmbito de aplicação

• Etiquetagem, orçamentos e práticas de gestão de custos apropriadas para qualquer startup.
• As quatro alavancas do percurso da solicitação: armazenamento em cache, processamento em lote, roteamento e seleção de modelos.
• Dimensionamento adequado da GPU e escalonamento até zero para inferência autoalojada.
• Padrões de recuperação multi-inquilino para produtos com três a 100 inquilinos pagantes.
• Um ciclo de governação para alterações seguras: controlo de avaliação, alertas orçamentais e limites de pedidos por locatário.

Fora de âmbito

Topic	Quando o adicionar
Reservas e planos de poupança para computação de IA	A fatura de inferência mantém-se estável durante 90 dias, normalmente a meio de Expand.
Ferramentas dedicadas de FinOps, como Apptio Cloudability, Vantage e ferramentas semelhantes	O gasto na cloud ultrapassa aproximadamente os 50.000 dólares por mês, ou então opera em multi-cloud. A maioria das startups em fase inicial não precisa disto.
Faturação personalizada baseada em tokens por cliente final	Vende preços baseados no uso, ou um inquilino ultrapassa 25 por cento da fatura.
Otimização dos custos de treino, como a otimização do DeepSpeed e do FSDP	Treinas modelos internamente. Os produtos centrados na inferência não precisam disto.
Arbitragem de custos entre regiões ou multicloud	Está na fase de extração com viabilidade económica comprovada numa única região.

Quando esta abordagem deixar de ser suficiente

As práticas descritas neste artigo destinam-se a equipas pequenas que gerem a sua própria nuvem. A certa altura, o seu negócio ultrapassa-os. Os sinais seguintes não são falhas. Representam crescimento. Quando se aplicarem duas ou mais, planeie recorrer a ferramentas específicas ou a um responsável pela plataforma a tempo parcial.

• O gasto mensal no Azure ultrapassa aproximadamente os 50.000 dólares, e a IA representa mais de 30 por cento desse valor.
• Mais de 10 engenheiros podem enviar alterações que aumentem o custo em 5 por cento ou mais.
• Pelo menos um cliente tem um consumo superior a 10.000 dólares por mês e está a pagar-lhe uma taxa fixa.
• Os seus investidores ou parceiro financeiro começaram a pedir uma previsão mensal de custos.
• O produto corre em mais do que uma região Azure ou cloud.

Até lá, o ciclo simples descrito neste artigo, que inclui etiquetas, orçamentos, um ponto de controlo de avaliação e uma revisão mensal, é a ferramenta certa. Resista à tentação de adotar as ferramentas FinOps empresariais desde cedo. Acrescenta sobrecarga ao processo antes de acrescentar valor.

Lista de verificação de referências

Utilize os seguintes itens como lista de verificação mensal. Cada item corresponde a uma secção deste artigo.

• Todos os recursos de IA estão marcados com costCenter, tenant, workload, e env.
• Existe um painel de Gestão de Custos, agrupado por etiqueta e revisto semanalmente.
• Os prompts do sistema são suficientemente estáveis para permitir ocorrências na cache de prompts.
• O trabalho assíncrono, como embeddings, avaliações e resumos, corre em API Batch.
• O router envia pelo menos 60 por cento do tráfego para um modelo mais barato, sem regressão de avaliação.
• As cargas de trabalho de GPU são reduzidas para zero fora do horário de funcionamento ou utilizam instâncias spot para processamento em lote.
• A contagem mediana de recolha por turno é de dois ou menos.
• A estratégia multitenant é escolhida explicitamente: partilhada com filtragem ou dedicada.
• Os orçamentos e os limites de tarifa por inquilino são aplicados.
• Cada prompt, modelo ou alteração de encaminhamento passa pelo controlo de avaliação antes da integração.