AWS incorporó NVIDIA Multi-Instance GPU a los endpoints de inferencia en tiempo real de SageMaker. La opción permite dividir aceleradores para alojar modelos aislados, aunque los clientes siguen pagando la instancia completa y el ahorro depende del tráfico.
***

• La función permite asignar particiones de GPU a componentes de inferencia, pero excluye endpoints sin servidor, asíncronos y de un solo modelo.
• En una prueba de AWS, una partición H100 superó a una A100 completa en rendimiento bajo varias cargas de trabajo y logró menor costo por token sobre ciertos puntos de equilibrio.
• El diseño no puede cambiarse en un endpoint activo y el particionamiento no reduce la tarifa de la instancia ni ofrece métricas de utilización de GPU en CloudWatch.

AWS divide sus GPU en SageMaker para alojar más modelos de IA

Amazon Web Services (AWS) anunció soporte para NVIDIA Multi-Instance GPU (MIG) en Amazon SageMaker AI, una función que permite repartir un acelerador entre varios modelos en endpoints de inferencia en tiempo real. En vez de reservar una GPU completa por despliegue, los clientes pueden asignar a cada modelo una partición con recursos de cómputo y memoria dedicados, una alternativa pensada para aumentar la capacidad disponible en una misma instancia.

El cambio no equivale a una reducción automática de costos: AWS continúa facturando la instancia GPU completa, mientras que la conveniencia económica depende de cuánto tráfico atienda cada modelo. La comparación publicada por la compañía también muestra que una GPU completa puede seguir siendo más barata en cargas ligeras; por eso, la nueva opción exige medir el uso real antes de decidir cómo desplegar los modelos.

Qué cambia en los endpoints de SageMaker

La asignación tradicional de una GPU completa impone un límite al número de modelos que una instancia puede alojar, incluso si cada modelo consume solo una parte de la memoria o del cómputo disponibles. También puede obligar a los clientes que evalúan un acelerador más reciente a reservarlo por completo, aunque su carga de inferencia no aproveche todos sus recursos.

MIG divide el acelerador en particiones que reciben una porción fija de las unidades de cómputo y un bloque dedicado de memoria, con aislamiento aplicado directamente en el hardware. Cada modelo puede permanecer residente en su partición, lo que evita el retraso que se produce cuando un endpoint multimodelo debe cargar el modelo en un dispositivo compartido durante su primera solicitud.

La función se limita a endpoints en tiempo real que usan componentes de inferencia, la estructura de SageMaker que permite desplegar varios modelos en un endpoint y definir el cómputo asignado a cada uno. No admite endpoints de un solo modelo, endpoints sin servidor ni grupos de instancias heterogéneos, y tampoco cubre cargas de trabajo asíncronas, porque esas invocaciones no pueden dirigirse a un componente de inferencia.

Salesforce participó en la definición de requisitos y en la validación inicial de la implementación. Richard Chang, arquitecto de ingeniería de software de la empresa, dijo que Salesforce espera consolidar cargas de trabajo de forma segura, mejorar el uso de GPU y reducir costos de inferencia sin sacrificar un rendimiento predecible ni el aislamiento; la compañía todavía prepara validaciones con cargas representativas de producción, por lo que esos beneficios siguen siendo expectativas.

Configuración mediante componentes de inferencia

La documentación de SageMaker AI describe dos campos opcionales para configurar la función. AcceleratorPartitionLayouts define el reparto de una variante de producción, mientras que AcceleratorPartitionType selecciona el perfil que utilizará un componente de inferencia; si el cliente omite ambos campos, el endpoint conserva su comportamiento actual.

AWS indica que la opción no agrega operaciones de API, tipos de recursos ni acciones de AWS Identity and Access Management. El diseño configurado se aplica de manera uniforme a cada acelerador de cada instancia de la variante, una condición que simplifica la disposición de las particiones, pero deja menos margen para mezclar distribuciones distintas dentro de una misma variante.

En el ejemplo de la compañía, cada una de las ocho A100 de una instancia ml.p4d.24xlarge se reparte entre particiones mig-4g.20gb, mig-2g.10gb y mig-1g.5gb. La configuración suma 24 particiones para el endpoint, y cada copia de un componente de inferencia ocupa una partición del perfil solicitado.

Las solicitudes continúan dirigiéndose al modelo por el nombre del componente mediante InvokeEndpoint, sin que el cliente tenga que especificar un identificador de partición. AWS reportó que particionar los aceleradores añadió cerca de 17 segundos al aprovisionamiento en sus pruebas; además, si un componente solicita un perfil que no existe en el diseño, SageMaker rechaza la solicitud en lugar de asignarle una GPU completa.

La comparación de AWS entre H100 y A100

Para evaluar rendimiento, AWS comparó una partición mig-3g.40gb de una H100 con una A100-40GB completa, ambas ejecutando Llama-3.1-8B-Instruct en endpoints de SageMaker en producción. Los dos entornos usaron una réplica del modelo, contenedores, tokenizadores y configuraciones de cliente idénticos, mientras que genai-bench generó cinco patrones de tráfico con concurrencias de 2 a 512.

El perfil H100 utilizado asigna tres de las siete partes de los streaming multiprocessors y cuatro de las ocho unidades de memoria, según la guía de perfiles de NVIDIA. Aunque ambas configuraciones ofrecen capacidad de memoria comparable, sus recursos de cómputo difieren; por eso, la prueba compara una fracción de la H100 con una A100 completa, no dos dispositivos con asignaciones equivalentes.

En las cargas donde el beneficio de costo de cada escenario alcanzó su mayor nivel, AWS reportó que la partición H100 entregó entre 53% y 89% más tokens de salida por segundo. La latencia entre tokens fue de 8,9% a 42,1% menor, y el tiempo hasta el primer token bajó entre 5,6% y 47,5%, resultados que corresponden a las condiciones concretas de esa prueba.

La diferencia también apareció con concurrencia elevada y solicitudes extensas: para cargas de 6.000 y 8.000 tokens, la A100 incumplió el plazo de servicio en entre un tercio y la mitad de las solicitudes en la concurrencia máxima. La partición H100 no registró fallos en esos escenarios, aunque la fuente no presenta ese resultado como una garantía general para otras aplicaciones, modelos o configuraciones.

El ahorro depende del tráfico y tiene límites operativos

En el análisis económico, AWS calculó que el costo por millón de tokens de salida podía ser entre 18% y 34% menor con la partición H100 una vez superado el punto de equilibrio de cada carga. Ese umbral llegó a una concurrencia de 64 para prompts de 100 tokens y de 4 para prompts de 8.000 tokens, de modo que el volumen y el tamaño de las solicitudes alteran el momento en que la opción resulta conveniente.

Por debajo de esos umbrales, la A100 completa seguía siendo más económica en la comparación de AWS, lo que deja a las cargas de entrada corta o concurrencia baja como posibles candidatas para la GPU anterior. La empresa dividió los precios de instancias bajo demanda entre el número de unidades probadas en cada instancia para calcular los costos unitarios, así que su resultado no constituye una conclusión universal para todos los despliegues.

La disponibilidad inicial comprende cuatro familias: P4d con NVIDIA A100 de 40 GB y hasta siete particiones por GPU; P5 con NVIDIA H100 de 80 GB y hasta siete; G7 con NVIDIA RTX PRO 4500 Blackwell de 32 GB y hasta dos; y G7e con NVIDIA RTX PRO 6000 Blackwell Server Edition de 96 GB y hasta cuatro. Los perfiles disponibles y el número de particiones dependen del acelerador, y ninguna partición puede abarcar varios dispositivos.

La función está disponible en US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Singapur), Asia Pacific (Tokio), Europe (Frankfurt) y Europe (Irlanda), sujeta a la disponibilidad regional de instancias y a la cuota de endpoints. Los clientes cuyos modelos requieren una GPU completa o varias GPU deben seguir usando dispositivos completos, pues el particionamiento no combina aceleradores para formar una partición mayor.

El aislamiento cubre la memoria y el cómputo de GPU, pero los modelos de una misma instancia todavía comparten CPU del host, memoria del host, almacenamiento, red y enrutamiento del endpoint. Además, los endpoints particionados y sus componentes no publican métricas de utilización de GPU, CPU o memoria en CloudWatch, aunque sí mantienen disponibles métricas de invocación y latencia.

Los cambios de diseño también requieren planificación: modificar la distribución de un endpoint activo obliga a crear otro endpoint y migrar el tráfico, mientras que mover un componente a un perfil distinto exige crear un componente nuevo. En P4d, el perfil mig-1g.10gb requiere el driver NVIDIA R525 o una versión posterior; AWS recomienda una AMI de inferencia más reciente porque la imagen predeterminada no incluye ese requisito.

La propuesta amplía las opciones para distribuir modelos, pero el despliegue más denso no elimina el costo de la instancia completa y reduce la telemetría disponible sobre el uso de recursos. Las pruebas publicadas favorecen la partición H100 en escenarios específicos de mayor carga y contexto largo, mientras que los puntos de equilibrio muestran por qué una A100 completa todavía puede convenir con menos tráfico.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín