Como é que o encaminhamento Mixture-of-Experts altera a computação de modelos locais?
O encaminhamento Mixture-of-Experts altera a computação dos modelos locais ao enviar cada token apenas através de um pequeno subconjunto de redes feed-forward especializadas, em vez de ativar todos os especialistas.
Isto faz com que um modelo MoE de grandes dimensões pareça invulgar num servidor doméstico: o seu checkpoint total pode ser enorme, mas a computação dos especialistas realizada para um token pode assemelhar-se à de um modelo ativo muito mais pequeno. A vantagem está na aritmética esparsa, não numa memória gratuita. Os pesos dos especialistas continuam a precisar de armazenamento, e o encaminhamento entre vários dispositivos pode transformar parte da computação poupada em comunicação.
Um Transformer denso ativa os mesmos parâmetros feed-forward para cada token
Numa camada Transformer densa comum, cada token passa pela mesma rede feed-forward. Por conseguinte, aumentar o número de parâmetros feed-forward aumenta tanto o tamanho do modelo como a quantidade de operações aritméticas realizadas por cada token.
O Switch Transformer contrasta isto com camadas Mixture-of-Experts ativadas de forma esparsa, nas quais diferentes tokens podem selecionar diferentes subconjuntos de parâmetros.
Para a inferência local, isto cria a primeira distinção dos MoE: o total de parâmetros determina quanto estado do modelo tem de ser armazenado, enquanto os parâmetros ativados determinam grande parte da computação dos especialistas por token.
Um encaminhador avalia cada token face aos especialistas disponíveis
Numa camada MoE, um pequeno encaminhador analisa a representação do token e produz pontuações ou probabilidades para os especialistas candidatos. Em seguida, o sistema escolhe um número limitado, normalmente top-1 ou top-k, consoante a arquitetura.
O NVIDIA Megatron Core disponibiliza um encaminhador que determina para que especialistas cada token é enviado. A decisão de encaminhamento altera quais matrizes de especialistas processarão esse token.
Assim, dois tokens no mesmo prompt podem ativar diferentes pesos de especialistas, embora partilhem a atenção e as restantes partes densas do modelo.
A ativação esparsa reduz a computação dos especialistas, mas não o armazenamento total dos pesos
Se uma camada tiver oito especialistas, mas encaminhar cada token para dois, apenas são executadas as computações dos especialistas selecionados para esse token. As restantes matrizes de especialistas ficam inativas durante esse passo.
A investigação Expert Choice descreve os MoE como uma forma de aumentar o número de parâmetros mantendo a computação por token relativamente limitada. É por isso que um checkpoint MoE pode anunciar um número total de parâmetros muito elevado, mas um valor de parâmetros ativos bastante menor.
Um servidor doméstico continua a precisar do conjunto completo de pesos dos especialistas disponível algures, a menos que o sistema os transfira ou descarregue dinamicamente. Computação esparsa não é o mesmo que armazenamento esparso.
A colocação dos especialistas pode transformar o encaminhamento em comunicação entre dispositivos
Numa única GPU, selecionar um especialista altera sobretudo quais blocos de pesos locais são lidos. Em várias GPUs, os especialistas podem estar distribuídos, fazendo com que a representação de um token tenha de ser enviada para o dispositivo que contém o especialista selecionado e depois regressar ao fluxo principal da camada.
O design de inferência MoE do DeepSpeed atribui grupos de especialistas através do paralelismo de especialistas entre GPUs. O encaminhamento passa então a incluir comunicação, além da multiplicação de matrizes.
Um pequeno servidor doméstico com várias GPUs pode, por isso, ficar limitado pela interligação, mesmo quando a aritmética de cada token é esparsa. A topologia PCIe e o suporte ponto a ponto são mais importantes do que o número de parâmetros ativos, por si só, pode fazer supor.
Um encaminhamento desequilibrado cria especialistas sobrecarregados e capacidade inativa
Os prompts reais não distribuem necessariamente os tokens de forma uniforme. Se muitos tokens escolherem o mesmo especialista, esse dispositivo ou kernel torna-se um ponto de congestionamento, enquanto os restantes especialistas aguardam.
O MoETuner identifica o encaminhamento desequilibrado de tokens e a ativação de especialistas como estrangulamentos práticos no serviço, porque alguns dispositivos podem acumular mais trabalho encaminhado e mais comunicação do que outros.
Na inferência local, um encaminhamento desigual pode manifestar-se como uma latência variável por token entre prompts, mesmo quando o comprimento do contexto e o tamanho do modelo são semelhantes. O modelo está a escolher dinamicamente um percurso de computação diferente.
Planeie a capacidade local de MoE separando os pesos totais do percurso ativo
Uma estimativa de hardware útil regista o tamanho total dos pesos do modelo, o número de especialistas ativos por token, o custo das camadas densas, a cache KV, a quantização e se os especialistas estão num único acelerador, em várias GPUs, na RAM do CPU ou no armazenamento.
A discussão da ZimaSpace sobre planeamento da memória e dos aceleradores para IA local fornece o contexto mais abrangente sobre a capacidade de um servidor doméstico. Os MoE acrescentam uma separação adicional entre a capacidade residente e a computação ativa.
Faça benchmarks com prompts de diferentes tarefas, porque os padrões de encaminhamento podem variar. Meça tokens por segundo, utilização por dispositivo, carga dos especialistas, tráfego de comunicação e permanência na memória, em vez de presumir que o número anunciado de parâmetros ativos prevê o comportamento de todo o sistema.
Para checkpoints locais especialmente grandes, a análise da ZimaSpace sobre a implementação de modelos grandes aborda a questão adjacente da capacidade. O encaminhamento altera a computação ativa, mas a permanência dos pesos totais e a sua distribuição entre dispositivos continuam a determinar se o modelo é viável.
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...
