Entrenamiento y ajuste de hiperparámetros en Amazon SageMaker

Un trabajo de entrenamiento es el objeto más caro que creas antes de que un modelo sirva una sola petición, y es el objeto sobre el que el examen AIF-C01 te pide razonar con más precisión. El Dominio 1 concentra el 20% del contenido puntuado, y la Tarea 1.3 nombra textualmente «realizar ajuste de hiperparámetros u optimización de modelos». El modo de fallo nunca es «no sabías que SageMaker puede entrenar». Es que elegiste modo File para un conjunto de datos de 600 GB de archivos pequeños, o escogiste Bayesian cuando el requisito era «reproducir el mismo conjunto de combinaciones en cada re-ejecución», o activaste Spot sin checkpoint y luego te topaste con el límite de espera de 3.600 segundos que tus notas no documentaban.

Al terminar esta lección sabrás:

• nombrar los campos obligatorios de CreateTrainingJob y explicar qué controla cada uno;
• elegir entre los modos de entrada File, FastFile y Pipe usando los propios umbrales de tamaño de AWS, y configurar canales (s3_data_type, distribution, compression, record_wrapping);
• seleccionar una familia de instancias ml.* para entrenamiento frente a inferencia, y calcular el tamaño del clúster como instancias × GPU;
• decidir entre paralelismo de datos y paralelismo de modelo, y nombrar las bibliotecas de AWS (SMDDP, SMP v2) que los implementan;
• ejecutar Automatic Model Tuning y elegir la estrategia adecuada: Grid vs. Random vs. Bayesian vs. Hyperband;
• configurar correctamente Managed Spot Training (MaxWaitTimeInSeconds ≥ MaxRuntimeInSeconds) y calcular el ahorro real con la fórmula oficial;
• dimensionar un flujo de checkpoint para que un trabajo interrumpido se reanude en lugar de reiniciarse;
• leer las métricas de entrenamiento en CloudWatch y explicar qué hacen Debugger y Experiments, y que Debugger está cerrado para clientes nuevos;
• defender un veredicto comparativo sobre Grid vs. Random vs. Bayesian y sobre entrenamiento gestionado frente a hacerlo tú mismo;
• responder diez preguntas estilo examen redactadas en el tono oficial, incluidos dos cálculos de coste.

---

1. Anatomía de un trabajo de entrenamiento en SageMaker

1.1 Las ocho piezas obligatorias

CreateTrainingJob es una sola llamada a la API, pero es un paquete de ocho decisiones independientes. El examen tiende a probarlas como «¿cuál de estas falta o está mal configurada?», así que apréndetelas como una lista de verificación.

Dos límites vale la pena memorizar porque son baratos de recordar y aparecen a menudo: el MaxRuntimeInSeconds de un trabajo arranca en 1 día y para en firme a los 28 días, y entre ejecución y espera el trabajo no puede superar 30 días. Al detenerse, SageMaker envía SIGTERM y espera 120 segundos a que tu código vuelque lo pendiente: que es exactamente la ventana en la que tu manejador de checkpoints tiene que trabajar.

1.2 El ciclo de vida real de un trabajo

1.3 Cómo cuesta el entrenamiento y cómo se factura

SageMaker factura por instancia-seundo en horas de instancia parciales, sin mínimo y sin compromiso previo. Eso importa más que cualquier tarifa por hora: un trabajo de entrenamiento de 90 segundos cuesta 90 segundos de una instancia, no una hora completa.

• 📚 ¿Sabías que…? El free tier de SageMaker para entrenamiento son 50 horas de ml.m4.xlarge o ml.m5.xlarge en los dos primeros meses: suficiente para unos seis días laborables completos de entrenamiento continuo de CPU, pero solo para unas pocas ejecuciones en GPU. AWS etiqueta la ventana de dos meses como una promoción en la página de precios, así que confirma los términos antes de presupuestar un curso alrededor de ella.

---

2. Cómo entran los datos en el trabajo: modos de entrada y canales

Este es el tema de mayor rendimiento de la lección. AWS documenta exactamente tres modos de entrada en el enum de la API, File, FastFile y Pipe, y la guía del desarrollador todavía llama a File el predeterminado.

2.1 Los tres modos lado a lado

2.2 Modo File: el predeterminado que te cuesta tiempo en silencio

