Kann Home Assistant eine GPU oder einen Beschleuniger mit einem anderen Container gemeinsam nutzen?

Ja, Workloads im Zusammenhang mit Home Assistant können sich manchmal eine GPU mit einem anderen Container teilen, aber die Antwort hängt vom Beschleunigungspfad und der Virtualisierungsgrenze ab.

Home Assistant Core selbst benötigt normalerweise keine GPU; der Beschleuniger wird meist für Frigate, lokale Bildverarbeitung oder KI, Medienverarbeitung oder einen anderen Begleitdienst verwendet. Unter Linux können mehrere Container häufig Zugriff auf dasselbe Rendergerät erhalten, wobei der Treiber die Arbeit verteilt. Eine VM, der per Passthrough ein vollständiges PCIe-Gerät zugewiesen wird, folgt einem anderen Modell und kann dazu führen, dass dieses Gerät für den Host und andere Gäste nicht verfügbar ist. Ermitteln Sie den tatsächlichen Verbraucher, bevor Sie Berechtigungen ändern.

Ermitteln Sie zunächst, welcher Home-Assistant-Workload den Beschleuniger tatsächlich benötigt

Geben Sie keine GPU an den Home-Assistant-Core-Container weiter, nur weil der Host über eine verfügt. Benennen Sie den Prozess, der sie verwenden wird: Videodekodierung durch Frigate, OpenVINO-Objekterkennung, ein lokaler Sprach- oder Bildverarbeitungsdienst, Sprachverarbeitung oder einen anderen Container, den Home Assistant aufruft. Die Gerätezuordnung sollte zum Container und zur Sicherheitsgrenze dieses Workloads gehören.

Frigate-Bereitstellungen veranschaulichen das Gerätemodell deutlich: Die Hardwarebeschleunigung hängt davon ab, dass ein bestimmtes Rendergerät durch den gesamten Container-Stack hindurch sichtbar ist. Ein aktueller Leitfaden zum Frigate-iGPU-Passthrough zeigt, warum Gerätesichtbarkeit, Gruppenberechtigungen und Virtualisierungsebenen überprüft werden müssen, anstatt aus dem Vorhandensein einer GPU auf dem Host darauf zu schließen.

Wenn Home Assistant den beschleunigten Dienst nur über eine API oder MQTT orchestriert, benötigt Core überhaupt keinen direkten Gerätezugriff. Wenn die GPU-Zuordnung im Container des Verbrauchers verbleibt, werden die Berechtigungen eingeschränkt und Fehler lassen sich leichter isolieren.

Gemeinsam genutzte Linux-Rendergeräte und vollständiges GPU-Passthrough zu VMs sind unterschiedliche Modelle

Bei Linux-Containern kann die Zuordnung eines Render-Nodes wie /dev/dri/renderD128 zu mehr als einem Container beiden Anwendungen ermöglichen, über den Host-Treiber Arbeit einzureichen. Sie teilen sich einen Scheduler und Speicherressourcen, erhalten aber nicht jeweils eine unabhängige physische GPU. Ob ein bestimmter Workload dies sicher unterstützt, hängt weiterhin vom Verhalten des Treibers und der Anwendung ab.

Ein LXC-Leitfaden zum GPU-Passthrough macht die Containergrenze deutlich: Der Host behält den eigentlichen GPU-Treiber, während ein Container ausgewählte Geräteknoten wie /dev/dri/renderD128 erhält. Dieses Modell gemeinsam genutzter Rendergeräte ermöglicht mehreren Containern den Zugriff auf denselben Beschleunigungspfad, dennoch konkurrieren sie um GPU-Engines, Speicherbandbreite und herstellerspezifische Grenzen.

Das PCIe-Passthrough eines vollständigen Geräts an eine virtuelle Maschine ist etwas anderes. Ein aktueller Proxmox-VFIO-Leitfaden beschreibt diese Übergabe als exklusive GPU-Nutzung durch eine VM, wodurch der normale gemeinsame Zugriff über den Host-Treiber für diese Karte entfällt. SR-IOV, vermittelte Geräte, vGPU oder ähnliche Funktionen können auf unterstützter Hardware ein weiteres Freigabemodell ermöglichen, sind jedoch separate Fähigkeiten und sollten nicht vom gewöhnlichen Passthrough abgeleitet werden.

Überprüfen Sie Sichtbarkeit und Berechtigungen in beiden Containern, bevor Sie die Leistung testen

Starten Sie jeden Beschleuniger-Verbraucher einzeln und prüfen Sie im Container den Geräteknoten, die Benutzer- und Gruppenberechtigungen, die Treiberbibliotheken sowie den Hardwarebericht der Anwendung. Ein privilegierter Container ist kein guter Ersatz dafür, zu verstehen, welches Rendergerät und welche Gruppen erforderlich sind. Gewähren Sie nur den kleinstmöglichen Gerätezugriff, mit dem der vorgesehene Workload funktioniert.

Der gleiche LXC-Workflow zur Gerätezuordnung überprüft den Render-Node innerhalb des Containers und empfiehlt, ihn als echtes Dienstkonto zu testen, anstatt sich allein auf die Sichtbarkeit auf dem Host zu verlassen. Verwenden Sie diese Methode, um den Beschleunigerzugriff auf Containerebene zu bestätigen, bevor Sie die Leistung vergleichen; ein auf dem Host aufgelistetes Gerät beweist nicht, dass die Anwendung es öffnen kann.

Bestehen Sie die Sichtbarkeitsprüfung erst dann, wenn beide Container die Hardware-Nutzung unabhängig voneinander nachweisen. Wenn einer unbemerkt auf die CPU zurückfällt, beheben Sie die Zuordnung oder die Treiberkonfiguration, bevor Sie einen Parallelitätstest durchführen. Andernfalls kann ein CPU-Fallback den Eindruck erwecken, dass die GPU-Freigabe funktioniert, während der Host tatsächlich einen Workload per Software verarbeitet.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Führen Sie Tests einzeln und gemeinsam durch, um die Freigabegrenze zu ermitteln

Messen Sie zunächst jeden Workload allein: Frame-Verarbeitungszeit, Kodier- und Dekodiergeschwindigkeit, Beschleunigerauslastung, Speichernutzung, Temperatur, Stromverbrauch und Anwendungslatenz. Führen Sie anschließend beide Workloads während ihrer normalen Spitzenlast gemeinsam aus. Die gemeinsame Konfiguration ist nur dann akzeptabel, wenn der kritische Home-Assistant-bezogene Workload seine Frist einhält und keine der Anwendungen Fehler produziert oder zurückfällt.

Der bestehende Test von ZimaSpace zum Teilen einer GPU zwischen Containern liefert dieselbe praktische Regel: Die Gerätesichtbarkeit ist nur die erste Hürde; gemeinsame Stabilität und Ressourcenkonflikte entscheiden darüber, ob die Freigabe tatsächlich sinnvoll ist.

Verwenden Sie weiterhin einen gemeinsamen Beschleuniger, wenn beide Verbraucher unter der realen Überschneidung innerhalb der Latenz- und Speichergrenzen bleiben. Trennen Sie sie, wenn ein Job zu verlorenen Frames, verzögerter Inferenz, Treiber-Resets, Fehlern durch zu wenig Speicher, thermischer Drosselung oder unvorhersehbaren Fallbacks führt. Wenn die GPU vollständig an eine VM durchgereicht wird, gestalten Sie die Virtualisierungsebene neu oder fügen Sie einen weiteren Beschleuniger hinzu, anstatt zu versuchen, das bereits belegte physische Gerät einem zweiten Container zuzuordnen.