Well-Architected Framework:Pilar de custos

Economia de tokens

O Model Studio precifica serviços por milhão de tokens. Para modelos mainstream de geração de texto: o qwen3-max na faixa de até 32K custa CNY 2,5 para entrada e CNY 10 para saída; o qwen-plus na faixa de até 128K custa CNY 0,8 para entrada e CNY 2 para saída (unidade: CNY por milhão de tokens). A diferença de preço entre os níveis leve e premium pode variar de várias vezes até mais de uma ordem de grandeza. Por isso a seleção de modelo é uma decisão de altíssima alavancagem.

Observe duas características de precificação. Primeiro, a saída custa mais que a entrada. Para modelos de texto mainstream, a razão de preço saída/entrada fica tipicamente entre 2,5x e 4x. Suas estimativas precisam separar tokens de entrada e tokens de saída. Usar uma contagem média única de tokens mascara o custo mais alto dos tokens de saída. Segundo, alguns modelos utilizam tiered pricing: o preço unitário depende do total de tokens de entrada em uma única requisição, e todos os tokens nessa requisição são cobrados na mesma faixa. Para o qwen3-max, a entrada custa CNY 2,5 para até 32K tokens, CNY 4 de 32K a 128K, e CNY 7 de 128K a 256K. Isso significa que o impacto de custo do comprimento de contexto não é suave nem linear. Ao cruzar o limite de uma faixa, a base de precificação da requisição inteira aumenta. Esse mecanismo tem um impacto mais direto na sua fatura do que fatores teóricos como a complexidade de atenção.

Exemplo de estimativa para atendimento ao cliente: processe 1 milhão de conversas por mês, em que cada uma consome 2.000 tokens de entrada e 500 tokens de saída. Com o qwen3-max, o custo de entrada é 1.000.000 × 2.000 ÷ 1.000.000 × 2,5 = CNY 5.000. O custo de saída é 1.000.000 × 500 ÷ 1.000.000 × 10 = CNY 5.000. O total fica em torno de CNY 10.000 por mês.

Custo de computação

Para empresas que hospedam inference por conta própria ou realizam fine-tuning, o poder de computing power de GPU é o recurso mais caro. A Alibaba Cloud oferece famílias de instance de computação GPU como gn8is, gn7i, gn6v, gn6e e gn6i, correspondendo a tipos de GPU L20, A10, V100, T4, entre outros. training em larga escala e inference de alta concorrência normalmente rodam no Lingjun Intelligent Computing Service em vez de famílias de Elastic Compute Service (ECS) de instance de GPU vendidas publicamente. Escolha a menor opção que atenda aos seus requisitos de memória e throughput. Utilize os preços em tempo real no ECS console e na Pricing Calculator. Como âncora de custo, recursos públicos no Platform for AI-Elastic Algorithm Service (PAI-EAS) são cobrados a CNY 0,194 por vCPU core-hora e CNY 0,024 por GB-hora de memória.

O custo de fine-tuning é aproximadamente linear com o tamanho do modelo. Para duas faixas de modelo cujas contagens de parâmetros diferem por uma ordem de grandeza, as GPU-horas necessárias e a quantidade de GPUs paralelas tipicamente diferem por uma ordem semelhante. Antes de iniciar o fine-tuning, valide se uma faixa menor consegue atingir o objetivo após um ajuste aprofundado. É possível estimar a computação de inference da seguinte forma: para modelos densos, a computação direta por token gerado equivale aproximadamente ao dobro da contagem de parâmetros. Ou seja, um modelo de 7 bilhões de parâmetros consome cerca de 14 GFLOPs por token, e um modelo de 72 bilhões de parâmetros, cerca de 144 GFLOPs por token. Essa é uma escala por token, não por requisição. Para uma única requisição, multiplique esse valor pelo comprimento da saída e adicione o overhead de prefill do lado da entrada.

A utilização de GPU em clusters de inference auto-hospedados costuma ser baixa. As causas comuns incluem distribuição desigual de tráfego, esperas de cold start, batching ineficiente e fragmentação causada por equipes implantando stacks separados. Use seus dados de monitoramento para avaliar a utilização e quantificar os benefícios da consolidação de recursos.

Custo de armazenamento

Tome o text-embedding-v4 como exemplo. A saída padrão é de 1.024 dimensões. Se cada vetor for armazenado como floats de 4 bytes, um vetor ocupa 4.096 bytes (cerca de 4 KB). Com metadados e overhead de index, cada chunk de texto normalmente consome de 5 KB a 6 KB. Para 10 milhões de chunks de texto, os vetores brutos requerem de 40 GB a 60 GB de storage. Após adicionar um grafo HNSW de index, o total geralmente aumenta de 10% a 30%. Esse modelo suporta múltiplos tamanhos de saída, de 2.048 a 64 dimensões. Reduzir dimensões diminui diretamente o custo de storage e de recuperação. Passar de 1.024 para 512 corta o storage pela metade — uma alavanca de custo frequentemente ignorada.

Arquivos de modelo também importam. Um modelo de 7 bilhões de parâmetros armazenado em FP16 ocupa cerca de 14 GB. Um modelo de 72 bilhões de parâmetros ocupa cerca de 144 GB. Manter múltiplas versões com fine-tuning para testes A/B e rollback faz os custos crescerem rapidamente. Conjuntos de Training, conjuntos de evaluation e checkpoints intermediários também adicionam custos significativos.

Custos ocultos

Computação de Evaluation. Cada alteração de modelo exige reexecutar centenas a milhares de casos de teste. Se o seu conjunto de evaluation possui 1.000 amostras e cada amostra usa 800 tokens de entrada e 200 tokens de saída, uma evaluation completa com qwen-plus custa aproximadamente CNY 1. Em iteração rápida, uma equipe pode executá-la mais de dez vezes por dia. Some comparações entre múltiplos modelos e verificações de regressão, e o total mensal se torna significativo. A Evaluation não é sensível a latência, então execute-a com batch inference a um preço unitário menor.

Amplificação de custo pela saída de cadeia de pensamento. Em modelos de raciocínio, a cadeia de pensamento é cobrada como tokens de saída. Quando o modelo emite seu processo de raciocínio, todos os tokens de saída são cobrados pelo preço de saída do modo de pensamento. Em um exemplo oficial da Alibaba Cloud, uma chamada gera cerca de 360 tokens de saída, dos quais 286 são tokens de pensamento — perto de 80%. Ativar o pensamento profundo por padrão para tarefas simples pode multiplicar o custo de saída. Esse é o custo oculto mais fácil de perder o controle atualmente. Ative o modo de pensamento apenas por tipo de tarefa e defina um limite superior para o comprimento do pensamento.

Sunk cost de experimentos falhos. Uma parcela significativa dos experimentos de fine-tuning nunca chega à produção, mas consome computing power. Torne a perda experimental um item de linha explícito no orçamento. Ambientes de desenvolvimento superdimensionados também são comuns. As equipes frequentemente solicitam a mesma faixa de computação da produção para depuração, mas a utilização é baixa. Prefira recursos elásticos que possam scale to zero. Além disso, o Model Studio disponibiliza cotas gratuitas de chamadas para muitos modelos por um período limitado após a ativação, o que ajuda a reduzir o custo de tentativa e erro em POCs.

Uso de energia e computação verde

A pegada de carbono de cargas de trabalho de large language model (LLM) é hoje um tema nos relatórios ESG. O uso de energia de Training se correlaciona com a contagem de parâmetros, o volume de dados e a duração. O consumo de energia de Inference por chamada é pequeno, mas se acumula em escala. Se você precisa de emissões quantificadas, estime-as com base no tempo real de computing power e no fator de emissões da rede elétrica da sua região, em vez de usar analogias genéricas. O princípio central da green computing é dimensionar o modelo corretamente. Se um modelo de 7 bilhões de parâmetros dá conta da tarefa, usar um modelo de 72 bilhões de parâmetros consome aproximadamente uma ordem de grandeza mais de computing power e produz um múltiplo semelhante de emissões.

BP-COST-01 Adeque a faixa do modelo à complexidade da tarefa

Melhor prática: construa uma matriz de mapeamento tarefa-modelo. Escolha a faixa mais econômica com base na complexidade cognitiva. Evite usar o maior modelo para todos os cenários.

Pontos-chave: divida as tarefas em quatro níveis de complexidade. O nível 1 abrange tarefas estruturadas (classificação, extração de entidades, conversão de formato, extração de palavras-chave). A lógica é simples e os padrões são estáveis, então use faixas leves (como a série Qwen Flash) ou um modelo pequeno especializado. O nível 2 cobre tarefas conversacionais padrão (perguntas e respostas simples, recuperação de informações, respostas baseadas em modelo) e se encaixa na faixa Qwen Plus. O nível 3 contempla tarefas de raciocínio complexo (raciocínio em múltiplas etapas, geração criativa, sumarização complexa, síntese entre documentos) e exige a faixa Qwen Max. O nível 4 envolve tarefas especializadas (geração de código, provas matemáticas, análise de domínio específico) e pode requerer um modelo com fine-tuning de domínio ou a maior faixa de propósito geral. Na matriz, registre a família do modelo e o nível de capacidade em vez de fixar números de versão, e reteste quando uma nova versão for lançada. Antipadrão: usar o modelo mais potente no POC para maximizar a qualidade e, ao escalar, pular a evaluation de downgrade.

Implementação na Alibaba Cloud: use o AI Gateway para gerenciar centralmente chamadas a modelos de múltiplas faixas e credenciais de API. Configure políticas de seleção de modelo baseadas em cenário e utilize os recursos de evaluation de modelo para verificar se as faixas inferiores atendem ao seu patamar de qualidade.

BP-COST-02 Use roteamento de modelo para equilibrar custo e qualidade

Melhor prática: implante um classificador de requisições para pontuar cada requisição de inference e roteá-la à instance de modelo mais econômica.

