Esta publicación fue escrita en colaboración con Tomer Berkovich, Yitzhak Leviy Max Rabin.
La selección de instancias adecuadas para cargas de trabajo de aprendizaje automático (ML) es una decisión importante con implicaciones potencialmente significativas en la velocidad y el costo del desarrollo. en un Publicación anterior Ampliamos este proceso, propusimos una métrica para tomar esta importante decisión y destacamos algunos de los muchos factores que debe tener en cuenta. En esta publicación demostraremos la oportunidad de reducir los costos de capacitación del modelo de IA tomando Instancia puntual tenga en cuenta la disponibilidad al tomar su decisión de selección de instancia basada en la nube.
Una de las oportunidades más importantes para ahorrar costos en la nube es aprovechar el bajo costo. Instancias puntuales de Amazon EC2. Las instancias puntuales son motores informáticos con descuento de la capacidad excedente de servicios en la nube. A cambio del precio con descuento, AWS se reserva el derecho de adelantar la instancia sin previo aviso. En consecuencia, la relevancia del uso de instancias de Spot se limita a cargas de trabajo que son tolerantes a fallas. Afortunadamente, mediante el uso eficaz de puntos de control del modelo Las cargas de trabajo de capacitación de ML se pueden diseñar para que sean tolerantes a fallas y aprovechen la oferta de instancias Spot. De hecho, Amazon SageMaker, el servicio administrado de AWS para desarrollar ML, facilita el entrenamiento en instancias Spot mediante gestionar el ciclo de vida del spot de extremo a extremo para ti.
Desafortunadamente, Capacidad de instancia puntual, que mide la disponibilidad de instancias Spot para su uso, está sujeto a fluctuaciones constantes y puede ser muy difícil de predecir. Amazon ofrece asistencia parcial para evaluar la Capacidad de instancia puntual de un tipo de instancia de elección a través de su Puntuación de ubicación puntual (SPS) que indica la probabilidad de que una solicitud Spot tenga éxito en un determinado región o zona de disponibilidad (AZ). Esto es especialmente útil cuando tienes la libertad de elegir entrenar tu modelo en una de varias ubicaciones diferentes. Sin embargo, la función SPS no ofrece garantías.
Cuando elige entrenar un modelo en una o más instancias de Spot, corre el riesgo de que el tipo de instancia que elija no tenga capacidad de Spot (es decir, su trabajo de entrenamiento no comenzará) o, peor aún, de que ingrese a un modelo. Ciclo iterativo en el que su entrenamiento se ejecuta repetidamente durante solo una pequeña cantidad de pasos de entrenamiento y se detiene antes de que haya logrado un progreso significativo, lo que puede sumar sus costos de entrenamiento sin ningún retorno.
En los últimos años, los desafíos de la utilización de instancias puntuales han sido particularmente graves cuando se trata de múltiples GPU. EC2 tipos de instancias como g5.12xgrande y p4d.24xgrande. Un enorme aumento en la demanda de potentes aceleradores de capacitación (impulsado en parte por avances en el campo de la IA generativa) combinado con interrupciones en la cadena de suministro global, han hecho que sea prácticamente imposible depender de manera confiable de instancias Spot con múltiples GPU para la capacitación de ML. La alternativa natural es utilizar el más costoso. Bajo demanda (OD) o instancias reservadas. Sin embargo, en nuestro Publicación anterior Destacamos el valor de considerar muchas alternativas diferentes para elegir el tipo de instancia. En esta publicación, demostraremos los beneficios potenciales de reemplazar instancias On Demand con múltiples GPU por múltiples instancias Spot con una sola GPU.
Aunque nuestra demostración utilizará Amazon Web Services, se pueden llegar a conclusiones similares en plataformas de servicios en la nube (CSP) alternativas. No interprete nuestra elección de CSP o servicios como un respaldo. La mejor opción para usted dependerá de los detalles únicos de su proyecto. Además, tenga en cuenta la posibilidad de que el tipo de ahorro de costos que demostraremos no se reproduzca en el caso de su proyecto y/o que la solución que proponemos no sea aplicable (por ejemplo, por alguna razón fuera del alcance de esta publicación). ). Asegúrese de realizar una evaluación detallada de la relevancia y eficacia de la propuesta antes de adaptarla a su caso de uso.
Hoy en día, entrenar modelos de IA en múltiples dispositivos GPU en paralelo, un proceso llamado entrenamiento distribuido – es un lugar común. Dejando de lado el precio de las instancias, cuando tiene la opción de elegir entre un tipo de instancia con varias GPU y varios tipos de instancias con el mismo tipo de GPU únicas, normalmente elegiría la instancia con varias GPU. El entrenamiento distribuido normalmente requiere una cantidad considerable de comunicación de datos (por ejemplo, intercambio de gradientes) entre las GPU. La proximidad de las GPU en una sola instancia facilitará un mayor ancho de banda de red y una menor latencia. Además, algunas instancias de múltiples GPU incluyen interconexiones dedicadas de GPU a GPU que pueden acelerar aún más la comunicación (p. ej., NVEnlace en p4d.24xgrande). Sin embargo, cuando la capacidad de Spot se limita a instancias de GPU únicas, la opción de entrenar en varias instancias de GPU únicas a un costo mucho menor se vuelve más atractiva. Como mínimo, justifica la evaluación de su oportunidad de ahorrar costos.
Cuando el entrenamiento distribuido se ejecuta en varias instancias, las GPU se comunican entre sí a través de la red entre las máquinas host. Para optimizar la velocidad del entrenamiento y reducir la probabilidad y/o el impacto de un cuello de botella en la red, debemos garantizar una latencia mínima de la red y un rendimiento máximo de los datos. Estos pueden verse afectados por una serie de factores.
Colocación de instancias
La latencia de la red puede verse muy afectada por las ubicaciones relativas de las instancias EC2. Idealmente, cuando solicitamos varias instancias basadas en la nube, nos gustaría que todas estuvieran ubicadas en el mismo bastidor físico. En la práctica, sin una configuración adecuada, es posible que ni siquiera se encuentren en la misma ciudad. En nuestra demostración a continuación usaremos un Configuración de VPC objeto para programar un trabajo de capacitación de Amazon SageMaker para utilizar una única subred de un Nube privada virtual de Amazon (VPC). Esta técnica asegurará que todas las instancias de capacitación solicitadas estén en la misma zona de disponibilidad (AZ). Sin embargo, la colocación en la misma AZ puede no ser suficiente. Además, el método que describimos implica elegir una subred asociada con una AZ específica (por ejemplo, la que tiene el mayor Puntuación de ubicación puntual). Una API preferida cumpliría la solicitud en cualquier zona de disponibilidad que tenga capacidad suficiente.
Una mejor manera de controlar la ubicación de nuestras instancias es lanzarlas dentro de un grupo de colocaciónespecíficamente un grupo de colocación de clúster. Esto no sólo garantizará que todas las instancias estarán en el mismo Arizona, pero también los colocará en “el mismo segmento de ancho de banda de alta bisección de la red” para maximizar el rendimiento del tráfico de red entre ellos. Sin embargo, al momento de escribir este artículo, SageMaker no no proporciona la opción de especificar un grupo de colocación. Para aprovechar los grupos de colocación necesitaríamos utilizar una solución de servicio de formación alternativa (como demostraremos a continuación).
Red EC2 By restricciones de ancho
Asegúrese de tener en cuenta el máximo ancho de banda de la red soportado por las instancias EC2 que usted elija. Tenga en cuenta, en particular, que los anchos de banda de red asociados con máquinas con una sola GPU a menudo se documentan como “hasta” una cierta cantidad de Gbps. Asegúrate de entender lo que eso significa y cómo puede afectar la velocidad del entrenamiento con el tiempo.
Tenga en cuenta que la comunicación de datos de GPU a GPU (por ejemplo, uso compartido de gradientes) puede necesitar compartir el ancho de banda limitado de la red con otros datos que fluyen a través de la red, como muestras de entrenamiento que se transmiten a las instancias de entrenamiento o artefactos de entrenamiento que se cargan en archivos persistentes. almacenamiento. Considere formas de reducir la carga útil de cada una de las categorías de datos para minimizar la probabilidad de que se produzca un cuello de botella en la red.
Adaptador de tela elástica (EFA)
Un número creciente de tipos de instancias EC2 son compatibles Adaptador de tela elástica (EFA), una interfaz de red dedicada para optimizar la comunicación entre nodos. El uso de EFA puede tener un impacto decisivo en el rendimiento en tiempo de ejecución de su carga de trabajo de entrenamiento. Tenga en cuenta que el ancho de banda en el canal de la red EFA es diferente al ancho de banda documentado de la red estándar. Al momento de escribir este artículo, es difícil conseguir documentación detallada de las capacidades de EFA y generalmente es mejor evaluar su impacto mediante prueba y error. Considere usar un Instancia EC2 que admite el tipo EFA cuando sea relevante.
Ahora demostraremos el rendimiento comparativo de precios de la capacitación en cuatro GPU únicas. EC2 g5 Instancias puntuales (ml.g5.2xlarge y ml.g5.4xlarge) frente a una única instancia On-Demand de cuatro GPU (ml.g5.12xlarge). Usaremos el siguiente script de entrenamiento que contiene un modelo de clasificación respaldado por Vision Transformer (ViT) (entrenado con datos sintéticos).
import os, torch, time
import torch.distributed as dist
from torch.utils.data import Dataset, DataLoader
from torch.cuda.amp import autocast
from torch.nn.parallel import DistributedDataParallel as DDP
from timm.models.vision_transformer import VisionTransformerbatch_size = 128
log_interval = 10
# use random data
class FakeDataset(Dataset):
def __len__(self):
return 1000000
def __getitem__(self, index):
rand_image = torch.randn([3, 224, 224], dtype=torch.float32)
label = torch.tensor(data=[index % 1000], dtype=torch.int64)
return rand_image, label
def mp_fn():
local_rank = int(os.environ['LOCAL_RANK'])
dist.init_process_group("nccl")
torch.cuda.set_device(local_rank)
# model definition
model = VisionTransformer()
loss_fn = torch.nn.CrossEntropyLoss()
model.to(torch.cuda.current_device())
model = DDP(model)
optimizer = torch.optim.Adam(params=model.parameters())
# dataset definition
num_workers = os.cpu_count()//int(os.environ['LOCAL_WORLD_SIZE'])
dl = DataLoader(FakeDataset(), batch_size=batch_size, num_workers=num_workers)
model.train()
t0 = time.perf_counter()
for batch_idx, (x, y) in enumerate(dl, start=1):
optimizer.zero_grad(set_to_none=True)
x = x.to(torch.cuda.current_device())
y = torch.squeeze(y.to(torch.cuda.current_device()), -1)
with autocast(enabled=True, dtype=torch.bfloat16):
outputs = model(x)
loss = loss_fn(outputs, y)
loss.backward()
optimizer.step()
if batch_idx % log_interval == 0 and local_rank == 0:
time_passed = time.perf_counter() - t0
samples_processed = dist.get_world_size() * batch_size * log_interval
print(f'{samples_processed / time_passed} samples/second')
t0 = time.perf_counter()
if __name__ == '__main__':
mp_fn()
El siguiente bloque de código demuestra cómo usamos el Paquete Python de SageMaker (versión 2.203.1) para ejecutar nuestros experimentos. Tenga en cuenta que para los experimentos de cuatro instancias, configuramos el uso de una VPC con una única subred, como se explicó anteriormente.
from sagemaker.pytorch import PyTorch
from sagemaker.vpc_utils import VPC_CONFIG_DEFAULT# Toggle flag to switch between multiple single-GPU nodes and
# single multi-GPU node
multi_inst = False
inst_count=1
inst_type='ml.g5.12xlarge'
use_spot_instances=False
max_wait=None #max seconds to wait for Spot job to complete
subnets=None
security_group_ids=None
if multi_inst:
inst_count=4
inst_type='ml.g5.4xlarge' # optinally change to ml.g5.2xlarge
use_spot_instances=True
max_wait=24*60*60 #24 hours
# configure vpc settings
subnets=['<VPC subnet>']
security_group_ids=['<Security Group>']
estimator = PyTorch(
role='<sagemaker role>',
entry_point='train.py',
source_dir='<path to source dir>',
instance_type=inst_type,
instance_count=inst_count,
framework_version='2.1.0',
py_version='py310',
distribution={'torch_distributed': {'enabled': True}},
subnets=subnets,
security_group_ids=security_group_ids,
use_spot_instances=use_spot_instances,
max_wait=max_wait
)
# start job
estimator.fit()
Tenga en cuenta que nuestro código depende del tercero. timm Paquete de Python al que apuntamos en un archivo require.txt en la raíz del directorio de origen. Esto supone que la VPC se ha configurado para habilitar el acceso a internet. Alternativamente, puede definir un servidor PyPI privado (como se describe aquí), o cree una imagen personalizada con sus dependencias de terceros preinstaladas (como se describe aquí).
Resumimos los resultados de nuestro experimento en la siguiente tabla. Los precios On-Demand fueron tomados del Página de precios de SageMaker (al momento de escribir este artículo, enero de 2024). Los valores de ahorro puntual se recopilaron de los informes ahorros gestionados en formación puntual del trabajo terminado. Por favor vea el Documentación de precios al contado de EC2 para tener una idea de cómo se calculan los ahorros al contado informados.
Nuestros resultados demuestran claramente el potencial de ahorro considerable al utilizar cuatro instancias Spot de una sola GPU en lugar de una sola instancia On Demand de cuatro GPU. Además, demuestran que, aunque el costo de un tipo de instancia On Demand g5.4xlarge es mayor, el aumento de la potencia de la CPU y/o el ancho de banda de la red, combinado con mayores ahorros de Spot, resultaron en ahorros mucho mayores.
Es importante tener en cuenta que los resultados de rendimiento relativo pueden variar considerablemente según los detalles de su trabajo, así como los precios al contado en el momento en que ejecuta sus experimentos.
en un Publicación anterior Describimos cómo crear un entorno administrado personalizado además de un servicio no administrado, como Amazon EC2. Uno de los factores motivadores enumerados fue el deseo de tener un mayor control sobre la ubicación del dispositivo en una configuración de instancias múltiples, por ejemplo, mediante el uso de un grupo de colocación de clúster, como se discutió anteriormente. En esta sección, demostramos la creación de una configuración de múltiples nodos utilizando un grupo de ubicación de clúster.
Nuestro código asume la presencia de un VPC predeterminada así como la creación (por única vez) de un grupo de colocación de clústerdemostrado aquí usando el SDK de Python de AWS (versión 1.34.23):
import boto3ec2 = boto3.client('ec2')
ec2.create_placement_group(
GroupName='cluster-placement-group',
Strategy='cluster'
)
En el bloque de código siguiente utilizamos el SDK de Python de AWS para lanzar nuestras instancias Spot:
import boto3ec2 = boto3.resource('ec2')
instances = ec2.create_instances(
MaxCount=4,
MinCount=4,
ImageId='ami-0240b7264c1c9e6a9', # replace with image of choice
InstanceType='g5.4xlarge',
Placement={'GroupName':'cluster-placement-group'},
InstanceMarketOptions={
'MarketType': 'spot',
'SpotOptions': {
"SpotInstanceType": "one-time",
"InstanceInterruptionBehavior": "terminate"
}
},
)
Por favor vea nuestro Publicación anterior para obtener consejos paso a paso sobre cómo extender esto a una solución de capacitación automatizada.
En esta publicación, hemos ilustrado cómo demostrar flexibilidad en la elección del tipo de instancia de capacitación puede aumentar su capacidad para aprovechar la capacidad de la instancia de Spot y reducir el costo general de la capacitación.
A medida que los tamaños de los modelos de IA continúan creciendo y los costos de los aceleradores de capacitación de IA continúan aumentando, se vuelve cada vez más importante que exploremos formas de mitigar los gastos de capacitación. La técnica descrita aquí es sólo uno entre varios métodos para optimizar el rendimiento de los costos. Le animamos a explorar nuestra publicaciones anteriores para obtener información sobre oportunidades adicionales en este ámbito.