mosec

A porção de modelo tornada eficiente na nuvem.

Introdução

O MOSEC é uma estrutura de atendimento de modelo de alto desempenho e flexível para a criação de back-end e microsserviços habilitados para modelos ML. Ele preenche a lacuna entre os modelos de aprendizado de máquina que você acabou de treinar e a eficiente API de serviço on -line.

• Altamente Performant : camada da web e coordenação de tarefas construídas com ferrugem?, Que oferece velocidade em chamas, além da utilização eficiente da CPU alimentada por E/S assíncrona
• Facilidade de uso : Interface do usuário puramente em Python?, Por que os usuários podem servir seus modelos de maneira agnóstica da estrutura ML usando o mesmo código que para testar offline
• Batching dinâmico : solicitações agregadas de diferentes usuários para inferência em lotes e distribuir resultados de volta
• Estágios de pipeline : gerar vários processos para estágios de pipeline para lidar com cargas de trabalho mistas de CPU/GPU/IO
• Amigável em nuvem : projetado para correr na nuvem, com o aquecimento do modelo, o desligamento gracioso e as métricas de monitoramento de Prometheus, facilmente gerenciadas por Kubernetes ou qualquer sistema de orquestração de contêineres
• Faça bem uma coisa : concentre -se na parte on -line, os usuários podem prestar atenção à otimização do modelo e lógica de negócios

Instalação

O MOSEC requer Python 3.7 ou superior. Instale o pacote Pypi mais recente para Linux X86_64 ou MacOS x86_64/ARM64 com:

pip install -U mosec
# or install with conda
conda install conda-forge::mosec

Para construir a partir do código -fonte, instale a ferrugem e execute o seguinte comando:

make package

Você receberá um arquivo de roda MOSEC na pasta dist .

Uso

Demonstramos como o MOSEC pode ajudá-lo a hospedar facilmente um modelo de difusão estável pré-treinado como um serviço. Você precisa instalar difusores e transformadores como pré -requisitos:

pip install --upgrade diffusers[torch] transformers

Escreva o servidor

Clique em mim para obter códigos de servidor com explicações.

Em primeiro lugar, importamos as bibliotecas e configuramos um madeireiro básico para observar melhor o que acontece.

 from io import BytesIO
from typing import List

import torch  # type: ignore
from diffusers import StableDiffusionPipeline  # type: ignore

from mosec import Server , Worker , get_logger
from mosec . mixin import MsgpackMixin

logger = get_logger ()

Em seguida, criamos uma API para os clientes consultar um prompt de texto e obter uma imagem com base no modelo estável difusão-v1-5 em apenas 3 etapas.

1. Defina seu serviço como uma classe que herda mosec.Worker . Aqui também herdamos MsgpackMixin para empregar o formato de serialização do MSGPACK ^(A) .

2. Dentro do método __init__ , inicialize seu modelo e coloque -o no dispositivo correspondente. Opcionalmente, você pode atribuir self.example com alguns dados para aquecer ^(b) o modelo. Observe que os dados devem ser compatíveis com o formato de entrada do seu manipulador, que detalhamos a seguir.

3. Substitua o método forward para escrever seu manipulador de serviço ^(c) , com a assinatura forward(self, data: Any | List[Any]) -> Any | List[Any] . Receber/retornar um único item ou uma tupla depende se está configurado em lote dinâmico ^(d) .

 class StableDiffusion ( MsgpackMixin , Worker ):
    def __init__ ( self ):
        self . pipe = StableDiffusionPipeline . from_pretrained (
            "sd-legacy/stable-diffusion-v1-5" , torch_dtype = torch . float16
        )
        self . pipe . enable_model_cpu_offload ()
        self . example = [ "useless example prompt" ] * 4  # warmup (batch_size=4)

    def forward ( self , data : List [ str ]) -> List [ memoryview ]:
        logger . debug ( "generate images for %s" , data )
        res = self . pipe ( data )
        logger . debug ( "NSFW: %s" , res [ 1 ])
        images = []
        for img in res [ 0 ]:
            dummy_file = BytesIO ()
            img . save ( dummy_file , format = "JPEG" )
            images . append ( dummy_file . getbuffer ())
        return images

[!OBSERVAÇÃO]

(a) Neste exemplo, retornamos uma imagem no formato binário, que o JSON não suporta (a menos que codificado com base64 que aumente a carga útil). Portanto, o msgpack combina com a nossa necessidade melhor. Se não herdarmos MsgpackMixin , o JSON será usado por padrão. Em outras palavras, o protocolo da solicitação/resposta de serviço pode ser msgpack, json ou qualquer outro formato (verifique nossos mixins).

