O que acontece quando os serviços de IA locais competem pela memória do acelerador?
Quando os serviços de IA locais competem pela memória do acelerador, cada runtime reduz a capacidade disponível para outros modelos, pedidos, caches e tensores temporários.
Um servidor doméstico pode executar chat, embeddings, geração de imagens, reconhecimento de voz, conversão de texto em voz, deteção visual e análise de câmaras através de contentores ou processos separados. Os respetivos painéis podem parecer inativos, enquanto os pesos dos modelos e os pools do alocador permanecem residentes na mesma GPU, NPU ou acelerador de memória partilhada. Um novo pedido precisa então de espaço para o estado do prompt, ativações e buffers de saída que a ocupação estática do modelo não revelava. As secções abaixo explicam como os serviços separados transformam a capacidade nominal do acelerador em falhas de admissão e latência instável.
Cada serviço traz mais do que pesos de modelos
Um modelo carregado ocupa memória para os parâmetros, mas a inferência ativa também precisa de bibliotecas de runtime, contextos de execução, áreas de trabalho temporárias, buffers de entrada, ativações e estado específico de cada pedido.
A investigação sobre disponibilização de modelos de linguagem de grande dimensão identifica a memória de cache KV como um limite importante à concorrência, porque cresce com o número de sequências ativas e o comprimento do contexto. Um modelo que funciona quando está inativo pode falhar quando várias solicitações longas ficam ativas.
Os serviços de visão, difusão, voz e embeddings utilizam padrões diferentes de memória temporária. As respetivas alocações máximas podem sobrepor-se, mesmo quando a utilização média permanece baixa.
Os processos separados duplicam o contexto e a sobrecarga do runtime
Executar cada função de IA no seu próprio contentor melhora a separação operacional, mas os processos separados podem criar contextos de acelerador, bibliotecas, pools de alocadores e cópias de componentes partilhados distintos.
Os sistemas com vários modelos estudam a disponibilização de vários modelos porque a colocação ingénua de um serviço por modelo desperdiça memória e capacidade de computação. A colocação coordenada pode partilhar a capacidade de forma mais eficaz do que runtimes independentes que assumem, cada um, o controlo do dispositivo.
Dois serviços que utilizam o mesmo tokenizador, codificador visual ou modelo de linguagem não partilham automaticamente uma única cópia física. A partilha requer suporte do runtime e limites de processo compatíveis.
A penalização da duplicação é mais visível em aceleradores pequenos, onde algumas centenas de megabytes de contexto e sobrecarga das bibliotecas podem determinar se outro modelo consegue iniciar.
Os pools reservados podem ocultar memória dos outros runtimes
As frameworks retêm frequentemente blocos libertados para que os pedidos seguintes evitem alocações dispendiosas no dispositivo e sincronizações. O serviço comunica menos memória alocada ativamente, mas outro processo continua sem poder utilizar o espaço físico reservado.
Sistemas como a multiplexagem estatística tratam a colocação e os padrões de picos como um problema global, em vez de permitirem que cada servidor de modelos reserve recursos para o seu próprio pior caso. Os serviços locais independentes não têm essa visão global, a menos que um orquestrador a imponha.
É por isso que um acelerador pode apresentar baixa utilização de computação e, ainda assim, recusar um novo modelo. A capacidade está ocupada por pesos, blocos reservados ou regiões livres fragmentadas, e não por kernels ativos.
A contenção altera a latência antes de produzir um erro de falta de memória
Um runtime pode reagir à pouca memória reduzindo o tamanho do lote, admitindo menos sequências concorrentes, recalculando o estado expulso, transferindo camadas para a RAM do CPU ou descarregando outro modelo.
O Aegaeon utiliza escalonamento ao nível dos tokens para coordenar vários modelos perante uma procura variável. Um servidor doméstico sem uma coordenação comparável costuma manifestar a escassez através de primeiros tokens mais lentos, pausas, trocas de modelos ou filas imprevisíveis.
O artigo da ZimaSpace sobre concorrência familiar mostra a versão do mesmo limite ao nível dos pedidos: as conversas ativas competem pela memória e pela atenção do escalonador, mesmo quando os testes com um utilizador parecem rápidos.
Uma exceção de falta de memória é apenas o modo de falha final. A instabilidade da latência e a redução do débito surgem frequentemente mais cedo.
A expulsão de modelos troca resposta imediata por capacidade
Descarregar um modelo inativo liberta uma grande região contígua para outro serviço. O pedido seguinte ao serviço expulso tem de recarregar os pesos e reconstruir o estado do runtime, transformando a pressão sobre a memória num atraso de arranque a frio.
O WarmServe explora a colocação consciente de expulsões porque as trocas frequentes prejudicam o tempo até ao primeiro token. Manter todos os modelos aquecidos só é mais rápido quando o acelerador tem memória suficiente para os respetivos estados residentes e ativos combinados.
Para um servidor doméstico, a política útil depende da carga de trabalho. O controlo por voz pode justificar residência permanente, enquanto a geração ocasional de imagens pode aceitar um recarregamento.
Um único gestor de recursos pode impor limites reais de capacidade
Coordene os serviços através de um único servidor de inferência sempre que possível, ou atribua limites explícitos de memória por serviço, visibilidade dos dispositivos, regras de residência dos modelos, limites de concorrência e prioridades.
Trabalhos recentes sobre ballooning de memória mostram por que razão a alocação estática desperdiça capacidade quando a popularidade dos modelos e a carga de pedidos mudam. A partilha dinâmica pode melhorar a utilização, mas requer um sistema que observe todas as cargas de trabalho concorrentes.
Meça os pesos, a memória reservada, as alocações ativas, a cache KV, a concorrência dos pedidos, o comprimento do contexto, o tamanho do lote e a frequência de troca de modelos por serviço. Um total global do dispositivo sem atribuição por serviço não consegue explicar a colisão.
Proteja primeiro os serviços sensíveis à latência, agende embeddings e indexação para janelas de manutenção e deixe margem não alocada para picos temporários. O objetivo não é preencher todos os bytes quando o sistema está inativo; é manter estável a combinação de serviços pretendida perante uma procura simultânea.
FAQ
Porque é que a memória do acelerador está cheia quando a utilização da GPU é baixa?
A utilização de computação mede a execução ativa, enquanto os pesos dos modelos, os contextos, as caches e os blocos reservados pelo alocador podem ocupar memória entre pedidos.
Os contentores conseguem impor automaticamente limites de memória da GPU?
Não de forma fiável em todos os runtimes. A atribuição de dispositivos e o isolamento de processos não garantem que várias frameworks coordenem as suas reservas internas.
Um único servidor de inferência partilhado é sempre melhor?
Não. Pode reduzir a duplicação e melhorar o escalonamento, mas o isolamento dos serviços, a compatibilidade entre frameworks, a segurança, a recuperação de falhas e o suporte dos modelos podem justificar runtimes separados.
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...