En el modo File la instancia de entrenamiento debe tener espacio de almacenamiento suficiente para alojar el conjunto de datos completo: esa es una cita literal de la guía del desarrollador, y es el mecanismo detrás del clásico ítem del examen: «el entrenamiento solo comienza tras una larga fase de transferencia de datos y el almacenamiento de la instancia debe contener el conjunto de datos completo». Respuesta: File.

El modo File es también el único modo que la documentación vincula explícitamente al entrenamiento incremental, y acepta los tres valores de s3_data_type, incluido AugmentedManifestFile. La fragmentación entre instancias se hace con distribution = ShardedByS3Key.

La propia guía de dimensionamiento de AWS: el modo File sirve para conjuntos de datos por debajo de 50 to 100 GB, y a la tasa documentada de 50 GB en unos 5 minutos con fragments de 100 MB, AWS aconseja serializar los archivos menores de 50 MB en trozos de unos 150 MB (TFRecord o RecordIO).

Ejemplo resuelto 1, dimensionamiento del modo File (sección 12, Ejemplo 1). Un conjunto de datos de 80 GB en modo File necesita un volumen ≥ 80 GB más espacio para la salida. A la tasa de AWS la descarga lleva unos 8 minutos antes de que se ejecute el paso uno, roughly el 21% de un trabajo de 30 minutos dedicado a copiar. Cambia a FastFile, o fragmenta con ShardedByS3Key.

2.3 FastFile: transmite sin copiar

FastFile identifica los objetos pero no descarga nada. S3 se expone como un sistema de archivos POSIX y se lee bajo demanda, así que el arranque es rápido y el espacio local solo hace falta para los artefactos. Dos restricciones que memorizar: acepta solo prefijo (sin manifiesto aumentado), y las lecturas aleatorias funcionan pero las lecturas secuenciales son las mejores. Pueden aplicarse cargos extra de CloudTrail y KMS porque FastFile registra el acceso a nivel de objeto.

2.4 Pipe: el modo de streaming original

Pipe transmite los objetos de S3 por una tubería FIFO con alto pre-fetch, deja el disco solo para los artefactos y te ofrece shuffle por época gestionado, compresión Gzip y envoltura RecordIO. AWS ahora lo describe como «en gran medida reemplazado por … el modo de archivo rápido», así que en el examen Pipe suele ser el distractor de streaming cuando FastFile es la mejor respuesta, o la respuesta correcta cuando la pregunta menciona RecordIO/Gzip/shuffle por época.

2.5 Canales: cómo se enumeran y se dividen los objetos

Un canal es una entrada del trabajo. Sus campos de configuración es donde el examen esconde detalles.

Los almacenes compatibles son Amazon S3, Amazon EFS y Amazon FSx for Lustre (más S3 Express One Zone), y el conjunto de datos debe estar en la misma Región que el trabajo de entrenamiento: un bucket de S3 en us-west-2 alimentando un trabajo en us-east-1 no es un patrón compatible.

2.6 Cómo elegir un modo, con los umbrales de AWS

---

3. Elegir compute: las familias de instancias ml.*

3.1 La regla de nombres

Toda SKU de compute de SageMaker lleva el prefijo ml.. Ese prefijo es la pista más barata del examen: si una opción dice p4d.24xlarge sin el ml. cuando el contexto es un trabajo de entrenamiento o un endpoint de SageMaker, está describiendo EC2, no SageMaker. Las familias se separan con claridad por papel.

3.2 El hardware de GPU que publica AWS

3.3 Dos reglas de dimensionamiento que deciden tu factura

Regla 1: escala el tamaño de la instancia antes de añadir instancias. La guía de entrenamiento distribuido de AWS es explícita: un único ml.p3.16xlarge supera a dos ml.p3.8xlarge para las mismas 8 GPU, porque pagas un solo interconecto en lugar de un salto de red. Añadir instancias es lo que haces cuando una sola máquina no puede alojar el modelo o los datos.

Regla 2: el tamaño del clúster = instancias × GPU. Dos nodos ml.p3.16xlarge te dan un clúster de 16 GPU, no de 8. Todo grado de paralelismo, cálculo de batch size y coste de comunicación de la sección 4 se deriva de ese producto.

