O futuro da inferência sem servidor para grandes modelos de linguagem

Avanços recentes em grandes modelos de linguagem (LLMs), porquê GPT-4 e PaLM, levaram a capacidades transformadoras em tarefas de linguagem originário. Os LLMs estão sendo incorporados em diversas aplicações, porquê chatbots, mecanismos de procura e assistentes de programação. No entanto, servir LLMs em graduação continua a ser um duelo devido aos seus requisitos substanciais de GPU e memória.

As abordagens para superar isso geralmente se enquadram em duas categorias principais:

1. Técnicas de compressão de padrão

Essas técnicas visam reduzir o tamanho do padrão, mantendo a precisão. As abordagens comuns incluem:

• Poda – Remoção de parâmetros redundantes ou menos importantes do padrão. Isso cria um padrão esparso com menos parâmetros.
• Quantização – Usando números de menor precisão porquê int8 ou bfloat16 para simbolizar pesos em vez de fp32 ou fp16. Isso reduz o consumo de memória.
• Destilação de conhecimento – Treinar um padrão menor de “aluno” para imitar um padrão grande de “professor”. O padrão menor é portanto usado para inferência.

2. Realização Seletiva

Em vez de modelos compactados, essas técnicas executam seletivamente unicamente partes do padrão por inferência:

• Ativações esparsas – Ignorando o conta em zero ativações.
• Computação condicional – Executando unicamente determinadas camadas condicionadas à ingressão.

Do lado complementar ao lado do arquiteto de software; para permitir uma implantação mais rápida de LLMs, os pesquisadores propuseram sistemas de inferência sem servidor. Em arquiteturas sem servidor, os LLMs são hospedados em clusters de GPU compartilhados e alocados dinamicamente com base na demanda. Isso permite a utilização eficiente de GPUs e reduz custos para desenvolvedores. Implementações proeminentes incluem Amazon SageMaker, Microsoft Azure ML e opções de código franco porquê KServe.

Apesar da promessa de LLMs sem servidor, os sistemas existentes apresentam altas sobrecargas de latência que degradam a experiência do usuário em aplicações interativas:

1. Downloads caros de pontos de verificação: LLMs ocupam muito espaço de memória, geralmente de gigabytes a terabytes de tamanho. O download de pontos de verificação do armazenamento remoto é demorado, demorando mais de 20 segundos, mesmo com redes otimizadas.
2. Carregamento de ponto de verificação ineficiente: mesmo com armazenamento SSD lugar, o carregamento de pontos de verificação na memória da GPU leva dezenas de segundos devido a fatores porquê desserialização e alocação de tensor. Isto adiciona atrasos significativos além do tempo de inicialização do contêiner.

Para resolver esses problemas, pesquisadores do MIT CSAIL propuseram o ServerlessLLM, um sistema inovador que alcança inferência sem servidor de baixa latência para LLMs. ServerlessLLM aprimora a localidade explorando a capacidade e a largura de orquestra abundantes, porém subutilizadas, no armazenamento de servidor multicamadas para implantação de LLM.

Principais inovações no ServerlessLLM ServerlessLLM incorpora vários designs novos para reduzir o tempo de carregamento do LLM em ambientes sem servidor:

1. Carregamento rápido do ponto de verificação

• Formato de ponto de verificação otimizado para carregamento que permite leitura sequencial rápida e endereçamento eficiente de tensor na memória.
• Pipeline de carregamento de ponto de verificação multicamadas que maximiza a utilização da largura de orquestra na rede, SSDs, DRAM e memória de GPU por meio de técnicas porquê E/S direta, transferência de memória fixada e paralelismo.

2. Transmigração em tempo real para inferência orientada por localidade

• Transmigração baseada em token que transmite unicamente tokens de prompt essenciais pela rede, evitando transferência lenta de snapshots.
• Transmigração em duas fases que permite inferência ininterrupta recalculando de forma assíncrona os estados do cache no servidor de orientação antes de transferir os tokens finais.

3. Alocação de servidores com otimização de latência

