Kan Immich een GPU of accelerator delen met een andere container?

Ja, Immich kan een GPU of accelerator delen met een andere container wanneer de runtime van de host gelijktijdige toegang toestaat en beide workloads binnen de praktische limieten van het apparaat blijven.

Het delen van het apparaat garandeert geen isolatie of gelijke prestaties. Immich kan hardwareversnelling gebruiken voor videocodering of machine-learninginferentie, terwijl een andere service media codeert, AI-inferentie uitvoert of hetzelfde renderknooppunt gebruikt. Stel het apparaat bewust beschikbaar, test elke workload afzonderlijk en voer daarna de werkelijke overlap uit. Let daarbij op geheugen-, latent en temperatuurproblemen en op driverfouten.

Bewijs eerst dat elke container de accelerator afzonderlijk kan gebruiken

Controleer voordat je het delen test de hostdriver en container-runtime met één workload tegelijk. Activeer voor Immich de versnelde functie die je daadwerkelijk wilt gebruiken en controleer het apparaatgebruik en duidelijke applicatielogs. Herhaal dit met de tweede container en diens normale workload.

Het voorbeeld van de NVIDIA-container-runtime voor meerdere GPU-geactiveerde containers laat zien dat meerdere containers kunnen worden gestart met GPU-toegang. Dat bewijst het runtime-model, maar niet dat elk paar applicaties eerlijk kan delen of op één apparaat past.

Als een van beide applicaties de accelerator afzonderlijk niet betrouwbaar kan gebruiken, onderzoek dan nog geen gelijktijdigheid. Los eerst problemen met de driverversie, apparaattoewijzing, rechten, runtimeconfiguratie, codec-ondersteuning of applicatiebackend op. Een gedeelde test kan die basisproblemen niet onderscheiden van daadwerkelijke concurrentie.

Stel alleen het apparaat beschikbaar dat elke workload nodig heeft

Wijs op systemen met meerdere accelerators indien mogelijk een specifiek apparaat toe in plaats van elke container toegang tot alle GPU's te geven. Controleer bij geïntegreerde Intel- of AMD-graphics het bedoelde renderapparaat en de groepsrechten. Controleer bij NVIDIA welk zichtbaar apparaat het proces daadwerkelijk selecteert.

Een recent antwoord op het NVIDIA-forum over één GPU delen tussen containers merkt op dat gewone containerprocessen toegang kunnen krijgen tot dezelfde GPU wanneer die aan beide containers wordt blootgesteld. Het belangrijke operationele punt is dat containergrenzen niet automatisch een vaste prestatieverdeling creëren.

De zichtbaarheid van apparaten moet na het opnieuw maken van containers reproduceerbaar zijn. Start elke service opnieuw en controleer of hetzelfde apparaat met dezelfde rechten verschijnt. Als een applicatie na een herstart stilletjes terugvalt op de CPU, los dan de toewijzing op voordat je gedeelde prestaties meet.

Meet concurrentie in de workloads die daadwerkelijk overlappen

Voer Immich afzonderlijk uit en noteer de verwerkingssnelheid, interactieve reactietijd, GPU-gebruik, apparaatgeheugen, terugval naar de CPU en temperatuur. Voer de andere container afzonderlijk uit met dezelfde metingen. Laat de twee representatieve taken daarna overlappen en vergelijk de verandering in plaats van te vertrouwen op de theoretische piekdoorvoer.

Een recentere NVIDIA-discussie over GPU-deelgedrag tussen containers vraagt of twee containers dezelfde apparaten kunnen selecteren en met elkaar kunnen concurreren. Dat is precies de grens die je moet testen: gedeelde zichtbaarheid betekent gedeelde toegang, geen automatische toegangscontrole of gegarandeerde capaciteit.

Accepteer het delen wanneer beide workloads versneld blijven werken, correct worden voltooid en binnen je latentie- en temperatuurdoelen blijven. Als één taak het VRAM uitput, de andere naar de CPU dwingt, fouten bij encoderallocatie veroorzaakt of zichtbare haperingen oplevert, verlaag dan de gelijktijdigheid, plan zware taken apart of wijs afzonderlijke apparaten toe.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Scheid transcoderingsbelasting van machine-learningbelasting

Immich kan een accelerator verschillend belasten afhankelijk van de vraag of het video codeert of machine-learninginferentie uitvoert. De andere container kan encodeerengines, rekeneenheden of gedeeld geheugen ook anders gebruiken. Totaal “GPU-gebruik” kan verbergen welke engine daadwerkelijk verzadigd is.

De ZimaSpace-gids over GPU-validatie tussen gedeelde containers biedt een nuttig testpatroon voor thuisservers: bevestig eerst de driver en toewijzing en verhoog daarna stapsgewijs het aantal representatieve gelijktijdige sessies terwijl je apparaatgeheugen, temperatuur, fouten en terugvalgedrag controleert.

Als videocodering en ML zelden overlappen, kan plannen eenvoudiger zijn dan hardwarepartitionering. Als beide de hele dag latentiegevoelig zijn, kunnen een tweede accelerator of een afzonderlijke host een duidelijkere foutgrens opleveren. De juiste architectuur hangt af van het overlapvenster, niet alleen van de vraag of Docker beide containers het apparaat laat openen.

Valideer het delen via herstarts en een normale slechtste piek

Stel een reproduceerbare piekbelasting samen, zoals één Immich-videotranscodering plus een batch Smart Search- of gezichtsverwerkings­taken, terwijl de tweede container zijn drukste normale versnelde taak uitvoert. Noteer voltooiingspercentages, staartlatentie, geheugengebruik, temperatuur, fouten en of een van beide services terugvalt op de CPU.

Start de containers in beide volgordes opnieuw en herhaal de test. Een robuuste configuratie mag niet afhangen van welke service de accelerator als eerste claimt, tenzij die prioriteit een bewuste ontwerpkeuze is. Controleer ook of apparaatknooppunten en runtime-toewijzingen stabiel blijven na een herstart van de host.

Blijf delen wanneer de gemeten overlap binnen de servicenormen blijft en er thermische en geheugenruimte over is. Verhoog de gelijktijdigheid niet verder zodra zich de eerste reproduceerbare fout of onaanvaardbare latentie voordoet. Voeg bij escalatie het GPU-model, de driver- en runtimeversies, apparaattoewijzingen, het VRAM-gebruik, de typen workloads en de exacte combinatie die de concurrentie veroorzaakt toe.