Como é que o paralelismo de pipeline move as camadas do modelo entre aceleradores de IA domésticos?
O paralelismo em pipeline distribui um modelo por aceleradores de IA domésticos, atribuindo diferentes grupos de camadas a etapas sequenciais em dispositivos distintos e transferindo as ativações entre elas.
Este método é útil quando um modelo profundo é demasiado grande para um único acelerador, mas pode ser dividido em grupos de camadas que caibam em vários dispositivos. Ao contrário do paralelismo tensorial, cada etapa contém camadas completas, em vez de fragmentos da mesma matriz. A principal contrapartida é uma menor permanência dos pesos em cada dispositivo, em troca de transferências de ativações, desequilíbrio entre etapas e períodos de inatividade do pipeline.
O paralelismo em pipeline divide um modelo profundo em etapas sequenciais de camadas
Um transformador tem uma ordem natural: as primeiras camadas transformam a entrada antes de as camadas seguintes poderem ser executadas. O paralelismo em pipeline agrupa secções contíguas dessa profundidade e atribui cada secção a um acelerador diferente.
O runtime de pipelining do PyTorch divide um modelo em partições executadas como etapas sequenciais em dispositivos diferentes. Cada dispositivo armazena apenas os parâmetros da etapa que lhe foi atribuída.
Isto pode reduzir suficientemente a memória do modelo em cada dispositivo para executar um modelo que não caberia numa única GPU doméstica.
As ativações avançam de uma etapa para a seguinte
Depois de a GPU 0 concluir as suas camadas, envia a ativação do estado oculto para a GPU 1. Esse dispositivo aplica o conjunto seguinte de camadas e encaminha outra ativação, até que a etapa final produza logits ou outro resultado do modelo.
O vLLM-Omni descreve o paralelismo em pipeline como a divisão dos blocos do transformador em etapas sequenciais entre GPUs. No percurso básico de propagação para a frente, apenas as ativações nos limites precisam de atravessar as etapas vizinhas.
Ao contrário do paralelismo tensorial, os dispositivos não calculam em conjunto uma matriz dentro da mesma camada. Cada um é responsável por camadas diferentes.
Um único pedido continua a percorrer as etapas pela ordem
Para um token ou microbatch, as etapas seguintes não podem começar até receberem a ativação necessária da etapa anterior. O simples facto de colocar quatro grupos de camadas em quatro GPUs não torna um pedido sequencial quatro vezes mais rápido.
O guia de paralelismo da NVIDIA define o PP como a divisão vertical das camadas do modelo segundo a profundidade. A dependência sequencial ao longo da profundidade mantém-se.
O ganho imediato pode, por isso, ser de capacidade em vez de latência. O débito melhora quando o runtime consegue sobrepor diferentes partes do trabalho entre as etapas.
Os microbatches preenchem o pipeline para que várias etapas trabalhem em simultâneo
Um pipeline torna-se eficiente quando a entrada é dividida em microbatches ou quando vários itens de inferência podem ocupar diferentes etapas em simultâneo. Enquanto a etapa 2 processa um microbatch, a etapa 1 pode iniciar o seguinte.
O guia de paralelismo da Hugging Face explica que a execução em pipeline utiliza microbatches para reduzir o tempo de inatividade do pipeline. O mesmo princípio de utilização aplica-se sempre que um runtime de inferência consegue sobrepor trabalho independente.
A geração interativa de tokens por um único utilizador oferece menos paralelismo natural, porque cada token novo depende do resultado do token anterior. Pedidos agrupados ou tráfego de vários utilizadores podem proporcionar mais oportunidades para manter as etapas ocupadas.
Tempos de etapa desiguais criam bolhas e tornam dominante a etapa mais lenta
Se uma etapa contiver mais camadas, hardware mais lento ou operações especialmente dispendiosas, a etapa seguinte espera pela entrada e a etapa anterior acaba por esperar por espaço. Estes períodos de inatividade são bolhas do pipeline.
O motor de pipeline do DeepSpeed dá ênfase ao particionamento das camadas do modelo em etapas de pipeline. Equilibrar a computação entre etapas é, por isso, tão importante como equilibrar os bytes dos parâmetros.
Uma configuração doméstica com aceleradores mistos pode atribuir intencionalmente menos camadas a uma GPU mais lenta, mas a capacidade de memória, o tamanho das ativações e as transferências suportadas entre dispositivos condicionam essa distribuição.
O paralelismo em pipeline troca capacidade para pesos por transferências de ativações e agendamento
O PP é atraente quando o modelo é profundo e pode ser dividido em grupos de camadas que caibam individualmente nos dispositivos. Comunica ativações nos limites, em vez das operações coletivas frequentes dentro das camadas, típicas do paralelismo tensorial, mas acarreta dependências sequenciais e bolhas.
O guia da ZimaSpace sobre concorrência de IA doméstica para vários utilizadores é relevante porque uma maior quantidade de trabalho simultâneo pode ajudar a preencher um pipeline, ao mesmo tempo que aumenta a pressão sobre a KV e o agendamento.
Meça a memória por etapa, o tempo de execução de cada etapa, o tempo de transferência das ativações, a latência de ponta a ponta, o débito e a percentagem de inatividade dos dispositivos. Uma configuração que permite executar o modelo, mas deixa metade dos aceleradores inativos, pode precisar de uma divisão diferente.
O guia de hardware para IA local da ZimaSpace fornece a referência de capacidade. O paralelismo em pipeline é uma forma de ultrapassar o limite de memória de um único dispositivo, mas o seu sucesso depende mais do equilíbrio entre etapas do que apenas do número de GPUs.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
As câmaras domésticas conseguem sincronizar eventos sem serviços de hora na nuvem?
Uma explicação baseada primeiro no mecanismo do tempo da câmara sem cloud, as suas contrapartidas na partilha de recursos, três perguntas frequentes sobre a...
Um serviço de IA local consegue detetar camadas de modelos corrompidas antes da inferência?
Uma explicação baseada primeiro no mecanismo da deteção de corrupção na camada do modelo, dos seus compromissos em termos de recursos partilhados, de três...
É possível restaurar um sistema RAG sem regenerar todos os embeddings?
Uma explicação, centrada no mecanismo, do restauro de RAG sem re-embedding, das suas contrapartidas em recursos partilhados, de três perguntas frequentes sobre a expansão...