Ejemplo resuelto 2: dimensionamiento distribuido (sección 12, Ejemplo 2). ml.p3.16xlarge × 2 = 8 GPU por nodo → tamaño del clúster 16. La referencia publicada de AWS para un LLM de 70.000 millones de parámetros es 32 × ml.p4d.24xlarge = 256 GPU, con grado de paralelismo de datos fragmentado 256 y batch size 2; un modelo de 175B necesita 64 × ml.p4d.24xlarge, mientras que un modelo de 7B cabe en 1 × ml.p4d.24xlarge.

• 📚 ¿Sabías que…? ml.p5.48xlarge se entrega con 8 × H100 y 640 GB de memoria total de GPU y 3.200 Gbps de red EFAv2: más ancho de banda que la mayoría de los racks hace una década, y la razón por la que el entrenamiento multinodo en esa familia está limitado por ancho de banda y no por cómputo. Alcanzó la disponibilidad general el 4 de agosto de 2023, inicialmente en us-east-1 y us-west-2.

---

4. Entrenamiento distribuido: paralelismo de datos vs. paralelismo de modelo

4.1 La distinción que el examen busca

La formulación del examen suele ser un síntoma: «el modelo no cabe en la memoria de una sola GPU, pero el conjunto de datos es modesto» → paralelismo de modelo. El espejo: «el modelo entrena bien en una GPU pero el conjunto de datos es enorme» → paralelismo de datos.

4.2 Las bibliotecas que nombra AWS

Para trabajos multinodo grandes, la guía de AWS converge siempre en el mismo stack: GPUs con EFA, idealmente ml.p4d/ml.p4de (A100) o más nuevas, más Amazon FSx for Lustre para el conjunto de datos. EFA importa porque evita el stack de red del sistema operativo; FSx importa porque mil archivos pequeños leídos desde S3 dejarían con hambre a 256 GPU.

Ejemplo resuelto 3: cuánto modelo cabe dónde (sección 12, Ejemplo 3). Las referencias publicadas de AWS: Llama 2 7B → 1 × ml.p4d.24xlarge; Llama 2 70B → 32 × ml.p4d.24xlarge; 175B → 64 ×; GPT-2 10B → 16 ×. Léelas como una regla práctica: el número de parámetros, no el tamaño del conjunto de datos, determina el número de instancias una vez que se supera la capacidad de una GPU.

---

5. Automatic Model Tuning: qué hace un trabajo de ajuste

5.1 La idea en una frase

Automatic Model Tuning (AMT) ejecuta muchos trabajos de entrenamiento sobre los rangos de hiperparámetros que le suministras y conserva el que mejor rendimiento obtiene en tu métrica objetivo. Tú defines los rangos; SageMaker ejecuta la búsqueda; tú recibes el mejor ensayo.

El examen lo llama «ajuste de hiperparámetros u optimización de modelos» y cae de lleno en la Tarea 1.3.

5.2 El flujo del trabajo de ajuste

5.3 Rangos, escalas y la métrica objetivo

Los rangos de hiperparámetros tienen tipo y escala. Auto, Linear, Logarithmic y ReverseLogarithmic son las cuatro opciones de escala, y cada una tiene una regla de dominio que conviene conocer porque es una comprobación de corrección gratuita en el examen:

TrainingJobEarlyStoppingType es OFF por defecto y puede ponerse en AUTO para detener ensayos que claramente no van a ganar. El warm start reutiliza los ensayos padre de un trabajo de ajuste anterior, lo que reduce el coste y el tiempo real cuando amplías una búsqueda en lugar de reiniciarla.

5.4 Los límites que debes poder recitar

De ahí se siguen dos consecuencias. Primero, AWS aconseja mantener el número de hiperparámetros muy por debajo del límite de 30: cada dimensión extra diluye la búsqueda. Segundo, RandomSeed hace que una búsqueda Random o Hyperband sea reproducible hasta en un 100%, que es el mecanismo detrás del ítem del examen de «reproducir combinaciones idénticas».

Ejemplo resuelto 4: presupuesto de ajuste y aritmética de cuotas (sección 12, Ejemplo 4). MaxNumberOfTrainingJobs = 20, una hora cada uno en ml.g4dn.12xlarge al precio publicado de AWS de 4,89 $/h → 20 × 4,89 $ = 97,80 $. Con MaxParallelTrainingJobs = 10 ejecutas 2 oleadas ≈ 2 horas en lugar de 20. Llevarlo a 100 trabajos cuesta 489 $ sin garantía de mayor precisión. Aparte, el propio ejemplo de cuota de AWS: 10 trabajos de ajuste × 100 trabajos de entrenamiento × 20 concurrentes en ml.m4.xlarge supera los límites de 100 ajustes concurrentes y 750 trabajos, pero necesita un aumento para 20 trabajos de entrenamiento concurrentes (predeterminado 10) y 200 instancias ml.m4.xlarge (predeterminado 20).

• 📚 ¿Sabías que…? Un trabajo de ajuste de SageMaker no es un producto de compute separado: es un orquestador que crea trabajos de entrenamiento ordinarios y observa sus métricas de CloudWatch. Por eso las cuotas del trabajo de ajuste se expresan tanto en trabajos de ajuste (100 concurrentes) como en trabajos de entrenamiento (10 paralelos, 750 en total): se te factura por las mismas instancias-seundo de cualquier forma.

---

6. Estrategias de ajuste: Grid vs. Random vs. Bayesian vs. Hyperband

Esta es la comparación que el examen te pide hacer bajo presión de tiempo. Apréndete la fila que difiere, no la tabla entera.

6.1 La comparación completa

6.2 Grid: determinista, categórica, combinatoria

Grid enumera cada combinación distinta de los valores categóricos que le das, y SageMaker calcula el número de trabajos automáticamente: deberías fijar MaxNumberOfTrainingJobs a ese número. Es la estrategia para reproducir resultados y para una cobertura uniforme del espacio de búsqueda.

Ejemplo resuelto 5: número de trabajos de Grid (sección 12, Ejemplo 5). Dos parámetros categóricos con 5 y 4 valores → 5 × 4 = 20 combinaciones → SageMaker crea 20 trabajos de entrenamiento. Añade un tercer parámetro con 3 valores → 60 trabajos. Grid explota combinatoriamente, y por eso AWS deriva los espacios de búsqueda grandes hacia Bayesian o Random.

6.3 Random: máximo paralelismo, cero aprendizaje

Como Random ignora los resultados previos, cada ensayo es independiente y la estrategia admite el mayor número de trabajos de entrenamiento paralelos de todas. Es también la única estrategia cuyo techo de trabajos puede elevarse de 750 a 10.000, y con un RandomSeed fijo reproduce la secuencia idéntica de configuraciones.

6.4 Bayesian: el predeterminado del SDK y un optimizador secuencial

Bayesian construye un modelo de regresión sobre los ensayos completados hasta el momento y propone la siguiente configuración donde la mejora parece más probable. Eso lo convierte en el mejor uso de un presupuesto pequeño y en el predeterminado del HyperparameterTuner del SDK de SageMaker, pero también lo hace secuencial: el ensayo n+1 depende del ensayo n, así que AWS afirma que no puede escalar masivamente en paralelo.

6.5 Hyperband: multi-fidelity, solo algoritmos iterativos

Hyperband reasigna épocas entre rondas sucesivas, detiene pronto los trabajos débiles y ejecuta muchos trabajos en paralelo. La restricción dura es el algoritmo: necesita algoritmos iterativos que puedan juzgarse significativamente a medio camino. XGBoost y Random Cut Forest califican; los árboles de decisión y k-NN no. AWS lo comercializa como hasta 3× más rápido que Bayesian: esa cifra proviene de una página what-is de AWS, así que cítala como una afirmación de AWS y no como un benchmark reproducido.

---

7. Managed Spot Training y checkpoints

7.1 Qué es

Managed Spot Training ejecuta tu trabajo de entrenamiento en capacidad Spot de EC2 con SageMaker gestionando las interrupciones por ti. AWS lo lanzó el 26 de agosto de 2019 y desde entonces ha publicado dos cifras de ahorro distintas: ambas publicadas por AWS, y ambas aparecen en el material del examen:

7.2 La fórmula oficial, y el único cálculo que necesitas

$$\text{Savings (\%)} = \left(1 - \frac{\text{BillableTimeInSeconds}}{\text{TrainingTimeInSeconds}}\right) \times 100$$

Ejemplo resuelto 6: aritmética del ahorro Spot (sección 12, Ejemplo 6). Un trabajo se ejecuta durante 500 segundos y se le factura por 100 segundos:

$$(1 - 100/500) \times 100 = 80\%$$

El trabajo de demostración del blog de lanzamiento de AWS corrió 2.423 segundos y se le facturó por 837 → $(1 - 837/2423) \times 100 \approx \mathbf{65\%}$. Calcula el ahorro por trabajo; nunca asumas una cifra fija.

Ejemplo resuelto 7, On-Demand vs. Spot para una ejecución con GPU (sección 12, Ejemplo 7). ml.g4dn.12xlarge publicado por AWS = 4,89 $/h. Dos horas On-Demand = 9,78 $. Si solo 36 de los 120 minutos de tiempo real son facturables en Spot: $0.6 \times 4.89 \approx$ 2,93 $, alrededor de un 70% de ahorro, coincidente con la historia del cliente Cinnamon AI.

7.3 Las dos reglas de configuración

Ejemplo resuelto 8, configuración Spot (sección 12, Ejemplo 8). Un trabajo con checkpointing de 6 horas: MaxRuntimeInSeconds = 21.600 y MaxWaitTimeInSeconds mayor que eso (la demo de AWS usó 48 h = 172.800 s), más CheckpointConfig.S3Uri. Ejecuta el mismo trabajo de 6 horas sin checkpointing y el límite de espera es 3.600 s, así que o añades checkpointing o ejecutas On-Demand.

7.4 Checkpoints: reanudar, no reiniciar

7.5 Cómo es realmente un trabajo interrumpido

La máquina de estados documentada es Starting → Downloading → Training → Uploading, con bucles Interrupted → Starting → … en medio y un estado terminal Stopped: MaxWaitTimeExceeded cuando el presupuesto de espera se agota antes de que termine el trabajo.

---

8. Observar la ejecución: métricas, Debugger y Experiments

8.1 Dónde acaban los números

Las métricas de entrenamiento se publican en Amazon CloudWatch bajo el namespace /aws/sagemaker/TrainingJobs, y la vista Training jobs → Monitor de la consola de SageMaker las grafica. Esa es la respuesta siempre que una pregunta pregunte cómo sabes si un trabajo está convergiendo, divergiendo o saturando la GPU.

8.2 Debugger: tensores, reglas y acciones

Así que el ítem del examen «detener automáticamente el trabajo de entrenamiento cuando se dispare una regla de gradiente desvaneciente y enviar un correo al equipo» se resuelve con las acciones integradas de Debugger: con la salvedad de que Debugger está cerrado para clientes nuevos.

8.3 SageMaker Experiments

Experiments rastrea cada ensayo y cada ejecución, los hiperparámetros usados, las métricas producidas, los artefactos escritos, para que puedas comparar ejecuciones lado a lado. La salida de Debugger puede dirigirse a TensorBoard para su visualización. Experiments es la respuesta a «¿cuál de mis 20 ejecuciones fue la mejor y con qué ajustes?»; Debugger es la respuesta a «¿qué está pasando dentro de esta ejecución ahora mismo?».

---

9. Rutas que se saltan por completo el bucle de entrenamiento

9.1 JumpStart: modelos preentrenados que puedes afinar

JumpStart es el centro de modelos preentrenados de código abierto de SageMaker, procedentes de TensorFlow Hub, PyTorch Hub, Hugging Face y GluonCV. Dos números importan para el examen: cubre 15 tipos de problema, de los cuales 8 son entrenables, es decir, puedes hacer entrenamiento incremental / fine-tuning sobre ellos, y se integra con Automatic Model Tuning.

9.2 Autopilot: AutoML para tabulares (y, vía v2, más)

Alcance: datos tabulares de hasta cientos de gigabytes; las tareas de texto, imagen y previsión más el fine-tuning de LLM se gestionan a través de la API AutoML v2. La UI se trasladó a SageMaker Canvas el 30 de noviembre de 2023, así que los usuarios sin código van a Canvas y Autopilot sigue siendo la vía de la API.

9.3 Cómo elegir un punto de partida

• 📚 ¿Sabías que…? La preselección de algoritmos de Autopilot es deliberadamente pequeña, árboles potenciados por gradiente, una DNN feedforward y regresión logística, porque AutoML es un motor de selección y ajuste, no un laboratorio de investigación. La etapa de HPO que ejecuta internamente es el mismo mecanismo de Automatic Model Tuning descrito en la sección 5, y por eso los dos comparten el lenguaje de cuotas.