Pontos-chave: a arquitetura tem três componentes — um classificador de requisições que avalia entradas em tempo real e gera uma pontuação de complexidade; um mecanismo de decisão de roteamento que despacha para o endpoint correto com base na pontuação e nos limiares; e um módulo de monitoramento de qualidade que coleta métricas continuamente e ajusta os limiares. A economia pode ser medida diretamente. Usando o exemplo de atendimento ao cliente da seção 6.1.1, a linha de base de chamar qwen3-max para todas as requisições custa cerca de CNY 10.000 por mês. Ao rotear 70% das requisições para qwen-plus e manter 30% no qwen3-max, o custo total de entrada é CNY 2.620 (CNY 1.500 para qwen3-max e CNY 1.120 para qwen-plus), o custo total de saída é CNY 2.200 (CNY 1.500 para qwen3-max e CNY 700 para qwen-plus), e o total fica em torno de CNY 4.820 por mês — uma economia de aproximadamente 52%. A economia depende da taxa de redirecionamento e da razão de preço entre as faixas. Utilize preços unitários reais para o seu par de modelos e não se baseie em multiplicadores aproximados. É possível treinar um classificador leve (um pequeno encoder pré-treinado ou regressão logística). Sua latência de inference pode ficar na casa de poucos milissegundos. Também é possível usar heurísticas baseadas no comprimento da entrada, tipo de intenção e necessidade de saída estruturada. Isso não requer training, mas é menos preciso. Antipadrão: lançar o roteamento sem monitoramento de qualidade. Classificações incorretas direcionam requisições complexas a um modelo mais fraco, e a perda de qualidade muitas vezes só é percebida após reclamações dos usuários.

Implementação na Alibaba Cloud: gerencie endpoints de modelo em múltiplas faixas no Model Studio. Implante um classificador leve no Function Compute (FC) 3.0 como pré-gateway de roteamento. Use o AI Gateway para despacho de requisições e load balancing.

BP-COST-03 Reduza custos com destilação e quantização

Melhor prática: para funções internas de IA ou funções não voltadas ao cliente e não críticas, use knowledge distillation e model quantization para reduzir o uso de recursos de inference. Mantenha a perda de qualidade dentro de uma faixa aceitável enquanto diminui o custo de implantação.

Pontos-chave: a Knowledge distillation treina um modelo estudante menor usando saídas de um grande modelo professor como sinal de training. Ao aprender a distribuição de probabilidade do professor em vez de apenas rótulos rígidos, o estudante herda parte da capacidade do professor. Um padrão típico é usar um professor de faixa grande e destilar um estudante com uma ordem de grandeza a menos em parâmetros, mantendo a maior parte da qualidade do professor em uma tarefa específica. A Model quantization comprime pesos de floats de alta precisão (FP16/FP32) para inteiros de baixa precisão. INT8 tipicamente reduz pela metade o tamanho do modelo e o uso de memória de inference. INT4 pode atingir uma compressão de aproximadamente 4x, com perda de qualidade maior à medida que a largura de bits diminui. Aplique essas técnicas em ferramentas internas e backends operacionais, pipelines de dados não voltados ao cliente (classificação em lote, geração de rótulos) e serviços de modelo para dev/teste. Evite quantização agressiva em caminhos centrais de experiência do usuário. Antipadrão: colocar em produção um modelo quantizado sem testá-lo no seu conjunto de evaluation de negócio. A sensibilidade à perda de acurácia varia muito por tarefa, e benchmarks genéricos não substituem a validação de negócio.

Implementação na Alibaba Cloud: use a capacidade de compressão de modelo no PAI-Model Gallery para executar a quantização. A tecnologia é baseada em Weight-only Quantization e fornece as estratégias MinMax-8Bit e MinMax-4Bit. Execute a quantização como um job separado de pré-implantação e, em seguida, implante o artefato comprimido como service online por meio do PAI-EAS. O PAI-EAS suporta inference engines como BladeLLM e vLLM para melhorar ainda mais o throughput.

BP-COST-04 Compartilhe um pool de GPU para inference

Melhor prática: consolide os resource silos criados por implantações separadas de equipes. Construa um pool unificado de recursos GPU para inference. Utilize compartilhamento multi-modelo e agendamento inteligente para aumentar a utilização.

Pontos-chave: um antipadrão típico é cinco equipes, cada uma implantando um service de inference com 2 GPUs, totalizando 10 GPUs, mas com horários de pico diferentes. A utilização média fica em torno de apenas 30%. Meça os benefícios da consolidação pela carga efetiva: 10 GPUs a 30% de utilização equivalem a cerca de 3 GPUs em carga plena. Após a consolidação, é possível configurar 4 GPUs para lidar com a sobreposição de picos, elevando a utilização média para aproximadamente 75%. Em comparação com as 10 GPUs originais, isso representa uma economia de cerca de 60% do investimento. A redução real depende de como os picos se sobrepõem. Modele isso com base em curvas históricas de tráfego em vez de copiar proporções. Para implementar a solução com agendamento de GPU compartilhado via Kubernetes: implante componentes de compartilhamento e isolamento de GPU para suportar múltiplos contêineres por GPU; implante um gateway unificado de service de modelo para roteamento de endpoints multi-modelo; configure dimensionamento horizontal com base na profundidade da fila e na utilização de GPU. Menos GPUs também significam menor consumo de energia e emissões. Antipadrão: reduzir a quantidade de GPUs agressivamente com base na utilização média em vez de nos picos sobrepostos. Quando múltiplos serviços apresentam picos simultâneos, o desempenho degrada de forma generalizada.

