Implante BLOOM-176B e OPT-30B no Amazon SageMaker com grande inferência de modelo Deep Learning Containers e DeepSpeed

Nos últimos anos, assistimos a um rápido desenvolvimento no campo da aprendizagem profunda. Embora o hardware tenha melhorado, como com a última geração de aceleradores da NVIDIA e da Amazon, os profissionais avançados de aprendizado de máquina (ML) ainda encontram regularmente problemas ao implantar seus grandes modelos de aprendizado profundo para aplicações como processamento de linguagem natural (PNL).

Em uma postagem anterior, discutimos recursos e configurações configuráveis in Implantação do modelo Amazon SageMaker isso pode facilitar a inferência com esses modelos grandes. Hoje anunciamos um novo Amazon Sage Maker Deep Learning Container (DLC) que você pode usar para começar a inferência de modelos grandes em questão de minutos. Esse DLC empacota algumas das bibliotecas de código aberto mais populares para inferência paralela de modelos, como DeepSpeed ​​​​e Hugging Face Accelerate.

Nesta postagem, usamos um novo DLC de inferência de modelo grande do SageMaker para implantar dois dos grandes modelos de PNL mais populares: BigScience's FLOR-176B e Metas OPT-30B do repositório Hugging Face. Em particular, usamos técnicas de serviço Deep Java Library (DJL) e paralelismo de tensor do DeepSpeed ​​para atingir latência de 0.1 segundo por token em um caso de uso de geração de texto.

Você pode encontrar nossos cadernos de exemplo completos em nosso Repositório GitHub.

Técnicas de inferência de modelos grandes

Os modelos de linguagem explodiram recentemente em tamanho e popularidade. Com acesso fácil a partir de zoológicos de modelos, como Hugging Face, e maior precisão e desempenho em tarefas de PNL, como classificação e geração de texto, os profissionais estão cada vez mais buscando esses grandes modelos. No entanto, modelos grandes geralmente são grandes demais para caber na memória de um único acelerador. Por exemplo, o modelo BLOOM-176B pode exigir mais de 350 gigabytes de memória do acelerador, o que excede em muito a capacidade dos aceleradores de hardware disponíveis atualmente. Isso requer o uso de técnicas de modelo paralelo de bibliotecas como DeepSpeed ​​e Hugging Face Accelerate para distribuir um modelo entre vários aceleradores para inferência. Nesta postagem, usamos o Contêiner de inferência de modelo grande SageMaker para gerar e comparar a latência e o desempenho da taxa de transferência usando essas duas bibliotecas de código aberto.

DeepSpeed ​​e Accelerate usam técnicas diferentes para otimizar grandes modelos de linguagem para inferência. A principal diferença é o DeepSpeed uso de kernels otimizados. Esses kernels podem melhorar drasticamente a latência de inferência, reduzindo gargalos no gráfico de computação do modelo. Kernels otimizados podem ser difíceis de desenvolver e normalmente são específicos para uma arquitetura de modelo específica; DeepSpeed ​​oferece suporte a grandes modelos populares, como OPT e BLOOM, com esses kernels otimizados. Em contraste, a biblioteca Accelerate do Hugging Face não inclui kernels otimizados no momento da escrita. Conforme discutimos em nossa seção de resultados, essa diferença é responsável por grande parte da vantagem de desempenho que o DeepSpeed ​​tem em relação ao Accelerate.

Uma segunda diferença entre DeepSpeed ​​e Accelerate é o tipo de paralelismo do modelo. Accelerate usa paralelismo de pipeline para particionar um modelo entre as camadas ocultas de um modelo, enquanto DeepSpeed ​​usa paralelismo de tensor para particionar as próprias camadas. O paralelismo de pipeline é uma abordagem flexível que suporta mais tipos de modelos e pode melhorar o rendimento quando são usados ​​tamanhos de lote maiores. O paralelismo de tensores requer mais comunicação entre GPUs porque as camadas do modelo podem ser espalhadas por vários dispositivos, mas podem melhorar a latência de inferência ao envolver várias GPUs simultaneamente. Você pode aprender mais sobre técnicas de paralelismo em Introdução ao Paralelismo de Modelos e Paralelismo Modelo.

