Kan Home Assistant een GPU of accelerator delen met een andere container?

Ja, workloads die aan Home Assistant zijn gerelateerd kunnen soms een GPU delen met een andere container, maar het antwoord hangt af van het acceleratiepad en de virtualisatiegrens.

Home Assistant Core zelf heeft normaal gesproken geen GPU nodig; de accelerator wordt meestal gebruikt voor Frigate, lokale vision- of AI-taken, mediaverwerking of een andere begeleidende service. Op Linux kunnen meerdere containers vaak toegang krijgen tot hetzelfde renderapparaat, waarna de driver het werk inplant. Een VM die via passthrough een volledig PCIe-apparaat ontvangt, werkt volgens een ander model en kan dat apparaat onbeschikbaar maken voor de host en andere gasten. Bepaal eerst welke component het apparaat daadwerkelijk gebruikt voordat je rechten wijzigt.

Identificeer eerst welke Home Assistant-workload de accelerator daadwerkelijk nodig heeft

Geef niet alleen een GPU door aan de Home Assistant Core-container omdat de host er een heeft. Benoem het proces dat de GPU zal gebruiken: hardwarematige videodecodering in Frigate, objectdetectie met OpenVINO, een lokale taal- of visionservice, spraakverwerking of een andere container die door Home Assistant wordt aangeroepen. De apparaattoewijzing hoort bij de container en beveiligingsgrens van die workload.

Frigate-implementaties laten het model van het apparaattoegangspad duidelijk zien: hardwareacceleratie hangt ervan af dat een specifiek renderapparaat zichtbaar is door de volledige containerstack heen. Een actuele handleiding voor Frigate iGPU-passthrough laat zien waarom apparaatzichtbaarheid, groepsrechten en virtualisatielagen moeten worden gecontroleerd in plaats van afgeleid uit het feit dat de host een GPU heeft.

Als Home Assistant de versnelde service alleen via een API of MQTT aanstuurt, heeft Core helemaal geen directe apparaattoegang nodig. Door de GPU-toewijzing in de container te houden die het apparaat gebruikt, beperk je de rechten en kun je fouten eenvoudiger isoleren.

Gedeelde Linux-renderapparaten en passthrough van een volledige GPU aan een VM zijn verschillende modellen

Bij Linux-containers kan het koppelen van een rendernode zoals /dev/dri/renderD128 aan meer dan één container ervoor zorgen dat beide applicaties via de hostdriver werk indienen. Ze delen een scheduler en geheugenresources; elk krijgt dus geen onafhankelijke fysieke GPU. Of een specifieke workload dit veilig ondersteunt, hangt nog steeds af van het gedrag van de driver en applicatie.

Een handleiding voor GPU-passthrough naar LXC maakt de containergrens expliciet: de host behoudt de echte GPU-driver, terwijl een container geselecteerde apparaatnodes ontvangt, zoals /dev/dri/renderD128. Dit model met gedeeld renderapparaat geeft meerdere containers toegang tot hetzelfde acceleratiepad, maar ze concurreren nog steeds om GPU-engines, geheugenbandbreedte en leverancierspecifieke limieten.

Passthrough van een volledig PCIe-apparaat aan een virtuele machine is anders. Een actuele Proxmox VFIO-uitleg beschrijft die overdracht als exclusief GPU-bezit door één VM, waardoor het normale gedeelde hostdriverpad voor die kaart verdwijnt. SR-IOV, mediated devices, vGPU of vergelijkbare functies kunnen op ondersteunde hardware een ander deelmodel creëren, maar dit zijn afzonderlijke mogelijkheden die je niet mag veronderstellen bij gewone passthrough.

Controleer zichtbaarheid en rechten in beide containers voordat je de prestaties test

Start elke acceleratorgebruiker afzonderlijk en controleer vanuit de container de apparaatnode, gebruikers- en groepsrechten, driverbibliotheken en hardwareoverzichten van de applicatie. Een geprivilegieerde container is geen goede vervanging voor inzicht in welk renderapparaat en welke groepen vereist zijn. Geef alleen de minimaal benodigde apparaattoegang waarmee de beoogde workload werkt.

Dezelfde LXC-workflow voor apparaattoewijzing controleert de rendernode vanuit de container en adviseert om die te testen als het echte serviceaccount, in plaats van alleen op zichtbaarheid op de host te vertrouwen. Gebruik die methode om acceleratortoegang op containerniveau te bevestigen voordat je prestaties vergelijkt; een apparaat dat op de host wordt vermeld, bewijst niet dat de applicatie het kan openen.

Ga pas verder wanneer beide containers onafhankelijk hardwaregebruik aantonen. Als één container ongemerkt terugvalt op de CPU, los dan de mapping- of driverconfiguratie op voordat je een gelijktijdigheidstest uitvoert. Anders kan een CPU-terugval de indruk wekken dat GPU-delen werkt, terwijl de host in werkelijkheid één workload softwarematig uitvoert.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Voer tests afzonderlijk en gelijktijdig uit om de grens van het delen te bepalen

Meet eerst elke workload afzonderlijk: frametijd, encodeer- en decodeersnelheid, acceleratorgebruik, geheugengebruik, temperatuur, stroomverbruik en applicatielatentie. Voer daarna beide workloads gelijktijdig uit op hun normale piekniveau. De gedeelde opstelling is alleen geschikt wanneer de kritieke Home Assistant-gerelateerde workload binnen de deadline blijft en geen van beide applicaties fouten gaat geven of terugvalt.

De bestaande test van ZimaSpace voor het delen van één GPU tussen containers hanteert dezelfde praktische regel: apparaatzichtbaarheid is slechts de eerste controle; stabiliteit bij gelijktijdig gebruik en resourceconcurrentie bepalen of delen daadwerkelijk nuttig is.

Houd één gedeelde accelerator aan wanneer beide gebruikers onder de echte gelijktijdige belasting binnen hun latentie- en geheugenlimieten blijven. Splits ze wanneer één taak leidt tot verloren frames, inferentievertraging, driverresets, out-of-memory-fouten, thermische throttling of onvoorspelbare terugval. Als de GPU volledig aan een VM is doorgegeven, pas dan de virtualisatielaag aan of voeg een extra accelerator toe, in plaats van het reeds toegewezen fysieke apparaat aan een tweede container te proberen te koppelen.