O que faz um runtime de IA local carregar cópias duplicadas de um modelo?
As cópias duplicadas do modelo surgem quando processos, réplicas, sessões ou contextos de dispositivos separados não conseguem partilhar uma única alocação de pesos carregada.
Um servidor de IA doméstico pode apresentar aproximadamente o dobro da RAM ou VRAM esperada depois de adicionar uma interface Web, um trabalhador em segundo plano, um serviço de voz, um indexador de documentos ou um segundo endpoint de API. O ficheiro do modelo em disco pode continuar a ser único, enquanto vários objetos de execução mantêm pesos independentes, tensores convertidos, kernels pré-empacotados, caches e contextos de dispositivos. Algumas duplicações são acidentais; outras são réplicas deliberadas, criadas para permitir concorrência, isolamento ou execução paralela.
Um Único Ficheiro de Modelo Pode Produzir Vários Objetos de Execução Independentes
Carregar a partir do mesmo caminho não significa que duas aplicações façam referência ao mesmo modelo em memória. Cada instância de execução pode analisar o checkpoint e alocar os seus próprios tensores.
As orientações do Google Cloud para inferência distinguem configurações que carregam uma cópia do modelo por processo ou por máquina virtual.
Se a utilização de memória aumentar em incrementos do tamanho do modelo à medida que aumenta o número de trabalhadores, a principal causa é a replicação de instâncias. Aumentos menores apontam mais fortemente para caches por trabalhador, alocadores ou contextos de execução.
Os Servidores Web e os Trabalhadores de Tarefas Iniciam Frequentemente Processos Separados
Um servidor frontend, um consumidor de filas, um agendador, um serviço de transcrição e um trabalhador de RAG podem importar cada um o carregador do modelo, mesmo pertencendo à mesma stack do Compose.
O isolamento entre processos dá a cada serviço o seu próprio espaço de endereçamento. As páginas de CPU podem, por vezes, ser partilhadas através de mecanismos do sistema operativo, mas os objetos normais das frameworks e as alocações da GPU não constituem automaticamente um único serviço de modelo partilhado.
A duplicação segue os IDs dos processos e os limites dos serviços. Se parar um contentor libertar aproximadamente uma cópia do modelo, o contentor não estava simplesmente a encaminhar pedidos para um runtime central.
As Réplicas de Serviço São Cópias Individuais por Conceção
Os sistemas de escalabilidade automática aumentam o débito iniciando mais réplicas. Uma réplica é um trabalhador independente, capaz de processar pedidos quando os outros trabalhadores estão ocupados.
O Ray Serve define as réplicas como cópias individuais executadas em processos de atores separados.
O crescimento da memória que acompanha picos de tráfego ou eventos do escalador automático é uma replicação intencional, não uma fuga de memória. A causa é o modelo de concorrência escolhido, mesmo que as réplicas adicionais demorem a ser reduzidas posteriormente.
Várias Sessões de Inferência Podem Duplicar Inicializadores e Pesos Pré-empacotados
Uma aplicação pode criar várias sessões dentro do mesmo processo para diferentes threads, endpoints, perfis ou fornecedores de execução.
A documentação do ONNX Runtime explica como partilhar alocadores, inicializadores e pesos pré-empacotados entre sessões, porque sessões separadas acrescentam, caso contrário, sobrecarga de memória.
Se um processo possuir vários objetos de sessão e a memória aumentar quando cada sessão é inicializada, o estado duplicado existe dentro da aplicação, e não entre contentores.
Fazer Fork Não Garante Pesos do Acelerador Partilhados
Um processo principal pode carregar um modelo antes de criar trabalhadores e parecer partilhar páginas de CPU através da cópia na escrita. A inicialização do acelerador e o estado mutável do runtime complicam essa suposição.
As orientações de multiprocessamento do PyTorch explicam que os tensores podem utilizar mecanismos de memória partilhada entre processos, mas a partilha exige uma conceção compatível e explícita.
Um trabalhador que mova o modelo para a GPU, altere os pesos, crie uma cache ou inicialize depois do spawn pode alocar uma nova cópia, mesmo que as páginas do checkpoint original na CPU tenham sido partilhadas.
Contextos CUDA Separados Acrescentam Estado de Dispositivo por Processo
Dois processos que utilizem uma GPU operam normalmente através de contextos CUDA distintos, exceto quando é utilizada uma arquitetura especial de partilha.
A NVIDIA indica que vários processos de aplicações CUDA geralmente criam vários contextos com sobrecarga de memória.
A sobrecarga do contexto não constitui, por si só, um segundo modelo completo, mas pode acompanhar a duplicação de pesos, kernels, espaços de trabalho e caches. Por isso, aumentos de memória inferiores ao tamanho do checkpoint podem ainda resultar da duplicação entre processos.
Duas Instâncias de Runtime na Mesma GPU Reservam Memória de Forma Independente
Um painel pode iniciar um servidor de modelos enquanto um serviço de automatização inicia outro, apontando ambos para o mesmo checkpoint e dispositivo.
A documentação do vLLM indica que a utilização da memória da GPU é um limite por instância e apresenta o exemplo de duas instâncias dividirem a capacidade de uma GPU.
Se cada endpoint tiver o seu próprio listener, registos, agendador e cache KV, os dois processos são motores de inferência independentes. Um diretório de modelos partilhado evita transferências duplicadas, mas não evita alocações duplicadas durante a execução.
Os Recarregamentos Podem Deixar um Processo Antigo Ativo ao Lado do Novo
Os recarregadores automáticos, supervisores, atualizações contínuas, encerramentos falhados e reinícios por verificações de estado podem iniciar uma substituição antes de o trabalhador antigo libertar o modelo.
Esta causa manifesta-se como um par temporário ou persistente de processos quase idênticos, com horas de início diferentes. Os pedidos podem chegar apenas ao processo mais recente, enquanto o antigo continua a manter RAM ou VRAM ocupada.
O artigo da ZimaSpace sobre por que motivo deve separar o estado do runtime de IA dos ficheiros do modelo estabelece a distinção: uma única cache de checkpoints pode servir várias implementações, mas a topologia do serviço continua a determinar quantas cópias carregadas existem.
FAQ
Um único ficheiro de modelo em disco significa que só existe uma cópia na RAM?
Não. Vários processos ou sessões podem ler independentemente o mesmo ficheiro e alocar os seus próprios tensores, caches e estado de execução.
Cada cópia adicional é uma fuga de memória?
Não. As réplicas, os trabalhadores de paralelismo de tensores, os runtimes de fallback e os serviços isolados podem alocar deliberadamente estado adicional. Uma fuga cresce sem um objeto de runtime ativo correspondente.
Os contentores podem partilhar automaticamente um modelo na mesma GPU?
Não. Os contentores podem aceder ao mesmo dispositivo e aos mesmos ficheiros, mas precisam de um processo de serviço partilhado ou de uma conceção explícita entre processos para reutilizar uma única alocação de modelo carregada.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Que funcionalidades permitem criar um limite de confiança de IA doméstico em torno de ficheiros sensíveis?
Uma fronteira de confiança para IA doméstica combina encriptação em repouso, permissões de privilégio mínimo, sandboxing em tempo de execução e recuperação com âmbito...
O que faz com que os resultados de pesquisa privada favoreçam ficheiros editados com frequência?
Os ficheiros editados frequentemente obtêm vantagens no posicionamento quando cada atualização acrescenta sinais de atualidade, fragmentos, versões ou interação, sem normalização por fonte.
O que faz com que os modelos de presença de casas inteligentes confundam visitantes com residentes?
Os visitantes podem parecer residentes quando o sistema observa padrões de atividade doméstica, mas não dispõe de um sinal de identidade estável da pessoa...
