Kan flera mediecontainrar dela på en GPU utan enhetskonflikter?
Ja, flera mediecontainrar kan dela på en GPU när värddatorns drivrutin och runtime har stöd för samtidig åtkomst och varje container får rätt enhet korrekt.
Containrar äger normalt inte en GPU exklusivt på samma sätt som en virtuell maskin med full passthrough gör. Intel Quick Sync och AMD VA-API exponerar vanligtvis delade renderingsenheter, medan NVIDIA-containrar kan dela på samma drivrutinsstack och GPU, beroende på begränsningar i hårdvara, drivrutin, codec, minne och antal sessioner. Konflikter uppstår när orkestreringen tilldelar enheten exklusivt, behörigheterna skiljer sig åt, containrarna innehåller inkompatibla bibliotek eller samtidiga transkodningar överskrider GPU:ns praktiska kapacitet.
Bekräfta att värddatorn stöder samtidiga GPU-arbetsbelastningar
Installera och verifiera värddatorns drivrutin först och kör sedan en hårdvaruaccelererad transkodning utanför eller inuti en känd fungerande container. Dokumentera GPU-modell, drivrutin, codec för kodning och avkodning som stöds, minne och uppmätt användning.
En diskussion i TrueNAS-communityn rapporterar att flera appar kan dela samma GPU när den exponeras för användning i stället för att tilldelas som en exklusiv programresurs. Skillnaden ligger mellan delad enhetsåtkomst och exklusiv passthrough.
Om en container inte kan använda GPU:n tillförlitligt ska du inte lägga till en till. Åtgärda värddatorns drivrutin, kärnenhet, firmware eller runtime innan du testar samtidig användning.
Exponera rätt enhet för varje container
För Intel och AMD ska du jämföra /dev/dri-kortet och renderingsnoderna som skickas till varje container. För NVIDIA ska du jämföra runtime eller enhetsbegäran, variabler för synliga enheter och drivrutinsfunktioner.
Ett Jellyfin-fall i NixOS beskriver hur samma GPU på värddatorn fungerar olika i olika containrar eftersom operativsystemets och enhetens miljö ändrades. Det visar varför matchande enhetsexponering och bibliotek är viktigare än att kopiera en Compose-rad.
Använd minsta möjliga uppsättning enheter som varje app behöver och undvik privilegierat läge som genväg. Bekräfta att den förväntade renderingsnoden eller NVIDIA-enheten visas inuti varje container efter en ombyggnad.
Matcha behörigheter och användargrupper mellan containrar
Dokumentera den numeriska ägaren och gruppen för renderingsenheten på värddatorn och bekräfta sedan att varje containerprocess har motsvarande kompletterande grupp eller behörighet. Användarnamn som är specifika för avbildningen kan mappas till olika numeriska ID:n.
En container som listar GPU:n men inte kan öppna den kan falla tillbaka till mjukvarutranskodning eller rapportera nekad åtkomst. Felet kan se ut som en enhetskonflikt när den andra mediecontainern fortsätter att fungera.
Testa varje container separat med samma fil och codec. Gör behörighetsändringar tydliga i Compose så att uppgraderingar och återskapningar av avbildningen inte tar bort dem.
Kontrollera kompatibilitet mellan codec, drivrutin och runtime
Jämför vilka codecs och filter varje app ber GPU:n att köra, inklusive H.264, HEVC, AV1, tonmappning, undertexter, skalning samt OpenCL- eller CUDA-filter. En arbetsbelastning kan kräva funktioner som en annan aldrig använder.
En aktuell guide om GPU-passthrough för Jellyfin betonar att containerkonfigurationen måste matcha Intel QSV, NVIDIA NVENC eller AMD VA-API, i stället för att behandla alla vägar för hårdvaruacceleration som utbytbara. runtimen måste matcha GPU-familjen.
Se till att värddatorns drivrutin är kompatibel med runtime-biblioteken i containern och undvik att paketera motstridiga drivrutiner i enskilda mediecontainrar. Testa avkodning, kodning och tonmappning separat.
Mät samtidiga sessioner samt minnes- och temperaturgränser
Starta en hårdvarutranskodning i varje container och övervaka GPU-processer, användning, belastning på kodare och avkodare, minne, temperatur, fel och strömmarnas stabilitet. Öka samtidigheten gradvis med representativa medier.
En Proxmox-konfiguration i communityn beskriver flera Jellyfin-instanser som transkodar samtidigt och hur aktiviteten verifieras från värddatorn. Den visar också att samtidiga sessioner har praktiska gränser som bestäms av hårdvara och programvara.
En delad GPU fungerar när båda apparna fortsätter att vara accelererade och responsiva. Bildstörningar, misslyckad initiering av kodaren, slut på minne, termiska återställningar eller att en app tvingar den andra att använda programvara visar att arbetsbelastningen överskrider den aktuella marginalen.
Håll konfiguration och transkodningssökvägar separata när GPU:n delas
Ge varje mediecontainer en egen konfigurationsdatabas, cache, transkodningskatalog, portar och identitet. Dela endast det skrivskyddade mediebiblioteket och GPU-enheten, om inte apparna uttryckligen stöder en gemensam tillståndskatalog.
ZimaSpace-guiden om isolering av containerberoenden hjälper dig att skilja en GPU-konflikt från fel i databas, cache, nätverk eller montering.
Designen är validerad först när båda containrarna överlever ombyggnader, använder hårdvaruacceleration samtidigt, respekterar sina egna behörigheter och tillstånd samt håller sig inom gränserna för sessioner, minne och temperatur. Använd separata GPU:er eller mjukvarufallback när samtidiga arbetsbelastningar inte på ett tillförlitligt sätt kan uppfylla den kvalitet som krävs.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
