Como é que a localidade NUMA afeta a inferência de IA doméstica com várias GPUs?

A localidade NUMA afeta a inferência quando as threads da CPU, a memória do sistema anfitrião e as GPUs comunicam através de domínios não locais, em vez de permanecerem perto do respetivo caminho PCIe.

Um servidor doméstico de IA com dois sockets pode expor dois grandes pools de RAM e várias GPUs como uma única máquina, mas o acesso não é uniforme. Um worker agendado num socket pode preparar tensores na memória ligada ao outro antes de os transferir para uma GPU sob uma raiz PCIe diferente. O impacto depende da colocação do modelo, do staging no anfitrião, do tráfego de paralelismo de tensores, da topologia de interligação, do batching e de a carga de trabalho estar limitada pelo cálculo ou pelas transferências.

A NUMA Transforma um Único Pool de Memória em Acesso Dependente da Distância

Num sistema NUMA, cada socket da CPU ou domínio de computação tem memória mais próxima de alguns núcleos do que de outros. O software pode endereçar a capacidade combinada, mas um acesso remoto tem de atravessar uma interligação. Esse caminho apresenta normalmente latência e largura de banda disponível diferentes da memória local.

A topologia NUMA também afeta o DMA da GPU, porque as páginas do anfitrião podem estar longe do complexo de raiz PCIe da GPU. O agendamento da CPU e a colocação da memória são decisões separadas, e uma máquina virtual pode não detetar automaticamente a topologia do anfitrião necessária para as alinhar.

O efeito é reduzido quando o tráfego de memória do anfitrião é pouco relevante face ao cálculo da GPU. Aumenta durante o carregamento do modelo, o offload para a CPU, a tokenização, as cópias para buffers fixados, as sincronizações frequentes ou as cargas de trabalho que excedem a VRAM. A capacidade NUMA não garante localidade NUMA.

A Colocação das GPUs Acrescenta uma Segunda Topologia ao Caminho do Modelo

Várias GPUs podem estar ligadas a sockets de CPU, switches PCIe ou partições no encapsulamento diferentes. Um tensor que se desloca entre dois aceleradores pode usar um caminho direto entre pares, uma ligação dedicada da GPU, um switch PCIe ou uma rota que envolva a memória do anfitrião e um salto entre sockets. Estes caminhos não são equivalentes.

Investigação sobre GPUs com várias partições conclui que o acesso não uniforme e a comunicação entre partições podem amplificar a contenção e a latência dos kernels. As estratégias de colocação diferem consoante os dados sejam partilhados globalmente, parcialmente ou apenas dentro de um grupo de trabalho ou partição.

A partição do modelo deve seguir a topologia que transporta o maior volume de tráfego repetido. Camadas adjacentes ou o estado da atenção colocados através de uma fronteira lenta podem comunicar a cada token, enquanto uma divisão com menos comunicação pode tolerar a distância. Contar GPUs sem mapear as respetivas ligações oculta a relação relevante.

O Paralelismo de Tensores Pode Tornar a Localidade num Custo por Token

A inferência com paralelismo de tensores divide as operações dentro de uma camada por várias GPUs e combina os resultados parciais através de operações coletivas. Isto pode permitir acomodar modelos maiores e utilizar mais capacidade de cálculo, mas a comunicação repete-se em muitas camadas e tokens. Assim, um caminho remoto torna-se um custo recorrente, em vez de uma penalização única do carregamento do modelo.

O paralelismo de tensores funciona melhor quando as ligações entre aceleradores e a colocação dos fragmentos suportam a sincronização necessária. Adicionar uma GPU através de uma fronteira NUMA ou PCIe mais fraca pode aumentar a capacidade, proporcionando contudo um ganho de throughput inferior ao que o número de dispositivos sugere.

O paralelismo de dados ou a colocação ao nível dos pedidos pode ser melhor quando os modelos cabem individualmente e os pedidos podem permanecer locais. O paralelismo de tensores torna-se necessário quando um modelo não cabe num único dispositivo, mas o tamanho do batch, a frequência das operações coletivas e a interligação determinam se a capacidade adicional também melhora a velocidade.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

O First-Touch e a Migração de Threads Podem Quebrar uma Disposição Planeada

Os sistemas operativos colocam frequentemente a memória perto da thread que toca primeiro em cada página. Se a inicialização for executada num socket e os workers de inferência forem posteriormente executados noutro, as páginas podem permanecer remotas. A migração efetuada pelo escalonador também pode afastar as threads de preparação da CPU da memória e da GPU que deveriam servir.

A consciência NUMA liga os bancos de memória locais aos sockets da CPU que lhes acedem com maior eficiência. Fixar threads da CPU sem controlar a alocação de memória, ou fixar a memória sem alinhar a GPU, resolve apenas parte do caminho.

Uma disposição estável pode exigir afinidade da CPU, política de memória, atribuição de dispositivos e lançamento de processos consciente da topologia. Os contentores e as máquinas virtuais acrescentam outra camada de mapeamento. O objetivo não é fixar tudo cegamente, mas manter os caminhos de alto volume entre produtores, buffers e consumidores dentro do domínio prático mais próximo.

A Localidade É Mais Importante em Fases Específicas da Inferência

O carregamento do modelo dá prioridade ao movimento do armazenamento para o anfitrião e do anfitrião para a GPU. O prefill processa muitos tokens do prompt e pode utilizar operações matriciais maiores, enquanto o decode avança repetidamente um ou poucos tokens e pode tornar-se sensível à largura de banda da memória, à sincronização e à sobrecarga do lançamento de kernels. Por isso, os efeitos NUMA podem variar dentro do mesmo pedido.

Os efeitos NUMA das GPUs mostram que o agendamento consciente da colocação pode melhorar a atenção, alinhando o trabalho com os domínios de memória e a reutilização da cache. A conclusão é mais limitada do que um ganho universal de velocidade: o benefício surge quando o padrão de partilha do kernel corresponde ao mapeamento consciente da topologia.

Um benchmark que apresente apenas a média de tokens por segundo pode ocultar uma latência elevada até ao primeiro token ou uma escalabilidade fraca num determinado batch. Registe separadamente o tempo de carregamento, o throughput do prefill, a latência entre tokens, o tráfego das ligações das GPUs, os acessos NUMA remotos e a largura de banda da memória da CPU.