---

10. Veredicto comparativo: estrategias y entrenamiento gestionado frente a hacerlo tú mismo

10.1 Entrenamiento gestionado vs. construirlo yourself

10.2 Estrategias de ajuste de un vistazo

---

11. Límites, cuotas y evidencia de coste en un solo lugar

11.1 Límites y benchmarks publicados

11.2 Evidencia de coste

11.3 Actualizaciones de 2025 to 2026

Cada número de las secciones 1 to 10 procede de páginas de AWS comprobadas el 6 de octubre de 2026. Lo que realmente se movió en 2025 to 2026 fue sobre todo disponibilidad, no aritmética: el producto cambió de nombre, toda una franja de funciones de SageMaker alrededor del bucle de entrenamiento pasó a mantenimiento, y la guía del examen se revisó. Los cambios de disponibilidad importan en el examen porque una función cerrada para clientes nuevos puede ser la respuesta equivocada incluso cuando la guía del desarrollador todavía la documenta por completo.

El vocabulario de ciclo de vida propio de AWS (AWS General Reference, Service lifecycle) vale la pena aprenderlo porque te dice qué significa realmente «cerrado»: Maintenance = sin clientes nuevos, sin funciones nuevas, todavía soportado; Sunset = un fin de operaciones planificado, normalmente con unos 12 meses de horizonte; Full Shutdown = eliminado del portafolio. Cada ítem de SageMaker del aviso del 30 de julio de 2026 está en el primer estado, no en el tercero, y por eso esta lección mantiene Debugger en la sección 8 con una fecha adjunta en lugar de borrarlo.

• 📚 ¿Sabías que…? AWS afirma que los cambios en la guía del examen aparecen en el examen real aproximadamente un mes después de su publicación: así que los objetivos de la v1.1 publicados el 30 de abril de 2026 se pudieron examinar desde aproximadamente finales de mayo de 2026. Esa misma revisión puso SageMaker JumpStart en la lista de servicios del alcance (sección 9.1 de esta lección), eliminó Amazon MemoryDB y dejó intacta la aritmética del examen: 65 preguntas (50 puntuadas + 15 sin puntuar), 90 minutos, 100 USD, 700/1000 para aprobar, validez de tres años, con dominios ponderados 20 / 24 / 28 / 14 / 14.

---

12. Ejemplos prácticos de AWS con números

Ejemplo 1: dimensionamiento del modo File. Conjunto de datos de 80 GB, modo File → volumen ≥ 80 GB más margen para la salida. A la tasa documentada de AWS (50 GB ≈ 5 min con fragments de 100 MB) la copia lleva ≈ 8 minutos, alrededor del 21% de un trabajo de 30 minutos, antes del primer paso de entrenamiento. Solución: FastFile, o distribution = ShardedByS3Key.

Ejemplo 2: dimensionamiento distribuido. ml.p3.16xlarge × 2 → 8 GPU/nodo → tamaño del clúster 16. Guía de AWS: prueba primero el nodo individual más grande (1 × 16xlarge supera a 2 × 8xlarge para las mismas 8 GPU). Escala de referencia: 7B → 1 × ml.p4d.24xlarge, 70B → 32 × (256 GPU, grado de paralelismo de datos fragmentado 256, batch 2), 175B → 64 ×.

Ejemplo 3, el ajuste del modelo determina el número de instancias. El número de parámetros, no el tamaño del conjunto de datos, decide el número de nodos una vez que se supera la memoria de una GPU: 8 × A100 de 40 GB = 320 GB en un ml.p4d.24xlarge, 8 × H100 = 640 GB en un ml.p5.48xlarge. Si el modelo más el estado del optimizador excede el dispositivo, ninguna cantidad de paralelismo de datos ayuda, necesitas paralelismo de modelo (SMP v2).

Ejemplo 4: presupuesto de ajuste y aritmética de cuotas. MaxNumberOfTrainingJobs = 20 × 1 h × ml.g4dn.12xlarge a 4,89 $/h = 97,80 $; con MaxParallelTrainingJobs = 10 → 2 oleadas ≈ 2 h en lugar de 20 h. Con 100 trabajos la factura es de 489 $ sin garantía de precisión. El ejemplo de cuota de AWS: 10 trabajos de ajuste × 100 trabajos de entrenamiento × 20 concurrentes → supera los límites de 100 ajustes y 750 trabajos, pero necesita aumentos para 20 trabajos de entrenamiento concurrentes (predeterminado 10) y 200 instancias ml.m4.xlarge (predeterminado 20).

