Mapeamento de ficheiros de modelos na memória: como as páginas partilhadas reduzem a utilização duplicada de RAM
Os ficheiros de modelos mapeados na memória podem reduzir a utilização duplicada de RAM, porque os processos referenciam as mesmas páginas limpas suportadas por ficheiros através da cache de páginas do sistema operativo.
Carregar dois trabalhadores de modelos locais nem sempre exige duas cópias completas do ficheiro de pesos na memória física. Com o mapeamento de memória, cada processo recebe endereços virtuais associados a posições no ficheiro, e as páginas são carregadas a pedido. O sistema operativo pode disponibilizar páginas limpas idênticas a partir de uma única cópia física em cache, mantendo separado o estado de execução privado de cada processo.
O mapeamento de memória associa endereços virtuais a posições no ficheiro
Um ficheiro mapeado aparece no espaço de endereçamento de um processo sem que a aplicação leia o ficheiro inteiro para uma área de memória intermédia separada. O acesso a uma página ausente desencadeia uma falha; o kernel carrega ou encontra a página correspondente suportada pelo ficheiro e atualiza a tabela de páginas do processo.
O manual de mapeamento de memória do Linux documenta os mapeamentos MAP_SHARED e MAP_PRIVATE, bem como a relação entre as atualizações do mapeamento e o objeto subjacente. Os pesos de modelos só de leitura permanecem normalmente como dados limpos suportados por ficheiros, tornando-os elegíveis para reutilização através da cache de páginas. Esta distinção continua a ser importante em condições domésticas realistas de funcionamento.
A paginação a pedido pode acelerar o arranque e limitar a memória residente quando apenas parte de um modelo é utilizada. Também pode transferir o custo para o primeiro acesso, pelo que as falhas de páginas frias e a latência do armazenamento podem ocorrer durante a inferência, em vez de ocorrerem durante uma fase explícita de carregamento.
A cache de páginas pode servir vários processos em simultâneo
Dois processos podem mapear o mesmo inode de modelo e as mesmas posições em diferentes espaços de endereçamento virtuais. Quando ambos leem a mesma página limpa, o kernel pode mapear a mesma página física em cache em ambas as tabelas de páginas. Os mapeamentos virtuais são separados; os dados residentes subjacentes podem ser partilhados.
A documentação do Linux sobre dados de mapeamento de páginas explica como o espaço de utilizador pode inspecionar mapeamentos de páginas e informações sobre frames de páginas, sujeito a restrições de acesso. Estas interfaces ajudam a mostrar se regiões virtuais aparentemente separadas referenciam páginas físicas partilhadas. O estado intermédio deve continuar visível durante diagnósticos e revisões posteriores.
É por isso que somar o RSS de cada processo pode sobrestimar a utilização física total: uma página partilhada aparece como residente em cada processo. O tamanho proporcional do conjunto (PSS) distribui as páginas partilhadas pelos mapeamentos e é normalmente mais útil para estimar a ocupação combinada dos trabalhadores de modelos.
O estado privado e as páginas alteradas continuam a multiplicar-se
As caches KV, as ativações, as áreas do alocador, os buffers do tokenizador e o estado dos pedidos são criados por trabalhador ou por sessão. A escrita através de um mapeamento privado desencadeia a cópia na escrita, criando uma página anónima que já não pode partilhar a cópia limpa suportada pelo ficheiro. Versões diferentes do ficheiro também impedem a reutilização.
O manual smaps do Linux classifica os mapeamentos privados, partilhados, limpos e alterados, bem como o smaps manual para cada mapeamento. Estas categorias explicam por que motivo dois trabalhadores que partilham pesos podem continuar a apresentar um aumento substancial da memória à medida que a simultaneidade e o comprimento do contexto aumentam.
O limite é que o mapeamento reduz a duplicação dos pesos limpos, não a memória total de inferência. Os ficheiros de modelos montados através da rede também podem produzir uma latência de falhas instável, e os carregadores comprimidos ou transformados podem alocar uma segunda representação descompactada que elimina a partilha esperada.
Compare um trabalhador com dois trabalhadores mapeados
Comece com a cache fria, inicie um trabalhador de modelos, execute um prompt fixo e registe o tempo de arranque, as falhas de páginas, o RSS, o PSS e a memória privada alterada. Inicie um segundo trabalhador idêntico e repita o processo sem alterar o ficheiro do modelo nem as opções do carregador.
Relacione o resultado com os compromissos da compressão apresentados em compromissos da compressão: os ficheiros mais pequenos ajudam no armazenamento, enquanto os benefícios do mapeamento dependem da representação efetivamente utilizada na memória. Inspecione cada mapeamento do modelo em smaps, em vez de depender do total de um único processo.
Considere o teste bem-sucedido se o segundo trabalhador acrescentar muito menos memória de pesos do que o primeiro, produzindo simultaneamente o mesmo resultado e uma latência fria aceitável. Se o PSS quase duplicar, verifique a identidade do ficheiro, os mapeamentos graváveis, a descompressão e as cópias ocultas antes de concluir que o mmap é ineficaz.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Que fatores determinam a precisão das citações RAG numa base de conhecimento doméstica?
Saiba por que motivo uma fonte relevante pode ainda assim ser uma citação incorreta, que fases do pipeline controlam o suporte e a cobertura,...
Que funcionalidades permitem obter uma saída JSON fiável de um LLM local?
Veja quais funcionalidades impõem a sintaxe JSON, quais protegem a correção semântica e como testar um modelo local com diferentes esquemas, prompts e casos...
Linhagem de dados de IA local: porque cada resposta precisa de um percurso de origem rastreável
Saiba como os caminhos de origem tornam as respostas locais de IA auditáveis, por que motivo as citações, por si só, são incompletas e...
