Amazon AIF-C01: Optimización de Costos y Precios para IA/ML — Guía de estudio

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

Forma parte de la AWS AI Practitioner AIF-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Factores de costo y modelos de precios en Bedrock, SageMaker y EC2

La tarificación para cargas de trabajo de IA/ML se divide entre cómputo, almacenamiento, red y medición específica del servicio. El acceso a los modelos fundacionales a través de Amazon Bedrock generalmente se mide por solicitud o por token para cargas de trabajo de texto, y por segundo para las API de streaming; SageMaker cobra por horas de instancia para el entrenamiento y el alojamiento multiinquilino (multi-tenancy), además de la transferencia y el almacenamiento de datos. El alojamiento basado en EC2 conlleva el costo bruto por hora de instancia, con cargos adicionales de almacenamiento de EBS, EFS o FSx y de egreso de VPC. Los factores de costo clave son el tamaño del modelo (los modelos más grandes aumentan el trabajo de tokens/matemáticas y el consumo de memoria), el rendimiento de la inferencia (las llamadas síncronas sensibles a la latencia cuestan más cuando se fijan a GPU costosas) y el movimiento de datos para la generación aumentada por recuperación (RAG), donde las búsquedas de embeddings y las búsquedas vectoriales pueden multiplicar las llamadas. Las trampas comunes para los profesionales incluyen subestimar los costos de los embeddings para sistemas RAG con un alto número de consultas por segundo (QPS), dejar en ejecución múltiples endpoints de SageMaker inactivos e ignorar el egreso entre regiones al mantener la PII (información de identificación personal) dentro de una región. Por lo tanto, los criterios de decisión deben considerar el volumen de solicitudes, la tolerancia a la latencia por solicitud, si el modelo debe ser ajustado (fine-tuned) o puede permanecer listo para usar (off-the-shelf), y si la inferencia gestionada por el proveedor (endpoints de Bedrock/SageMaker) o las instancias EC2/GPU autogestionadas ofrecen un mejor TCO al tener en cuenta la sobrecarga de gestión y escalado.

Selección de instancias, instancias Spot y patrones de optimización de cómputo

La elección de las instancias afecta tanto al rendimiento como al costo. Para el entrenamiento, utilice clústeres de Trainium (trn1) o GPU (p4/p5) cuando el rendimiento de matrices a gran escala sea esencial; para la inferencia, prefiera Inferentia/Inf2 (inf1/inf2) o la inferencia en CPU basadas en Graviton para modelos más pequeños con el fin de reducir costos. Servicios gestionados como SageMaker Managed Spot Training y SageMaker Distributed Training integran la creación de puntos de control (checkpointing) y recuperan automáticamente la capacidad Spot para reducir sustancialmente el costo del entrenamiento; sin embargo, las instancias Spot son una trampa para entornos de producción de baja latencia a menos que se combinen con mecanismos de respaldo (fallbacks) robustos. Los patrones de arquitectura que reducen el gasto incluyen el procesamiento por lotes asíncrono (asynchronous batching), el autoescalado con protecciones contra el arranque en frío (cold-start), los endpoints multimodelo para consolidar muchos modelos pequeños en un único host, y el uso de precisión mixta y cuantización para reducir las necesidades de memoria y rendimiento. Utilice frameworks como DeepSpeed o ZeRO para reducir el consumo de memoria en el entrenamiento de modelos grandes, y evalúe el ajuste fino eficiente en parámetros (LoRA/adaptadores) para evitar el reentrenamiento completo del modelo. Un error frecuente es usar GPU de gama alta para cargas de trabajo con uso intensivo de embeddings, donde las instancias de CPU o Inferentia ofrecerían una relación precio-rendimiento mucho mejor.

Compensaciones en la selección de modelos y estrategias conscientes del costo