Ejemplo 5: número de trabajos de Grid. 5 valores × 4 valores = 20 trabajos. Añade un tercer parámetro con 3 valores → 60 trabajos. Grid crece multiplicativamente; ese es el argumento para Bayesian o Random en cualquier espacio no trivial.

Ejemplo 6, ahorro Spot. 500 s de entrenamiento, 100 s facturados → $(1 - 100/500) \times 100 = \mathbf{80\%}$. Trabajo del blog de lanzamiento: 837 / 2.423 → ≈ 65%. El mismo trabajo con una fracción facturable del 90% solo ahorraría un 10%, el ahorro es una medición por trabajo, nunca un descuento fijo.

Ejemplo 7: On-Demand vs. Spot. ml.g4dn.12xlarge al precio publicado por AWS de 4,89 $/h: 2 h On-Demand = 9,78 $. Spot con 36 minutos facturables de 120 → $0.6 \times 4.89 \approx$ 2,93 $, es decir ≈ 70% de ahorro.

Ejemplo 8: configuración Spot + checkpoint. Trabajo de 6 horas: MaxRuntimeInSeconds = 21.600, MaxWaitTimeInSeconds mayor (la demo de AWS usó 48 h), más CheckpointConfig.S3Uri y código que escribe en /opt/ml/checkpoints. El mismo trabajo con un algoritmo integrado y sin checkpointing → espera limitada a 3.600 s → ejecuta On-Demand en su lugar.

• 📚 ¿Sabías que…? SageMaker factura el entrenamiento por segundo y sin mínimo, así que el experimento fallido más barato es el rápido. Ese es el argumento real detrás de TrainingJobEarlyStoppingType = AUTO: detener un ensayo sin esperanzas en el minuto 12 en lugar del minuto 60 es una reducción de 5/6 en la factura de ese ensayo, y con hasta 100 trabajos de entrenamiento paralelos por trabajo de ajuste esos ahorros se multiplican por toda la búsqueda.

---

13. Hechos en conflicto, sin verificar y no examinables

Separa lo que AWS documenta de lo que AWS comercializa. Mantén esta tabla fuera de tu conjunto de memorización salvo donde se marque «usar para el examen».

Las fuentes primarias de esta lección: las páginas de la guía del desarrollador de SageMaker model-access-training-data, model-access-training-data-best-practices, automatic-model-tuning{,-how-it-works,-considerations,-limits}, multiple-algorithm-hpo-create-tuning-jobs, model-managed-spot-training{,-status}, model-checkpoints{,-resume}, distributed-training{,-get-started,-scenarios}, model-parallel-intro-v2, model-parallel-best-practices-v2, train-debugger, debugger-debug-training-jobs, debugger-built-in-actions, experiments-mlops, view-train-metrics, cmn-info-instance-types, jumpstart-models, studio-jumpstart, use-auto-ml, autopilot-automate-model-development; la referencia de la API API_CreateTrainingJob, API_AlgorithmSpecification, API_Channel, API_HyperParameterTuningJobConfig, API_ResourceLimits, API_StoppingCondition; boto3 create_training_job / describe_training_job; el SDK de SageMaker HyperparameterTuner; la guía del examen AIF-C01; y las páginas de precios de SageMaker.

---

14. Casos Reales

AWS publica pocas historias de clientes sobre entrenamiento como tal, el momento facturable rara vez es fotogénico, así que estas cuatro son la mitad de entrenamiento y ajuste del registro de casos de estudio de AWS: cada una nombra sus servicios, sus números y su fuente, y cada una se mapea con una sección de arriba. Lee cada porcentaje como una cifra afirmada por el cliente o por AWS, sin auditar, y lee «hasta» como un techo.

14.1 Las cuatro historias