Visão geral da solução

Para hospedar efetivamente grandes modelos de linguagem, precisamos de recursos e suporte nas seguintes áreas principais:

• Construindo e testando soluções – Dada a natureza iterativa do desenvolvimento de ML, precisamos da capacidade de construir, iterar rapidamente e testar como o endpoint de inferência se comportará quando esses modelos forem hospedados, incluindo a capacidade de falhar rapidamente. Normalmente, esses modelos podem ser hospedados apenas em instâncias maiores, como p4dn ou g5, e, dado o tamanho dos modelos, pode demorar um pouco para ativar uma instância de inferência e executar qualquer iteração de teste. O teste local geralmente tem restrições porque você precisa de uma instância semelhante em tamanho para testar, e esses modelos não são fáceis de obter.
• Implantando e executando em escala – Os arquivos do modelo precisam ser carregados nas instâncias de inferência, o que representa um desafio por si só, dado o tamanho. Tar / Un-Tar como exemplo para o Bloom-176B leva cerca de 1 hora para criar e outra hora para carregar. Precisamos de um mecanismo alternativo para permitir fácil acesso aos arquivos do modelo.
• Carregando o modelo como singleton – Para um processo com vários trabalhadores, precisamos garantir que o modelo seja carregado apenas uma vez, para não entrarmos em condições de corrida e gastarmos ainda mais recursos desnecessários. Neste post, mostramos uma forma de carregar diretamente do Serviço de armazenamento simples da Amazon (Amazon S3). No entanto, isso só funciona se usarmos as configurações padrão do DJL. Além disso, qualquer escalonamento dos endpoints precisa ser iniciado em alguns minutos, o que exige reconsiderar como os modelos podem ser carregados e distribuídos.
• Estruturas de fragmentação – Esses modelos normalmente precisam ser implementados, geralmente por um mecanismo de paralelismo de tensor ou por fragmentação de pipeline como as técnicas típicas de fragmentação, e temos conceitos avançados como fragmentação ZeRO construídos sobre a fragmentação de tensor. Para obter mais informações sobre técnicas de fragmentação, consulte Paralelismo Modelo. Para conseguir isso, podemos ter diversas combinações e utilizar frameworks da NIVIDIA, DeepSpeed, entre outros. Isso requer a capacidade de testar BYOC ou usar contêineres 1P e iterar soluções e executar testes de benchmarking. Você também pode testar várias opções de hospedagem, como assíncrona, sem servidor e outras.
• Seleção de hardware – Sua escolha de hardware é determinada por todos os pontos mencionados acima e outros padrões de tráfego, necessidades de casos de uso e tamanhos de modelo.

Nesta postagem, usamos kernels otimizados e técnicas de paralelismo de tensor do DeepSpeed ​​para hospedar BLOOM-176B e OPT-30B no SageMaker. Também comparamos os resultados do Accelerate para demonstrar os benefícios de desempenho de kernels otimizados e paralelismo de tensor. Para obter mais informações sobre DeepSpeed ​​e Accelerate, consulte Inferência do DeepSpeed: habilitando a inferência eficiente de modelos de transformadores em escala sem precedentes e Inferência BLOOM incrivelmente rápida com DeepSpeed ​​e Accelerate.

Usamos DJLServing como solução de serviço de modelo neste exemplo. DJLServing é uma solução de serviço de modelo universal de alto desempenho desenvolvida pela Deep Java Library (DJL) que é independente de linguagem de programação. Para saber mais sobre DJL e DJLServing, consulte Implante modelos grandes no Amazon SageMaker usando DJLServing e inferência paralela de modelo DeepSpeed.

É importante notar que kernels otimizados podem resultar em alterações de precisão e em um gráfico de computação modificado, o que poderia, teoricamente, resultar em alteração do comportamento do modelo. Embora isso possa ocasionalmente alterar o resultado da inferência, não esperamos que essas diferenças tenham impacto material nas métricas básicas de avaliação de um modelo. No entanto, os profissionais são aconselhados a confirmar se os resultados do modelo são os esperados ao usar esses kernels.

As etapas a seguir demonstram como implantar um modelo BLOOM-176B no SageMaker usando DJLServing e um contêiner de inferência de modelo grande SageMaker. O exemplo completo também está disponível em nosso Repositório GitHub.

Usando a imagem DLC DJLServing SageMaker

Use o código a seguir para usar a imagem DLC DJLServing SageMaker após substituir a região pela região específica em que você está executando o notebook:

763104351884.dkr.ecr..amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113
# example uri might be like 763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113

Crie nosso arquivo de modelo

Primeiro, criamos um arquivo chamado serving.properties que contém apenas uma linha de código. Isso informa ao servidor modelo DJL para usar o mecanismo DeepSpeed. O arquivo contém o seguinte código:

engine=DeepSpeed

serving.properties é um arquivo definido por DJLServing que é usado para definir a configuração por modelo.

A seguir, criamos nosso model.py arquivo, que define o código necessário para carregar e depois servir o modelo. Em nosso código, lemos no TENSOR_PARALLEL_DEGREE variável de ambiente (o valor padrão é 1). Isso define o número de dispositivos sobre os quais os módulos tensores paralelos são distribuídos. Observe que o DeepSpeed ​​fornece algumas definições de partição integradas, incluindo uma para modelos BLOOM. Nós o usamos especificando replace_method e relpace_with_kernel_inject. Se você possui um modelo personalizado e precisa do DeepSpeed ​​para particionar de forma eficaz, você precisa alterar relpace_with_kernel_inject para false e adicione injection_policy para fazer a partição de tempo de execução funcionar. Para obter mais informações, consulte Inicializando para Inferência. Para nosso exemplo, usamos o modelo BLOOM pré-particionado no DeepSpeed.

Em segundo lugar, no model.py arquivo, também carregamos o modelo do Amazon S3 depois que o endpoint foi ativado. O modelo é carregado no /tmp espaço no contêiner porque o SageMaker mapeia o /tmp ao Loja de blocos elásticos da Amazon (Amazon EBS) volume que é montado quando especificamos o parâmetro de criação do endpoint VolumeSizeInGB. Para instâncias como p4dn, que vêm pré-construídas com a instância de volume, podemos continuar a aproveitar o /tmp no contêiner. Veja o seguinte código:

from djl_python import Input, Output
import os
import deepspeed
import torch
import torch.distributed as dist
import sys
import subprocess
import time
from glob import glob
from transformers import pipeline, AutoModelForCausalLM, AutoTokenizer
from transformers.models.opt.modeling_opt import OPTDecoderLayer

predictor = None

def check_config():
    local_rank = os.getenv('LOCAL_RANK')
    
    if not local_rank:
        return False
    return True
    
def get_model():

    if not check_config():
        raise Exception("DJL:DeepSpeed configurations are not default. This code does not support non default configurations") 
    
    tensor_parallel = int(os.getenv('TENSOR_PARALLEL_DEGREE', '1'))
    local_rank = int(os.getenv('LOCAL_RANK', '0'))
    model_dir = "/tmp/model"
    bucket = os.environ.get("MODEL_S3_BUCKET")
    key_prefix = os.environ.get("MODEL_S3_PREFIX")
    print(f"rank: {local_rank}")
    if local_rank == 0:
        if f"{model_dir}/DONE" not in glob(f"{model_dir}/*"):
            print("Starting Model downloading files")
            try:
                proc_run = subprocess.run(
                    ["aws", "s3", "cp", "--recursive", f"s3://{bucket}/{key_prefix}", model_dir]
                )
                print("Model downloading finished")
                # write file when download complete. Could use dist.barrier() but this makes it easier to check if model is downloaded in case of retry
                with open(f"{model_dir}/DONE", "w") as f:
                    f.write("download_complete")
                    
                proc_run.check_returncode() # to throw the error in case there was one
                
            except subprocess.CalledProcessError as e:
                print ( "Model download failed: Error:nreturn code: ", e.returncode, "nOutput: ", e.stderr )
                raise # FAIL FAST  
                               
    dist.barrier()
                
    
    tokenizer = AutoTokenizer.from_pretrained(model_dir)
    
    # has to be FP16 as Int8 model loading not yet supported
    with deepspeed.OnDevice(dtype=torch.float16, device="meta"):
        model = AutoModelForCausalLM.from_config(
            AutoConfig.from_pretrained(model_dir), torch_dtype=torch.bfloat16
        )
    model = model.eval()
    
    model = deepspeed.init_inference(
        model,
        mp_size=tensor_parallel,
        dtype=torch.int8,
        base_dir = model_dir,
        checkpoint=os.path.join(model_dir, "ds_inference_config.json"),
        replace_method='auto',
        replace_with_kernel_inject=True
    )

    model = model.module
    dist.barrier()
    return model, tokenizer

DJLServing gerencia a instalação em tempo de execução em qualquer pacote pip definido em requirement.txt. Este arquivo terá:

awscli
boto3

Criamos um diretório chamado code e os votos de model.py, serving.properties e requirements.txt os arquivos já foram criados neste diretório. Para visualizar os arquivos, você pode executar o seguinte código no terminal:

mkdir -p code
cat code/model.py 
cat code/serving.properties 
cat code/requirements.txt 

A figura a seguir mostra a estrutura do model.tar.gz.

Por fim, criamos o arquivo de modelo e o carregamos no Amazon S3:

tar cvfz model.tar.gz code
s3_code_artifact = sess.upload_data("model.tar.gz", bucket, s3_code_prefix)

Baixe e armazene o modelo em Hugging Face (opcional)

Fornecemos as etapas nesta seção caso você queira fazer download do modelo para o Amazon S3 e usá-lo a partir daí. As etapas são fornecidas no arquivo Jupyter no GitHub. A captura de tela a seguir mostra um instantâneo das etapas.

Criar um modelo do SageMaker

Agora criamos um Modelo do SageMaker. Nós usamos o Registro do Amazon Elastic Container (Amazon ECR) fornecida e o artefato de modelo da etapa anterior para criar o modelo do SageMaker. Na configuração do modelo, configuramos TENSOR_PARALLEL_DEGREE=8, o que significa que o modelo é particionado em 8 GPUs. Veja o seguinte código:

PrimaryContainer={
        "Image": inference_image_uri,
        "ModelDataUrl": s3_code_artifact,
        "Environment": {
            "MODEL_S3_BUCKET": bucket,
            "MODEL_S3_PREFIX": s3_model_prefix,
            "TENSOR_PARALLEL_DEGREE": "8",
},

Depois de executar a célula anterior no arquivo Jupyter, você verá uma saída semelhante a esta:

{
    "ModelArn": "arn:aws:sagemaker:us-east-1::model/bloom-djl-ds-"
}

Crie um endpoint SageMaker

Você pode usar qualquer instância com várias GPUs para teste. Nesta demonstração, usamos uma instância p4d.24xlarge. No código a seguir, observe como definimos o ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds e VolumeSizeInGB parâmetros para acomodar o tamanho do modelo grande. o VolumeSizeInGB O parâmetro é aplicável a instâncias de GPU compatíveis com o anexo de volume do EBS.

endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "variant1",
            "ModelName": model_name,
            "InstanceType": "ml.p4d.24xlarge",
            "InitialInstanceCount": 1,
            #"VolumeSizeInGB" : 200,
            "ModelDataDownloadTimeoutInSeconds": 2400,
            "ContainerStartupHealthCheckTimeoutInSeconds": 2400,
        },
    ],
)'