La elección del modelo es una compensación entre costo, latencia, precisión y sensibilidad de los datos. Los modelos fundacionales en Bedrock ofrecen escalado gestionado, herramientas de seguridad e iteración rápida, pero incurren en costos por llamada o por token que pueden ser dominantes a gran escala; los modelos de código abierto alojados en SageMaker o EC2 pueden reducir el gasto por inferencia si se amortiza la sobrecarga de alojamiento y operaciones (Ops). Las arquitecturas híbridas funcionan bien: ejecute un modelo pequeño y económico para la mayor parte de las solicitudes y escale a un modelo más grande para consultas complejas, o utilice la generación aumentada por recuperación, donde el contexto pesado es servido por un almacén de vectores (vector store) (OpenSearch, una base de datos de vectores respaldada por Amazon QLDB o de terceros) y solo se envían prompts concisos al LLM. Las decisiones de ajuste fino (fine-tuning) deben considerar métodos eficientes en parámetros (LoRA, adaptadores) y pares de prompt-completion en formato JSONL para tareas de texto a texto con el fin de limitar el uso del conjunto de datos y del cómputo. Las trampas comunes incluyen realizar un ajuste fino (fine-tuning) en modelos innecesariamente grandes en lugar de usar ingeniería de prompts, pasar por alto la inflación en la longitud de los tokens del prompt y no almacenar en caché ni deduplicar las respuestas para consultas muy repetitivas.

Almacenamiento, localidad de los datos, gobernanza y observabilidad para el control de costos

Las decisiones de almacenamiento influyen tanto en los costos mensuales como en el cumplimiento legal. Utilice S3 con políticas de ciclo de vida, Intelligent-Tiering y formatos comprimidos (Parquet/TFRecord) para los conjuntos de datos; almacene los datos de entrenamiento activos en niveles de alto rendimiento y archive los activos sin procesar en Glacier. Para la PII y la residencia de datos, mantenga los buckets de S3, las claves de KMS y la computación en la Región de AWS requerida y controle el acceso mediante VPC endpoints, políticas de IAM y redes privadas para evitar la salida accidental entre regiones. Las canalizaciones de recuperación para RAG deben coubicar los almacenes de vectores (Amazon OpenSearch Service o un almacén de embeddings en EC2/EBS) con la capa de inferencia para evitar costos de transferencia y latencia. Las herramientas de observabilidad y explicabilidad como SageMaker Clarify, Debugger y Model Monitor proporcionan gobernanza y detección temprana de desviaciones, pero añaden costos; implemente monitores basados en muestreo para controlar el gasto. Minimice la huella ambiental y la factura eligiendo chips eficientes (Inferentia/Trainium) y el procesamiento por lotes; un error común es habilitar el registro completo y el monitoreo continuo del modelo sin umbrales de muestreo, lo que aumenta tanto el costo como el ruido, a la vez que proporciona poco valor incremental.

Problema práctico: Escenario de caso de uso

Escenario: Acme Retail opera una pila de IA en AWS utilizando Amazon Bedrock para el acceso a LLM, Amazon SageMaker para el entrenamiento y alojamiento de modelos, S3 para los datos y Amazon OpenSearch para la indexación de productos. Deben generar miles de descripciones de productos de la longitud de un párrafo por día con una voz de marca consistente, requisitos estrictos de PII dentro de la región y un objetivo de costos ajustado.

Desafío: Entregar descripciones de alta calidad y con la identidad de la marca a escala, minimizando al mismo tiempo el costo por descripción y asegurando que los datos de los clientes nunca salgan de la Región de AWS designada.

Enfoque recomendado:

Utilice una canalización de inferencia de dos niveles: dirija todas las solicitudes primero a un modelo ligero alojado localmente en SageMaker o EC2 (cuantizado) para manejar los SKU comunes y las descripciones simples; escale los casos complejos o de baja confianza a un modelo fundacional de Bedrock.
Almacene los embeddings y los índices de recuperación en Amazon OpenSearch dentro de la región; utilice un contexto recuperado conciso para mantener bajo el uso de tokens de Bedrock y almacene en caché las respuestas comunes en ElastiCache.
Realice un ajuste fino de un modelo pequeño y especializado utilizando métodos de eficiencia de parámetros (LoRA) en SageMaker Managed Spot Training con puntos de control en S3, manteniendo el reentrenamiento completo del modelo como algo poco frecuente.
Aplique controles de límite de región: buckets de S3 y claves de KMS dentro de la región, VPC endpoints para Bedrock/SageMaker y un monitoreo basado en muestreo con Model Monitor + Clarify para limitar los costos de monitoreo.

Justificación: La combinación de un modelo base económico con una escalada selectiva minimiza los costos de tokens e instancia por descripción, mientras que RAG y el almacenamiento en caché reducen las llamadas a Bedrock. El entrenamiento gestionado con instancias spot y el ajuste fino de eficiencia de parámetros reducen los gastos de entrenamiento y la sobrecarga de almacenamiento, mientras que los controles dentro de la región satisfacen los requisitos de PII y cumplimiento.

← MLOps y Despliegue · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →