Escalado y rendimiento de las aplicaciones

Administración de artefactos de aprendizaje automático, marcos de servicio y optimización de empresas emergentes

La implementación de modelos de aprendizaje automático (ML) en Amazon EKS requiere considerar detenidamente cómo se integran los modelos en las imágenes de los contenedores y en los entornos de ejecución. Esto garantiza la escalabilidad, la reproducibilidad y la utilización eficiente de los recursos. En este tema se describen los diferentes enfoques para gestionar los artefactos de los modelos de aprendizaje automático, seleccionar los marcos de servicio y optimizar los tiempos de inicio de los contenedores mediante técnicas como el almacenamiento previo en caché, todas ellas diseñadas para reducir los tiempos de inicio de los contenedores.

Reducir el tamaño de las imágenes de los contenedores

Reducir el tamaño de las imágenes del contenedor durante el inicio es otra forma de reducir el tamaño de las imágenes. Puede realizar reducciones en cada paso del proceso de creación de la imagen del contenedor. Para empezar, elija imágenes base que contengan el menor número de dependencias necesario. Durante la creación de imágenes, incluya solo las bibliotecas y artefactos esenciales que sean necesarios. Al crear imágenes, intente combinar varios COPY comandos RUN o comandos para crear un número menor de capas más grandes. Para AI/ML los marcos, utilice compilaciones de varias etapas para separar la compilación y el tiempo de ejecución, copiando solo los artefactos necesarios (por ejemplo, mediante COPY —from= registros o contextos locales) y seleccione variantes como imágenes solo en tiempo de ejecución (por ejemplo, de 3,03 GB frente pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime a 6,66 GB de desarrollo). Para obtener más información, consulte Reducir el tamaño de las imágenes de los contenedores en el taller sobre IA en EKS.

Manejo de artefactos de modelos de aprendizaje automático en las implementaciones

Una decisión clave es cómo gestionar por sí mismos los artefactos del modelo de aprendizaje automático (como los pesos y las configuraciones). La elección afecta al tamaño de la imagen, a la velocidad de despliegue, a la frecuencia de actualización del modelo y a la sobrecarga operativa. Tenga en cuenta que cuando hablamos de almacenar el «modelo», nos referimos a los artefactos del modelo (como los parámetros entrenados y los pesos del modelo). Existen diferentes enfoques para gestionar los artefactos de los modelos de aprendizaje automático en Amazon EKS. Cada uno tiene sus ventajas y desventajas, y el mejor depende del tamaño del modelo, la cadencia de actualización y las necesidades de infraestructura. Considera los siguientes enfoques, desde el más mínimo hasta el más recomendado:

• Insertar el modelo en la imagen del contenedor: Copie los archivos del modelo (p. ej., .safetensors, .pth, .h5) en la imagen del contenedor (p. ej., Dockerfile) durante la creación de la imagen. El modelo forma parte de la imagen inmutable. Recomendamos usar este enfoque para modelos más pequeños con actualizaciones poco frecuentes. Esto garantiza la coherencia y la reproducibilidad, no retrasa la carga y simplifica la gestión de las dependencias, pero se traduce en tamaños de imagen más grandes, lo que ralentiza las compilaciones y las inserciones, requiere la reconstrucción y el redespliegue para las actualizaciones de los modelos, y no es ideal para modelos de gran tamaño debido al alto rendimiento del registro.

• Descarga del modelo en tiempo de ejecución: al iniciar el contenedor, la aplicación descarga el modelo del almacenamiento externo (por ejemplo, Amazon S3, respaldado por S3 CRT para optimizar las transferencias de alto rendimiento mediante métodos como el controlador CSI Mountpoint for S3, la CLI de AWS S3 o la CLI de OSS de s5cmd) mediante scripts en un contenedor de inicio o punto de entrada. Recomendamos empezar con este enfoque para modelos grandes con actualizaciones frecuentes. Esto hace que las imágenes de los contenedores se centren en el código y el tiempo de ejecución, permite actualizar fácilmente los modelos sin necesidad de volver a compilarlos, admite el control de versiones mediante metadatos de almacenamiento, pero introduce posibles fallos de red (requiere una lógica de reintento), requiere autenticación y almacenamiento en caché.

Para obtener más información, consulte Acelerar el proceso de extracción en el taller sobre IA sobre EKS.