(b) O aquecimento geralmente ajuda a alocar a memória da GPU com antecedência. Se o exemplo de aquecimento for especificado, o serviço só estará pronto depois que o exemplo for encaminhado através do manipulador. No entanto, se nenhum exemplo for dado, a latência da primeira solicitação deverá ser mais longa. O example deve ser definido como um único item ou uma tupla, dependendo do que forward espera receber. Além disso, no caso em que você deseja se aquecer com vários exemplos diferentes, você pode definir multi_examples (demonstração aqui).

(c) Este exemplo mostra um serviço de estágio único, onde o trabalhador StableDiffusion recebe diretamente a solicitação de prompt do cliente e responde à imagem. Assim, o forward pode ser considerado como um manipulador de serviço completo. No entanto, também podemos projetar um serviço de vários estágios com trabalhadores fazendo trabalhos diferentes (por exemplo, baixando imagens, inferência de modelos, pós-processamento) em um pipeline. Nesse caso, todo o pipeline é considerado o manipulador de serviços, com o primeiro trabalhador recebendo a solicitação e o último trabalhador enviando a resposta. O fluxo de dados entre os trabalhadores é feito pela comunicação entre processos.

(d) Como o lote dinâmico é ativado neste exemplo, o método forward receberá uma lista de string, por exemplo, ['a cute cat playing with a red ball', 'a man sitting in front of a computer', ...] , agregado de diferentes clientes para inferência em lote , melhorando o título do sistema.

Finalmente, anexamos o trabalhador ao servidor para construir um fluxo de trabalho de estágio único (vários estágios podem ser pipelados para aumentar ainda mais a taxa de transferência, consulte este exemplo) e especificamos o número de processos que queremos que ele seja executado em paralelo ( num=1 ) e o tamanho máximo de lotes ( max_batch_size=4 , o max_wait_time=10 Em milissegundos, o que significa o mais tempo que Mosec espera até enviar o lote para o trabalhador).

 if __name__ == "__main__" :
    server = Server ()
    # 1) `num` specifies the number of processes that will be spawned to run in parallel.
    # 2) By configuring the `max_batch_size` with the value > 1, the input data in your
    # `forward` function will be a list (batch); otherwise, it's a single item.
    server . append_worker ( StableDiffusion , num = 1 , max_batch_size = 4 , max_wait_time = 10 )
    server . run ()

Execute o servidor

Clique em mim para ver como executar e consultar o servidor.

Os trechos acima são mesclados em nosso arquivo de exemplo. Você pode ser executado diretamente no nível da raiz do projeto. Primeiro, damos os argumentos da linha de comando (explicações aqui):

python examples/stable_diffusion/server.py --help

Então vamos iniciar o servidor com logs de depuração:

python examples/stable_diffusion/server.py --log-level debug --timeout 30000

Abra http://127.0.0.1:8000/openapi/swagger/ no seu navegador para obter o documento Openapi.

E em outro terminal, teste -o:

python examples/stable_diffusion/client.py --prompt " a cute cat playing with a red ball " --output cat.jpg --port 8000

Você receberá uma imagem chamada "Cat.jpg" no diretório atual.

Você pode verificar as métricas:

curl http://127.0.0.1:8000/metrics

É isso! Você acabou de hospedar seu modelo de difusão estável como um serviço!

Exemplos

Exemplos mais prontos para uso podem ser encontrados na seção Exemplo. Inclui:

• Oleoduto: uma demonstração simples de eco, mesmo sem qualquer modelo de ML.
• Validação de solicitação: Validar a solicitação com anotação de tipo e gerar documentação do OpenAPI.
• Rota múltipla: sirva vários modelos em um serviço
• Serviço de incorporação: Serviço de incorporação compatível com o OpenAI
• Serviço de reranquilha: Rerrank uma lista de passagens com base em uma consulta
• Memória compartilhada IPC: comunicação entre processos com memória compartilhada.
• Alocação de GPU personalizada: implante várias réplicas, cada uma usando GPUs diferentes.
• Métricas personalizadas: grave suas próprias métricas para monitoramento.
• Jax inferência: a compilação just-in-time acelera a inferência.
• Compressão: ative a compactação de solicitação/resposta.
• Modelos de aprendizado profundo de Pytorch:
  • Análise de sentimentos: inferir o sentimento de uma frase.
  • Reconhecimento da imagem: categoriza uma determinada imagem.
  • Difusão estável: Gere imagens com base em textos, com serialização do msgpack.

Configuração

• Lote dinâmico
  • max_batch_size e max_wait_time (millisecond) são configurados quando você chama append_worker .
  • Verifique se a inferência no valor max_batch_size não causará a falta de memória na GPU.
  • Normalmente, max_wait_time deve ser menor que o tempo de inferência em lote.
  • Se ativado, ele coletará um lote quando o número de solicitações acumuladas chegar max_batch_size ou quando max_wait_time tiver decorrido. O serviço se beneficiará desse recurso quando o tráfego estiver alto.
