O Immich pode partilhar uma GPU ou acelerador com outro contentor?

Sim, o Immich pode partilhar uma GPU ou um acelerador com outro contentor quando o runtime do anfitrião permite acesso concorrente e ambas as cargas de trabalho permanecem dentro dos limites práticos do dispositivo.

Partilhar o dispositivo não garante isolamento nem um desempenho equivalente. O Immich pode utilizar aceleração para transcodificação de vídeo ou inferência de aprendizagem automática, enquanto outro serviço codifica multimédia, executa inferência de IA ou utiliza o mesmo nó de renderização. Exponha o dispositivo deliberadamente, teste cada carga de trabalho isoladamente, depois execute a sobreposição real e monitorize falhas de memória, latência, temperatura ou controladores.

Comprove Primeiro Que Cada Contentor Consegue Utilizar o Acelerador Isoladamente

Antes de testar a partilha, verifique o controlador do anfitrião e o runtime dos contentores com uma carga de trabalho de cada vez. No Immich, acione a função acelerada que pretende realmente utilizar e confirme a utilização do dispositivo, bem como registos da aplicação sem erros. Repita o processo com o segundo contentor, utilizando a sua carga de trabalho normal.

O exemplo do runtime de contentores da NVIDIA sobre vários contentores com GPU demonstra que é possível iniciar vários contentores com acesso à GPU. Isso comprova o modelo do runtime, mas não que todos os pares de aplicações partilharão o dispositivo de forma justa ou caberão numa só unidade.

Se alguma das aplicações não conseguir utilizar o acelerador de forma fiável quando executada isoladamente, não diagnostique ainda a concorrência. Corrija primeiro a versão do controlador, o mapeamento do dispositivo, as permissões, a configuração do runtime, o suporte de codecs ou o backend da aplicação. Um teste partilhado não consegue distinguir esses problemas de base da verdadeira contenção.

Exponha Apenas o Dispositivo Necessário a Cada Carga de Trabalho

Em sistemas com vários aceleradores, atribua um dispositivo específico sempre que possível, em vez de expor todas as GPUs a todos os contentores. Em gráficos integrados Intel ou AMD, confirme o dispositivo de renderização pretendido e as permissões do grupo. Na NVIDIA, confirme qual o dispositivo visível que o processo seleciona efetivamente.

Uma resposta recente no fórum da NVIDIA sobre partilhar uma GPU entre contentores refere que processos normais de contentores podem aceder à mesma GPU quando esta é exposta a ambos. O ponto operacional importante é que os limites dos contentores não criam automaticamente uma quota fixa de desempenho.

A visibilidade do dispositivo deve ser reproduzível após a recriação do contentor. Reinicie cada serviço e confirme que o mesmo dispositivo aparece com as mesmas permissões. Se uma aplicação mudar silenciosamente para a CPU após o reinício, corrija o mapeamento antes de medir o desempenho partilhado.

Meça a Contenção nas Cargas de Trabalho Que Realmente se Sobrepõem

Execute o Immich isoladamente e registe a taxa de processamento, o tempo de resposta interativo, a utilização da GPU, a memória do dispositivo, o fallback para a CPU e a temperatura. Execute o outro contentor isoladamente com as mesmas métricas. Depois sobreponha as duas tarefas representativas e compare a alteração, em vez de depender do débito teórico máximo.

Uma discussão mais recente da NVIDIA sobre o comportamento da partilha de GPUs entre contentores questiona se dois contentores podem selecionar os mesmos dispositivos e entrar em contenção. Esse é precisamente o limite que deve testar: a visibilidade significa acesso partilhado, não controlo automático de admissão nem capacidade garantida.

Aceite a partilha quando ambas as cargas de trabalho continuarem aceleradas, concluírem corretamente e permanecerem dentro dos seus objetivos de latência e temperatura. Se uma tarefa esgotar a VRAM, obrigar a outra a utilizar a CPU, provocar falhas de alocação do codificador ou causar bloqueios percetíveis para o utilizador, reduza a simultaneidade, agende as tarefas pesadas para momentos diferentes ou atribua dispositivos separados.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separe a Pressão da Transcodificação da Pressão da Aprendizagem Automática

O Immich pode exercer diferentes tipos de pressão sobre um acelerador, consoante esteja a codificar vídeo ou a executar inferência de aprendizagem automática. O outro contentor também pode utilizar de forma diferente os motores de codificação, as unidades de computação ou a memória partilhada. A “utilização da GPU” total pode ocultar qual o motor que está realmente saturado.

O guia da ZimaSpace sobre a validação da partilha de GPUs entre contentores apresenta um padrão de teste útil para servidores domésticos: confirme primeiro o controlador e o mapeamento, depois aumente o número de sessões concorrentes representativas enquanto observa a memória do dispositivo, a temperatura, os erros e o comportamento de fallback.

Se a transcodificação de vídeo e a aprendizagem automática raramente se sobrepuserem, o agendamento pode ser mais simples do que o particionamento do hardware. Se ambas forem sensíveis à latência durante todo o dia, um segundo acelerador ou um anfitrião separado pode criar um limite de falha mais claro. A arquitetura correta depende da janela de sobreposição, não apenas do facto de o Docker permitir que ambos os contentores abram o dispositivo.

Valide a Partilha Após um Reinício e Durante o Pico Normal Mais Exigente

Crie um pico reproduzível, como uma transcodificação de vídeo do Immich juntamente com um lote de processamento do Smart Search ou relacionado com rostos, enquanto o segundo contentor executa a sua tarefa acelerada normal mais exigente. Registe as taxas de conclusão, a latência de cauda, a utilização de memória, a temperatura, os erros e se algum dos serviços muda para a CPU.

Reinicie os contentores pelas duas ordens e repita o teste. Uma configuração robusta não deve depender do serviço que reclamou primeiro o acelerador, salvo se essa prioridade for uma escolha explícita de conceção. Verifique também se os nós dos dispositivos e as atribuições do runtime permanecem estáveis após o reinício do anfitrião.

Mantenha a partilha quando a sobreposição medida permanecer dentro dos objetivos do serviço, com margem térmica e de memória. Pare de aumentar a simultaneidade ao primeiro erro repetível ou a uma latência inaceitável. Ao pedir assistência, inclua o modelo da GPU, as versões do controlador e do runtime, os mapeamentos dos dispositivos, a utilização de VRAM, os tipos de carga de trabalho e a combinação exata que provoca a contenção.