Porque é que os modelos de IA em contentores reiniciam mesmo quando o anfitrião indica memória livre?
Os modelos de IA em contentores podem reiniciar apesar de a memória livre no anfitrião ser suficiente, porque os limites do respetivo cgroup, acelerador ou supervisor são mais restritos do que a visão da RAM de toda a máquina.
Um painel de um servidor doméstico pode mostrar vários gigabytes livres enquanto um contentor de inferência desaparece e regressa com um novo ID de processo. O contentor pode atingir o seu próprio limite de memória, falhar uma verificação de integridade durante a recuperação de memória, esgotar a memória da GPU ou terminar após um erro de alocação. Uma política de reinício transforma então essa falha local num reinício aparentemente espontâneo do modelo.
O contentor tem um limite de memória diferente do anfitrião
Os grupos de controlo do Linux contabilizam e limitam a memória de um grupo de processos selecionado. Um contentor pode atingir memory.max ou um limite do runtime enquanto continua a haver RAM do anfitrião disponível para o kernel, pelo que o valor de memória livre de toda a máquina não descreve o limite de alocação imposto a esse serviço.
Uma explicação detalhada da contabilização de memória do cgroup distingue a memória anónima, os ficheiros mapeados e a cache atribuída a um grupo de controlo. Essa contabilização mostra por que motivo os pesos mapeados do disco, os buffers temporários do modelo e a cache de páginas podem consumir o orçamento de um contentor mesmo quando uma vista simples do RSS do processo parece indicar um valor inferior.
Os limites também podem estar aninhados: um contentor de modelos pode estar dentro de um serviço compose, de um slice do systemd, de uma máquina virtual ou de um grupo de orquestração. O limite ativo mais restritivo pode desencadear recuperação de memória ou uma eliminação por falta de memória antes de o anfitrião físico se aproximar de uma exaustão global.
A pressão da memória pode bloquear as verificações de integridade antes de uma eliminação por falta de memória
À medida que o limite se aproxima, o kernel pode recuperar cache, analisar a memória e limitar as alocações. O modelo pode continuar ativo, mas responder demasiado lentamente para uma sonda de integridade, levando o supervisor a terminá-lo e a iniciar uma substituição sem registar uma eliminação por falta de memória ao nível do contentor.
A estrutura de informações sobre bloqueios causados por pressão mede o tempo perdido porque as tarefas aguardam devido à pressão sobre a memória, a CPU ou a E/S, em vez de depender apenas da utilização. As informações sobre bloqueios causados por pressão explicam por que motivo os bytes livres e a capacidade de resposta do serviço podem divergir durante uma recuperação de memória agressiva.
O carregamento de IA cria picos irregulares: a desserialização pode manter temporariamente os pesos comprimidos e expandidos, a quantização pode alocar espaço de trabalho temporário e os trabalhadores paralelos podem duplicar buffers. Por isso, a utilização estável após o carregamento subestima o pico curto que coincide com a sonda que falhou.
As falhas da GPU e a política de reinício podem parecer falta de memória no anfitrião
As métricas da RAM do anfitrião normalmente excluem a VRAM dedicada. Um modelo pode falhar numa alocação da GPU porque os pesos, a cache KV, os kernels e outra carga de trabalho ocupam o acelerador, terminando depois com um erro da aplicação enquanto o anfitrião continua a indicar uma quantidade abundante de memória do sistema.
As orientações de gestão de recursos distinguem os limites de memória dos contentores de uma escassez de memória ao nível do nó e explicam que os limites são impostos pelo runtime e pelo kernel, e não pelo rótulo de memória livre do painel. O reinício é então determinado pela política de reinício da carga de trabalho, não pela medição da memória em si.
O erro está em presumir que cada novo ID de contentor comprova um evento de falta de memória. Atualizações de imagens, tempos limite de watchdog, novas implementações manuais, reinícios de dispositivos e falhas da aplicação produzem o mesmo sintoma visível. O motivo da saída, o registo do kernel, os eventos do cgroup e os erros da GPU têm de estar de acordo antes de atribuir a causa à memória.
Correlacione o motivo da saída com cada limite de memória
Reproduza um carregamento do modelo enquanto regista, no mesmo relógio, container memory.current, memory.max, memory.events, o RSS do processo e os ficheiros mapeados, MemAvailable do anfitrião, os totais de pressão, a memória da GPU, a latência da sonda de integridade, o código de saída do processo e o número de reinícios do supervisor.
Use a contenção entre contentores como contexto e, em seguida, repita o teste com o mesmo modelo sob um limite de contentor mais elevado, com a política de reinício desativada e sem uma carga de trabalho concorrente no acelerador. Altere apenas um limite por execução, para que um reinício bem-sucedido não oculte a falha original.
Classifique o evento como OOM do cgroup, OOM global, falha de alocação da GPU, terminação pela verificação de integridade ou saída da aplicação antes de alterar os limites. Se o pico for legítimo, mantenha margem de segurança; se uma sonda terminar um modelo saudável que está a recuperar memória, ajuste o tempo da sonda sem ocultar bloqueios reais.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Como afeta a redução da frequência de amostragem de séries temporais a deteção de anomalias em casas inteligentes?
Veja como a largura dos intervalos, a agregação, o anti-aliasing, os dados em falta, a duração dos eventos e a retenção multiescala alteram a...
Como é que uma grelha de ocupação combina sinais fracos de uma casa inteligente?
Saiba como células espaciais, modelos de sensores, atualizações de log-odds, decaimento, evidências correlacionadas e limiares transformam sinais domésticos fracos em estimativas de ocupação.
Como é que a normalização fotométrica afeta o agrupamento privado de rostos?
Veja como a correção da iluminação altera recortes faciais, embeddings, distâncias entre clusters, limiares, sobre-normalização e a avaliação da pesquisa privada de fotografias.
