Porque é que um runtime de IA local reserva memória depois de um pedido?
Um runtime de IA local reserva memória após um pedido para que os tensores futuros possam reutilizar blocos do dispositivo sem suportar repetidamente os custos de alocação e sincronização.
O resultado visível pode parecer uma fuga de memória: o uso de GPU cai para zero, a resposta está concluída, mas o processo continua a ocupar a maior parte da memória do acelerador. Parte dessa utilização pode corresponder a pesos do modelo ou ao estado KV ainda ativos, enquanto outra parte pertence a um alocador de memória em cache, ao contexto de execução, à captura de grafos, ao espaço de trabalho de uma biblioteca ou a uma política de manutenção do modelo em memória. As secções abaixo distinguem as alocações ativas das reservas reutilizáveis e mostram quando a memória persistente é normal, desperdiçada ou indício de uma fuga real.
A Alocação no Dispositivo é Suficientemente Dispendiosa para Ser Colocada em Cache
Os tensores criados durante os pedidos são repetidamente criados e libertados. Devolver todos os blocos ao controlador pode introduzir sincronização e obrigar o pedido seguinte a reconstruir a mesma disposição de memória.
O alocador CUDA do PyTorch separa os blocos do alocador em cache dos tensores que continuam ativamente alocados.
Manter blocos livres dentro do processo melhora a latência de pedidos repetidos, mas outro serviço de IA não pode utilizar esses bytes enquanto o alocador não os devolver ao controlador.
Memória Alocada, Reservada e Livre no Dispositivo São Métricas Diferentes
A memória alocada pertence a tensores ativos. A memória reservada é gerida pelo alocador do runtime e pode incluir tanto alocações ativas como blocos reutilizáveis atualmente não utilizados.
Um runtime pode, por isso, apresentar uma diferença de memória reservada mesmo depois de os tensores temporários serem destruídos.
Ferramentas do dispositivo, como o nvidia-smi, apresentam a utilização do processo visível ao controlador, não os blocos que estão logicamente livres dentro da framework.
O Estado do Modelo e do Runtime Pode Permanecer Intencionalmente Ativo
O processo pode manter os pesos do modelo, o estado do tokenizador, os kernels, os grafos de execução e os contextos do acelerador prontos, porque descarregá-los transformaria o pedido seguinte num arranque a frio.
A explicação da ZimaSpace sobre a permanência do modelo em memória mostra por que motivo um serviço ativo consome memória mesmo quando nenhum utilizador está atualmente a gerar tokens.
Trata-se de um compromisso deliberado entre capacidade e latência. Do ponto de vista computacional, a memória está inativa, mas continua a ser valiosa como estado pronto a utilizar.
A Fragmentação Pode Deixar os Blocos Reservados Difíceis de Reutilizar
Um conjunto pode conter bytes não utilizados suficientes no total, mas os tamanhos dos blocos podem não corresponder ao pedido seguinte. Prompts variáveis, dimensões de imagem, lotes e mudanças de modelo podem criar um padrão de reserva fragmentado.
O GMLake estuda a fragmentação do alocador causada por tamanhos de alocação irregulares.
Nesse caso, a memória retida não é ativamente útil nem está disponível para outros processos, e reiniciar o processo pode restaurar temporariamente uma disposição mais organizada.
Meça se a Utilização de Memória Estabiliza ou Continua a Crescer
Execute repetidamente o mesmo pedido fixo e registe a memória alocada, reservada, da cache KV, dos pesos do modelo e livre no dispositivo após cada conclusão.
Um limite máximo estável e elevado sugere um comportamento normal de colocação em cache ou de manutenção ativa. Uma utilização que cresce a cada pedido idêntico e nunca reutiliza os blocos antigos sugere uma fuga de memória, uma cache sem limite, uma sessão retida ou variações na carga de trabalho.
Teste os controlos de libertação da cache apenas depois de confirmar que estado removem. Esvaziar os blocos não utilizados do alocador não descarrega os pesos ativos do modelo, e descarregar o modelo pode prejudicar o tempo de resposta.
Num servidor doméstico com vários serviços, defina um orçamento de memória e uma política de inatividade para cada runtime, para que a reserva de um serviço não impeça silenciosamente outro de arrancar.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Porque é que as previsões da casa inteligente se tornam menos precisas após mudanças sazonais na rotina?
As rotinas sazonais alteram a relação entre o tempo, os sensores, a ocupação e as ações pretendidas, tornando obsoleto um modelo treinado com hábitos...
Porque é que um NVR doméstico não regista eventos breves quando o seguimento de objetos está ativado?
O seguimento precisa de deteções suficientes para iniciar e confirmar uma trajetória, pelo que um objeto que apareça brevemente pode desaparecer antes de o...
Porque é que as etiquetas de fotografias geradas por IA mudam após uma atualização do modelo?
Uma atualização do modelo altera a representação e a classificação utilizadas para atribuir etiquetas, pelo que a mesma fotografia pode ultrapassar diferentes limites semânticos...
