Cada minuto que una GPU pasa esperando a que se descargue una imagen de contenedor es un minuto que se paga y que no hace avanzar el modelo. Amazon Web Services (AWS) anunció el 27 de octubre que lleva la indexación Seekable OCI (SOCI) a los trabajos de entrenamiento y de procesamiento de Amazon SageMaker AI, para que empiecen en segundos en lugar de minutos.
En sus pruebas, la descarga de una imagen de 35,4 GB pasó de 7 minutos y 17 segundos a entre 3 y 11 segundos, y el tiempo de GPU ociosa durante esas descargas se redujo hasta un 90 %. La función está disponible en todas las regiones de AWS.
SOCI no es nuevo. Es un proyecto de código abierto que AWS ya aplica en Fargate y que, desde diciembre de 2025, usa también en SageMaker Studio. La novedad es que llega a donde más se nota: los trabajos que se lanzan una y otra vez para entrenar y ajustar modelos.
El problema: GPU que facturan sin trabajar
Los trabajos de SageMaker AI se ejecutan dentro de imágenes de contenedor guardadas en Amazon Elastic Container Registry (ECR). Antes de ejecutar el código, el servicio descarga la imagen completa, la descomprime y escribe cada capa en disco.
Con imágenes pequeñas, eso dura segundos. Pero las de aprendizaje profundo, que incluyen marcos como PyTorch o TensorFlow y sus bibliotecas, superan con frecuencia los 10 GB. La descarga añade minutos a cada trabajo, y esos minutos se facturan.
AWS señala que el golpe es mayor justo donde más importa la velocidad: los barridos de ajuste de hiperparámetros con cientos de trabajos, los experimentos rápidos y los trabajos de procesamiento cortos, en los que la descarga puede ocupar buena parte del tiempo total.
Cómo funciona SOCI en SageMaker AI
SOCI es una tecnología de carga diferida (lazy loading). Un índice, que es un mapa de metadatos de todos los archivos de la imagen, permite descargar solo lo necesario para arrancar el contenedor. El resto llega en segundo plano a medida que el código lo pide.
El índice se guarda en ECR como un artefacto aparte, vinculado a la imagen original. Así, el identificador de la imagen (digest) y sus firmas siguen siendo válidos.
SageMaker AI comprueba por su cuenta si la imagen tiene índice. Si lo tiene, la carga bajo demanda. Si no lo tiene, o si la carga diferida falla, hace la descarga estándar y el trabajo sigue adelante. No hace falta tocar la definición del trabajo, el punto de entrada ni los canales de datos: solo cambia la etiqueta de la imagen.
Lo que midió AWS
AWS probó ocho imágenes de entre 1,8 y 35,4 GB comprimidas, en instancias con GPU y con CPU de las regiones de Oregón y Norte de Virginia. Las cifras son medianas de varias ejecuciones:
- 1,8 GB: de 48 segundos a entre 3 y 11 segundos, unas 8 veces más rápido.
- 13,2 GB: de 3 minutos y 42 segundos a unos 6 segundos, unas 34 veces más rápido.
- 35,4 GB: de 7 minutos y 17 segundos a entre 3 y 11 segundos, unas 38 veces más rápido.
Con la imagen de 13,2 GB, la mejora se mantuvo en las 13 combinaciones de tipo y tamaño de instancia probadas. La descarga estándar tardó entre 3 minutos y 16 segundos y 4 minutos y 20 segundos; la carga diferida, entre 6 y 8 segundos.
¿Y el entrenamiento en sí? AWS lo comprobó con dos cargas de trabajo: una clasificación de imágenes con ResNet-50 y un ajuste fino completo del modelo de lenguaje Qwen2.5-0.5B. Desde la segunda época, el tiempo por época fue el mismo con y sin índice. La primera tardó entre 3 y 16 segundos más, mientras se descargaban los archivos que el marco de trabajo usa por primera vez. En conjunto, cada trabajo terminó entre 1 y 6 minutos antes.
La letra pequeña
La mejora no es igual para todos. La propia AWS detalla varios límites:
- Solo funciona con repositorios privados de Amazon ECR. Las imágenes de otros registros, o las que se descargan a través de un registro privado dentro de una VPC, quedan fuera.
- Con imágenes de menos de unos 4 GB, la mejora es relativamente pequeña.
- Si el código lee casi toda la imagen antes de empezar a entrenar, por ejemplo para verificarla o precargar su contenido, la primera época espera casi lo mismo que una descarga completa y la ganancia se reduce.
- Las imágenes indexadas se ejecutan en un entorno basado en containerd, así que AWS recomienda revisar los scripts que dependan de Docker.
- Si se construye una imagen propia sobre un contenedor de AWS ya indexado, hay que crear un índice nuevo: el de la imagen base no se hereda.
Aun así, en las pruebas con arranques exigentes la indexación salió ganando. Con un modelo de 6 GB incluido dentro de la imagen, la carga de los pesos añadió entre 2 y 3,5 minutos, pero el trabajo terminó igualmente entre 2 y 2,5 minutos antes.
Cómo empezar a usarlo
AWS publica versiones ya indexadas de varios de sus Deep Learning Containers (PyTorch Training, TensorFlow Training, vLLM y SGLang), reconocibles por el sufijo -soci en la etiqueta. Para usarlas basta con cambiar la etiqueta en la definición del trabajo.
Para imágenes propias, el índice se crea en un equipo Linux con containerd, el SOCI snapshotter y Finch o nerdctl. AWS ofrece además una plantilla, CFN ECR SOCI Index Builder, que genera el índice automáticamente cada vez que se sube una imagen a ECR.
Por qué importa
La indexación SOCI no hace los modelos más listos, pero ataca un coste que pocas veces se ve: el de la infraestructura esperando. En equipos que lanzan cientos de trabajos para ajustar un modelo, unos minutos por ejecución pueden sumar horas de GPU facturadas sin producir nada.
Es otro recordatorio de que la eficiencia de la IA no depende solo de las GPU. Ya contamos que, en el caso de los agentes, la CPU también manda. Aquí el cuello de botella es todavía más prosaico: esperar a que llegue un archivo.
La fotografía de representación de este artículo pertenece a Amazon y ha sido publicada en su web de noticias, About Amazon.
