Kan Home Assistant dela ett GPU-kort eller en accelerator med en annan container?

Ja, arbetsbelastningar som är relaterade till Home Assistant kan ibland dela en GPU med en annan container, men svaret beror på acceleratorsökvägen och virtualiseringsgränsen.

Home Assistant Core behöver normalt ingen GPU; acceleratorn används vanligtvis för Frigate, lokal bildanalys eller AI, mediebearbetning eller någon annan kompletterande tjänst. I Linux kan flera containrar ofta få åtkomst till samma renderingsenhet och låta drivrutinen schemalägga arbetet. En virtuell maskin som får en hel PCIe-enhet via passthrough är en annan modell och kan göra enheten otillgänglig för värden och andra gäster. Identifiera den faktiska användaren innan du ändrar behörigheter.

Identifiera först vilken Home Assistant-arbetsbelastning som faktiskt behöver acceleratorn

Skicka inte in en GPU i Home Assistant Core-containern bara för att värden har en. Ange vilken process som ska använda den: Frigates videodekodning, OpenVINO-objektdetektering, en lokal språk- eller bildtjänst, talbearbetning eller någon annan container som Home Assistant anropar. Enhetsmappningen bör tillhöra den arbetsbelastningens container och säkerhetsgräns.

Frigate-distributioner visar tydligt hur enhetssökvägen fungerar: maskinvaruacceleration beror på att en specifik renderingsenhet är synlig genom hela containerstacken. En aktuell guide till Frigate iGPU-passthrough visar varför enhetssynlighet, gruppbehörigheter och virtualiseringslager måste verifieras i stället för att antas utifrån att värden har en GPU.

Om Home Assistant endast samordnar den accelererade tjänsten via ett API eller MQTT behöver Core inte ha direkt åtkomst till enheten alls. Genom att behålla GPU-mappningen i den konsumerande containern minskar du behörigheterna och gör det enklare att isolera fel.

Delade Linux-renderingsenheter och passthrough av en hel GPU till en virtuell maskin är olika modeller

Med Linux-containrar kan mappning av en renderingsnod som /dev/dri/renderD128 till fler än en container göra det möjligt för båda programmen att skicka arbete via värdens drivrutin. De delar en schemaläggare och minnesresurser, inte varsin fysisk GPU. Huruvida en viss arbetsbelastning stöder detta säkert beror fortfarande på drivrutinens och programmets beteende.

En guide till GPU-passthrough för LXC tydliggör containergränsen: värden behåller den riktiga GPU-drivrutinen medan en container får utvalda enhetsnoder som /dev/dri/renderD128. Denna modell med delad renderingsenhet gör det möjligt för flera containrar att komma åt samma acceleratorsökväg, men de konkurrerar fortfarande om GPU-motorer, minnesbandbredd och leverantörsspecifika begränsningar.

Passthrough av en hel PCIe-enhet till en virtuell maskin är annorlunda. En aktuell Proxmox-genomgång av VFIO beskriver överlämningen som exklusivt GPU-ägande för en virtuell maskin, vilket tar bort den normala delade åtkomstvägen via värdens drivrutin för det kortet. SR-IOV, medierade enheter, vGPU och liknande funktioner kan skapa en annan delningsmodell på maskinvara som stöder det, men de är separata funktioner och ska inte antas utifrån vanlig passthrough.

Verifiera synlighet och behörigheter i båda containrarna innan du testar prestandan

Starta varje acceleratoranvändare separat och kontrollera enhetsnoden, användar- och gruppbehörigheter, drivrutinsbibliotek samt programmets maskinvarurapport inifrån containern. En privilegierad container är ingen bra ersättning för att förstå vilken renderingsenhet och vilka grupper som krävs. Ge endast den begränsade enhetsåtkomst som behövs för att den avsedda arbetsbelastningen ska fungera.

Samma arbetsflöde för LXC-enhetsmappning verifierar renderingsnoden inifrån containern och rekommenderar att den testas som det riktiga tjänstekontot i stället för att enbart lita på synligheten från värden. Använd den metoden för att bekräfta acceleratoråtkomst på containernivå innan du jämför prestanda; att enheten listas på värden är inget bevis på att programmet kan öppna den.

Godkänn synlighetssteget först när båda containrarna oberoende kan bevisa att maskinvaran används. Om någon tyst faller tillbaka till CPU, åtgärda mappningen eller drivrutinskonfigurationen innan du kör ett samtidighetstest. Annars kan ett CPU-fallback få det att se ut som att GPU-delning fungerar, medan värden i själva verket belastas med en arbetsbelastning i programvara.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kör tester en i taget och tillsammans för att hitta delningsgränsen

Mät först varje arbetsbelastning separat: bildrutebearbetningstid, kodnings- och avkodningshastighet, acceleratorutnyttjande, minnesanvändning, temperatur, effektförbrukning och programfördröjning. Kör sedan båda tillsammans vid sin normala maximala belastning. Den delade konfigurationen är acceptabel endast när den kritiska Home Assistant-relaterade arbetsbelastningen håller sin tidsgräns och inget av programmen börjar rapportera fel eller falla tillbaka.

ZimaSpaces befintliga test av att dela en GPU mellan containrar ger samma praktiska regel: enhetssynlighet är bara det första steget; samtidig stabilitet och resurskonkurrens avgör om delning faktiskt är användbar.

Behåll en gemensam accelerator när båda användarna håller sig inom gränserna för fördröjning och minne under den verkliga överlappningen. Separera dem när ett jobb orsakar tappade bildrutor, fördröjd inferens, drivrutinsåterställningar, slut på minne, termisk strypning eller oförutsägbart fallback. Om hela GPU:n har skickats vidare till en virtuell maskin bör du ändra virtualiseringslagret eller lägga till en annan accelerator i stället för att försöka mappa den redan ägda fysiska enheten till en andra container.