Porque é que a fragmentação da memória da GPU pode bloquear um modelo de IA local?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

A fragmentação da memória da GPU pode impedir a execução de um modelo de IA local quando a capacidade livre está dividida em regiões que não conseguem satisfazer o padrão da próxima alocação do runtime.

A falha surge frequentemente depois de mudar de modelo, alterar os comprimentos de contexto, executar cargas de trabalho de imagem e linguagem em conjunto ou processar pedidos cujos tensores temporários aumentam e diminuem. A monitorização pode indicar VRAM não utilizada, mas o alocador continua sem conseguir colocar um espaço de trabalho grande, um fragmento do modelo ou uma expansão da cache KV sem libertar ou reorganizar blocos existentes. As secções abaixo distinguem uma verdadeira falta de capacidade da fragmentação do alocador e explicam por que motivo reiniciar o runtime pode fazer temporariamente com que o mesmo modelo volte a caber.

A VRAM total livre não é o mesmo que espaço de alocação utilizável

Um monitor de memória apresenta a capacidade agregada, mas um alocador tem de satisfazer os pedidos através dos blocos e mapeamentos virtuais que gere. Várias regiões livres pequenas podem, em conjunto, ultrapassar o tamanho solicitado e, ainda assim, permanecer inutilizáveis ao abrigo de uma regra de alocação contígua.

Uma análise de operações de LLM descreve este desfasamento da memória livre quando as caches KV e os tensores de tamanho variável deixam lacunas menores do que o próximo pedido. O erro de falta de memória visível está, por isso, relacionado tanto com a disposição como com o número total de bytes.

Os controladores e as frameworks também podem apresentar de forma diferente a memória livre no dispositivo, reservada, alocada e inativa. Compare a perspetiva do alocador do runtime com a utilização ao nível do dispositivo, em vez de confiar num único número principal.

A alteração dos tamanhos dos tensores cria lacunas ao longo do tempo

As cargas de trabalho de IA alocam e libertam repetidamente tensores de tamanhos diferentes para prompts, lotes, dimensões de imagens, espaços de trabalho de atenção e conversões temporárias. Um alocador com cache mantém os blocos para reutilização, porque devolvê-los repetidamente ao controlador é dispendioso.

A investigação do GMLake mostra que alocações irregulares podem degradar pools de memória baseados na divisão de blocos e criar uma fragmentação significativa em modelos grandes. A reutilização de tamanhos exatos é eficiente; dividir e fundir repetidamente tamanhos incompatíveis é mais difícil.

Um servidor doméstico que alterna entre modelos é especialmente vulnerável, porque os runtimes de linguagem, difusão, visão e voz solicitam formas de blocos muito diferentes à mesma GPU.

A fragmentação pode acumular-se sem uma fuga de memória. Cada alocação pode acabar por ser libertada para o pool, mas a forma do pool pode continuar mal ajustada à próxima carga de trabalho.

O crescimento da cache KV torna dinâmica a fragmentação durante a inferência

Os pesos dos LLM são relativamente estáveis depois de carregados, enquanto a cache KV cresce com o número de utilizadores ativos, o comprimento dos prompts e os tokens gerados. Os pedidos também terminam em momentos diferentes, libertando regiões desiguais.

O PagedAttention foi concebido para reduzir a fragmentação da cache KV, armazenando o estado dos pedidos em blocos mais pequenos em vez de reservar uma única região contígua grande para um comprimento final de sequência desconhecido.

Este problema é diferente da fragmentação no alocador geral de tensores da framework, mas ambos podem coexistir. Um gestor de KV paginada não consegue compactar automaticamente os espaços de trabalho do modelo nem as alocações pertencentes a outro processo.

A discussão da ZimaSpace sobre contextos simultâneos mostra por que motivo um modelo que funciona para um utilizador pode ultrapassar um limite de memória quando várias conversas se expandem em simultâneo.

-15% OFF

A memória reservada pode fazer com que a falha pareça uma fuga

Os alocadores das frameworks retêm frequentemente blocos libertados para acelerar pedidos posteriores. As ferramentas do dispositivo contabilizam esses blocos como utilizados pelo processo, mesmo quando o modelo atual não mantém tensores ativos em todos eles.

Um guia prático sobre erros de falta de memória distingue a memória reservada dos requisitos do modelo ativo e da cache. Uma diferença grande pode indicar blocos reutilizáveis do alocador, fragmentação ou uma carga de trabalho cujo pico foi superior ao estado atual.

Limpar uma cache pode devolver alguns blocos ao controlador, mas não consegue libertar pesos ativos, estado KV em utilização, o contexto de outro processo nem um espaço de trabalho exigido pela operação seguinte.

Formas de alocação estáveis e paginação reduzem falhas repetidas

Reproduza a falha com um único modelo, um limite de contexto fixo, um tamanho de lote fixo e sem serviços de IA concorrentes. Registe a memória alocada e reservada ao nível do processo, a memória livre ao nível do dispositivo, o maior pedido e a sequência de cargas de trabalho que precedeu o erro de falta de memória.

O vAttention utiliza mapeamento de memória virtual para separar o espaço KV virtual contíguo da alocação física. Abordagens semelhantes baseadas em paginação e alocação segmentada reduzem a dependência de uma única região fisicamente contínua.

Para um servidor doméstico, os controlos práticos incluem deixar margem de VRAM, limitar a mudança de modelos, utilizar limites máximos estáveis para o contexto e o lote, coordenar os serviços através de um único runtime e reiniciar um processo fragmentado durante a manutenção, em vez de esperar que um pedido de utilizador falhe.

Se um reinício limpo não fizer com que o modelo caiba, o problema principal é provavelmente a capacidade real, e não a fragmentação acumulada. Reduza o tamanho do modelo, a memória ocupada pela quantização, o contexto, o lote ou as alocações concorrentes.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.