Escalando o serviço de modelos LoRA ajustados

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
No domínio da implantação de aplicações de IA, escalar a entrega de modelos ajustados surgiu como um desafio crucial. Considere um cenário: você é uma startup SaaS atendendo 500 clientes com necessidades diversas, exigindo adaptações de Modelos de Linguagem (LLM) ajustados para suporte interno e conteúdo de marketing personalizado. Isso implica na tarefa assustadora de ajustar cerca de 1000 modelos.
Para lidar com essas limitações, entra em cena o LoRA Finetuning — uma técnica que envolve congelar o LLM central e refinar seletivamente pesos específicos para acomodar dados atualizados. Essa abordagem, eficiente e escalável, opera com uma fração dos parâmetros originais definidos pela Configuração LoRA.
No entanto, o verdadeiro desafio surge na implantação eficaz desses adaptadores ajustados.
Configuração do Experimento
Numerosos frameworks de entrega de LLM de código aberto estão trabalhando ativamente para incorporar a entrega de adaptadores LoRA, mas uma solução abrangente permanece difícil de ser encontrada. Neste experimento, exploramos LoRAX da Predibase, um framework promissor que parece ter decifrado eficientemente o código para servir e escalar adaptadores LoRA.
💡
Para mais informações sobre o LoRAX da Predibase, consulte o blog deles: LoRAX - Sirva Centenas de LLMs Ajustados pelo Custo de Um
Principais Recursos de LoRAX
O LoRAX se destaca com três pilares fundamentais de implementação:
- Carregamento Dinâmico de Adaptadores: Permite o carregamento just-in-time de pesos LoRA ajustados, garantindo nenhuma interrupção às requisições concorrentes em tempo de execução.
- Cache de Pesos em Camadas: Facilita a troca rápida de adaptadores LoRA entre requisições, prevenindo problemas de falta de memória ao descarregar os pesos dos adaptadores para a CPU e disco.
- Processamento em Lotes Contínuo de Múltiplos Adaptadores: Emprega uma política de agendamento justa para otimizar o rendimento geral do sistema, estendendo estratégias de agrupamento contínuo em múltiplos conjuntos de adaptadores LoRA em paralelo.
Avaliação de Desempenho com LoRAX
Em nosso experimento, avaliamos exaustivamente o desempenho do LoRAX no gerenciamento de uma vasta gama de adaptadores ajustados usando o modelo LLM TinyLlama. Ao longo de nossos experimentos, medimos sua eficiência no processamento de inúmeras requisições em múltiplos adaptadores.
Pré-requisitos para LoRAX Configuração
Para replicar nossos experimentos, siga estes pré-requisitos para configurar o LoRAX em seu servidor:
docker run \
--gpus all \
--shm-size 1g \
-p 8080:80 \
-v $PWD/data:/data \
ghcr.io/predibase/lorax:latest \
--model-id TinyLlama/TinyLlama-1.1B-Chat-v0.6 # modelo base usado para ajuste fino
Além disso, instale o cliente LoRAX para chamadas de inferência usando:
pip install lorax-client
Insights de Inferência
Aproveitar o LoRAX para servir modelos LoRA ajustados proporcionou vantagens distintas devido à sua capacidade de utilizar uma única GPU para o modelo LLM base, enquanto carrega dinamicamente cada adaptador por requisição. Essa abordagem dinâmica — empregando uma única GPU e carregando adaptadores em tempo real — posiciona o LoRAX como uma solução ideal para servir uma infinidade de modelos LoRA ajustados.
Exemplo de Código de Inferência:
from lorax import Client
client = Client("https://example.lorax.truefoundry.tech", timeout=10)
generated_text = client.generate(
prompt,
do_sample=False,
max_new_tokens=10,
adapter_id=adapter_id,
adapter_source="local"
).generated_text
Nossas descobertas experimentais demonstraram conclusivamente os benefícios substanciais de empregar o LoRAX para servir modelos LoRA ajustados. Através do carregamento dinâmico de adaptadores por solicitação e da utilização eficaz de uma única GPU A100 para o modelo LLM base, o LoRAX otimizou notavelmente o desempenho.
Insights de Desempenho
Em nossos experimentos recentes, envolvendo o carregamento dinâmico de 100 adaptadores, examinamos de perto suas características de desempenho. A latência inicial observada durante a primeira solicitação resultou principalmente da necessidade de carregar o modelo LLM base na memória. No entanto, as solicitações subsequentes demonstraram uma redução na latência devido à capacidade do LoRax de trocar adaptadores rapidamente e realizar fusões em tempo real para previsões.

