Rendimiento - Amazon EKS
Escalado y rendimiento de las aplicaciones

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Rendimiento

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 comandos RUN o COPY para crear un número menor de capas más grandes. La creación de imágenes más pequeñas tiene las siguientes ventajas y desventajas:

  • Ventajas:

    • La extracción de imágenes es más rápida y, en general, se necesita menos espacio de almacenamiento.

    • Las imágenes más pequeñas tienen menos vector de ataque.

  • Desventajas:

    • Dado que las imágenes de contenedores están más optimizadas, tendrá que crear varias imágenes para satisfacer las necesidades de ejecución en diferentes entornos.

    • El ahorro de tamaño que supone la combinación de comandos a veces puede ser insignificante, por lo que deberías probar diferentes enfoques de compilación para ver cuál ofrece los mejores resultados. En el caso de AI/ML los marcos, selecciona variantes, como las imágenes que solo se ejecutan en tiempo de ejecución (p. ej., 3,03 GB frente pytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime a las de 6,66 GB), pero compara las cargas de trabajo, ya que las imágenes más pequeñas pueden omitir la compilación JIT, lo que lleva a que las rutas de código sean más lentas. 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= para registros o contextos locales). Utilice la optimización de capas combinando COPY en una etapa de ensamblaje para obtener menos capas, pero opte por reducir la eficiencia de la memoria caché y prolongar los tiempos de construcción.

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

Una decisión clave es cómo gestionar los artefactos del modelo de aprendizaje automático (p. ej., pesos, configuraciones) en sí mismos. 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. No es que cuando nos referimos a almacenar el «modelo», nos referimos a los artefactos del modelo (por ejemplo, parámetros entrenados, pesos del modelo). Existen tres 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, enumeradas de las menos a las más recomendadas:

Cómo 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.

  • Ventajas: Garantiza la coherencia y la reproducibilidad, sin demoras en la carga y simplifica la administración de dependencias.

  • Contras: el tamaño de las imágenes es mayor, lo que ralentiza la creación y el procesamiento de archivos, requiere reconstrucción y redespliegue para actualizar los modelos, lo que no es ideal para modelos de gran tamaño debido al alto rendimiento del registro. Además, esto puede provocar ciclos de retroalimentación más prolongados para la experimentación, la depuración y las pruebas debido a la configuración más compleja, y puede aumentar los costos de almacenamiento si se ubican en diferentes imágenes.

Descarga del modelo en tiempo de ejecución Al iniciar el contenedor, la aplicación descarga el modelo desde un almacenamiento externo (p. ej., Amazon S3, respaldado por S3 CRT para transferencias optimizadas de alto rendimiento mediante métodos como el controlador CSI Mountpoint for S3, AWS S3 CLI o s5cmd OSS CLI) mediante scripts en un contenedor de inicio o punto de entrada. Recomendamos comenzar con este enfoque para modelos grandes con actualizaciones frecuentes.

  • Ventajas: permite centrar las imágenes de los contenedores en code/runtime, enables easy model updates without rebuilds, supports versioning via storage metadata. It also allows for A/B las pruebas, el intercambio en caliente o la reversión de los modelos sin aumentar el tamaño de las imágenes de los contenedores, y permite compartir modelos entre distintas aplicaciones sin necesidad de empaquetarlos en todas las imágenes de los contenedores. Además, introduce cambios mínimos en los flujos de trabajo de los equipos de aplicaciones o de aprendizaje automático y permite crear contenedores más rápidamente para facilitar la experimentación y las pruebas. El uso de herramientas respaldadas por CRT de S3, como la AWS CLI, s5cmd o el controlador CSI Mountpoint S3, puede reducir significativamente la latencia de descarga y mejorar el rendimiento de los archivos de gran tamaño, lo que a menudo se traduce en tiempos generales de inicio de los pods más rápidos en comparación con la extracción de imágenes de contenedores grandes de registros como el ECR, según el rendimiento de la red y el registro.

  • Contras: presenta posibles fallos en la red (requiere una lógica de reintento) y requiere autenticación y almacenamiento en caché. La complejidad operativa adicional se debe a la gestión del proceso de descarga, que incluye los reintentos, la gestión de los errores y los retrasos, junto con la gestión adicional del almacenamiento y la limpieza, que reproduce la funcionalidad del ECR.