Implementação na Alibaba Cloud: use Shared GPU Scheduling no Container Service for Kubernetes (ACK) para compartilhar uma GPU entre múltiplos serviços. O componente cGPU isola tanto memória quanto computação. Note que o agendamento de GPU compartilhado e o agendamento com reconhecimento de topologia para aceleração de training distribuído são capacidades distintas. No lado do PAI, use um dedicated resource group no PAI-EAS com GPU slicing para construir um pool unificado de inference, e use um Virtual Resource Group para agendamento de recursos mistos e gerenciamento de prioridades.

BP-COST-05 Engenharia de prompts e orçamentos de saída

Melhor prática: Trate prompts e comprimento de saída como fatores de custo mensuráveis. Aplique corte sistemático, restrições de saída estruturada e controles de orçamento de raciocínio para minimizar o consumo de tokens por requisição sem sacrificar a qualidade.

Pontos-chave: O prompt de sistema representa um overhead fixo em cada requisição. Remova descrições redundantes e instruções repetidas. Substitua frases longas em linguagem natural por formatos concisos e estruturados. Mova regras de baixa frequência para ramificações condicionais.

Importante: Avalie o benefício de reduzir o prompt de sistema em conjunto com o cache de contexto. O Model Studio habilita o cache implícito por padrão para modelos compatíveis. Um prefixo de entrada em cache é cobrado a uma porcentagem menor do preço unitário de entrada (consulte BP-COST-06). O prompt de sistema fica no início do prefixo e é a parte mais fácil de armazenar em cache. Quando o cache acerta de forma consistente, a economia obtida ao reduzir o prompt de sistema corresponde apenas a uma pequena fração do que você economizaria com o preço integral. Siga a ordem correta: primeiro garanta que um prefixo longo e estável acerte o cache, depois reduza as partes não cobertas pelo cache. Inverter essa ordem leva a uma superestimativa de economia.

A otimização do lado da saída costuma gerar mais economia, pois a saída é várias vezes mais cara que a entrada e não é afetada pelo cache de entrada. Exija saída estruturada (JSON, listas) para reduzir explicações verbosas. Para modelos de raciocínio, controle o modo de raciocínio profundo por tipo de tarefa. Desative o raciocínio profundo em tarefas simples. Quando for necessário ativá-lo, use parâmetros de thinking-budget para limitar o comprimento da cadeia de raciocínio. Como os tokens de raciocínio podem representar a maior parte da saída, esse é o controle individual mais eficaz no lado da saída. Outras estratégias incluem resumir documentos longos antes de enviá-los ao modelo, comprimir o histórico de conversas com janela deslizante e manter uma biblioteca de modelos compactos específicos por cenário. Essas práticas também ajudam a evitar a ultrapassagem de limites de tiered pricing. Antipadrão: Reportar economia multiplicando os tokens reduzidos pelo preço unitário integral sem validar os acertos de cache. Isso pode superestimar significativamente a economia. Baseie os cálculos nos tokens faturados dos relatórios de uso.

Implementação na Alibaba Cloud: Use o Prompt Management no Model Studio para criar uma biblioteca de modelos versionados. Utilize parâmetros de raciocínio profundo para controlar o gasto com cadeia de raciocínio. Monitore o desempenho faturado de cada modelo por workspace, chave de API e modelo no relatório Model Usage.

BP-COST-06 Reutilize com caches de contexto e semântico

Melhor prática: Construa um sistema de cache em duas camadas. Use o cache de contexto nativo da plataforma para reutilizar computação de prefixos de requisição e implante um semantic cache na camada de aplicação para interceptar requisições repetidas semanticamente equivalentes.

Pontos-chave: Os dois caches funcionam de maneiras distintas e oferecem diferentes níveis de economia potencial. Para máxima eficácia, combine ambos.

A camada 1 é o cache de contexto da plataforma. Ele reutiliza o prefixo compartilhado da requisição e reduz o custo no lado da entrada. O cache implícito vem habilitado por padrão para modelos compatíveis e não exige alterações. As porções em cache são cobradas como uma fração do preço unitário de entrada (20% para a maioria dos modelos, com percentuais ainda menores para alguns). O cache explícito requer que você marque o conteúdo para cache na requisição. A taxa de cobrança para acertos de cache é mais baixa (tipicamente 10% do preço unitário de entrada), porém a criação do cache é cobrada a 125% do preço unitário de entrada, e há limites de TTL e faixa de retrocesso. O cache de contexto é baseado em prefixo. Posicione conteúdo estável, como o prompt de sistema e trechos de conhecimento, no início da sequência de mensagens, e mantenha as definições de ferramentas serializadas exatamente na mesma estrutura entre requisições. Para caminhos críticos que exigem custo e latência previsíveis, use o cache explícito. Na maioria dos cenários, o cache implícito é suficiente.

A camada 2 é o semantic cache na camada de aplicação. Ele retorna diretamente um resultado histórico e evita o custo total de entrada e saída da chamada, oferecendo maior potencial de economia. O cache por correspondência exata apresenta baixas taxas de acerto para linguagem natural, pois os usuários expressam a mesma intenção de diversas formas. Um semantic cache codifica o texto da requisição em um vetor e faz correspondência por similaridade (geralmente com um limiar de similaridade de cosseno de 0,95 ou superior). Sua estratégia de invalidação deve cobrir três dimensões: tempo, com um TTL para evitar respostas desatualizadas — e TTLs mais curtos para dados sensíveis ao tempo, como mercado financeiro e clima; atualizações de conhecimento, limpando ativamente entradas relacionadas quando a base de conhecimento subjacente muda; e feedback de qualidade, removendo entradas de baixa qualidade com base em sinais negativos dos usuários. As taxas de acerto variam bastante por cenário: consultas de FAQ são as mais concentradas e têm as maiores taxas de acerto; atendimento ao cliente em geral fica em uma faixa intermediária; escrita criativa aberta requer saídas únicas e não é adequada para cache. Antes de lançar, avalie a taxa de acerto offline usando logs históricos de requisições. Do ponto de vista arquitetural, posicione o cache como interceptor à frente do service de modelo. Use o vetor da requisição como chave e armazene a saída e metadados (timestamp, versão do modelo, confiança) como valor. Monitore continuamente a taxa de acerto e a satisfação dos usuários. Antipadrão: Usar semantic cache em cenários que exigem diversidade de saída ou incluem contexto privado do usuário. Isso pode causar respostas irrelevantes ou vazamento de dados entre usuários. Inclua dimensões de tenant e permissão na chave do cache.

Implementação na Alibaba Cloud: O cache de contexto é fornecido nativamente pelo Model Studio. O cache implícito funciona sem alterações. Ative o cache explícito por meio de parâmetros na requisição. Para um semantic cache na camada de aplicação, use a estrutura de dados vetorial TairVector no Tair (compatível com Redis). Ela suporta index HNSW e TTL por chave. Combine com modelos de text-embedding do Model Studio para vetorização de requisições.

BP-COST-07 Use inferência em lote e assíncrona

Melhor prática: Para cenários que não exigem resposta em tempo real, use batch inference e asynchronous inference. Prefira os descontos de batch inference da plataforma e combine-os com agendamento em horários de baixa demanda e opções de spot instance para reduzir ainda mais os custos.

Pontos-chave: Muitas cargas de trabalho de inference não precisam de respostas em tempo real. Cenários típicos incluem processamento de documentos em lote (análise de contratos, triagem de currículos, moderação de conteúdo), pipelines de dados offline (análise de log, atualização de perfis), geração programada de relatórios, e evaluation de modelos e rotulagem de dados. Para chamadas à API do Model Studio, o batch inference oferece a economia mais direta. Envie um conjunto de requisições como arquivo JSONL e processe-o de forma assíncrona. A cobrança é de 50% do preço em tempo real. Você pode definir o tempo máximo de espera de 1 a 14 dias. Se o job não finalizar até o prazo, ele é encerrado, e apenas as requisições executadas com sucesso são cobradas. Migre tarefas de evaluation, rotulagem e processamento de documentos em lote para essa API e reduza pela metade o custo dessas tarefas sem alterar modelos ou prompts. Observe que, ao ativar o raciocínio profundo, os tokens de cadeia de raciocínio continuam sendo cobrados pelo preço de saída.

Para inference auto-hospedada, os benefícios vêm de três áreas: o preço de spot instance é muito inferior ao de pay-as-you-go e, embora a reclamação seja possível, jobs em lote geralmente suportam checkpointing e retomada; agendar jobs não urgentes em janelas de baixa demanda e horários fora de pico melhora a disponibilidade de recursos; agrupar várias requisições pequenas em um único lote aumenta o throughput da GPU e reduz overhead de comunicação e agendamento. O design assíncrono principal é simples: o frontend envia requisições a uma message queue, workers de inference consomem e processam a fila e, ao concluir, notificam via callback ou gravam resultados em storage para consumo downstream. Esse design suporta suavização de tráfego, tolerância a falhas com retry e dimensionamento horizontal. Antipadrão: Converter caminhos interativos do usuário final para batch inference apenas para obter descontos. A janela de espera é medida em dias e se aplica somente a cargas insensíveis à latência.

Implementação na Alibaba Cloud: Chame a API de Model Studio do batch inference para tarefas offline e obtenha preços com desconto. Para inference auto-hospedada, use o recurso de batch inference para LLM do PAI-EAS (que fornece uma Batch API compatível com OpenAI por meio de roteamento inteligente de LLM). Para cenários de AIGC e tarefas de longa duração quase em tempo real, como processamento de áudio e vídeo, use o service de inference assíncrona e o service de fila no PAI-EAS. O Function Compute (FC) 3.0 suporta invocação assíncrona e invocação atrasada. Você pode entregar resultados assíncronos ao Message Service, EventBridge ou ApsaraMQ for RocketMQ como camada de desacoplamento.

BP-COST-08 Melhore a previsibilidade de custos com compromissos

Melhor prática: Com base no histórico de uso e previsões de crescimento, garanta descontos por meio de Savings Plans ou de um resource plan. Estabeleça monitoramento de uso e planejamento de capacidade para assegurar que seu compromisso esteja alinhado ao consumo real.

Pontos-chave: O Model Studio oferece um Savings Plans de propósito geral para IA, uma opção de desconto projetada para uso pay-as-you-go de large language models (LLMs). Você se compromete com um valor mensal de gasto por um período (3, 6, 12 ou 24 meses). A flexibilidade de pay-as-you-go é mantida enquanto você recebe descontos escalonados, o que reduz os custos de uso do modelo.

Observe que o Model Studio também oferece uma assinatura Token Plan para ferramentas de codificação e agentes de IA. Ela utiliza créditos com limites por período fixo e pausa as chamadas quando o limite é esgotado. Essa opção é adequada para ferramentas de desenvolvimento e não segue o mesmo modelo de otimização de custos do uso corporativo via API. Não confunda essas opções ao fazer sua escolha.

Implementação na Alibaba Cloud: Adquira Savings Plans ou um resource plan no Model Studio do console. Use o relatório Model Usage para monitorar o progresso de gastos e a cota restante por workspace, chave de API e modelo. Configure alertas de limiar no Budget Management do Billing Management (com base em valores reais ou previstos).

BP-COST-09 Utilize autoscaling para pagar conforme o uso

Melhor prática: configure elasticidade em múltiplas camadas com base nos padrões de tráfego de inference. Minimize a capacidade ociosa sem comprometer seus SLOs. Em ambientes de desenvolvimento, adote scale to zero quando não houver tráfego, eliminando gastos com recursos inativos.

Pontos-chave: o tráfego de inference de IA costuma ser periódico e apresentar picos. Dimensionar de forma fixa ou provisiona para o pico e permanece ocioso a maior parte do tempo, ou dimensiona para a média e degrada nos picos. Aplique três camadas de elasticidade. Primeira, scale to zero: para ambientes de desenvolvimento/teste e service de baixa frequência, reduza as réplicas a zero após um período sem requisições. A contrapartida é o cold start. A primeira requisição pode levar de dezenas de segundos a minutos; mitigue esse efeito com pré-aquecimento. Segunda, dimensionamento preditivo: preveja a carga com base em padrões históricos e escale antes do pico. Utilize essa abordagem para service de produção com tráfego regular, evitando a defasagem do dimensionamento reativo. Terceira, dimensionamento reativo com cooldown period: acione o dimensionamento com base em métricas em tempo real (utilização de GPU, profundidade da fila, latência de resposta) e defina um cooldown period adequado para evitar oscilações excessivas. Antipadrão: ativar scale to zero para caminhos em tempo real voltados ao cliente. Quando o tráfego retornar, as primeiras requisições sofrerão latência de cold start. Mantenha sempre ao menos uma réplica ativa para service voltados ao cliente.

Implementação na Alibaba Cloud: o PAI-EAS oferece autoscaling horizontal e autoscaling agendado. Ele permite definir a contagem mínima de instance como 0 para scale to zero (service com gateway dedicado não oferecem suporte a isso). As métricas de acionamento incluem QPS, CPU, utilização de GPU, backlog de fila (para service assíncronos) e métricas personalizadas. O Function Compute (FC) cobra por requisição e escala automaticamente. Suas instances GPU lidam com inference quase em tempo real e disponibilizam instances em modo de suspensão superficial para reduzir o custo de reserva. O ACK e o ACK Serverless permitem implantar o Advanced Horizontal Pod Autoscaler (AHPA), que utiliza métricas históricas do Prometheus para dimensionamento preditivo. Mantenha ao menos 7 dias de histórico.

BP-COST-10 Gerencie o ciclo de vida dos dados de treinamento

Melhor prática: classifique os dados relacionados a training em quatro camadas — quente, morna, fria e exclusão — com base na frequência de acesso e no valor para o negócio. Automatize a storage tiering e a limpeza. Minimize o custo de storage enquanto atende aos requisitos de conformidade.

Pontos-chave: a camada quente inclui conjuntos de training de ajuste fino em uso, benchmarks de evaluation ativos e training de checkpoints em andamento. Essa camada exige acesso de alto throughput e baixa latência; utilize NAS de desempenho ou avançado, Extreme NAS ou SSD local. Para training de computação inteligente em larga escala, utilize o Cloud Paralleled File System (CPFS). A camada morna inclui dados de experimentos concluídos recentemente, resultados históricos de evaluation e os dados originais de training de modelos em produção (para reprodutibilidade e auditoria). Utilize Object Storage Service (OSS) padrão do storage. A camada fria inclui dados históricos sem uso prolongado, checkpoints de modelos descontinuados e conjuntos de dados experimentais antigos que precisam ser mantidos por conformidade ou reprodutibilidade. Utilize OSS de acesso infrequente, archive, cold archive ou deep cold archive do storage. A camada de exclusão inclui dados que devem ser removidos permanentemente com base em políticas de retenção, como dados pessoais além do período de retenção (conformidade com a Personal Information Protection Law (PIPL)), artefatos intermediários de experimentos falhos sem valor de reutilização e conjuntos de dados antigos totalmente substituídos por novas versões.

