Amazon AIF-C01: Otimização de Custos e Precificação para AI/ML — Guia de estudos

By Laurynas Brazys · 30 July 2026 · #amazon #aif-c01 #certification #exam-prep #study-guide

Faz parte do AWS AI Practitioner AIF-C01 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Fatores de custo e modelos de precificação em Bedrock, SageMaker e EC2

A precificação para workloads de IA/ML se divide entre computação, armazenamento, rede e medição específica do serviço. O acesso a modelos de fundação via Amazon Bedrock é tipicamente medido por solicitação ou por token para workloads de texto e por segundo para APIs de streaming; o SageMaker cobra por horas de instância para treinamento e hospedagem multi-tenant, além de transferência e armazenamento de dados. A hospedagem baseada em EC2 traz o custo bruto por hora de instância, com cobranças adicionais de armazenamento EBS, EFS ou FSx e egress de VPC. Os principais fatores de custo são o tamanho do modelo (modelos maiores aumentam o trabalho de tokens/matemática e o uso de memória), o throughput de inferência (chamadas síncronas sensíveis à latência custam mais quando fixadas em GPUs caras) e a movimentação de dados para geração aumentada por recuperação (RAG), onde buscas de embedding e pesquisas de vetores podem multiplicar as chamadas. Armadilhas comuns para profissionais incluem subestimar os custos de embedding para sistemas RAG com alto QPS (queries per second), deixar múltiplos endpoints ociosos do SageMaker em execução e ignorar o egress entre regiões ao manter PII (Personally Identifiable Information) na região. Os critérios de decisão devem, portanto, considerar o volume de solicitações, a tolerância à latência por solicitação, se o modelo precisa passar por fine-tuning ou pode ser usado pronto para uso, e se a inferência gerenciada pelo provedor (endpoints do Bedrock/SageMaker) ou instâncias EC2/GPU auto-hospedadas oferecem um TCO (Total Cost of Ownership) melhor ao levar em conta o custo adicional (overhead) de gerenciamento e escalabilidade.

Seleção de instâncias, instâncias spot e padrões de otimização de computação

A escolha das instâncias afeta tanto o desempenho quanto o custo. Para treinamento, use Trainium (trn1) ou clusters de GPU (p4/p5) quando o throughput de matriz em larga escala é essencial; para inferência, prefira Inferentia/Inf2 (inf1/inf2) ou inferência em CPU baseada em Graviton para modelos menores a fim de reduzir o custo. Serviços gerenciados como SageMaker Managed Spot Training e SageMaker Distributed Training integram checkpointing e recuperam automaticamente a capacidade spot para reduzir substancialmente o custo de treinamento; no entanto, spot é uma armadilha para produção de baixa latência, a menos que combinado com fallbacks robustos. Padrões de arquitetura que reduzem os gastos incluem processamento em lote (batch) assíncrono, autoscaling com proteções contra cold-start, endpoints de múltiplos modelos para consolidar muitos modelos pequenos em um único host, e o uso de precisão mista e quantização para reduzir as necessidades de memória e throughput. Use frameworks como DeepSpeed ou ZeRO para diminuir o uso de memória no treinamento de modelos grandes e avalie o fine-tuning eficiente em parâmetros (LoRA/adapters) para evitar o retreinamento completo do modelo. Um erro frequente é usar GPUs de ponta para cargas de trabalho com uso intensivo de embeddings, onde instâncias de CPU ou Inferentia entregariam uma relação preço-desempenho muito melhor.

Trade-offs na seleção de modelos e estratégias conscientes de custo

A escolha do modelo é um trade-off entre custo, latência, precisão e sensibilidade dos dados. Os modelos de fundação no Bedrock oferecem escalabilidade gerenciada, ferramentas de segurança e iteração rápida, mas incorrem em custos por chamada ou por token que podem predominar em escala; modelos de código aberto hospedados no SageMaker ou EC2 podem reduzir a despesa por inferência se você amortizar o custo adicional (overhead) de hospedagem e operações. Arquiteturas híbridas funcionam bem: execute um modelo pequeno e barato para a maior parte das solicitações e escale para um modelo maior para consultas complexas, ou use geração aumentada por recuperação, onde o contexto pesado é servido por um banco de dados de vetores (OpenSearch, um banco de dados de vetores baseado no Amazon QLDB ou de terceiros) e apenas prompts concisos são enviados para o LLM. As decisões de fine-tuning devem considerar métodos eficientes em parâmetros (LoRA, adapters) e pares de prompt-conclusão em formato JSONL para tarefas de texto para texto, a fim de limitar o uso de dataset e computação. Armadilhas comuns incluem fazer fine-tuning de modelos desnecessariamente grandes em vez de usar engenharia de prompt, ignorar a inflação do comprimento do prompt em tokens e não fazer cache ou desduplicar respostas para consultas de alta repetição.