Montaje del modelo mediante volúmenes persistentes Guarde el modelo en un almacenamiento externo (por ejemplo, Amazon EFS, EBS, FSx para NetApp ONTAP, Lustre, FSx FSx para OpenZFS o S3 mediante el controlador CSI Mountpoint S3) y móntelo como Kubernetes (PV). PersistentVolume Estos son los archivos y datos generados durante el proceso de entrenamiento del modelo que le permiten hacer predicciones o inferencias. Recomendamos utilizar este enfoque para los modelos compartidos entre grupos o clústeres.

  • Ventajas: desacopla el modelo de la imagen para el acceso compartido, facilita las actualizaciones sin necesidad de reiniciarlas (si su marco lo admite) y gestiona grandes conjuntos de datos de forma eficiente. También permite el aprovisionamiento y el control de acceso impulsados por Kubernetes mediante funciones como la clonación, el uso compartido y las instantáneas, lo que reduce la necesidad de copiar modelos y crear nuevas operaciones. Es posible controlar el acceso a los modelos mediante POSIX, además de poder actualizar las versiones de los modelos por separado de la aplicación sin tener que volver a crear la imagen del contenedor, y crear contenedores más rápido para la experimentación y las pruebas. En el caso de las aplicaciones de AI/ML inferencia que leen artefactos en la memoria, esto permite cargar los datos directamente desde el sistema de archivos externo sin necesidad de almacenarlos de forma intermedia en el disco local del nodo, lo que mejora el rendimiento de carga. Además, para almacenar modelos grandes a escala, servicios como FSx NetApp ONTAP y Lustre ofrecen técnicas de optimización del almacenamiento (por ejemplo, deduplicación, compresión o aprovisionamiento ligero), creación de versiones mediante instantáneas y soporte para reutilizar el mismo archivo sin desperdiciar espacio de almacenamiento. FSx Otros servicios, como S3, ofrecen un control de versiones nativo. Este enfoque también puede abarcar clústeres y, potencialmente, regiones, según la configuración de replicación (por ejemplo, replicación asíncrona FSx o replicación entre regiones en S3 y EFS).

  • Contras: puede añadir I/O latencia si está conectada a la red, requiere aprovisionamiento de almacenamiento y controles de acceso, y puede ser menos portátil (por ejemplo, EBS) si el almacenamiento es específico de un clúster. Las desventajas incluyen una complejidad operativa adicional para los CI/CD cambios y el mantenimiento de los procesos de carga, la necesidad de TTL/retention mecanismos personalizados para reducir los costos de almacenamiento y una replicación más compleja entre regiones. El rendimiento de lectura de los artefactos del modelo debe medirse en función del tiempo de descarga de las imágenes del contenedor.

