Kan Immich dela ett GPU- eller acceleratorresurser med en annan container?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Can Immich Share a GPU or Accelerator With Another Container? - Zima Store Online

Ja, Immich kan dela en GPU eller accelerator med en annan container när värdkörmiljön tillåter samtidig åtkomst och båda arbetsbelastningarna håller sig inom enhetens praktiska gränser.

Att dela enheten garanterar inte isolering eller jämn prestanda. Immich kan använda acceleration för videotranskodning eller maskininlärningsinferens medan en annan tjänst kodar media, kör AI-inferens eller använder samma renderingsnod. Exponera enheten medvetet, testa varje arbetsbelastning separat och kör sedan den faktiska överlappningen samtidigt som du övervakar minne, latens, temperatur och drivrutinsfel.

Kontrollera först att varje container kan använda acceleratorn separat

Innan du testar delning ska du verifiera värddrivrutinen och containerruntime-miljön med en arbetsbelastning i taget. För Immich ska du utlösa den accelererade funktion du faktiskt tänker använda och bekräfta enhetsanvändning samt rena programloggar. Upprepa sedan med den andra containern och dess normala arbetsbelastning.

NVIDIA:s exempel på containerkörmiljö för flera GPU-aktiverade containrar visar att flera containrar kan startas med GPU-åtkomst. Det bevisar körmodellens funktion, inte att varje kombination av program delar rättvist eller ryms på en och samma enhet.

Om något av programmen inte kan använda acceleratorn tillförlitligt på egen hand ska du inte felsöka samtidighet ännu. Åtgärda först drivrutinsversion, enhetsmappning, behörigheter, runtime-konfiguration, stöd för kodekar eller programmets backend. Ett delningstest kan inte skilja sådana grundproblem från faktisk konkurrens om resurser.

Exponera endast den enhet som varje arbetsbelastning behöver

På system med flera acceleratorer ska du om möjligt tilldela en specifik enhet i stället för att exponera alla GPU:er för varje container. För integrerad Intel- eller AMD-grafik ska du verifiera avsedd renderingsenhet och gruppbehörigheter. För NVIDIA ska du bekräfta vilken synlig enhet processen faktiskt väljer.

Ett aktuellt NVIDIA-foruminlägg om att dela en GPU mellan containrar påpekar att vanliga containerprocesser kan komma åt samma GPU när den exponeras för båda. Den viktiga operativa poängen är att containergränser inte automatiskt skapar en fast prestandaandel.

Enhetens synlighet ska kunna återskapas efter att containern skapats om. Starta om varje tjänst och bekräfta att samma enhet visas med samma behörigheter. Om ett program tyst växlar tillbaka till CPU efter omstart ska du åtgärda mappningen innan du mäter delad prestanda.

Mät konkurrensen i de arbetsbelastningar som faktiskt överlappar

Kör Immich separat och registrera bearbetningstakt, svarstid för interaktioner, GPU-användning, enhetsminne, CPU-fallback och temperatur. Kör den andra containern separat med samma mätvärden. Överlappa sedan de två representativa jobben och jämför förändringen i stället för att förlita dig på teoretisk maximal genomströmning.

En nyare NVIDIA-diskussion om GPU-delning mellan containrar frågar om två containrar kan välja samma enheter och konkurrera om dem. Det är exakt denna gräns som ska testas: gemensam synlighet innebär delad åtkomst, inte automatisk åtkomstkontroll eller garanterad kapacitet.

Acceptera delning när båda arbetsbelastningarna fortsätter att accelereras, slutförs korrekt och håller sig inom dina mål för latens och temperatur. Om ett jobb tömmer VRAM, tvingar det andra till CPU, orsakar fel vid tilldelning av kodare eller leder till märkbara avbrott ska du minska samtidigheten, schemalägga de tunga jobben vid olika tidpunkter eller tilldela separata enheter.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Skilj på belastning från transkodning och belastning från maskininlärning

Immich kan belasta en accelerator på olika sätt beroende på om tjänsten kodar video eller kör maskininlärningsinferens. Den andra containern kan också använda kodningsmotorer, beräkningsenheter eller delat minne på ett annat sätt. Total ”GPU-användning” kan dölja vilken motor som faktiskt är överbelastad.

ZimaSpace-guiden om validering av delad GPU mellan containrar ger ett användbart testmönster för hemmaservrar: bekräfta drivrutin och mappning först och öka sedan antalet representativa samtidiga sessioner medan du övervakar enhetsminne, temperatur, fel och fallback-beteende.

Om videotranskodning och maskininlärning sällan överlappar kan schemaläggning vara enklare än hårdvarupartitionering. Om båda är latenskänsliga hela dagen kan en andra accelerator eller separat värd ge en tydligare felgräns. Rätt arkitektur beror på överlappningsfönstret, inte bara på om Docker låter båda containrarna öppna enheten.

Validera delningen genom omstarter och en värsta normala belastningstopp

Skapa en upprepningsbar toppbelastning, till exempel en Immich-videotranskodning plus en batch med Smart Search- eller ansiktsrelaterad bearbetning, medan den andra containern utför sin mest krävande normala accelererade uppgift. Registrera slutförandegrad, svanslatens, minnesanvändning, temperatur, fel och om någon av tjänsterna växlar tillbaka till CPU.

Starta om containrarna i båda ordningarna och upprepa testet. En robust konfiguration får inte vara beroende av vilken tjänst som tog acceleratorn först, såvida den prioriteringen inte är ett uttryckligt designval. Kontrollera även att enhetsnoder och runtime-tilldelningar förblir stabila efter en omstart av värden.

Fortsätt dela när den uppmätta överlappningen håller sig inom tjänsternas mål och det finns marginal för temperatur och minne. Sluta öka samtidigheten vid det första återkommande felet eller den första oacceptabla latensen. Vidarebefordra GPU-modell, drivrutins- och runtime-versioner, enhetsmappningar, VRAM-användning, arbetsbelastningstyper och den exakta kombination som orsakar konkurrens.