HAYAT HOLDING: Automatic Model Tuning en una línea de producción real (manufactura, 2023). El fabricante de paneles MDF había construido sus propios entornos de ML y los describía como «costosos en tiempo y engorrosos». La arquitectura publicada ejecuta 194 sensores por OPC-UA hacia un SiteWise Edge Gateway de AWS IoT Greengrass, y luego SageMaker Model Training + Automatic Model Tuning + Model Deployment, con SageMaker Edge Manager sirviendo el modelo resultante en el dispositivo. Resultado comunicado: 300.000 dólares al año de ahorro, junto con mayor calidad y producción optimizada. Esto es la sección 5 en producción: barridos manuales de hiperparámetros reemplazados por AMT en 194 entradas: con el destino de despliegue un dispositivo edge en lugar de un endpoint. Fuente: AWS Machine Learning Blog, blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).

RareJob: entrenamiento Spot gestionado en lugar de una cola (EdTech, 2020). La evaluación de pruebas de habla (PROGOS) empezó en un PC local, lo que permitía un modelo por desarrollador, y luego pasó a EC2/ECS y seguía costando demasiado. La arquitectura de AWS alimenta AWS Glue y Amazon Athena hacia trabajos de entrenamiento Spot gestionados de SageMaker en paralelo. Resultado comunicado: 25% menos de tiempo de entrenamiento, más de 10× de eficiencia de desarrollo, 100 horas al mes de ahorro y puntuaciones devueltas en 2 to 3 minutos. Esto es la sección 7 en producción: el cuello de botella era la cola, no la calidad del modelo, y Spot más orquestación convirtió una cola serial en un fan-out. Fuente: caso de estudio de AWS, solutions/case-studies/rare-job-case-study (2020).

Chronomics, el fallo documentado del entrenamiento DIY (salud digital, 2022). Cuatro meses de modelado interno de visión por computador personalizado para leer resultados de pruebas de COVID-19 nunca alcanzaron el objetivo. El equipo se lanzó con Amazon Rekognition Custom Labels (AutoML de AWS) en 3 to 4 semanas con 96,5% de precisión / 97,9% de F1, puntuado con DetectCustomLabels. El análisis de umbrales publicado es la parte que vale la pena memorizar: un umbral de confianza de 0,99 → el 99,6% de predicciones correctas con un 5% descartado, y 0,999 → 99,87% con un 27% descartado. La lección es la selección de nivel (sección 9): para una tarea de visión estrecha, el AutoML gestionado superó a un bucle de entrenamiento construido a mano, y alguien tiene que decidir todavía qué pasa con el 5% descartado, la ruta humana que AWS documenta para esa cola es Amazon A2I. Fuente: AWS Machine Learning Blog, blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (2022).

Forethought, lo que la infraestructura DIY le cuesta a un equipo de tres personas (soporte de clientes SaaS). SupportGPT gestiona 30 millones de interacciones al año con varios modelos por cliente, y el equipo de 3 personas no podía ejecutar a la vez modelos y Kubernetes, excepciones de memoria y caídas los expulsaron de su propio Amazon EKS. Migraron a SageMaker multi-model endpoints y SageMaker Serverless Inference: 66% menos de coste en multi-model endpoints con mejor latencia, aproximadamente un 80% menos en Serverless (titular: hasta el 80%), y más del 80% de la inferencia de GPU ejecutándose ahora en SageMaker. La conexión con esta lección es el veredicto de la sección 10: cada dólar ahorrado en serving vuelve al presupuesto de entrenamiento y ajuste, y la infraestructura autoadministrada es el impuesto oculto del que advierten ambas columnas de esa tabla. Fuente: caso de estudio de AWS, solutions/case-studies/forethought-technologies-case-study.

14.2 Servicios, números y fuentes de un vistazo

• 📚 ¿Sabías que…? El «antes» más demoledor de todo el registro de casos de estudio pertenece a Sun Finance (fintech, ML Blog 2026): su primer prototipo enviaba fotos de identificación directamente a Claude Sonnet 4 y puntuó 61,8% en total, 43% en el número de identificación, y fue rechazado. Separar los trabajos (Amazon Textract para OCR, Rekognition como respaldo y para enmascarar caras, el modelo solo para estructurar, más reglas de validación en 585 imágenes) llevó el mismo pipeline al 85% y luego al 90,80% de precisión, −91% de coste por documento y 20 horas → menos de 5 segundos. El bucle de entrenamiento nunca fue el problema; la evaluación lo era.

14.3 Qué demuestra cada caso frente a esta lección

---

Preguntas de Práctica (Practice Questions)

---