Por fim, criamos um endpoint SageMaker:

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=f"{endpoint_name}", EndpointConfigName=endpoint_config_name
)

Você o vê impresso no código a seguir:

{
    "EndpointArn": "arn:aws:sagemaker:us-east-1::endpoint/bloom-djl-ds-"
}

Iniciar o endpoint pode demorar um pouco. Você pode tentar mais algumas vezes se você se deparar com o InsufficientInstanceCapacity erro, ou você pode enviar uma solicitação à AWS para aumentar o limite em sua conta.

Ajuste de desempenho

Se você pretende usar este post e o notebook que o acompanha com um modelo diferente, você pode explorar alguns dos parâmetros ajustáveis ​​que SageMaker, DeepSpeed ​​e DJL oferecem. A experimentação iterativa com esses parâmetros pode ter um impacto significativo na latência, na taxa de transferência e no custo do seu modelo grande hospedado. Para saber mais sobre parâmetros de ajuste, como número de trabalhadores, grau de paralelismo do tensor, tamanho da fila de tarefas e outros, consulte Configurações de serviço DJL e Implante modelos grandes no Amazon SageMaker usando DJLServing e inferência paralela de modelo DeepSpeed.

Resultados

Nesta postagem, usamos DeepSpeed ​​​​para hospedar BLOOM-176B e OPT-30B em instâncias SageMaker ML. A tabela a seguir resume nossos resultados de desempenho, incluindo uma comparação com o Accelerate do Hugging Face. A latência reflete o número de milissegundos necessários para produzir uma string de 256 tokens quatro vezes (batch_size=4) do modelo. A taxa de transferência reflete o número de tokens produzidos por segundo para cada teste. Para Hugging Face Accelerate, usamos o carregamento padrão da biblioteca com mapeamento de memória GPU. Para DeepSpeed, usamos seu mecanismo de carregamento de checkpoint mais rápido.

Do ponto de vista da latência, o DeepSpeed ​​é cerca de 3.4 vezes mais rápido para o BLOOM-176B e 5.6 vezes mais rápido para o OPT-30B do que o Accelerate. Os kernels otimizados do DeepSpeed ​​são responsáveis ​​por grande parte dessa diferença na latência. Dados esses resultados, recomendamos usar DeepSpeed ​​​​em vez de Accelerate se o modelo de sua escolha for compatível.

Também é importante notar que os tempos de carregamento do modelo com DeepSpeed ​​foram muito mais curtos, tornando-o uma opção melhor se você prevê a necessidade de aumentar rapidamente o número de endpoints. A técnica de paralelismo de pipeline mais flexível do Accelerate pode ser uma opção melhor se você tiver modelos ou precisões de modelo que não são suportadas pelo DeepSpeed.

Esses resultados também demonstram a diferença na latência e na taxa de transferência de diferentes tamanhos de modelo. Em nossos testes, o OPT-30B gera 2.4 vezes mais tokens por unidade de tempo do que o BLOOM-176B em um tipo de instância que é mais de três vezes mais barato. Com base no preço por taxa de transferência unitária, o OPT-30B em uma instância g5.24xl é 8.9 vezes melhor que o BLOOM-176B em uma instância p4d.24xl. Se você tiver limitações rígidas de latência, produtividade ou custo, considere usar o menor modelo possível que ainda atenda aos requisitos funcionais.

limpar

Como parte das práticas recomendadas, é sempre recomendável excluir instâncias ociosas. O código abaixo mostra como excluir as instâncias.

# - Delete the end point
sm_client.delete_endpoint(EndpointName=endpoint_name)