Ao escolher um tipo de storage frio, inclua os custos ocultos na sua estimativa. Comparar apenas o preço unitário de storage subestima o gasto total. Usando pay-as-you-go com redundância local no continente chinês como referência: storage padrão custa cerca de CNY 0,12 por GB-mês, acesso infrequente cerca de CNY 0,08 (aproximadamente dois terços do padrão), archive cerca de CNY 0,033, cold archive cerca de CNY 0,015 e deep cold archive cerca de CNY 0,0075. Considere também as durações mínimas de storage (30 dias para acesso infrequente, 60 dias para archive e 180 dias para cold archive e deep cold archive). A exclusão antecipada exige o pagamento da diferença. A recuperação de dados gera taxas de recuperação. Cold archive e deep cold archive requerem descongelamento antes da leitura. Utilize acesso infrequente para dados mornos/frios que ainda são lidos ocasionalmente. Reserve archive e classes de menor custo apenas para dados que você tem certeza de que não acessará por um longo período, mas precisa reter. Antipadrão: mover dados que ainda serão necessários no curto prazo para archive ou cold archive baseando-se apenas no preço unitário. Taxas de recuperação e cobranças de duração mínima podem aumentar o custo total.

Implementação na Alibaba Cloud: utilize Lifecycle Rules no storage para automatizar transições de classe de OSS e exclusão por expiração. As regras suportam correspondência por prefixo ou tags. É possível fazer a transição para acesso infrequente, archive, cold archive e deep cold archive. Também é possível excluir objetos expirados, uploads multipart incompletos, versões históricas e marcadores de exclusão. Em cenários de storage, utilize o data lake para gerenciamento centralizado de metadados e políticas de acesso, combinando-o com o Data Lake Formation (DLF) para implementar processos de qualidade de dados e ciclo de vida.

BP-COST-11 Utilize camadas de dados para armazenamento vetorial

Melhor prática: implemente DataWorks com base na frequência de consulta. Mantenha vetores quentes em índices em memória para desempenho, mova vetores de baixa frequência para índices em disco ou data tiering compactado, e reduza a escala geral diminuindo as dimensões dos embeddings.

Pontos-chave: o custo de um storage inclui custo de vector database e custo computacional (construção de storage e consulta). Índices em memória (como HNSW) oferecem a melhor latência de consulta, mas a memória é muito mais cara que o disco. Para bases de conhecimento com dezenas a centenas de milhões de vetores, um index totalmente em memória é insustentável. Antes de estratificar, reduza os próprios vetores. O text-embedding-v4 suporta saídas de 2.048 a 64 dimensões. A redução de dimensão corta proporcionalmente os custos de index e recuperação. Valide a qualidade de recall entre as dimensões no seu conjunto de storage de recuperação de negócio e escolha a menor dimensão que atenda ao seu limiar de qualidade. Essa etapa costuma gerar mais economia do que o trabalho posterior de estratificação. Para a estratégia de camadas, mantenha a camada quente em um evaluation em memória para trechos de conhecimento acessados com frequência e conhecimento de negócio essencial (manuais de produto, documentos de política). Utilize um index em disco para a camada morna, armazenando embeddings históricos de baixa frequência mas ainda necessários. A latência aumenta, porém o custo unitário cai significativamente. Para a camada fria, arquive offline em formato compactado. Carregue sob demanda quando necessário. A latência de acesso fica na faixa de segundos, mas o custo de index é o mais baixo. Rastreie a frequência de acesso registrando-a para cada ID de vetor na camada de gateway de recuperação e migre conforme um cronograma. Antipadrão: pressupor que o mecanismo de storage gerencia a estratificação automaticamente. A maioria dos armazenamentos vetoriais não oferece atualmente estratificação automática baseada em frequência. Você precisa implementar estatísticas de calor e orquestração de migração na camada de aplicação.

Implementação na Alibaba Cloud: o storage oferece um service de busca vetorial totalmente gerenciado com DashVector serverless. O autoscaling fornece análise vetorial e suporta AnalyticDB for PostgreSQL no nível do product, mas a estratificação requer uma chamada explícita a funções de transição de data tiering (você pode executar jobs agendados por partição). A migração automática com base no calor de acesso não ocorre. Observe que, ao mover uma tabela quente para uma tabela fria, chaves primárias, índices e sequências são removidos. Inclua uma estratégia de storage no seu plano de migração. O Alibaba Cloud Elasticsearch pode usar o indexing para separação quente/frio, ou utilizar o mecanismo OpenStore para separação de armazenamento e computação, armazenando grandes volumes de dados históricos com menor custo e mantendo-os pesquisáveis.

Utilize uma arquitetura de governança em cinco camadas

Camada 1: governança de uso na camada de chamada. Essa camada gera a economia mais direta e não exige mudanças de infraestrutura. Utilize DataWorks por complexidade de tarefa, aproveite o cache de contexto para reutilizar prefixos estáveis, mova model routing e processamento de documentos em lote para evaluation com 50% de desconto, controle o modo de raciocínio e defina orçamentos de raciocínio por tarefa, e limite o comprimento do contexto para evitar ultrapassar limiares de batch inference.

Camada 2: desconto com compromisso. Após a estabilização da sua linha de base de uso, utilize tiered pricing ou um Savings Plans para garantir descontos. Inclua no compromisso apenas a linha de base estável e mantenha a porção variável em resource plan, pois a cota não utilizada é zerada a cada ciclo. O valor central é converter gastos de consumo incertos em gastos planejados e orçáveis.