• Modelos precisos para prezar os tempos de carregamento dos pontos de verificação de cada classe e os tempos de transmigração de um servidor.
• Agendador com reconhecimento de localidade que seleciona servidores minimizando a latência de inicialização esperada usando os modelos supra.

Essas otimizações permitem que o ServerlessLLM reduza os tempos de carregamento do LLM em 4-8X e os tempos de inicialização ponta a ponta em mais de 25X em verificação com sistemas existentes porquê PyTorch, TensorFlow e KServe.

Vamos nos aprofundar em porquê o ServerlessLLM alcança esses ganhos significativos de desempenho.

Acelerando o carregamento de pontos de verificação

O primeiro grande gargalo resolvido pelo ServerlessLLM é a subida latência de carregamento de pontos de verificação LLM do armazenamento para a memória da GPU.

Para permitir o carregamento rápido do ponto de verificação, o ServerlessLLM apresenta:

1. Formato de ponto de verificação otimizado para carregamento

Os pontos de verificação padrão usados ​​por estruturas porquê PyTorch são projetados para treinamento e depuração de modelos. Mas para inferência sem servidor, os pontos de verificação são somente leitura e acessados ​​repetidamente.

Para otimizar esse uso intenso de leitura, o ServerlessLLM converte os pontos de verificação em um formato com duas propriedades principais:

• Leitura sequencial baseada em blocos: os tensores são agrupados em arquivos binários por GPU, facilitando grandes leituras sequenciais.
• Endereçamento eficiente de tensores: um índice mapeia nomes de tensores para deslocamentos de memória, permitindo restauração direta na memória sem desserialização.

2. Pipeline de carregamento de ponto de verificação multicamadas

ServerlessLLM aproveita a arquitetura em camadas de servidores GPU, com mídias de armazenamento porquê SSDs e rede conectada a GPUs via PCIe, NVMe, etc.

O sistema incorpora um pipeline de vários estágios para maximizar a utilização da largura de orquestra em todas as camadas:

• Os pedaços de dados na memória são alocados usando memória fixada para transferência rápida de GPU.
• A E/S direta é usada para leituras SSD eficientes sem sobrecarga de cache.
• Vários threads leem diferentes blocos de armazenamento em paralelo.
• A coordenação entre estágios ocorre por meio de filas de tarefas assíncronas.

Juntos, isso permite saturar a capacidade de largura de orquestra até mesmo dos níveis mais rápidos, porquê o NVMe RAID. Experimentos revelam que ServerlessLLM atinge carregamento 6 a 8 vezes mais rápido do que PyTorch/TensorFlow, reduzindo o tempo de inicialização para grandes LLMs de mais de um minuto para menos de 10 segundos.

Inferência LLM baseada em localidade por meio de transmigração ao vivo

Com o carregamento veloz, o ServerlessLLM enfrenta um novo duelo: porquê aproveitar pontos de verificação pré-carregados para localidade sem interromper inferências contínuas em servidores ocupados?

ServerlessLLM apresenta uma novidade técnica – transmigração ao vivo de inferência LLM entre servidores GPU. Isso permite transferir perfeitamente a realização para servidores com pontos de verificação locais disponíveis.

Principais facilitadores da transmigração LLM ao vivo:

1. Transmigração baseada em token

Em vez de conquistar todo o estado do padrão, o ServerlessLLM migra unicamente os tokens mínimos de prompt pela rede. Isso transfere muito menos dados do que instantâneos.

2. Transmigração em duas fases

O servidor de orientação pré-calcula de forma assíncrona os estados de cache a partir de tokens de prompt. Quando estiver pronto, o servidor de origem transfere os tokens finais antes de liberar recursos. Isso evita paralisações de inferência.

Experimentos revelam que a transmigração baseada em tokens reduz o tempo de transmigração de dezenas de segundos para menos de um segundo, mesmo para sequências longas. A transmigração em tempo real é crucial para evitar atrasos nas filas ao conseguir a alocação baseada na localidade.

Agendamento de padrão otimizado para latência

Para minimizar a latência ponta a ponta, o ServerlessLLM aprimora o agendador para otimizar a seleção do servidor considerando a localidade. Isso involve:

1. Estimador de tempo de carregamento refinado

Os modelos prevêem tempos de carregamento da rede, caches SSD e memória para cada servidor usando métricas porquê atrasos de fileira, tamanhos de padrão e largura de orquestra medida.

2. Preditor preciso do tempo de transmigração

O planejador estima os tempos de transmigração para servidores usando o número de tokens de prompt e de saída. Ele rastreia o progresso da inferência de forma assíncrona para evitar sobrecarga.

3. Alocação com reconhecimento de localidade

Para cada solicitação de inferência, o agendador avalia os tempos estimados de carregamento e transmigração entre servidores. Ele seleciona o servidor minimizando a latência de inicialização esperada.

O agendador também mantém filas de tarefas do servidor e aproveita um armazenamento fortemente consistente para tolerância a falhas. Juntas, essas inovações reduzem as despesas gerais de agendamento e, ao mesmo tempo, maximizam os benefícios da localidade.

Avaliando o desempenho do ServerlessLLM

Experimentos abrangentes comparam a eficiência ponta a ponta do ServerlessLLM em relação aos sistemas existentes usando modelos do mundo real porquê OPT-175B e cargas de trabalho modeladas a partir de rastreamentos do Azure.

Principais resultados:

• Microbenchmarks: ServerlessLLM acelera o carregamento do ponto de verificação em 3,6-8,2X em PyTorch/TensorFlow. Ele satura totalmente a largura de orquestra de armazenamento, mesmo para RAID NVMe de última geração.
• Agendamento: ServerlessLLM reduz a latência de alocação em 4 a 12 vezes em verificação com o agendamento aleatório, destacando os benefícios do reconhecimento de localidade. A transmigração em tempo real evita atrasos nas filas.
• Atendimento de ponta a ponta: para modelos grandes porquê OPT-30B, o ServerlessLLM melhora a latência do percentil 99 em 28-200X em sistemas porquê KServe e Ray Serve. Também aumenta a eficiência dos recursos.

Esses ganhos substanciais demonstram a capacidade do ServerlessLLM de superar gargalos nas implementações sem servidor existentes e liberar o poder dos LLMs para serviços interativos.

As otimizações introduzidas no ServerlessLLM, porquê carregamento multicamadas, transmigração ao vivo e agendamento fundamentado em latência, podem ajudar a informar o design de futuras arquiteturas sem servidor. A capacidade do sistema de reduzir os tempos de carregamento e inicialização desbloqueia a implantação escalável de grandes modelos de linguagem para aplicações práticas.

Olhando para o Horizonte: Desafios Contínuos

Embora seja um progresso significativo, o ServerlessLLM representa unicamente o primeiro passo na otimização da inferência sem servidor para LLMs massivos. Vários problemas em franco permanecem, incluindo:

• Prever a demanda do padrão em tempo real para orientar o provisionamento e o pré-carregamento
• Colocação inteligente de pontos de verificação nos servidores para maximizar os acessos ao cache
• Dimensionamento eficiente de algoritmos de agendamento para mourejar com clusters maiores
• Prometer justiça na alocação de recursos entre modelos e desenvolvedores
• Generalizando inovações porquê transmigração ao vivo para outras cargas de trabalho sem servidor

Abordar essas áreas pode ajudar a aproveitar a promessa dos LLMs sem servidor e tornar seus recursos ainda mais acessíveis. Além das otimizações ao nível do sistema, a redução da flagrante pegada de carbono e dos potenciais danos dos grandes modelos também continua a ser uma prioridade urgente.

ServerlessLLM demonstra que existe um enorme espaço para inovação em arquiteturas sem servidor de próxima geração para cargas de trabalho de IA. À medida que os LLMs continuam aumentando em tamanho e popularidade, soluções porquê o ServerlessLLM, que liberam sua escalabilidade, terão ainda mais impacto. A confluência de sistemas e pesquisas em estágio de máquina pode introduzir novos paradigmas no fornecimento, compartilhamento e dimensionamento de modelos de IA de forma segura e sustentável.