# - In case the end point failed we still want to delete the model
sm_client.delete_endpoint_config(EndpointConfigName=endpoint_config_name)
sm_client.delete_model(ModelName=model_name)

Opcionalmente, exclua o ponto de verificação do modelo do seu S3

!aws s3 rm --recursive s3:///{s3_model_prefix}

Conclusão

Nesta postagem, demonstramos como usar contêineres de inferência de modelos grandes do SageMaker para hospedar dois modelos de linguagem grandes, BLOOM-176B e OPT-30B. Usamos técnicas de modelo paralelo do DeepSpeed ​​​​com várias GPUs em uma única instância do SageMaker ML.

Para obter mais detalhes sobre o Amazon SageMaker e seus recursos de inferência de modelos grandes, consulte Amazon SageMaker agora oferece suporte à implantação de modelos grandes por meio de tamanho de volume configurável e cotas de tempo limite e Inferência em tempo real.

Sobre os autores

Simon Zamarin é arquiteto de soluções de AI / ML cujo foco principal é ajudar os clientes a extrair valor de seus ativos de dados. Em seu tempo livre, Simon gosta de passar o tempo com a família, lendo ficção científica e trabalhando em vários projetos de casa DIY.

Rupinder Grewal é um arquiteto de soluções especialista sênior em Ai/ML da AWS. Ele atualmente se concentra em servir de modelos e MLOps no SageMaker. Antes dessa função, ele trabalhou como engenheiro de aprendizado de máquina construindo e hospedando modelos. Fora do trabalho, ele gosta de jogar tênis e andar de bicicleta em trilhas nas montanhas.

Frank liu é engenheiro de software do AWS Deep Learning. Ele se concentra na criação de ferramentas inovadoras de aprendizado profundo para engenheiros de software e cientistas. Nas horas vagas, gosta de fazer caminhadas com amigos e familiares.

Alan Tan é Gerente de Produto Sênior da SageMaker, liderando os esforços de inferência de grandes modelos. Ele é apaixonado por aplicar Machine Learning na área de Analytics. Fora do trabalho, ele gosta de atividades ao ar livre.

Dhawal Patel é Arquiteto Principal de Machine Learning na AWS. Ele trabalhou com organizações que vão desde grandes empresas até startups de médio porte em problemas relacionados à computação distribuída e Inteligência Artificial. Ele se concentra em aprendizado profundo, incluindo domínios de PNL e Visão Computacional. Ele ajuda os clientes a obter inferência de modelo de alto desempenho no SageMaker.

Qinglan é engenheiro de desenvolvimento de software na AWS. Ele vem trabalhando em vários produtos desafiadores na Amazon, incluindo soluções de inferência de ML de alto desempenho e sistema de registro de alto desempenho. A equipe de Qing lançou com sucesso o primeiro modelo Billion-parameter no Amazon Advertising com latência muito baixa necessária. Qing possui profundo conhecimento sobre otimização de infraestrutura e aceleração de Deep Learning.

Qingwei Li é especialista em aprendizado de máquina na Amazon Web Services. Ele recebeu seu Ph.D. em Pesquisa Operacional depois que ele quebrou a conta de bolsa de pesquisa de seu orientador e não entregou o Prêmio Nobel que prometeu. Atualmente, ele ajuda os clientes do setor de seguros e serviços financeiros a criar soluções de aprendizado de máquina na AWS. Nas horas vagas, gosta de ler e ensinar.

Robert Van Dusen é gerente de produto sênior do Amazon SageMaker. Ele lidera a otimização de modelos de aprendizado profundo para aplicativos como inferência de modelos grandes.

Siddharth Venkatesan é engenheiro de software em AWS Deep Learning. Atualmente ele se concentra na construção de soluções para inferência de grandes modelos. Antes da AWS, ele trabalhou na organização Amazon Grocery, criando novos recursos de pagamento para clientes em todo o mundo. Fora do trabalho, ele gosta de esquiar, praticar atividades ao ar livre e assistir esportes.