Anteriormente, discutimos o processo de carregamento de modelos Lora ajustados usando HuggingFace PEFT em nossos blogs. No entanto, nossos experimentos destacaram problemas significativos com essa abordagem:
1) Escalada da Latência com o Aumento de Adaptadores na Memória da GPU:
O principal problema surgiu quando tentamos encaixar mais adaptadores na memória da GPU. Isso levou a um aumento notável na latência. Com cada adaptador adicional, a latência experimentou um aumento considerável, impactando assim o desempenho geral.
2) Capacidade Limitada na Memória da GPU:
Outra limitação crítica foi o conjunto finito de adaptadores que poderiam ser acomodados na memória da GPU. Essa restrição dificultou a escalabilidade e representou um gargalo para acomodar um número maior de adaptadores simultaneamente.
Para ilustrar ainda mais as diferenças de desempenho, considere as seguintes comparações:
Processamento de 70 Tokens e Geração de 10 Tokens em uma GPU A100:
HuggingFace PEFT: A latência variou de 400-450 ms.
LoRAX: Demonstrou uma latência média de 170ms.
Impacto dos Adaptadores na Latência:
HuggingFace PEFT: Adicionar 1000 adaptadores Lora tinyllama ao LLM base elevou a latência para 3500-4000ms, marcando um aumento de aproximadamente 700%.
LoRAX: A latência permaneceu consistentemente inalterada pelo número de adaptadores, graças ao seu mecanismo de carregamento dinâmico na GPU, garantindo latência estável mesmo com um número maior de modelos.
Em resumo, enquanto o HuggingFace PEFT facilita a adaptação de modelos e a utilização de adaptadores, ele enfrenta desafios de desempenho à medida que o número de adaptadores aumenta, afetando notavelmente a latência e a escalabilidade. Em contraste, o LoRAX se destaca por sua capacidade de carregar adaptadores dinamicamente e executar previsões em tempo real, garantindo desempenho e escalabilidade consistentes, mesmo com um número substancial de modelos Lora ajustados.
Conclusão
A capacidade do LoRAX em lidar eficientemente com diversos modelos LoRA ajustados, enquanto mantém um modelo base consistente, é promissora para empresas que buscam serviços de IA escaláveis e adaptados às necessidades individuais dos clientes.
Ao aproveitar as estratégias eficientes de carregamento de adaptadores do LoRAX, as empresas podem escalar seus serviços com confiança para abranger milhares de modelos LoRA ajustados e especificamente adaptados, tudo isso enquanto mantêm um modelo base unificado.
Em resumo, o LoRAX surge como um divisor de águas no fornecimento de adaptadores ajustados, oferecendo uma solução escalável e otimizada para empresas que buscam implantar modelos de IA diversos de forma eficaz.
TrueFoundry é uma PaaS de Implantação de ML sobre Kubernetes para acelerar os fluxos de trabalho dos desenvolvedores, ao mesmo tempo que lhes permite total flexibilidade no teste e implantação de modelos, garantindo total segurança e controle para a equipe de Infraestrutura. Através da nossa plataforma, capacitamos as Equipes de Machine Learning a implantar e monitorar modelos em 15 minutos com 100% de confiabilidade, escalabilidade e a capacidade de reverter em segundos - permitindo-lhes economizar custos e lançar Modelos em produção mais rapidamente, possibilitando a realização de valor de negócio real.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI

















.webp)






.webp)

.webp)
.webp)





.png)



