Como é que o descarregamento para a CPU mantém modelos de grandes dimensões a funcionar num servidor doméstico?
O descarregamento para a CPU mantém um modelo de grandes dimensões em execução, armazenando parte dos seus pesos na RAM do sistema, em vez de exigir que o modelo completo permaneça na memória do acelerador.
Num servidor de IA doméstico, isto pode transformar um modelo que não consegue ser carregado numa GPU num serviço local utilizável. A troca é direta: a pressão sobre a VRAM diminui, mas a memória da CPU, o tráfego PCIe ou de interligação e, por vezes, a execução na CPU passam a fazer parte do caminho de inferência. O descarregamento é, em primeiro lugar, uma técnica de capacidade e só melhora o desempenho quando a hierarquia de memória é suficientemente rápida.
Um modelo de grandes dimensões falha quando o dispositivo rápido não consegue alojar o estado necessário
Um modelo local precisa de espaço para os pesos, além da cache KV, ativações, buffers temporários e reservas do ambiente de execução. Se o acelerador não conseguir alojar o estado residente necessário, o carregamento pode falhar antes de a inferência útil começar.
O Hugging Face Accelerate trata a inferência de modelos de grandes dimensões como um problema de distribuição dos pesos do modelo pelos níveis de memória disponíveis. O descarregamento para a CPU acrescenta a RAM do sistema como um nível de armazenamento mais lento para o estado do modelo.
O modelo torna-se executável porque uma parte menor tem de permanecer na VRAM ao mesmo tempo, e não porque o acelerador tenha ganho memória física.
Os pesos descarregados permanecem na RAM do sistema até serem necessários pela respetiva camada
Um ambiente de execução pode manter determinados tensores de parâmetros na CPU enquanto a camada ou o grupo de camadas atual está ativo na GPU. À medida que a execução avança, os pesos necessários são transferidos para o acelerador e os antigos podem ser movidos novamente ou removidos da memória do dispositivo.
O DeepSpeed ZeRO-Inference pode manter os pesos do modelo na memória da CPU ou NVMe e transmiti-los camada a camada para a GPU. Isto reduz a ocupação máxima do acelerador, mas faz com que a transferência dos pesos passe a fazer parte da execução.
A colocação das camadas também pode ser estática: algumas permanecem na CPU e são executadas aí, enquanto outras ficam na GPU. Ambas as estratégias trocam a pressão sobre a memória do dispositivo por caminhos de memória e transferência mais lentos.
O caminho PCIe ou de memória unificada passa a fazer parte de cada token
Se os pesos tiverem de atravessar o PCIe durante a execução direta, a latência e a largura de banda da transferência ficam diretamente no caminho crítico da inferência. Um modelo que caiba totalmente na VRAM pode reutilizar os pesos residentes à largura de banda do dispositivo; um modelo descarregado pode ter de obter repetidamente tensores de grandes dimensões.
A documentação do PyTorch aborda a memória do anfitrião fixada e o comportamento das transferências da CPU para a GPU, demonstrando por que motivo o movimento entre anfitrião e dispositivo é um domínio de desempenho separado dos cálculos da GPU.
É por isso que o descarregamento para a CPU pode transformar uma falha por falta de memória num modelo funcional, mas mais lento. A capacidade é resolvida primeiro; o débito pode diminuir acentuadamente.
Mais RAM do sistema aumenta a capacidade, mas não garante velocidade
É necessária RAM suficiente para alojar a parte descarregada, além do sistema operativo, da cache de páginas, dos contentores, das bases de dados e de outros serviços do servidor doméstico. Quando o modelo passa para a memória de troca, uma configuração lenta pode tornar-se impraticável.
O Linux documenta a recuperação de memória e a memória de troca como parte da hierarquia de memória do sistema. Um modelo descarregado compete com todos os outros processos pelo mesmo orçamento de RAM.
Um servidor doméstico que também execute um NAS, um indexador de fotografias e uma base de dados multimédia deve deixar uma margem real, em vez de dimensionar a RAM apenas com base no ficheiro do modelo.
A quantização e o descarregamento resolvem partes diferentes do problema de compatibilidade
A quantização reduz o número de bytes utilizados pelos pesos, o que pode diminuir a ocupação tanto na GPU como na CPU e reduzir o volume de transferências. O descarregamento altera o local onde esses bytes permanecem durante a execução.
O NVIDIA NeMo documenta a quantização pós-treino FP8, INT8 e INT4 para reduzir a memória do modelo. Um modelo quantizado pode caber totalmente na GPU e evitar o descarregamento; um modelo maior pode continuar a precisar de ambas as técnicas.
A sequência correta consiste em decidir primeiro a precisão e a qualidade aceitáveis do modelo e, depois, escolher a colocação. Descarregar uma representação desnecessariamente grande pode desperdiçar largura de banda.
Utilize o descarregamento para a CPU quando executar o modelo for mais importante do que atingir o débito máximo
O caso de utilização mais forte é um modelo local ocasional que excede a VRAM, mas continua a oferecer uma latência aceitável quando parte do seu estado vive na RAM. É menos atrativo para um serviço interativo multiutilizador, em que cada token tem de atravessar repetidamente uma ligação lenta.
O guia da ZimaSpace sobre memória e dimensionamento do acelerador para um NAS de IA é a camada de planeamento: o descarregamento deve ser tratado como uma solução de recurso dentro da carga de trabalho completa do servidor doméstico.
Meça a utilização de VRAM, a utilização de RAM, os bytes transferidos entre o anfitrião e o dispositivo, o tempo até ao primeiro token, os tokens de saída por segundo e o efeito nos outros serviços autoalojados. Uma configuração que carrega tecnicamente o modelo, mas obriga a utilizar memória de troca ou bloqueia o NAS, não é uma solução adequada.
A explicação da ZimaSpace sobre residência e expulsão de modelos aborda o compromisso relacionado: libertar memória do acelerador aumenta a capacidade para outras tarefas, mas pode fazer com que o pedido seguinte volte a pagar o custo do carregamento ou da transferência.
FAQ
O descarregamento para a CPU combina a RAM e a VRAM num único conjunto de memória rápida?
Não. Permite que o ambiente de execução distribua o estado do modelo pelos dois níveis, mas a RAM da CPU e a VRAM da GPU têm larguras de banda e latências diferentes. As transferências entre ambas podem tornar-se o principal estrangulamento da inferência.
Adicionar mais RAM torna um modelo descarregado mais rápido?
Apenas quando o sistema atual tem pouca RAM, está a utilizar paginação ou não consegue manter residente o estado descarregado pretendido. RAM adicional não utilizada não elimina os custos do PCIe nem da execução na CPU.
O descarregamento para SSD é igual ao descarregamento para a CPU?
Não. O descarregamento para disco acrescenta um nível de armazenamento ainda mais lento quando a RAM é insuficiente. Pode aumentar ainda mais a capacidade, mas as páginas do modelo têm de atravessar o armazenamento e, normalmente, a memória do sistema antes da execução no acelerador.
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...
