Czy Home Assistant może współdzielić kartę graficzną lub akcelerator z innym kontenerem?

Tak, obciążenia związane z Home Assistant mogą czasami współdzielić procesor graficzny z innym kontenerem, ale odpowiedź zależy od ścieżki akceleracji i granicy wirtualizacji.

Sam Home Assistant Core zwykle nie potrzebuje procesora graficznego; akcelerator jest zazwyczaj używany przez Frigate, lokalne usługi wizyjne lub AI, przetwarzanie multimediów albo inną usługę towarzyszącą. W systemie Linux wielu kontenerom można często przyznać dostęp do tego samego urządzenia renderującego i pozwolić sterownikowi planować pracę. Maszyna wirtualna otrzymująca całe urządzenie PCIe za pośrednictwem passthrough działa w innym modelu i może sprawić, że urządzenie stanie się niedostępne dla hosta oraz innych gości. Zidentyfikuj faktycznego użytkownika akceleratora, zanim zmienisz uprawnienia.

Najpierw ustal, które obciążenie Home Assistant faktycznie potrzebuje akceleratora

Nie przekazuj procesora graficznego do kontenera Home Assistant Core tylko dlatego, że host go ma. Wskaż proces, który będzie z niego korzystać: dekodowanie obrazu wideo przez Frigate, wykrywanie obiektów za pomocą OpenVINO, lokalną usługę językową lub wizyjną, przetwarzanie mowy albo inny kontener wywoływany przez Home Assistant. Mapowanie urządzenia powinno należeć do kontenera tego obciążenia i jego granicy bezpieczeństwa.

Wdrożenia Frigate wyraźnie pokazują model ścieżki urządzenia: akceleracja sprzętowa zależy od tego, czy konkretne urządzenie renderujące jest widoczne w całym stosie kontenerów. Aktualny przewodnik po passthrough iGPU i Coral dla Frigate pokazuje, dlaczego widoczność urządzenia, uprawnienia grup oraz warstwy wirtualizacji trzeba zweryfikować, a nie wywnioskować jedynie z faktu, że host ma procesor graficzny.

Jeśli Home Assistant tylko koordynuje działanie akcelerowanej usługi za pośrednictwem API lub MQTT, Core w ogóle nie potrzebuje bezpośredniego dostępu do urządzenia. Pozostawienie mapowania procesora graficznego w kontenerze korzystającym z akceleratora ogranicza uprawnienia i ułatwia izolowanie awarii.

Współdzielone urządzenia renderujące systemu Linux i przekazywanie całego procesora graficznego do maszyny wirtualnej to różne modele

W kontenerach Linux mapowanie węzła renderującego, takiego jak /dev/dri/renderD128, do więcej niż jednego kontenera może umożliwić obu aplikacjom przesyłanie zadań za pośrednictwem sterownika hosta. Współdzielą one harmonogram oraz zasoby pamięci, a nie otrzymują niezależnego fizycznego procesora graficznego. To, czy konkretne obciążenie będzie działać w ten sposób bezpiecznie, nadal zależy od zachowania sterownika i aplikacji.

Przewodnik po passthrough GPU w LXC jasno przedstawia granicę kontenera: host zachowuje rzeczywisty sterownik procesora graficznego, a kontener otrzymuje wybrane węzły urządzeń, takie jak /dev/dri/renderD128. Ten model współdzielonego urządzenia renderującego umożliwia wielu kontenerom dostęp do tej samej ścieżki akceleratora, ale nadal konkurują one o silniki GPU, przepustowość pamięci i limity zależne od producenta.

Przekazanie całego urządzenia PCIe do maszyny wirtualnej działa inaczej. Aktualny przewodnik VFIO dla Proxmox opisuje to przekazanie jako wyłączne posiadanie procesora graficznego przez jedną maszynę wirtualną, co usuwa standardową ścieżkę współdzielenia przez sterownik hosta dla tej karty. SR-IOV, urządzenia mediowane, vGPU lub podobne funkcje mogą zapewnić inny model współdzielenia na obsługiwanym sprzęcie, ale są to odrębne możliwości i nie należy ich zakładać przy zwykłym passthrough.

Przed testowaniem wydajności sprawdź widoczność i uprawnienia w obu kontenerach

Uruchom oddzielnie każdego użytkownika akceleratora i sprawdź z poziomu kontenera węzeł urządzenia, uprawnienia użytkownika i grup, biblioteki sterownika oraz raport aplikacji dotyczący sprzętu. Uprzywilejowany kontener nie zastępuje zrozumienia, które urządzenie renderujące i które grupy są wymagane. Przyznaj najmniejszy zakres dostępu do urządzenia, który umożliwia działanie zamierzonego obciążenia.

Ten sam proces mapowania urządzenia LXC pozwala zweryfikować węzeł renderujący z poziomu kontenera i zaleca testowanie go jako rzeczywiste konto usługi, zamiast polegania wyłącznie na widoczności hosta. Użyj tej metody, aby potwierdzić dostęp kontenera do akceleratora przed porównaniem wydajności; urządzenie widoczne na hoście nie jest dowodem, że aplikacja może je otworzyć.

Przejdź etap widoczności dopiero wtedy, gdy oba kontenery niezależnie potwierdzą wykorzystanie sprzętu. Jeśli jeden z nich po cichu przełącza się na procesor, napraw mapowanie lub konfigurację sterownika przed przeprowadzeniem testu współbieżności. W przeciwnym razie awaryjne użycie procesora może sprawiać wrażenie, że współdzielenie GPU działa, podczas gdy host faktycznie obsługuje jedno obciążenie programowo.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wykonaj testy osobno i jednocześnie, aby znaleźć granicę współdzielenia

Najpierw zmierz każde obciążenie osobno: czas przetwarzania klatek, szybkość kodowania i dekodowania, wykorzystanie akceleratora, zużycie pamięci, temperaturę, pobór mocy oraz opóźnienia aplikacji. Następnie uruchom oba obciążenia jednocześnie, przy ich typowym szczytowym poziomie. Współdzielona konfiguracja jest akceptowalna tylko wtedy, gdy krytyczne obciążenie związane z Home Assistant zachowuje wymagany czas realizacji, a żadna aplikacja nie zaczyna zgłaszać błędów ani przełączać się na tryb awaryjny.

Istniejący test ZimaSpace dotyczący współdzielenia jednego procesora graficznego przez kontenery przedstawia tę samą zasadę operacyjną: widoczność urządzenia to dopiero pierwszy etap; o faktycznej użyteczności współdzielenia decydują stabilność podczas jednoczesnej pracy i rywalizacja o zasoby.

Pozostaw jeden współdzielony akcelerator, jeśli oba użytkowane zasoby mieszczą się w limitach opóźnień i pamięci podczas rzeczywistego nakładania się obciążeń. Rozdziel je, gdy jedno zadanie powoduje gubienie klatek, opóźnienia wnioskowania, resetowanie sterownika, błędy braku pamięci, dławienie termiczne lub nieprzewidywalne przełączanie awaryjne. Jeśli procesor graficzny został w całości przekazany maszynie wirtualnej, przeprojektuj warstwę wirtualizacji albo dodaj drugi akcelerator, zamiast próbować mapować już zajęte fizyczne urządzenie do drugiego kontenera.