SageMaker Inference ahora admite Multi-Instance GPU para maximizar la utilización de GPU en los endpoints de modelos

Cuando implementa un modelo en un endpoint de GPU, la unidad más pequeña de GPU que puede solicitar es un acelerador completo.

Esta restricción puede costarle dos veces. Primero, no puede alojar más modelos en una instancia de los aceleradores que tiene. Una ml.p4d.24xlarge tiene ocho A100, por lo que contiene ocho modelos, ya sea que cada uno necesite 40 GB o 14 GB. Segundo, y menos obvio, hace que cada implementación se reduzca a una elección de a qué GPU completa implementar. A medida que su concurrencia y la longitud de los prompts crecen, una GPU completa en una instancia más antigua deja de ser suficiente, pero una GPU completa en una más nueva es más de lo que su modelo puede usar. Termina quedándose corto o pagando por una capacidad que nunca alcanza.

Hoy, Amazon SageMaker Inference admite la partición de GPU, que utiliza NVIDIA Multi-Instance GPU (MIG) para dividir una GPU física en particiones independientes. Cada partición recibe una parte fija de las unidades de cómputo de la GPU y un bloque dedicado de su memoria, con aislamiento aplicado en el hardware. Eso cambia ambas restricciones: puede colocar un modelo diferente en cada partición, y puede elegir una fracción de un acelerador más nuevo en lugar de uno completo de cualquiera de las dos generaciones.

Esta publicación cubre ambos aspectos. La primera parte es el beneficio directo: implementar más modelos de los que tiene GPUs, con aislamiento entre ellos. La segunda es la que los clientes preguntan cuando la cuestión pasa al costo: cómo la granularidad de la partición lo ayuda a elegir la unidad del tamaño adecuado, y lo que medimos cuando lo hicimos.

Una cosa que debe saber antes de seguir leyendo: la partición de GPU funciona en endpoints que usan componentes de inferencia, la estructura que se usa para implementar varios modelos en un solo endpoint y establecer el cómputo que recibe cada modelo. La partición se construye directamente sobre esto. Una partición es un recurso que un componente solicita, en el mismo lugar donde ya solicita CPU y memoria. Si no ha usado componentes de inferencia, esta publicación los presenta. Los endpoints de un solo modelo, los endpoints sin servidor y los grupos de instancias heterogéneos no pueden particionarse.

Lo que hacen los clientes hoy, y por qué cada opción se queda corta

Si tiene más modelos que aceleradores, ha tenido tres opciones.

Ejecutar endpoints más grandes y en menor cantidad y hacer más batching – Esto aumenta la utilización, pero solo cuando los modelos son intercambiables. Un portafolio de variantes ajustadas (fine-tuned) o modelos por inquilino no lo es.

Usar endpoints multi-modelo – Estos cargan y descargan modelos de una GPU compartida a demanda, lo que se adapta a tráfico disperso y con ráfagas. Pero los modelos comparten el dispositivo sin aislamiento, por lo que una solicitud pesada de un modelo afecta a los demás. Un modelo que no está cargado también paga una penalización de carga en el primer uso.

Migrar a Kubernetes autogestionado – Aquí es donde han ido los clientes que necesitan una partición de GPU real. MIG funciona allí, pero usted asume la gestión de versiones de controladores, la configuración de particiones, un device plugin, la programación y mantener todo consistente en un flota. Es mucho trabajo para una capacidad de hardware que sus instancias ya tienen.

Por qué MIG

NVIDIA Multi-Instance GPU (MIG) divide una GPU en hasta siete instancias, dependiendo de la GPU. Cada instancia tiene su propio cómputo, caché, memoria y ancho de banda de memoria. Como la división se realiza en hardware en lugar de software, obtiene garantías que otros métodos de compartición no pueden dar:

1. Latencia predecible – Cada partición tiene un ancho de banda de memoria dedicado, por lo que un pico de tráfico de un modelo no aparece en el p99 de otro modelo.
2. Aislamiento de fallos – Un fallo o error de memoria permanece dentro de su partición en lugar de derribar todos los modelos en la GPU.
3. Capacidad del tamaño adecuado – Los modelos pequeños y medianos obtienen una porción que se adapta a ellos en lugar de una GPU completa. Puede mezclar tamaños de porciones en un dispositivo.
4. Sin arranques en frío – Cada modelo conserva su propia partición y permanece cargado, sin penalización de carga ni expulsión.
5. Aislamiento de inquilinos: La protección de memoria entre particiones se aplica en el hardware, lo que simplifica las revisiones de seguridad y cumplimiento.
6. Planificación y contracargo fiables: Una partición funciona de la misma manera independientemente de sus vecinas, por lo que las pruebas de carga predicen la producción. El costo de GPU también se asigna con claridad a un modelo, equipo o inquilino.

La partición tiene límites que conviene conocer de antemano. El número máximo de particiones depende del acelerador y nunca supera siete. MIG por sí solo solo permite cambiar una distribución mientras sus particiones están inactivas, y en SageMaker AI eso significa elegir una distribución al crear el endpoint. Un modelo que necesita más de una GPU sigue necesitando dispositivos completos. Dentro de esos límites, se obtiene el aislamiento de GPU separadas sin dedicar una a cada modelo.

Particionar sin el trabajo de plataforma

Hasta ahora, obtener MIG significaba ejecutar usted mismo la pila de Kubernetes. La partición de GPU en Amazon SageMaker AI elimina ese paso: usted elige un perfil de partición para su modelo, y SageMaker AI se encarga de la configuración, colocación y escalado de GPU. Obtendrá uso compartido de GPU con aislamiento de hardware en un endpoint administrado, sin tener que ejecutar la plataforma que hay debajo.

Salesforce ha formado parte de este trabajo desde el principio, ayudando a definir los requisitos y validando la implementación inicial.

“NVIDIA MIG particiona una sola GPU en múltiples instancias aisladas, cada una con recursos dedicados de cómputo y memoria. Salesforce considera que esta es una capacidad importante porque muchas cargas de trabajo de inferencia no requieren una GPU completa. MIG nos permitiría consolidar cargas de trabajo de forma segura, mejorar significativamente la utilización de GPU, reducir los costos de inferencia y mantener un rendimiento predecible y un fuerte aislamiento.

Esta capacidad nos ayudaría a escalar la inferencia de IA de manera más eficiente en diferentes casos de uso. Salesforce ha ayudado a definir los requisitos y ha validado la solución inicial. Ahora nos estamos preparando para validar la solución con una carga de trabajo de producción representativa y demostrar una fuerte demanda de los clientes junto con AWS. Creemos que la compatibilidad con MIG aportaría un valor técnico y comercial significativo para los clientes empresariales.”

— Richard Chang, Arquitecto de Ingeniería de Software, Salesforce

Cómo funciona

La partición de GPU añade dos campos opcionales a las llamadas de API que ya realiza. No hay nuevas operaciones de API, ni nuevos tipos de recursos, ni nuevas acciones de AWS Identity and Access Management (IAM), y un endpoint que omite ambos campos se comporta exactamente igual que hoy.

AcceleratorPartitionLayouts va en una variante de producción en CreateEndpointConfig y declara cómo se divide cada acelerador:

{
  "EndpointConfigName": "multi-model-partitioned",
  "ExecutionRoleArn": "<execution-role-arn>",
  "ProductionVariants": [
    {
      "VariantName": "AllTraffic",
      "InstanceType": "ml.p4d.24xlarge",
      "InitialInstanceCount": 1,
      "AcceleratorPartitionLayouts": [
        { "AcceleratorPartitionTypes": ["mig-4g.20gb", "mig-2g.10gb", "mig-1g.5gb"] }
      ]
    }
  ]
}

Una A100 tiene siete segmentos de cómputo para dividir. La disposición anterior usa los siete, por lo que cada una de las ocho A100 en la instancia p4d lleva tres particiones y el endpoint proporciona 24, ocho de cada tipo.

El reparto se aplica de manera uniforme. Una entrada de la disposición describe cómo se divide un acelerador, y cada acelerador en cada instancia de la variante se divide de la misma manera. La lista no es posicional, por lo que una entrada no se corresponde con una GPU específica.

AcceleratorPartitionType va en un componente de inferencia y selecciona en qué partición se ejecuta el modelo:

{
  "InferenceComponentName": "summarizer",
  "EndpointName": "multi-model-partitioned",
  "VariantName": "AllTraffic",
  "Specification": {
    "ModelName": "summarizer-model",
    "ComputeResourceRequirements": {
      "AcceleratorPartitionType": "mig-4g.20gb",
      "NumberOfAcceleratorDevicesRequired": 1,
      "NumberOfCpuCoresRequired": 1,
      "MinMemoryRequiredInMb": 2048
    }
  },
  "RuntimeConfig": { "CopyCount": 1 }
}

Cada copia del componente ocupa una partición del tipo solicitado. Con ocho particiones de cada tipo en la instancia, aumentar CopyCount coloca copias adicionales en particiones libres. Esto es útil para un modelo pequeño que atiende alta concurrencia, donde un solo proceso deja a la GPU esperando solicitudes.

NumberOfAcceleratorDevicesRequired siempre es 1 aquí. Con un tipo de partición establecido significa una partición en lugar de un acelerador. NumberOfCpuCoresRequired y MinMemoryRequiredInMb siguen describiendo la CPU del host y la memoria del host, porque la memoria de la GPU proviene del tipo de partición.

La invocación no cambia. InvokeEndpoint dirige una solicitud a un modelo por el nombre del componente de inferencia, y la partición que ocupa nunca aparece en la solicitud.

La partición ocurre mientras se aprovisiona el endpoint. Cuando llega a InService cada acelerador está dividido y las particiones están vacías, lo cual es un estado válido ya que los componentes se colocan en ellas después. En nuestras pruebas, dividir los aceleradores añadió aproximadamente 17 segundos al aprovisionamiento. El resto del tiempo es el lanzamiento habitual de la instancia y la descarga del contenedor.

Perfiles de partición por GPU

Los perfiles disponibles para usted son una propiedad de la GPU, así que comience averiguando qué GPU lleva su tipo de instancia y consúltelo en los perfiles MIG compatibles de NVIDIA, que es la autoridad sobre el conjunto completo de perfiles y las combinaciones válidas en un dispositivo.

Lea el nombre del perfil como unidades de cómputo seguidas de la memoria de GPU: mig-3g.40gb toma tres unidades de cómputo y 40 GB. La columna de granularidad es lo que limita una distribución. Una A100 y una H100 se dividen en séptimos en cómputo y en octavos en memoria, mientras que la G7 se divide en mitades y la G7e en cuartos. Los nombres de los perfiles difieren entre GPUs incluso donde los recuentos de particiones coinciden, así que no traslade una distribución de una familia de instancias a otra sin verificarla contra esta tabla.

Dentro de esos límites tiene una elección real. En una P4d o P5 puede crear siete del perfil más pequeño, o dos particiones de 3g, o la distribución de 4g más 2g más 1g usada en el ejemplo anterior, o tomar el dispositivo completo como uno solo. En una G7e puede tomar cuatro de las más pequeñas, o dos 1g junto a una 2g, o dos 2g, o un dispositivo completo. En una G7, o dos particiones o una.

El perfil de 3g es el que hay que conocer, porque sus dos dimensiones no coinciden: toma tres de las siete unidades de cómputo pero cuatro de las ocho unidades de memoria. Dos de ellas llenan la GPU y nada más cabrá junto a ellas.

La regla general: Cada perfil en su distribución debe ser uno que su GPU ofrezca, y las unidades de cómputo y memoria que sumen sus perfiles no deben exceder lo que proporciona un dispositivo. Ambas condiciones se verifican al crear la configuración del endpoint, y si cualquiera falla es un rechazo, no una alternativa al acelerador completo.

Nota sobre el controlador para P4d: mig-1g.10gb requiere un controlador NVIDIA R525 o más nuevo, y la imagen predeterminada de P4d incluye la 470.256.02. Si lo solicita en la imagen predeterminada, la creación de particiones falla sin un error que mencione el perfil. Configure InferenceAmiVersion a al2023-ami-sagemaker-inference-gpu-4-1 en la variante de producción para obtener una imagen de la línea de controlador 580, que lo ofrece.

Elegir una distribución para su carga de trabajo

Elegir bien es una cuestión distinta de elegir una distribución que simplemente sea aceptada. Una partición le entrega cómputo y memoria en proporciones fijas, y cada uno hace un trabajo diferente durante la inferencia.

Las unidades de cómputo son lo que necesita para el prefill. El prefill lee el prompt y construye su representación. Es la fase intensiva en cómputo, y escala con los streaming multiprocessors, y por tanto con los TFLOPs, que tenga su partición. Cuanto más largas sean sus entradas y más prompts lleguen a la vez, más gobierna esto la rapidez con la que devuelve un primer token.

Las unidades de memoria son lo que necesita para el decode y para la capacidad. Generar tokens vuelve a leer los pesos del modelo en cada paso, así que el decode está limitado por el ancho de banda de memoria y no por el cálculo, y la memoria también limita cuánta caché KV puede mantener. Ese límite a su vez fija la longitud de contexto que puede servir y cuántas secuencias puede servir concurrentemente.

Casi ninguna carga de trabajo real ejercita solo una de estas dos, así que el objetivo no es elegir una dimensión sino elegir una combinación que soporte su caso de uso. Elija un perfil cuyas proporciones cubran su fase más pesada mientras deja la otra adecuadamente atendida. En el lado del cómputo, lo que importa es la longitud de sus prompts y cuántos llegan a la vez. En el lado de la memoria, es la longitud de su salida, su ventana de contexto y su concurrencia.

La memoria es la más fácil de subestimar de las dos, porque una partición debe albergar tres cosas y no solo el modelo: los pesos, que para un modelo de 8B en FP16 son unos 16 GB. La caché KV, dimensionada para la longitud de contexto y el número de secuencias concurrentes que permita, que es el término que la gente omite y el que crece con el tráfico. Y de 1 a 2 GB de sobrecarga de runtime para el contexto CUDA y el proceso de servicio. Sume todo eso antes de elegir un perfil, porque una partición dimensionada solo por los pesos cargará el modelo y luego fallará bajo carga, o servirá silenciosamente un contexto mucho más corto del que configuró. Como referencia concreta, ese mismo modelo de 8B en FP16 sirve cómodamente un contexto de 8,000 tokens en una partición de 40 GB.

Dónde añade más valor MIG

Un portafolio de modelos pequeños y medianos – El caso directo. Variantes ajustadas, modelos de embeddings, rerankers y clasificadores que cada uno deja sin usar la mayor parte de un acelerador ahora comparten uno.

Servicio de modelos multi-arrendatario – Cuando aloja un modelo por cliente, MIG le da un límite de hardware entre ellos: un proceso en una partición no puede leer la memoria de otra partición ni tomar su rendimiento. Delimite la afirmación con precisión, sin embargo. Los modelos en la misma instancia siguen compartiendo la CPU del host, la memoria del sistema, el almacenamiento, la red y el enrutamiento del endpoint, así que la partición es un mecanismo de aislamiento para la GPU y no un límite completo de arrendamiento.

Pipelines multietapa en una sola instancia – Un modelo de transcripción, un modelo de diarización y un modelo de lenguaje, o un embedder, un reranker y un generador. Cada etapa es un componente direccionable por separado en su propia partición, y un salto de red entre etapas desaparece.

Un modelo pequeño en la ruta de la petición – Un clasificador de seguridad o modelo de barreras de protección que debe ejecutarse en cada petición pero que no justifica un acelerador, con latencia predecible porque no hace división de tiempo contra el modelo principal.

Contendientes y canarios – Ejecutar un modelo candidato en una partición pequeña junto al modelo que sirve el tráfico de producción en lugar de montar un segundo endpoint.

Rendimiento: una porción de una GPU más nueva frente a una completa más antigua

Además de bin-packing, el otro beneficio que obtienes es la granularidad en GPU de gama alta: más opciones de GPU para desplegar un modelo, y la elección de cuál usar es tuya. Cada acelerador compatible se convierte en varios tamaños en lugar de uno, así que la forma práctica de pensarlo es que cada perfil es una opción de GPU por derecho propio, al lado de los aceleradores completos entre los que ya eliges. Esto importa más cuando estás considerando un tipo de instancia más grande o más nueva, porque subir de nivel deja de ser todo o nada: puedes tomar tanta parte de esa GPU más grande como necesite tu carga de trabajo, en cualquiera de los tamaños que publica, en lugar de pagar por el acelerador completo.

Para ver si esto vale la pena, comparamos una mig-3g.40gb partición de una H100 contra una A100-40GB completa, sin dividir. Las dos tienen memoria de GPU comparable, lo que lo convierte en una forma limpia de ver cuán poderosa puede ser una porción de una instancia más avanzada.

Usamos genai-bench para generar carga, dirigiendo ambos endpoints desde el mismo cliente para que la GPU fuera la única variable. Ambos lados ejecutaron Llama-3.1-8B-Instruct en endpoints de producción de SageMaker en tiempo real, una réplica de modelo cada uno, con una imagen de contenedor, un tokenizador y una configuración de cliente idénticos. Ambos se invocaron a través de la ruta nativa de SageMaker AI compatible con OpenAI. Barrimos cinco formas de tráfico, escritas D(tokens de entrada, tokens de salida) y con un rango que iba desde prompts cortos hasta resúmenes de contexto largo, cada una a lo largo de una escalera de concurrencia de 2 a 512.

Figura 1: Tokens de salida agregados por segundo para una partición mig-3g.40gb de una H100 contra una A100-40GB completa, en cinco formas de tráfico y una escalera de concurrencia de 2 a 512

Figura 2: Beneficio de costo de la partición por millón de tokens de salida frente a la concurrencia para las mismas cinco formas de tráfico

Cuatro cosas destacan.

• La partición es más rápida en todas partes – Entregó más tokens de salida por segundo en cada escenario a cada concurrencia, entre un 53 por ciento y un 89 por ciento a la carga donde el beneficio de costo de cada escenario es mayor, y una latencia entre tokens más baja también en cada caso, entre un 8.9 por ciento y un 42.1 por ciento. La brecha se amplía con la carga.
• El tiempo hasta el primer token es menor en todos los casos, entre un 5.6 por ciento y un 47.5 por ciento.
• En costo es entre un 18 y un 34 por ciento más barata por millón de tokens de salida, por encima de un punto de cruce que se adelanta a medida que los prompts se alargan. Concurrencia 64 para prompts de 100 tokens, 4 para prompts de 8,000 tokens. Por debajo del cruce, la A100 completa es la unidad más barata. Estos precios son todos bajo demanda, que en el momento del análisis se medían como $25.251286 por hora para una ml.p4d.24xlarge y $63.296000 por hora para una ml.p5.48xlarge en la Región de AWS Oeste de EE. UU. (Oregón). Puramente para nuestro propio análisis, derivamos el costo unitario dividiendo el costo de la instancia completa entre el número de unidades en ella: 8 en la p4d, y 16 en la p5, donde nuestra partición es la mitad de una GPU.
• En la parte alta de la escalera con tráfico de contexto largo, la A100 dejó de servir. En las cargas de trabajo de 6,000 y 8,000 tokens falló entre un tercio y la mitad de sus solicitudes contra un plazo del camino de servicio, mientras que la partición no falló ninguna. Por eso esos dos paneles terminan antes que el resto.

Trata esto como una comparación caso por caso, no como un veredicto. El modelo mental útil es considerar las fracciones de GPU disponibles como tipos de GPU por derecho propio. Enuméralas junto a los aceleradores completos, calcula qué exige realmente tu tráfico en cómputo y en memoria, y compáralas en tu propia carga de trabajo. Para tráfico de alta concurrencia y entrada larga, la partición ganó tanto en rendimiento como en costo aquí. Para cargas de trabajo de entrada corta o baja concurrencia, la A100 completa siguió siendo más barata. La partición no es una respuesta universal. Te da más tamaños para elegir, así que puedes escoger el que se ajuste a tu carga de trabajo.

Qué saber antes de comprometerte con una distribución

La partición cambia la forma de un endpoint, y algunas propiedades vale la pena entender antes de diseñar uno.

El tipo de partición de un componente es fijo durante la vida de ese componente. Mover un modelo a un perfil diferente significa crear un componente nuevo. Cambiar el recorte del endpoint significa un endpoint nuevo y una migración de tráfico, porque actualizar la configuración de un endpoint no vuelve a recortar los hosts que ya están en ejecución. Esto hace que la partición sea un buen ajuste para un portafolio estable y uno pobre para una mezcla que reorganizas a diario.

Un perfil solicitado tiene que existir en la distribución del endpoint. No hay alternativa al acelerador completo, por lo que un componente que pide un perfil que la variante no declaró es rechazado.

La partición aplica a la inferencia en tiempo real en endpoints de componentes de inferencia. Los endpoints serverless y los grupos de instancias heterogéneos no están soportados, y la invocación asíncrona no puede dirigirse a un componente de inferencia, así que las cargas de trabajo asíncronas están fuera de alcance.

Se te factura por la instancia de GPU completa, como hoy. La partición aumenta cuánto de esa instancia puedes usar. No cambia su precio por hora.

Finalmente, un modelo que realmente necesita un acelerador completo, o más de uno, debería seguir teniendo uno. Ninguna partición abarca múltiples aceleradores.

Instancias y Regiones soportadas

La partición de GPU está disponible en las familias de instancias P4d, P5, G7 y G7e. El soporte es a nivel de familia, por lo que los tamaños más pequeños dentro de una familia están cubiertos.

Está disponible en las siguientes Regiones de AWS: Este de EE. UU. (Norte de Virginia), Este de EE. UU. (Ohio), Oeste de EE. UU. (Oregón), Asia Pacífico (Singapur), Asia Pacífico (Tokio), Europa (Fráncfort) y Europa (Irlanda).

La disponibilidad de instancias varía según la Región, así que confirma que tu tipo de instancia elegido se ofrece en tu Región y que tienes cuota de uso de endpoints para él.

Para empezar

Para particionar un endpoint de GPU, calcule la memoria y el cómputo que necesita cada uno de sus modelos, elija los perfiles que se ajusten, declare una disposición en la configuración de su endpoint y despliegue cada modelo como un componente de inferencia que solicita un perfil de esa disposición. Nada cambia en la forma en que invoca sus modelos.

Para consultar la referencia de la API, las tablas completas de perfiles de cada familia de instancias y un recorrido paso a paso, consulte GPU partitioning en la Amazon SageMaker AI Developer Guide.

Para probarlo usted mismo, ejecute el GPU partitioning sample notebook, que despliega varios modelos en particiones de un único endpoint de GPU.

El cambio más amplio merece tenerse en cuenta al planificar la capacidad. Cada acelerador compatible ahora tiene varios tamaños en lugar de uno. Si una partición de una GPU más reciente o un acelerador completo de uno más antiguo es la unidad adecuada para un modelo determinado ya no es una pregunta que deba responder redondeando hacia arriba. Es algo que se puede medir.

Sobre los autores