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

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Can Immich Share a GPU or Accelerator With Another Container? - Zima Store Online

Tak, Immich może współdzielić GPU lub akcelerator z innym kontenerem, jeśli środowisko uruchomieniowe hosta pozwala na równoczesny dostęp, a oba obciążenia mieszczą się w praktycznych limitach urządzenia.

Współdzielenie urządzenia nie gwarantuje izolacji ani równej wydajności. Immich może korzystać z akceleracji podczas transkodowania wideo lub wnioskowania uczenia maszynowego, podczas gdy inna usługa koduje multimedia, wykonuje wnioskowanie AI lub korzysta z tego samego węzła renderowania. Udostępniaj urządzenie świadomie, najpierw przetestuj każde obciążenie osobno, a następnie uruchom rzeczywiste obciążenia jednocześnie i obserwuj pamięć, opóźnienia, temperaturę oraz awarie sterownika.

Najpierw sprawdź, czy każdy kontener może samodzielnie korzystać z akceleratora

Przed testowaniem współdzielenia zweryfikuj sterownik hosta i środowisko uruchomieniowe kontenerów, uruchamiając po jednym obciążeniu naraz. W przypadku Immich uruchom funkcję korzystającą z akceleracji, której rzeczywiście zamierzasz używać, i potwierdź wykorzystanie urządzenia oraz poprawność logów aplikacji. Powtórz test z drugim kontenerem, używając jego zwykłego obciążenia.

Przykład środowiska uruchomieniowego kontenerów NVIDIA dotyczący wielu kontenerów z obsługą GPU pokazuje, że wiele kontenerów może zostać uruchomionych z dostępem do GPU. Dowodzi to modelu środowiska uruchomieniowego, ale nie tego, że każda para aplikacji będzie współdzielić urządzenie sprawiedliwie lub zmieści się na jednym urządzeniu.

Jeśli któraś z aplikacji nie może niezawodnie korzystać z akceleratora samodzielnie, nie diagnozuj jeszcze współbieżności. Najpierw napraw wersję sterownika, mapowanie urządzenia, uprawnienia, konfigurację środowiska uruchomieniowego, obsługę kodeków lub backend aplikacji. Test współdzielenia nie pozwoli odróżnić tych podstawowych problemów od rzeczywistej rywalizacji o zasoby.

Udostępniaj tylko urządzenie potrzebne danemu obciążeniu

W systemach z wieloma akceleratorami przypisz konkretne urządzenie, jeśli to możliwe, zamiast udostępniać każdemu kontenerowi wszystkie GPU. W przypadku zintegrowanej grafiki Intel lub AMD sprawdź właściwe urządzenie renderowania oraz uprawnienia grup. W przypadku NVIDIA potwierdź, które widoczne urządzenie faktycznie wybiera proces.

Nowsza odpowiedź na forum NVIDIA dotycząca współdzielenia jednego GPU między kontenerami wskazuje, że zwykłe procesy kontenerowe mogą korzystać z tego samego GPU, gdy jest ono udostępnione obu kontenerom. Najważniejszy wniosek operacyjny jest taki, że granice kontenerów nie tworzą automatycznie stałego podziału wydajności.

Widoczność urządzenia powinna być odtwarzalna po ponownym utworzeniu kontenera. Uruchom ponownie każdą usługę i potwierdź, że pojawia się to samo urządzenie z tymi samymi uprawnieniami. Jeśli po restarcie jedna aplikacja po cichu przełącza się na CPU, napraw mapowanie przed pomiarem współdzielonej wydajności.

Mierz rywalizację w obciążeniach, które rzeczywiście działają jednocześnie

Uruchom Immich samodzielnie i zapisz tempo przetwarzania, czas odpowiedzi interaktywnej, wykorzystanie GPU, pamięć urządzenia, przejście na CPU oraz temperaturę. Uruchom drugi kontener osobno, używając tych samych metryk. Następnie uruchom oba reprezentatywne zadania jednocześnie i porównaj zmianę, zamiast opierać się na teoretycznej maksymalnej przepustowości.