Camada 3: computação elástica e uso de pay-as-you-go. Para spot instance online auto-hospedada, configure a estratégia de elasticidade em três camadas. Para jobs batch offline, prefira inference GPU spot.

Camada 4: pooling de GPU. Utilize o agendamento de GPU compartilhada no instances e o isolamento via ACK para executar múltiplos service em uma única GPU, ou utilize um cGPU no dedicated resource group com PAI-EAS. Combine com vLLM ou BladeLLM para aumentar o throughput por GPU.

Camada 5: GPU slicing, observabilidade e governança. Utilize Lifecycle Rules do Storage tiering para automatizar transições de classe de OSS e exclusão por expiração. Reduza as dimensões dos vetores e implemente estratificação quente/morna/fria para dados vetoriais. Utilize Model Usage e Application Monitoring no storage para o uso no lado do modelo, e utilize Cost Management no Model Studio para análise de custos, Billing Management e alertas de orçamento. Ative a cost allocation para identificar crescimento anormal e recursos ociosos.

Estime os custos para uma empresa de médio porte típica

Considere uma empresa de médio porte com 1 milhão de chamadas por mês como cenário de referência. Ela utiliza principalmente a API do cost anomaly detection e não hospeda um cluster de Model Studio próprio. Premissas: três aplicações — atendimento inteligente ao cliente, processamento de documentos e Q&A com base de conhecimento interna — com distribuição de volume de chamadas de 60%, 25% e 15%. Cada chamada utiliza em média 2.000 tokens de entrada e 500 tokens de saída. A linha de base sem otimização utiliza qwen3-max (na faixa abaixo de 32K) para todas as chamadas.

Custo da linha de base: entrada de inference do modelo é CNY 5.000, saída é CNY 5.000, total de aproximadamente CNY 10.000 por mês. Busca vetorial é cerca de CNY 4.000 por mês. inference é cerca de CNY 300 por mês. Computação de Object Storage Service (OSS) e experimental é cerca de CNY 1.500 por mês. O total da linha de base é de aproximadamente CNY 15.800 por mês, sendo que a Evaluation do modelo representa cerca de 63%, constituindo o maior item de custo.

Otimize o custo de inference na seguinte ordem. Passo 1, inference: direcione 70% das requisições para qwen-plus e mantenha 30% no qwen3-max. Entrada é CNY 2.620, saída é CNY 2.200, subtotal de aproximadamente CNY 4.820. Passo 2, cache de contexto: assuma que cerca de 60% da entrada é um prefixo estável, e aproximadamente 80% desse prefixo acerta o cache implícito, com as porções em cache cobradas a 20% do preço unitário de entrada. O fator efetivo de cobrança de entrada é cerca de 0,62, reduzindo a entrada para aproximadamente CNY 1.614 e o subtotal para cerca de CNY 3.814. Passo 3, model routing: mova o processamento de documentos (cerca de 25%) para batch inference com 50% de desconto, reduzindo o subtotal para cerca de CNY 3.337. Passo 4, batch inference: aplique committed use à linha de base estável. Usando uma estimativa conservadora de 10% de desconto, o custo de Savings Plans cai para cerca de CNY 3.000 por mês, aproximadamente 70% menor que a linha de base. Verifique os descontos reais no inference com base no seu nível de compromisso.

Outros itens de custo: reduza a busca vetorial para cerca de CNY 2.000 por mês por meio de redução de dimensão e estratificação; reduza o console para cerca de CNY 150 por mês por meio de regras de ciclo de vida; reduza a computação de OSS para cerca de CNY 750 por mês por meio de evaluation. O total otimizado é de aproximadamente CNY 5.900 por mês, com uma taxa de economia total de cerca de 63%.

Esses números são apenas um framework de estimativa. O custo real varia significativamente conforme o caso de uso, padrões de tráfego, metas de qualidade e escolhas técnicas. Se você hospedar um cluster de batch inference próprio, o custo de GPU sempre ativa se torna o custo dominante, e a estrutura de custos e o foco de otimização mudam. O valor desse framework está em como ele define a análise de custos, o escopo de contabilização e a sequência de otimização.

Estabeleça mecanismos organizacionais para governança de custos

A otimização de custos não é apenas um problema técnico — é também um problema de governança organizacional. Estabeleça quatro mecanismos: forme uma equipe virtual de inference onde arquitetos, finanças e stakeholders de negócio revisem tendências de gastos e oportunidades de otimização regularmente; implemente AI FinOps e atribua o custo de cost allocation a cada linha de negócio por volume de chamadas, proporcionando visibilidade aos responsáveis pelo negócio; defina a economia unitária estabelecendo uma métrica de custo por interação para cada aplicação e uma meta de otimização; e realize uma inference mensal para identificar crescimento anormal, recursos ociosos e oportunidades de otimização.

O objetivo do cost audit não é minimizar gastos, mas maximizar o retorno de negócio de cada real investido. Uma arquitetura de IA robusta mantém um equilíbrio dinâmico entre custo, desempenho e qualidade. Não sacrifique a experiência do usuário para economizar, nem permita que os custos disparem em busca de ganhos marginais de qualidade.