Sirviendo modelos de aprendizaje automático

Para implementar y ofrecer modelos de aprendizaje automático (ML) en Amazon EKS, es necesario seleccionar un enfoque de servicio de modelos adecuado para optimizar la latencia, el rendimiento, la escalabilidad y la simplicidad operativa. La elección depende del tipo de modelo (por ejemplo, el idioma o el modelo de visión), las exigencias de la carga de trabajo (por ejemplo, la inferencia en tiempo real) y la experiencia del equipo. Los enfoques comunes incluyen configuraciones basadas en Python para la creación de prototipos, servidores de modelos dedicados para funciones de nivel de producción y motores de inferencia especializados para un alto rendimiento y eficiencia. Cada método implica compensaciones en cuanto a la complejidad de la configuración, el rendimiento y la utilización de los recursos. Tenga en cuenta que los marcos de servicio pueden aumentar el tamaño de las imágenes de los contenedores (varios GBs) debido a las dependencias, lo que podría afectar a los tiempos de inicio; considere la posibilidad de disociarlos mediante técnicas de manejo de artefactos para mitigar esta situación. Las opciones se enumeran de las menos a las más recomendadas:

Uso de marcos de Python (por ejemplo, FastAPI, HuggingFace Transformers with PyTorch) Desarrolle una aplicación personalizada utilizando marcos de Python, incrustando archivos de modelo (pesos, configuración, tokenizador) dentro de una configuración de nodos en contenedores.

• Ventajas: creación sencilla de prototipos, solo para Python sin infraestructura adicional, compatible con todos los HuggingFace modelos, implementación sencilla de Kubernetes.

• Contras: se limita a un solo procesamiento por request/simple lotes, es lenta la generación de tokens (no hay núcleos optimizados), la memoria es ineficiente, no tiene capacidad de escalado ni supervisión e implica tiempos de inicio prolongados.

• Recomendación: Úselo para la creación inicial de prototipos o para tareas de un solo nodo que requieran una integración lógica personalizada.

Utilice marcos de servicio de modelos dedicados (por ejemplo, TensorRT-LLM, TGI) Adopte servidores especializados como TensorRT-LLM o TGI para la inferencia de ML, gestionando la carga, el enrutamiento y la optimización de modelos. Son compatibles con formatos como safetensors, con compilaciones o complementos opcionales.