Nowsza dyskusja NVIDIA dotycząca sposobu współdzielenia GPU między kontenerami porusza kwestię tego, czy dwa kontenery mogą wybrać te same urządzenia i rywalizować o zasoby. To właśnie należy przetestować: współdzielona widoczność oznacza wspólny dostęp, a nie automatyczną kontrolę dostępu ani gwarantowaną przepustowość.

Zaakceptuj współdzielenie, jeśli oba obciążenia nadal korzystają z akceleracji, kończą się poprawnie i mieszczą się w założonych limitach opóźnienia oraz temperatury. Jeśli jedno zadanie wyczerpuje VRAM, zmusza drugie do przejścia na CPU, powoduje błędy przydzielania zasobów enkodera lub wywołuje zauważalne dla użytkownika przestoje, ogranicz współbieżność, uruchamiaj ciężkie zadania osobno w czasie albo przypisz osobne urządzenia.

-15% OFF

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

Single board computer zimaboard2

Oddziel obciążenie związane z transkodowaniem od obciążenia związanego z uczeniem maszynowym

Immich może różnie obciążać akcelerator w zależności od tego, czy koduje wideo, czy wykonuje wnioskowanie uczenia maszynowego. Drugi kontener również może w odmienny sposób korzystać z silników kodowania, jednostek obliczeniowych lub współdzielonej pamięci. Łączne „wykorzystanie GPU” może ukrywać fakt, że nasycony jest konkretny silnik.

Poradnik ZimaSpace dotyczący weryfikacji współdzielonego GPU między kontenerami przedstawia przydatny schemat testu dla serwera domowego: najpierw potwierdź sterownik i mapowanie, a następnie zwiększaj liczbę reprezentatywnych równoczesnych sesji, obserwując pamięć urządzenia, temperaturę, błędy i zachowanie podczas przełączania na CPU.

Jeśli transkodowanie wideo i ML rzadko występują jednocześnie, planowanie zadań może być prostsze niż partycjonowanie sprzętu. Jeśli oba obciążenia przez cały dzień wymagają niskich opóźnień, drugi akcelerator lub osobny host może zapewnić wyraźniejszą granicę awarii. Właściwa architektura zależy od okresu nakładania się obciążeń, a nie tylko od tego, czy Docker pozwala obu kontenerom otworzyć urządzenie.

Zweryfikuj współdzielenie po restarcie i podczas najgorszego typowego szczytu obciążenia

Przygotuj powtarzalny scenariusz szczytowego obciążenia, na przykład jedno transkodowanie wideo w Immich oraz partię zadań Smart Search lub przetwarzania związanego z rozpoznawaniem twarzy, podczas gdy drugi kontener wykonuje swoje najbardziej wymagające typowe zadanie korzystające z akceleracji. Zapisz wskaźniki ukończenia, opóźnienie ogona, wykorzystanie pamięci, temperaturę, błędy oraz informację, czy któraś usługa przełącza się na CPU.

Uruchom ponownie kontenery w obu kolejnościach i powtórz test. Stabilna konfiguracja nie powinna zależeć od tego, która usługa jako pierwsza zajęła akcelerator, chyba że taki priorytet jest świadomą decyzją projektową. Sprawdź również, czy węzły urządzeń i przypisania środowiska uruchomieniowego pozostają stabilne po restarcie hosta.

Pozostaw współdzielenie, jeśli zmierzone nakładanie się obciążeń mieści się w założonych celach usług, z zapasem temperatury i pamięci. Przerwij zwiększanie współbieżności przy pierwszym powtarzalnym błędzie lub nieakceptowalnym opóźnieniu. Zgłaszając problem, podaj model GPU, wersje sterownika i środowiska uruchomieniowego, mapowania urządzeń, wykorzystanie VRAM, typy obciążeń oraz dokładną kombinację powodującą rywalizację o zasoby.