Implantação de LLMs em Escala

Implementar Modelos de Linguagem Grandes (LLMs) de código aberto em escala, garantindo confiabilidade, baixa latência e custo-benefício, pode ser um desafio. Com base em nossa vasta experiência na construção de infraestrutura de LLM e sua implantação bem-sucedida para nossos clientes, compilei uma lista dos principais desafios comumente enfrentados por indivíduos neste processo.

Principais Desafios na Implantação de LLMs

Encontrar a maneira ideal de hospedar uma instância do modelo

Existem várias opções de servidores de modelo para hospedar LLMs e diversos parâmetros de configuração para ajustar e obter o melhor desempenho para o seu caso de uso. TGI, VLLM, OpenLLM são alguns dos frameworks mais comuns para hospedar esses LLMs. Você pode encontrar uma análise detalhada neste blog. Para escolher o framework certo para sua hospedagem, é importante comparar o desempenho desses frameworks para o seu caso de uso e escolher aquele que melhor se adapta. Além disso, esses frameworks possuem seus próprios parâmetros ajustáveis que podem ajudar a obter os melhores resultados de benchmark.

Encontrar a frota de GPUs

GPUs são caras e difíceis de encontrar. Existem vários provedores de nuvem de GPU, desde grandes nuvens como AWS, GCP e Azure até provedores de nuvem de pequena escala como Runpod, Fluidstack, Paperspace e Coreweave. Há uma grande variação nos preços e ofertas de cada um desses provedores. A confiabilidade também continua sendo uma preocupação com alguns dos provedores de nuvem de GPU mais recentes.

Manter a confiabilidade

Na prática, isso é mais difícil do que parece. Pela nossa experiência de executar LLMs em produção, você deve estar preparado para bugs estranhos e pontuais em servidores de modelo que podem deixar seu processo travado e todas as requisições expirarem. É muito importante ter gerentes de processo adequados e sondas de prontidão/atividade configuradas para que os servidores de modelo possam se recuperar de falhas ou o tráfego possa ser transferido sem problemas de uma instância não saudável para uma saudável.

Garantir alto throughput com baixa latência

Ao fazer benchmarking, é muito importante descobrir o equilíbrio entre latência e throughput. À medida que aumentamos o número de requisições simultâneas ao modelo, a latência aumentará ligeiramente até certo ponto, após o qual a latência se deteriora drasticamente. Encontrar o equilíbrio correto entre latência, throughput e custo pode ser demorado e propenso a erros. Temos alguns blogs que descrevem esses benchmarks para Llama7B e Llama13B.

Benchmarking Llama-2-70B

This blog captures Llama-2-70B benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Benchmarking Falcon-40B

This blog captures Falcon-40B-Instruct benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Garanta um tempo de inicialização rápido do modelo

Modelos LLM são enormes em tamanho - variando de dezenas a 100GB. Pode levar muito tempo para baixar o modelo assim que o servidor do modelo estiver pronto, e depois para carregá-lo do disco para a memória. É essencial que você armazene o modelo em cache no disco para que não acabemos baixando o modelo novamente caso o processo seja reiniciado. Além disso, para economizar custos de rede, é melhor baixar o modelo uma vez e compartilhar o disco entre várias réplicas, em vez de cada réplica baixar repetidamente o modelo pela internet.

Configurar autoescalonamento

O autoescalonamento é complicado no caso de hospedagem de LLM devido ao alto tempo de inicialização de outra réplica. Se a carga for muito irregular, geralmente precisamos provisionar a infraestrutura de acordo com o pico de réplicas - no entanto, se o pico for esperado em determinados horários do dia, o autoescalonamento baseado em tempo funciona bem.

Como levar LLMs para produção?

1. Comece com o benchmarking do LLM com diferentes servidores de modelo, GPU e parâmetros para ver onde você obtém o melhor desempenho. Idealmente, você deve ter dados de benchmarking semelhantes aos que temos neste blog para Llama7B.
2. Você pode configurar modelos em várias GPUs no Kubernetes ou em instâncias bare metal. Idealmente, recomendamos o Kubernetes porque você obtém todas as verificações de saúde, roteamento e failover gratuitamente.
3. Coloque o modelo em um volume compartilhado como EFS para que os modelos não sejam baixados repetidamente e monte o volume em todos os pods.
4. Configurar monitoramento e alertas nas instâncias.
5. Idealmente, tenha uma camada que possa fazer a contagem de tokens para você em cada requisição, já que é mais fácil entender o padrão de tráfego que chega.
6. Observe o padrão de tráfego e ajuste a política de autoescalonamento de acordo.
7. Mantenha uma combinação de instâncias spot e sob demanda para reduzir custos.