• Ventajas: Ofrece procesamiento por lotes (paralelismo). static/in-flight or continuous), quantization (INT8, FP8, GPTQ), hardware optimizations (NVIDIA, AMD, Intel, Inferentia), and multi-GPU support (Tensor/Pipeline TensorRT-LLM admite diversos modelos (codificador-decodificador)LLMs, mientras que TGI aprovecha la integración. HuggingFace

• Contras: TensorRT-LLM necesita compilación y es solo para NVIDIA; es posible que TGI sea menos eficiente en el procesamiento por lotes; ambos añaden una sobrecarga de configuración y es posible que no se adapten a todos los tipos de modelos (por ejemplo, los que no son transformadores).

• Recomendación: adecuado para modelos que necesitan capacidades de producción, como pruebas, o un alto rendimiento con hardware PyTorch/TensorFlow compatible. A/B

Utilice motores de inferencia especializados de alto rendimiento (por ejemplo, el vLLM) Utilice motores de inferencia avanzados, como el vLLM, para optimizar el servicio de LLM, el procesamiento por lotes durante el vuelo y la cuantificación (, -KV, AWQ) PagedAttention, integrables con el escalado automático de EKS. INT8 FP8

• Ventajas: Alto rendimiento y eficiencia de memoria (entre un 40 y un 60% de ahorro en VRAM), gestión dinámica de solicitudes, transmisión de tokens, compatibilidad con múltiples GPU Tensor Parallel de un solo nodo y amplia compatibilidad de hardware.

• Desventajas: Optimizado para transformadores que solo utilizan decodificadores (p. ej., LLa MA), es menos eficaz para los modelos sin transformadores, pero requiere hardware compatible (p. ej., NVIDIA) y un esfuerzo de configuración. GPUs

• Recomendación: la mejor opción para realizar inferencias LLM de gran volumen y baja latencia en EKS, ya que maximiza la escalabilidad y el rendimiento.

Almacenamiento previo en caché de imágenes de contenedores

Las imágenes de contenedores grandes (como las que contienen modelos PyTorch) pueden provocar retrasos en el arranque en frío que afectan a la latencia. Para las cargas de trabajo sensibles a la latencia, como las cargas de trabajo de inferencia en tiempo real escaladas horizontalmente, y es fundamental iniciar rápidamente los módulos, recomendamos cargar previamente las imágenes de los contenedores para minimizar los retrasos en la inicialización. Considera los siguientes enfoques, desde el más mínimo hasta el más recomendado:

Uso del snapshotter SOCI para extraer imágenes previamente

Para imágenes muy grandes que no pueda minimizar fácilmente, puede utilizar el snapshotter Seekable OCI (SOCI) de código abierto configurado en modo paralelo de extracción y desempaquetado. Esta solución le permite utilizar las imágenes existentes sin tener que volver a crear ni modificar los procesos de creación. Esta opción resulta especialmente eficaz cuando se despliegan cargas de trabajo con imágenes muy grandes en instancias EC2 informáticas de alto rendimiento. Funciona bien con redes de alto rendimiento y configuraciones de almacenamiento de alto rendimiento, como es habitual en las cargas de trabajo escaladas. AI/ML

El pull/unpack modo paralelo SOCI mejora el rendimiento de extracción end-to-end de imágenes mediante estrategias de paralelización configurables. La obtención y preparación más rápidas de las imágenes afectan directamente a la rapidez con la que puede implementar nuevas cargas de trabajo y escalar su clúster de manera eficiente. La extracción de imágenes consta de dos fases principales:

1. Extraer capas del registro al nodo

Para optimizar la captura de capas, SOCI crea varias conexiones HTTP simultáneas por capa, lo que multiplica el rendimiento de descarga más allá del límite de conexión única. Divide las capas grandes en fragmentos y las descarga simultáneamente a través de varias conexiones. Este enfoque ayuda a saturar el ancho de banda de la red disponible y a reducir considerablemente los tiempos de descarga. Esto resulta especialmente útil para AI/ML las cargas de trabajo en las que una sola capa puede ocupar varios gigabytes.

2. Desempacar y preparar esas capas para crear contenedores

Para optimizar el desempaquetado de capas, SOCI procesa varias capas simultáneamente. En lugar de esperar a que cada capa se descomprima por completo antes de empezar con la siguiente, utiliza los núcleos de CPU disponibles para descomprimir y extraer varias capas simultáneamente. Este procesamiento paralelo transforma la tradicional fase de desempaquetado vinculada a la E/S en una operación optimizada para la CPU que se amplía con los núcleos disponibles. El sistema organiza cuidadosamente esta paralelización para mantener la coherencia del sistema de archivos y, al mismo tiempo, maximizar el rendimiento.

El modo de tracción paralela SOCI utiliza un sistema de control de doble umbral con parámetros configurables tanto para la concurrencia de descargas como para el desempaquetado del paralelismo. Este control granular le permite ajustar el comportamiento del SOCI para adaptarlo a sus requisitos de rendimiento específicos y a las condiciones del entorno. Comprender estos parámetros le ayuda a optimizar su tiempo de ejecución para obtener el mejor rendimiento de tracción.

Referencias

• Para obtener más información sobre la solución y las ventajas y desventajas de su ajuste, consulte la documentación sobre las funciones en el repositorio de proyectos de SOCI en. GitHub

• Para ver un ejemplo práctico de Karpenter en Amazon EKS, consulte el Karpenter Blueprint con el modo paralelo de SOCI snapshotter. pull/unpack

• Para obtener información sobre cómo configurar Bottlerocket para tracción paralela, consulte el modo de desembalaje con tracción paralela soci-snapshotter en la documentación de Bottlerocket.o

Uso de instantáneas de EBS para extraer imágenes previamente

Puede tomar una instantánea de Amazon Elastic Block Store (EBS) de las imágenes de contenedores almacenadas en caché y reutilizarla para los nodos de trabajo de EKS. Esto garantiza que las imágenes se precarguen localmente al iniciar el nodo, lo que reduce el tiempo de inicialización del pod. Consulte Reducir el tiempo de inicio de los contenedores en Amazon EKS con el volumen de datos de Bottlerocket para obtener más información sobre el uso de los planos de Karpenter y EKS Terraform para grupos de nodos gestionados.

Para obtener más información, consulte Uso de instantáneas de contenedores y precarga de imágenes de contenedores en volúmenes de datos de Bottlerocket con instantáneas de EBS en el taller AI on EKS.

Uso de la caché de ejecución de Container para extraer imágenes previamente

Puedes colocar previamente las imágenes de los contenedores en los nodos mediante los recursos de Kubernetes (p. ej., DaemonSet o Deployment) para rellenar la caché de tiempo de ejecución del contenedor del nodo. La caché de tiempo de ejecución del contenedor es el almacenamiento local administrado por el tiempo de ejecución del contenedor (por ejemplo, containerd), donde se almacenan las imágenes después de extraerlas de un registro. La extracción previa garantiza que las imágenes estén disponibles localmente, lo que evita demoras en la descarga durante el arranque del pod. Este enfoque resulta especialmente útil cuando las imágenes cambian con frecuencia (por ejemplo, cuando se actualizan con frecuencia), cuando las instantáneas de EBS no están preconfiguradas, cuando crear un volumen de EBS llevaría más tiempo que extraerlo directamente de un registro de contenedores, o cuando los nodos ya están en el clúster y necesitan hacer girar los pods bajo demanda utilizando una de las varias imágenes posibles.

La extracción previa de todas las variantes garantiza un tiempo de arranque rápido, independientemente de la imagen que se necesite. Por ejemplo, en una carga de trabajo de aprendizaje automático masivamente paralela que requiere 100 000 modelos pequeños creados con 10 técnicas diferentes, la extracción previa de 10 imágenes a DaemonSet través de un clúster grande (por ejemplo, miles de nodos) minimiza el tiempo de inicio del pod y permite completarlos en menos de 10 segundos al evitar las extracciones bajo demanda. El uso del enfoque de caché en tiempo de ejecución del contenedor elimina la necesidad de administrar las instantáneas de EBS y garantiza que siempre se obtenga la última versión de la imagen del contenedor DaemonSets, pero en el caso de las cargas de trabajo de inferencia en tiempo real en las que los nodos escalan los in/out, new nodes added by tools like Cluster Autoscaler may schedule workload pods before the pre-pull DaemonSet completes image pulling. This can cause the initial pod on the new node to trigger the pull anyway, potentially delaying startup and impacting low-latency requirements. Additionally, kubelet image garbage collection can affect pre-pulled images by removing unused ones when disk usage exceeds certain thresholds or if they exceed a configured maximum unused age. In scale-in/out patrones, esto puede desalojar las imágenes de los nodos inactivos, lo que requiere volver a extraerlas durante las posteriores ampliaciones y reducir la confiabilidad de la memoria caché para cargas de trabajo con ráfagas de trabajo.

Consulte el GitHub repositorio de AWS para ver ejemplos de cómo extraer imágenes previamente en la caché de tiempo de ejecución del contenedor.

Úselo NVMe para kubelet y almacenamiento en contenedores

Considere la posibilidad de configurar kubelet y containerd usar discos de almacenamiento de NVMe instancias efímeros para obtener un mayor rendimiento del disco. El proceso de extracción de contenedores implica descargar una imagen de contenedor de un registro y descomprimir sus capas en un formato utilizable. Para optimizar I/O las operaciones durante la descompresión, debe evaluar qué es lo que proporciona niveles más altos de I/O rendimiento y rendimiento para el tipo de instancia del host del contenedor: NVMe instancias respaldadas con almacenamiento local frente a IOPs/rendimiento por volumen de EBS. Para EC2 las instancias con almacenamiento NVMe local, considera configurar el sistema de archivos subyacente del nodo para que kubelet ()/var/lib/kubelet, containerd () y Pod logs (/var/lib/containerd/var/log/pods) usen discos de almacenamiento de NVMe instancias efímeros para obtener niveles más altos de rendimiento y rendimiento. I/O

El almacenamiento efímero del nodo se puede compartir entre los pods que soliciten almacenamiento efímero y las imágenes de contenedores que se descargan en el nodo. Si utilizas Karpenter con Bottlerocket o el AL2 023 EKS Optimized, puedes AMIs configurarlo en RAID0 o, si EC2NodeClassutilizas grupos de nodos gestionados, instanceStorePolicy configurándolo como parte de los datos del usuario. localStoragePolicy NodeConfig