Armazenamento, localidade de dados, governança e observabilidade para controle de custos

As escolhas de armazenamento influenciam tanto os custos mensais quanto a conformidade legal. Use o S3 com políticas de ciclo de vida, Intelligent-Tiering e formatos compactados (Parquet/TFRecord) para conjuntos de dados; armazene os dados de treinamento ativos em camadas de alta performance e arquive os ativos brutos no Glacier. Para informações de identificação pessoal (PII) e residência de dados, mantenha os buckets do S3, as chaves do KMS e os recursos de computação na Região da AWS necessária e controle o acesso por meio de endpoints da VPC, políticas do IAM e rede privada para evitar a saída acidental de dados entre regiões. Os pipelines de recuperação para RAG devem colocalizar os armazenamentos de vetores (vector stores), como o Amazon OpenSearch Service ou um armazenamento de embeddings no EC2/EBS, com a camada de inferência para evitar custos de transferência e latência. Ferramentas de observabilidade e explicabilidade, como SageMaker Clarify, Debugger e Model Monitor, proporcionam governança e detecção precoce de desvio (drift), mas adicionam custo — implemente monitores baseados em amostragem para controlar os gastos. Minimize a pegada ambiental e a fatura escolhendo chips eficientes (Inferentia/Trainium) e processamento em lote (batching); um erro comum é habilitar o logging completo e o monitoramento contínuo de modelos sem limiares de amostragem, o que aumenta tanto o custo quanto o ruído, ao mesmo tempo que oferece pouco valor incremental.

Problema Prático: Cenário de Caso de Uso

Cenário: A Acme Retail opera uma stack de IA na AWS usando o Amazon Bedrock para acesso a LLMs, o Amazon SageMaker para treinamento e hospedagem de modelos, o S3 para dados e o Amazon OpenSearch para indexação de produtos. Eles precisam gerar milhares de descrições de produtos, com o tamanho de um parágrafo, por dia, mantendo uma voz de marca consistente, requisitos rigorosos de PII na região e uma meta de custo apertada.

Desafio: Entregar descrições de alta qualidade e alinhadas à marca em escala, minimizando o custo por descrição e garantindo que os dados dos clientes nunca saiam da Região da AWS designada.

Abordagem Recomendada:

1. Use um pipeline de inferência de duas camadas: direcione todas as solicitações primeiro para um modelo leve e quantizado, hospedado localmente no SageMaker ou EC2, para lidar com SKUs comuns e descrições simples; escale casos complexos ou de baixa confiança para um modelo de fundação do Bedrock.
2. Armazene os embeddings e os índices de recuperação no Amazon OpenSearch dentro da região; use um contexto recuperado conciso para manter baixo o uso de tokens do Bedrock e armazene respostas comuns em cache no ElastiCache.
3. Faça o ajuste fino (fine-tune) de um modelo pequeno e especializado usando métodos eficientes em parâmetros (LoRA) no SageMaker Managed Spot Training com checkpoints para o S3, tornando raro o retreinamento do modelo completo.
4. Aplique controles de fronteira de região: buckets do S3 e chaves do KMS na região, endpoints da VPC para Bedrock/SageMaker e use o Model Monitor + Clarify com base em amostragem para limitar os custos de monitoramento.

Justificativa: A combinação de um modelo de base barato com escalonamento seletivo minimiza os custos de token e de instância por descrição, enquanto o RAG e o cache reduzem as chamadas ao Bedrock. O treinamento com instâncias spot gerenciadas (Managed Spot Training) e o ajuste fino eficiente em parâmetros reduzem as despesas de treinamento e a sobrecarga de armazenamento, enquanto os controles na região atendem aos requisitos de PII e conformidade.

← MLOps e Implantação · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →