Cuando despliegas un modelo en un punto de conexión de GPU, la unidad mínima de GPU que puedes solicitar es un acelerador completo.

ml.p4d.24xlarge tiene ocho A100, por lo que puede contener ocho modelos, ya sea que cada uno necesite 40 GB o 14 GB. Segundo, y menos obvio, hace que cada despliegue se reduzca a una elección de qué GPU completa desplegar. A medida que crecen tu concurrencia y las longitudes de los mensajes, 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 tu modelo puede utilizar. Terminas siendo subatendido o pagando por una capacidad que nunca alcanzas.

Hoy en día, 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 hardware. Eso cambia ambas restricciones: puedes colocar un modelo diferente en cada partición y puedes elegir una fracción de un acelerador más nuevo en lugar de uno completo de cualquiera de las generaciones.

Esta publicación cubre ambos aspectos. La primera parte es el beneficio directo: desplegar más modelos de los que tienes GPUs, con aislamiento entre ellos. La segunda es la que los clientes preguntan cuando la pregunta se centra en el costo: cómo la granularidad de la partición te ayuda a elegir la unidad del tamaño adecuado y qué medimos cuando lo hicimos.

Una cosa que debes saber antes de seguir leyendo: la partición de GPU funciona en puntos de conexión que utilizan componentes de inferencia, el constructo que usas para desplegar varios modelos en un punto de conexión y establecer la computación que cada modelo recibe. La partición se basa directamente en ello. Una partición es un recurso que un componente solicita, en el mismo lugar donde ya solicita CPU y memoria. Si no has utilizado componentes de inferencia, esta publicación los introduce. Los puntos de conexión de un solo modelo, los puntos de conexión sin servidor y las piscinas de instancias heterogéneas no se pueden particionar.

Qué hacen los clientes hoy en día y por qué cada opción es insuficiente

Si tienes más modelos que aceleradores, has tenido tres opciones.

Ejecutar menos puntos de conexión más grandes y realizar un procesamiento por lotes más intenso – Esto aumenta la utilización, pero solo cuando los modelos son intercambiables. Un portafolio de variantes ajustadas finamente o modelos por inquilino no lo es.

Usar puntos de conexión multi-modelo – Estos cargan y descargan modelos de una GPU compartida según sea necesario, lo que se adapta al tráfico disperso y de ráfagas. Pero los modelos comparten el dispositivo sin aislamiento, por lo que una solicitud pesada para 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.

Pasar a Kubernetes autoadministrado – Este es el lugar al que han ido los clientes que necesitan una partición de GPU real. MIG funciona allí, pero asumes la versión de controlador, la configuración de partición, un plugin de dispositivo, programación y mantener todo consistente en una flota. Eso es mucho trabajo para una capacidad de hardware que tus 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. Debido a que la división se realiza en hardware en lugar de software, obtienes garantías que otros métodos de compartición no pueden ofrecer:

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 se muestra en el p99 de otro modelo.
2. Aislamiento de fallos – Un error de memoria o un bloqueo se mantiene dentro de su partición en lugar de afectar a todos los modelos de la GPU.
3. Capacidad de tamaño adecuado – Los modelos pequeños y medianos obtienen una porción que se adapta a ellos en lugar de una GPU completa. Puedes mezclar tamaños de porción en un dispositivo.
4. No hay arranques en frío – Cada modelo mantiene su propia partición y permanece cargado, sin penalización de carga y sin expulsión.
5. Aislamiento de inquilinos – La protección de memoria entre particiones se aplica en hardware, lo que simplifica las revisiones de seguridad y cumplimiento.
6. Planificación y cargo confiables – Una partición funciona de la misma manera independientemente de sus vecinos, por lo que las pruebas de carga predicen la producción. El costo de la GPU también se asigna limpiamente a un modelo, equipo o inquilino.

La partición tiene límites que vale la pena conocer de antemano. El número máximo de particiones depende del acelerador y nunca supera los siete. MIG solo permite cambiar el diseño mientras sus particiones están inactivas, y en SageMaker AI eso significa elegir un diseño al crear el punto de conexión. Un modelo que necesita más de una GPU todavía necesita dispositivos completos. Dentro de esos límites, obtienes el aislamiento de GPUs separadas sin dedicar una a cada modelo.

Particionamiento sin el trabajo de la plataforma

Hasta ahora, obtener MIG significaba ejecutar la pila de Kubernetes tú mismo. La partición de GPU en Amazon SageMaker AI elimina ese paso: seleccionas un perfil de partición para tu modelo, y SageMaker AI maneja la configuración de la GPU, la colocación y la escalabilidad. Obtienes compartición de GPU aislada por hardware en un punto de conexión administrado, sin tener que ejecutar la plataforma subyacente.

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

“NVIDIA MIG divide una sola GPU en múltiples instancias aisladas, cada una con recursos de cómputo y memoria dedicados. 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 manera segura, mejorar significativamente la utilización de la GPU, reducir los costos de inferencia y mantener un rendimiento predecible y una fuerte aislación.

Esta capacidad nos ayudaría a escalar la inferencia de AI de manera más eficiente en diferentes casos de uso. Salesforce ha ayudado a definir los requisitos, ha validado la solución inicial. Ahora estamos preparándonos para validar la solución con una carga de trabajo de producción representativa y demostrar una fuerte demanda de los clientes con AWS. Creemos que el soporte de MIG entregará 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 agrega dos campos opcionales a las llamadas de API que ya realizas. No hay nuevas operaciones de API, no hay nuevos tipos de recursos y no hay nuevas acciones de AWS Identity and Access Management (IAM), y un endpoint que omite ambos campos se comporta exactamente como lo hace hoy.

AcceleratorPartitionLayouts se coloca 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"] }
      ]
    }
  ]
}

Un A100 tiene siete rebanadas de cómputo para dividir. El diseño anterior utiliza las 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.

La división se aplica de manera uniforme. Una entrada de diseño describe cómo se divide un acelerador, y cada acelerador en cada instancia en la variante se divide de la misma manera. La lista no es posicional, por lo que una entrada no se asigna a una GPU específica.

AcceleratorPartitionType se coloca en un componente de inferencia y selecciona qué partición 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 sirve una alta concurrencia, donde un solo proceso deja 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 aún describen 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 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 el endpoint está aprovisionado. Cuando alcanza InService, cada acelerador se divide y las particiones están vacías, lo que es un estado válido ya que los componentes se colocan en ellos posteriormente. En nuestras pruebas, dividir aceleradores agregó aproximadamente 17 segundos al aprovisionamiento. El resto del tiempo es el lanzamiento habitual de la instancia y la extracción del contenedor.

Perfiles de partición por GPU

Los perfiles disponibles para usted son una propiedad de la GPU, así que comience por averiguar qué GPU lleva su tipo de instancia y búsquelo en perfiles MIG compatibles de NVIDIA, que es la autoridad en 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 memoria de GPU: mig-3g.40gb toma tres unidades de cómputo y 40 GB. La columna de granularidad es lo que limita un diseño. Un A100 y un H100 se dividen en séptimos en cómputo y en octavos en memoria, mientras que G7 se divide en mitades y G7e en cuartos. Los nombres de los perfiles difieren entre GPUs incluso cuando las cuentas de rebanadas coinciden, así que no lleve un diseño de una familia de instancias a otra sin verificarlo contra esta tabla.

Dentro de esos límites, tiene una elección real. En un P4d o P5, puede dividir siete del perfil más pequeño, o dos particiones 3g, o el diseño 4g más 2g más 1g utilizado en el ejemplo anterior, o tomar todo el dispositivo como uno. En un G7e, puede tomar cuatro de los más pequeños, o dos 1g junto a un 2g, o dos 2g, o un dispositivo completo. En un G7, dos particiones o una.

El perfil 3g es el que hay que conocer, porque sus dos dimensiones no coinciden: ocupa 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 de alto nivel: Cada perfil en su diseño debe ser uno que su GPU ofrezca, y las unidades de cómputo y memoria que sus perfiles sumen no deben exceder lo que un dispositivo proporciona. Ambas se verifican al crear la configuración del endpoint, y si alguna de ellas falla, es un rechazo en lugar de un retroceso a un acelerador completo.

Nota del controlador para P4d: mig-1g.10gb requiere un controlador NVIDIA R525 o más nuevo, y la imagen P4d predeterminada envía 470.256.02. Solicítelo en la imagen predeterminada y la partición falla sin un error que nombre el perfil. Establezca InferenceAmiVersion en al2023-ami-sagemaker-inference-gpu-4-1 en la variante de producción para obtener una imagen en la línea de controladores 580, que lo ofrece.

Elección de un diseño para su carga de trabajo

Elegir bien es una pregunta separada de elegir un diseño que sea meramente aceptado. Una partición le proporciona unidades de cómputo y memoria en proporciones fijas, y ambas realizan trabajos diferentes durante la inferencia.

Las unidades de cómputo son lo que necesita para prefill. Prefill lee la solicitud y construye su representación. Esta es la fase intensiva en cómputo, y se escala con los multiprocesadores de transmisión, y por lo tanto con los TFLOPs que su partición contiene. Cuanto más largas sean sus entradas y cuanto más solicitudes lleguen al mismo tiempo, más gobierna la velocidad a la que devuelve el primer token.

Las unidades de memoria son lo que necesita para decode y para capacidad. Generar tokens vuelve a leer los pesos del modelo en cada paso, por lo que decode está limitado por la banda de memoria en lugar de por las matemáticas, y la memoria también limita cuánta caché KV puede contener. Ese límite, a su vez, establece la longitud de contexto que puede servir y cuántas secuencias puede servir de forma concurrente.

Casi ninguna carga de trabajo real ejercita solo una de estas, por lo que el objetivo no es elegir una dimensión sino elegir una combinación que admita su caso de uso. Elija un perfil cuyas proporciones cubran su fase más pesada mientras deja que la otra esté adecuadamente servida. En el lado de cómputo, lo que importa es la longitud de sus solicitudes y cuántas llegan al mismo tiempo. En el lado de 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 contener tres cosas y no solo el modelo: los pesos, que para un modelo de 8B en FP16 son de aproximadamente 16 GB. La caché KV, dimensionada según la longitud del contexto y la cantidad de secuencias concurrentes que se pretenden permitir, que es el término que la gente omite y que crece con el tráfico. Y 1-2 GB de sobrecarga de tiempo de ejecución para el contexto CUDA y el proceso de servicio. Suma esos antes de elegir un perfil, porque una partición dimensionada solo para los pesos cargará el modelo y luego fallará bajo carga, o servirá silenciosamente un contexto mucho más corto de lo que se configuró. Para un punto de referencia concreto, ese mismo modelo de 8B en FP16 sirve cómodamente un contexto de 8,000 tokens en una partición de 40 GB.

Donde MIG agrega el mayor valor

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

Servicio de modelos multi-inquilino – Cuando hospeda 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. Sin embargo, delimite la afirmación con precisión. Los modelos en la misma instancia aún comparten la CPU del host, la memoria del sistema, el almacenamiento, la red y la ruta de enrutamiento de endpoint, por lo que la particionación es un mecanismo de aislamiento para la GPU y no un límite de inquilinato completo.

Tuberías multi-etapa en una instancia – Un modelo de transcripción, un modelo de diarización y un modelo de lenguaje, o un incrustador, un reranker y un generador. Cada etapa es un componente separadamente direccionable en su propia partición, y un salto de red entre etapas desaparece.

Un modelo pequeño en la ruta de la solicitud – Un clasificador de seguridad o modelo de guardrail que debe ejecutarse en cada solicitud pero no puede justificar un acelerador, con latencia predecible porque no está compartiendo tiempo con el modelo principal.

Desafiantes y canarios – Ejecute un modelo candidato en una partición pequeña junto al modelo que sirve tráfico de producción en lugar de configurar un segundo endpoint.

Rendimiento: Una rebanada de una GPU más nueva contra una más antigua completa

Además del empaquetado de binarios, el otro beneficio que obtienes es granularidad en GPUs de alta gama: más opciones de GPU para implementar un modelo y la elección de cuál es tuya. Cada acelerador compatible se convierte en varios tamaños en lugar de uno, por lo que la forma práctica de pensar en ello es que cada perfil es una opción de GPU por derecho propio, junto con los aceleradores completos que ya elijes. Eso importa más cuando consideras un tipo de instancia más grande o más nuevo, porque moverse hacia arriba deja de ser todo o nada: puedes tomar tanto o tan poco de esa GPU más grande como necesite tu carga de trabajo, en cualquiera de los tamaños que publique, en lugar de pagar por el acelerador completo.

Para ver si eso compensa, comparamos una partición mig-3g.40gb de un H100 con un A100-40GB completo y sin particionar. Los dos tienen memoria de GPU comparable, lo que lo hace 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, conduciendo ambos endpoints desde el mismo cliente para que la GPU sea la única variable. Ambos lados ejecutaron Llama-3.1-8B-Instruct en endpoints de SageMaker en tiempo real, una réplica de modelo cada uno, con una imagen de contenedor idéntica, tokenizador y configuración de cliente. Ambos se invocaron a través de la ruta compatible con OpenAI nativa de SageMaker AI. Barrimos cinco formas de tráfico, escritas D(tokens de entrada, tokens de salida) y que van desde prompts cortos hasta resúmenes de contexto largo, cada uno a través 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 un H100 contra un A100-40GB completo, en cinco formas de tráfico y una escalera de concurrencia de 2 a 512

Figura 2: Beneficio de costo de partición por millón de tokens de salida contra 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 y en cada concurrencia, en un 53 por ciento a 89 por ciento en la carga donde el beneficio de costo de cada escenario es más grande, y una latencia entre tokens más baja en cada uno, en un 8,9 por ciento a 42,1 por ciento. La brecha se amplía con la carga.
• El tiempo hasta el primer token es más bajo en cada caso, en un 5,6 por ciento a 47,5 por ciento.
• En cuanto al costo, es un 18-34 por ciento más barato por millón de tokens de salida, por encima de un punto de equilibrio que se mueve antes a medida que se alargan las solicitudes. Concurrency 64 para solicitudes de 100 tokens, 4 para solicitudes de 8.000 tokens. Debajo del punto de equilibrio, toda la unidad A100 es la unidad más barata. Estos precios son todos bajo demanda, que en el momento del análisis se midieron en $25,251286 por hora para un ml.p4d.24xlarge y $63,296000 por hora para un ml.p5.48xlarge en la región de AWS US West (Oregon). Puramente para nuestro propio análisis, derivamos el costo unitario dividiendo el costo de la instancia completa por la cantidad de unidades en ella: 8 en el p4d y 16 en el p5, donde nuestra partición es la mitad de una GPU.
• En la parte superior de la escala en tráfico de contexto largo, el A100 dejó de servir. En las cargas de trabajo de 6.000 y 8.000 tokens, falló un tercio a la mitad de sus solicitudes contra un plazo de servidor, mientras que la partición no falló ninguna. Es por eso que esos dos paneles terminan antes que el resto.

Trate 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 en sí mismos. Enumérelos junto con los aceleradores completos, determine qué exige su tráfico de cómputo y memoria, y compárelos en su propia carga de trabajo. Para tráfico de alta concurrencia y entrada larga, la partición ganó en rendimiento y costo aquí. Para cargas de trabajo de entrada corta o baja concurrencia, la unidad A100 completa siguió siendo más barata. La partición no es una respuesta de un tamaño que se adapte a todos. Le da más tamaños para elegir, para que pueda elegir el que se adapte a su carga de trabajo.

Qué saber antes de comprometerse con un diseño

La partición cambia la forma de un endpoint, y algunas propiedades valen 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 nuevo componente. Cambiar la configuración del endpoint significa un nuevo endpoint y una migración de tráfico, porque actualizar la configuración de un endpoint no recorta los hosts que ya están en ejecución. Esto hace que la partición sea una buena opción para un portafolio estable y una mala para una mezcla que se reorganiza diariamente.

Un perfil solicitado debe existir en el diseño del endpoint. No hay fallback a un acelerador completo, por lo que un componente que solicita un perfil que la variante no declaró es rechazado.

La partición se aplica a la inferencia en tiempo real en los puntos finales de los componentes de inferencia. Los puntos finales sin servidor y las piscinas de instancias heterogéneas no están soportados, y la invocación asíncrona no puede dirigirse a un componente de inferencia, por lo que las cargas de trabajo asíncronas están fuera del alcance.

Se le factura por la instancia de GPU completa, como hoy en día. La partición aumenta la cantidad de esa instancia que puede utilizar. No cambia su precio por hora.

Finalmente, un modelo que realmente necesita un acelerador completo, o más de uno, debe seguir teniendo uno. Ninguna partición abarca 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. (N. 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 confirme que el tipo de instancia que ha elegido se ofrece en su región y que tiene cuota de uso de punto final para ella.

Introducción

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

Para la referencia de la API, las tablas de perfiles completas para cada familia de instancias y una guía paso a paso, consulte partición de GPU en la Guía de desarrollo de AI de Amazon SageMaker.

Para probarlo usted mismo, ejecute el cuaderno de ejemplo de partición de GPU, que despliega varios modelos en particiones de un solo punto final de GPU.

El cambio más amplio vale la pena tener en cuenta al planificar la capacidad. Cada acelerador soportado es ahora varios tamaños en lugar de uno. Si una partición de una GPU más nueva o un acelerador completo de una más antigua es la unidad adecuada para un modelo determinado, ya no es una pregunta que deba responder redondeando. Es una que puede medir.

Acerca de los autores