Arquitetura para hospedar LLMs em escala

Começamos com a abordagem anterior, mas logo migramos para a arquitetura apresentada abaixo, que nos permite hospedar LLMs com custos muito baixos e alta confiabilidade.

Basicamente, criamos múltiplos pools de GPU em diferentes provedores de nuvem e em diferentes regiões, e geralmente usamos instâncias spot se for um dos AWS, GCP ou Azure, ou nós sob demanda de provedores de nuvem menores. Também colocamos uma fila no meio que recebe todas as requisições, e os diferentes pools de GPU consomem da fila e retornam a resposta para a fila, de onde a resposta HTTP é retornada ao usuário. Algumas vantagens desta arquitetura:

1. Alta confiabilidade com instâncias spot: Como estamos distribuindo a carga entre instâncias spot de múltiplos provedores de nuvem e regiões, as chances de todas as instâncias spot caírem se tornam extremamente baixas, e cada um dos pools pode crescer para absorver a carga quando um pool cai.
2. A fila adiciona confiabilidade extra sob alta carga: Um serviço HTTP começará a retornar 503s se houver picos repentinos. Por causa da fila no meio, somos capazes de tolerar cargas de trabalho com picos — há um ligeiro aumento na latência para as requisições durante o pico, mas elas não falham. Adicionar a fila no meio adiciona uma latência geral de cerca de 10-20 ms, o que é aceitável para o caso de uso de inferência de LLM, já que a latência geral da inferência é da ordem de segundos.
3. Redução de Custos: Isso ajuda a reduzir drasticamente o custo em comparação com a hospedagem de LLMs em instâncias sob demanda — faremos uma comparação detalhada dos custos abaixo.
4. Análises detalhadas: A camada de gateway LLM nos ajuda a calcular as análises detalhadas sobre as requisições recebidas e também pode calcular a distribuição de tokens entre as requisições. Também podemos começar a registrar as requisições para permitir o ajuste fino (finetuning) posteriormente.
5. Sem dependência de um único provedor de nuvem: Esta arquitetura nos permite trocar facilmente nosso provedor de GPU por outro se encontrarmos um preço melhor em outro lugar, com tempo de inatividade zero. Além disso, caso um provedor caia, os outros pools mantêm o sistema funcionando sem problemas!

Redução de Custos para hospedagem de LLMs

Vamos considerar um cenário de hospedagem de um LLM com 10 requisições por segundo no pico e 7 requisições por segundo em média. Digamos que descobrimos, usando benchmarking, que uma máquina GPU A100 de 80GB pode fazer 0,5 RPS. Vamos também considerar que o tráfego é maior por 12 horas por dia (cerca de 9-10 RPS) e baixo pelas restantes 12 horas do dia (7-8 RPS).

Com base nos dados acima, podemos encontrar o número de máquinas GPU necessárias no período de pico de 12 horas e no período de não pico de 12 horas:

Período de pico de 12 horas: 20 GPUs
Período de não pico de 12 horas: 15 GPU

Vamos comparar o custo de execução do LLM usando Sagemaker, hospedando de forma direta em máquinas sob demanda na AWS, GCP e Azure e usando nossa própria arquitetura com autoescalonamento.

Custo de hospedagem no Sagemaker (região us-east-1):

Custo de máquina de 8 A100 80GB (ml.p4de.24xlarge) -> $47,11 por hora

Precisaremos de 2 máquinas durante horários de menor movimento e 3 máquinas durante horários de pico.

Custo mensal total: $85 mil

Custo de hospedagem diretamente em nós da AWS:

Custo de máquina de 8 A100 80GB (p4de.24xlarge) -> $40,966 por hora

Precisaremos de 2 máquinas durante horários de menor movimento e 3 máquinas durante horários de pico:

Custo mensal total: $73 mil

Custo de hospedagem na Truefoundry

Usando as instâncias spot e outros provedores de GPU, conseguimos reduzir o preço médio da GPU para $2,5 por hora. Assumindo 15 GPUs durante horários de menor movimento e 20 GPUs durante horários de pico, o custo total será:

$2,5 * (15*12 + 20*12) * 30 (dias por mês) = $31 mil

Como podemos ver, conseguimos hospedar o mesmo LLM por quase 30% do preço do Sagemaker com alta confiabilidade. No entanto, demandará esforços para construir e manter esta arquitetura. TrueFoundry pode ajudar a hospedá-lo para você ou hospedá-lo em sua própria conta na nuvem sem complicações, ao mesmo tempo em que economiza custos.