O que faz com que a memória do servidor de modelos local aumente gradualmente entre pedidos?
A memória do servidor de modelos local costuma aumentar gradualmente porque as caches e os alocadores retêm blocos reutilizáveis, embora referências sem limite ou fugas nativas possam causar um crescimento real.
Após cada pedido ao servidor doméstico, um painel pode mostrar a RAM ou VRAM a aumentar sem regressar ao nível inicial. O runtime pode manter blocos KV, entradas de prefixo, kernels, grafos, áreas de trabalho e blocos de tensores libertados para reutilização. Comprimentos variáveis dos prompts podem fragmentar os pools, enquanto os registos, as sessões, os buffers de imagem ou as extensões retêm objetos indefinidamente, pelo que estes mecanismos exigem evidências e limites diferentes.
Os alocadores de cache reservam blocos libertados para reutilização
As estruturas de GPU evitam alocações dispendiosas no dispositivo mantendo os blocos libertados num pool próprio do processo. Os tensores da aplicação podem já não existir, enquanto o controlador continua a reportar o pool reservado como estando a ser utilizado pelo servidor de modelos. Esta distinção continua visível durante testes domésticos posteriores.
Uma análise do alocador explica como os blocos de memória GPU em cache arredondam, dividem, fundem e colocam blocos CUDA em cache. O padrão característico é a memória dos tensores alocados diminuir depois de um pedido, enquanto a memória reservada permanece elevada e os pedidos seguintes reutilizam-na.
Este patamar não é automaticamente uma fuga. Torna-se prejudicial quando o pool impede outro serviço de alocar memória ou continua a expandir-se após pedidos repetidos com a mesma forma depois do aquecimento. O resultado intermédio tem de permanecer inspecionável antes de a automatização prosseguir.
As caches de disponibilização e as formas dos pedidos expandem o conjunto de trabalho previsto
As caches KV crescem com o contexto ativo, as caches de prefixos retêm prompts reutilizáveis e os grafos ou kernels compilados abrangem as formas de lote observadas. Novos comprimentos de contexto, modalidades e perfis de simultaneidade podem acrescentar entradas entre pedidos. Esse limite deve ser medido separadamente em condições de funcionamento realistas.
A investigação sobre a fragmentação da memória de LLM identifica fragmentação entre os espaços de memória das ativações e da cache KV na disponibilização de LLM. Esta observação explica por que motivo a capacidade total pode aumentar mesmo quando nenhum pedido ativo individual é grande. A consequência prática surge quando várias fontes competem por um contexto limitado.
Registe o número de entradas da cache e as classes de formas. Um crescimento que para quando a distribuição da carga de trabalho estabiliza indica um aquecimento limitado; um crescimento proporcional ao número total de pedidos ou aos IDs de sessão únicos sugere a ausência de expulsão. Esta dependência deve permanecer explícita na interface final.
Objetos CPU retidos e buffers nativos causam um aumento real
Históricos de pedidos, filas de transmissão, etiquetas de métricas, resultados do tokenizador, imagens carregadas, buffers de anfitrião fixados e alocações de extensões podem continuar referenciados após a conclusão. Os instantâneos da GPU podem parecer estáveis enquanto o RSS do processo continua a aumentar. O resultado deve, por isso, ser verificado face às evidências originais.
Uma investigação prática da memória alocada versus reservada separa os sinais de memória alocada, reservada e do processo. Esta visão em camadas evita que um problema de retenção no lado da CPU seja diagnosticado incorretamente como comportamento do alocador da GPU. Esta distinção continua visível durante testes domésticos posteriores.
O limite de falha é um aumento único seguido de um máximo estável. Chame-lhe fuga apenas quando pedidos idênticos controlados produzirem um crescimento contínuo da memória retida depois de contabilizados os limites da cache, a recolha de lixo e os pools esperados.
Crie uma curva de retenção de memória por pedido
Reproduza centenas de pedidos idênticos e, em seguida, comprimentos e modalidades mistos, enquanto regista os bytes alocados e reservados da GPU, as entradas KV e de prefixo, a cache de grafos, a memória fixa, o RSS do processo, as contagens de objetos, as sessões de pedidos, os reinícios dos trabalhadores e os instantâneos do alocador.
Utilize a reserva de memória após o pedido para distinguir a reserva deliberada depois do pedido. Repita o teste com cada cache opcional, extensão, caminho de carregamento e etiqueta de métricas desativados separadamente, mantendo o modelo e a simultaneidade fixos. O resultado intermédio tem de permanecer inspecionável antes de a automatização prosseguir.
Aceite um aquecimento limitado que estabilize dentro do orçamento de memória declarado. Adicione expulsão quando a cardinalidade da cache cresce sem benefícios, normalize as formas dos pedidos quando a fragmentação dominar e isole uma fuga real apenas depois de as pilhas de alocações retidas apontarem para um responsável.
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.