• Verifique os argumentos DOC para outras configurações.

Implantação

• Se você está procurando uma imagem base da GPU com mosec instalado, pode verificar a imagem oficial mosecorg/mosec . Para o caso de uso complexo, consulte o ENVD.
• Esse serviço não precisa de Gunheira ou Nginx, mas você certamente pode usar o controlador de entrada quando necessário.
• Este serviço deve ser o processo PID 1 no contêiner, pois controla vários processos. Se você precisar executar vários processos em um contêiner, precisará de um supervisor. Você pode escolher supervisor ou Horust.
• Lembre -se de coletar as métricas .
  • mosec_service_batch_size_bucket mostra a distribuição do tamanho do lote.
  • mosec_service_batch_duration_second_bucket mostra a duração do lote dinâmico para cada conexão em cada estágio (começa com o recebimento da primeira tarefa).
  • mosec_service_process_duration_second_bucket mostra a duração do processamento para cada conexão em cada estágio (incluindo o tempo do IPC, mas excluindo o mosec_service_batch_duration_second_bucket ).
  • mosec_service_remaining_task mostra o número de tarefas atualmente de processamento.
  • mosec_service_throughput mostra a taxa de transferência de serviço.
• Pare o serviço com SIGINT ( CTRL+C ) ou SIGTERM ( kill {PID} ), pois possui a lógica de desligamento graciosa.

Ajuste de desempenho

• Descubra o melhor max_batch_size e max_wait_time para o seu serviço de inferência. As métricas mostrarão os histogramas do tamanho real do lote e da duração do lote. Essas são as informações principais para ajustar esses dois parâmetros.
• Tente dividir todo o processo de inferência em etapas separadas da CPU e da GPU (Ref destilbert). Diferentes estágios serão executados em um pipeline de dados, que manterá a GPU ocupada.
• Você também pode ajustar o número de trabalhadores em cada estágio. Por exemplo, se o seu pipeline consistir em um estágio da CPU para pré-processamento e um estágio de GPU para inferência do modelo, aumentar o número de trabalhadores do estágio da CPU pode ajudar a produzir mais dados a serem lutados para a inferência do modelo no estágio da GPU; Aumentar os trabalhadores do estágio GPU pode utilizar completamente a memória da GPU e o poder de computação. Ambas as maneiras podem contribuir para uma maior utilização da GPU, o que consequentemente resulta em maior taxa de transferência de serviço.
• Para serviços de vários estágios, observe que os dados que passam por diferentes estágios serão serializados/desserializados pelos métodos serialize_ipc/deserialize_ipc , para que dados extremamente grandes possam tornar todo o pipeline lento. Os dados serializados são passados ​​para o próximo estágio através da ferrugem por padrão, você pode permitir que a memória compartilhada reduza a latência (ref RedissHMipcMixin).
• Você deve escolher os métodos serialize/deserialize adequados, que são usados ​​para decodificar a solicitação do usuário e codificar a resposta. Por padrão, ambos estão usando o JSON. No entanto, imagens e incorporações não são bem suportadas pelo JSON. Você pode escolher o MSGPACK, que é mais rápido e compatível binário (refusão estável de ref).
• Configure os threads para OpenBlas ou MKL. Pode não ser capaz de escolher as CPUs mais adequadas usadas pelo processo python atual. Você pode configurá -lo para cada trabalhador usando a alocação ENV (Ref Custom GPU).
• Ativar HTTP/2 do lado do cliente. mosec se adapta automaticamente ao protocolo do usuário (por exemplo, http/2) desde a v0.8.8.

Adotantes

Aqui estão algumas das empresas e usuários individuais que estão usando o MOSEC:

• ModelZ: plataforma sem servidor para inferência de ML.
• Moss: Um modelo de idioma de conversação aberto como ChatGpt.
• TencentCloud: Tencent Cloud Machine Learning Platform, usando o MOSEC como a estrutura do Core Inference Server.
• TensorChord: Empresa de infraestrutura de IA nativa em nuvem.
• OAT: Servindo modelos de recompensa para o alinhamento online LLM.

Citação

Se você achar este software útil para sua pesquisa, considere citar

 @software{yang2021mosec,
  title = {{MOSEC: Model Serving made Efficient in the Cloud}},
  author = {Yang, Keming and Liu, Zichen and Cheng, Philip},
  url = {https://github.com/mosecorg/mosec},
  year = {2021}
}

Contribuindo

Congratulamo -nos com qualquer tipo de contribuição. Por favor, dê -nos feedback levantando questões ou discutindo sobre a discórdia. Você também pode contribuir diretamente com o seu código e puxar a solicitação!

Para começar a se desenvolver, você pode usar o ENVD para criar um ambiente de Python & Rust isolado e limpo. Verifique o Envd-Docs ou Build.envd para obter mais informações.