Sirviendo modelos ML

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 (por ejemplo, las de 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 de la caché de tiempo de ejecución del contenedor 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] (https://containerd.io/)) donde las imágenes se almacenan 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 útil cuando las instantáneas de EBS no están preconfiguradas o cuando se prefiere la extracción previa de imágenes. Consulte el [ GitHub repositorio de muestras de AWS] (https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull) para ver ejemplos de imágenes extraídas previamente. Ten en cuenta que alternativas como la carga diferida con el [SOCI Snapshotter] (https://github.com/awslabs/soci-snapshotter) (un plugin containerd para la extracción parcial de imágenes) pueden complementar estos métodos, aunque requiere una configuración personalizada y puede que no se adapte a todos los escenarios. El uso de la caché de tiempo de ejecución del contenedor tiene las siguientes ventajas y desventajas:

  • Ventajas:

    • No es necesario administrar las instantáneas de EBS.

    • Con él siempre DaemonSets dispondrá de la última versión de la imagen del contenedor.

    • Más flexible, ya que las imágenes se pueden actualizar sin tener que volver a crear instantáneas.

    • Aún así, reduce el tiempo de inicio del módulo al garantizar que las imágenes ya estén en el nodo.

  • Desventajas:

    • La extracción inicial de imágenes grandes todavía puede llevar tiempo, aunque se hace con antelación.

    • Puede que no sea tan eficiente como las instantáneas de EBS para imágenes muy grandes (más de 10 GB), ya que sigue siendo necesario extraerlas, aunque no al arrancar el módulo.

    • Con ello DaemonSets, se extrae previamente una imagen de todos los nodos en los que se pueda ejecutar el pod. Por ejemplo, si 1000 nodos solo ejecutaran una instancia de un pod, se consumiría espacio en los 1000 nodos solo para ejecutar la única instancia en un nodo.

    • En el caso de las cargas de trabajo de inferencia en tiempo real en las que los nodos se escalan hacia dentro y hacia fuera, los nodos nuevos que se agreguen mediante herramientas como Cluster AutoScaler pueden programar los módulos de carga de trabajo antes de que la extracción previa finalice la extracción de imágenes. DaemonSet Esto puede provocar que el pod inicial del nuevo nodo active la atracción de todos modos, lo que podría retrasar el inicio y afectar a los requisitos de baja latencia.

    • La recolección de imágenes no utilizadas de Kubelet puede afectar a las imágenes extraídas previamente, ya que elimina las que no se utilizan cuando el uso del disco supera determinados umbrales o si se supera la antigüedad máxima configurada. En los patrones de escalado de entrada/salida, esto puede desalojar las imágenes de los nodos inactivos, lo que requiere volver a extraerlas durante las ampliaciones posteriores y reducir la fiabilidad de la memoria caché para cargas de trabajo con ráfagas de trabajo.

Uso de instantáneas de EBS

  • 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 este artículo Reducir el tiempo de inicio de los contenedores en Amazon EKS con Bottlerocket para obtener más información sobre el uso de Karpenter y este plan de EKS Terraform para grupos de nodos administrados. Recomendamos automatizar la creación de instantáneas de EBS como parte de su CI/CD proceso para mantenerlas con las versiones más recientes de imágenes de contenedores. up-to-date El uso de instantáneas de EBS tiene las siguientes ventajas y desventajas:

  • Ventajas:

    • Elimina la necesidad de extraer imágenes de contenedores de gran tamaño al iniciar el pod, lo que reduce considerablemente el tiempo de inicio (por ejemplo, de 10 a 15 minutos a segundos para imágenes de más de 10 GB).

    • Garantiza que las imágenes estén disponibles localmente al iniciar el nodo.

    • Resulta especialmente útil para cargas de trabajo de inferencia con imágenes de contenedores de gran tamaño.

  • Desventajas:

    • Requiere mantener y actualizar las instantáneas de EBS con cada actualización de imagen o versión.

    • Requiere medidas adicionales para garantizar que todas sus cargas de trabajo utilicen la última versión de la imagen del contenedor.

    • Implica actividades operativas adicionales para crear y administrar instantáneas.

    • Puede incluir imágenes innecesarias si no se administran adecuadamente, aunque esto se puede mitigar con una configuración adecuada del grupo de nodos.

Optimice el rendimiento de extracción de imágenes

Recomendamos encarecidamente optimizar el rendimiento de extracción de imágenes de contenedores para los clústeres de Amazon EKS que ejecutan AI/ML cargas de trabajo. El uso de imágenes base grandes y no optimizadas o una ordenación ineficiente de las capas pueden ralentizar los tiempos de inicio de los pods, aumentar el consumo de recursos y reducir la latencia de inferencia. Para solucionar este problema, adopte imágenes base pequeñas y livianas con dependencias mínimas, adaptadas a sus cargas de trabajo. También puede considerar los AWS Deep Learning Containers (DLCs), que son imágenes de contenedores prediseñadas que facilitan la ejecución de marcos de aprendizaje profundo populares (por ejemplo, PyTorchy TensorFlow). Para obtener más información sobre cómo crear una imagen personalizada, consulte Personalizar Deep Learning Containers. Al crear imágenes personalizadas, opte por imágenes base ligeras y añada solo las bibliotecas necesarias para mantener las imágenes compactas. Utilice compilaciones de varias etapas para reducir el tamaño de las capas y optimizar el orden de las capas para un almacenamiento en caché eficiente. Para obtener más información, consulta las prácticas recomendadas de Docker para crear imágenes.

Reduzca los tiempos de arranque de los contenedores cargando previamente las imágenes de los contenedores en los volúmenes de datos

Para las cargas de trabajo de aprendizaje automático que requieren una baja latencia de inicio del módulo, como la inferencia en tiempo real, recomendamos cargar previamente las imágenes de los contenedores para minimizar los retrasos en la inicialización. Las imágenes de contenedores de gran tamaño pueden ralentizar el inicio de los pods, especialmente en los nodos con un ancho de banda limitado. Además de utilizar imágenes base mínimas, compilaciones de varias etapas y técnicas de carga diferida, considere los siguientes enfoques para precargar imágenes en Amazon EKS. Además de utilizar imágenes base mínimas, compilaciones en varias etapas y técnicas de carga diferida, considere las siguientes opciones:

  • Carga previamente las imágenes con instantáneas de EBS: tome una instantánea de Amazon Elastic Block Store (EBS) de las imágenes de contenedores almacenadas en caché y reutilícela para los nodos de trabajo de EKS. Si bien esto añade actividades operativas adicionales, garantiza que las imágenes se obtengan previamente de forma local al iniciar el nodo, lo que reduce el tiempo de inicialización del pod. Consulte este artículo Reducir el tiempo de inicio de los contenedores en Amazon EKS con Bottlerocket para obtener más información sobre el uso de Karpenter y este plan de EKS Terraform para grupos de nodos administrados.

  • Extraiga previamente las imágenes a la caché de tiempo de ejecución del contenedor: extraiga previamente las imágenes de los contenedores en los nodos utilizando los recursos de Kubernetes (por ejemplo, DaemonSet o la implementación) para llenar 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 las imágenes se almacenan 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 útil cuando las instantáneas de EBS no están preconfiguradas o cuando se prefiere la extracción previa de imágenes. Pruebe este enfoque en un entorno provisional para validar las mejoras de latencia. Consulte el GitHub repositorio de muestras de AWS para ver ejemplos de imágenes extraídas previamente.