Como afeta a transferência ponto a ponto PCIe a inferência local com várias GPUs?

A transferência ponto a ponto através de PCIe pode reduzir a sobrecarga da inferência com várias GPUs, movendo tensores diretamente entre memórias de GPUs compatíveis, em vez de os encaminhar através da RAM do sistema anfitrião.

Um modelo local dividido por duas GPUs tem de transferir ativações, blocos KV ou resultados de especialistas sempre que a execução atravessa o limite entre dispositivos. Sem acesso direto entre pares, os dados podem viajar de uma GPU para a memória do anfitrião e depois regressar à outra, consumindo ligações voltadas para a CPU e adicionando cópias. O P2P encurta esse percurso, mas o seu valor depende da topologia, do tamanho da transferência, da sincronização e da frequência com que o modelo comunica.

O acesso entre pares substitui um percurso de cópia através do anfitrião

Com o acesso entre pares ativado, uma GPU pode endereçar ou copiar dados na memória de outra GPU através do caminho de interligação suportado. A transferência evita um buffer de retorno explícito na memória do sistema, paginável ou fixa, e pode reduzir a intervenção da CPU.

O guia de programação CUDA explica que o acesso à memória entre pares tem de ser suportado e ativado entre pares de dispositivos. A capacidade é direcional e depende da topologia, pelo que o software deve consultar cada par, em vez de presumir que todas as GPUs num anfitrião conseguem comunicar diretamente.

O modelo continua a precisar de sincronização para que uma GPU consumidora não leia ativações incompletas. O P2P remove uma etapa de encaminhamento temporário; não elimina os custos de ordenação, lançamento de kernels ou comunicação coletiva. Esta distinção continua visível durante os testes domésticos posteriores.

A topologia PCIe determina a largura de banda real do percurso direto

Duas GPUs sob o mesmo comutador PCIe conseguem muitas vezes trocar tráfego sem atravessar um socket de CPU, enquanto dispositivos ligados a complexos raiz diferentes podem precisar de um percurso através do anfitrião ou perder o suporte P2P. A geração da ligação, a largura de banda, a sobrecarga do comutador e o tráfego simultâneo determinam o limite máximo.

A NCCL documenta que prefere a comunicação direta entre GPUs quando o CUDA identifica GPUs compatíveis, utilizando PCIe ou NVLink de acordo com a topologia disponível. As respetivas ferramentas de topologia mostram se cada par de dispositivos pode utilizar acesso direto através de PCIe. O resultado intermédio deve continuar a ser inspecionável antes de a automatização avançar.

As transferências pequenas podem continuar dominadas pela latência de lançamento e sincronização, enquanto as transferências de tensores grandes se aproximam da largura de banda da ligação. Um pipeline com limites estreitos frequentes pode obter menos benefícios do que um design que comunica menos blocos, mas maiores. Esse limite deve ser medido separadamente em condições de funcionamento realistas.

O particionamento determina se cópias mais rápidas fazem diferença

O paralelismo de tensores comunica dentro de muitas camadas, o paralelismo de pipeline transfere ativações entre limites de etapas e o paralelismo de especialistas troca tokens encaminhados. Assim, a mesma ligação P2P pode ser pouco utilizada ou tornar-se o principal fator limitador, dependendo da estratégia de particionamento.

A discussão da NVIDIA sobre o design GPUDirect mostra como o posicionamento da topologia PCIe e dos comutadores afeta o movimento direto de dados em comparação com os percursos através do anfitrião. O princípio aplica-se mesmo quando as arquiteturas de inferência acrescentam as suas próprias camadas de comunicação coletiva e agendamento. A consequência prática surge quando várias fontes competem por um contexto limitado.

O limite de falha ocorre com uma topologia não suportada, restrições de IOMMU ou virtualização, ou comunicação que já excede o orçamento PCIe. Nesse caso, o software recorre ao encaminhamento através do anfitrião ou sofre contenção na ligação, e adicionar uma segunda GPU pode tornar a inferência mais lenta apesar da maior capacidade de computação.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Meça cada par de GPUs e cada limite do modelo

Mapeie a GPU, o socket da CPU, a raiz PCIe, o comutador, a geração da ligação, a largura, a capacidade P2P e a memória NUMA. Faça testes de cópias entre pares unidirecionais e bidirecionais, bem como de cópias através do anfitrião, utilizando tamanhos de transferência representativos. Esta dependência deve permanecer explícita na interface final.

Ligue o resultado ao posicionamento consciente de NUMA. Analise o tempo de computação, o tempo de comunicação, a sincronização, a largura de banda coletiva, os tokens por segundo e a latência p99 de pedidos para cada partição do modelo, com o P2P ativado e desativado. Por conseguinte, o resultado tem de ser verificado em relação às evidências originais.

Mantenha o plano de várias GPUs apenas quando a latência de ponta a ponta ou a capacidade melhorarem. Se as cópias diretas forem rápidas, mas a inferência continuar limitada pela comunicação, reduza as passagens entre partições ou escolha um posicionamento consciente da topologia, em vez de considerar o suporte P2P suficiente.