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
O que causa ciclos de reconexão do WebSocket numa interface de IA doméstica remota?
Diagnostique os ciclos de WebSocket nas camadas de handshake, proxy, autenticação, heartbeat, percurso da rede, recuperação de sessão e recuo do cliente.
O que faz com que as somas de verificação das cópias de segurança não coincidam após uma transferência interrompida?
Rastreie discrepâncias nas somas de verificação através de instantâneos de origem, manifestos de blocos, deslocamentos de retoma, ficheiros parciais, transformações, gravações no armazenamento e...
O que causa entidades domésticas duplicadas num grafo de conhecimento privado?
Diagnostique nós duplicados do grafo de conhecimento separando variantes de extração, chaves de identidade, limiares de resolução, linhagem da fonte e fusões concorrentes.
