Kann Immich eine GPU oder einen Beschleuniger mit einem anderen Container teilen?

Ja, Immich kann eine GPU oder einen Beschleuniger mit einem anderen Container teilen, wenn die Host-Laufzeitumgebung den gleichzeitigen Zugriff erlaubt und beide Workloads innerhalb der praktischen Gerätegrenzen bleiben.

Das Teilen des Geräts garantiert weder Isolation noch eine gleichmäßige Leistung. Immich kann die Beschleunigung für Videotranskodierung oder Machine-Learning-Inferenz nutzen, während ein anderer Dienst Medien kodiert, KI-Inferenz ausführt oder denselben Renderknoten verwendet. Stellen Sie das Gerät gezielt bereit, testen Sie zunächst jeden Workload einzeln und führen Sie anschließend die reale Überschneidung aus. Achten Sie dabei auf Speicher-, Latenz-, Temperatur- oder Treiberfehler.

Beweisen Sie zunächst, dass jeder Container den Beschleuniger allein verwenden kann

Überprüfen Sie vor dem Testen der gemeinsamen Nutzung den Host-Treiber und die Container-Laufzeitumgebung mit jeweils nur einem Workload. Lösen Sie in Immich genau die beschleunigte Funktion aus, die Sie verwenden möchten, und bestätigen Sie die Gerätenutzung sowie saubere Anwendungsprotokolle. Wiederholen Sie den Vorgang mit dem zweiten Container und dessen normalem Workload.

Das Beispiel der NVIDIA-Container-Laufzeitumgebung für mehrere GPU-fähige Container zeigt, dass mehrere Container mit GPU-Zugriff gestartet werden können. Das beweist das Laufzeitmodell, nicht aber, dass jedes Anwendungspaar die Ressourcen fair teilt oder in ein einzelnes Gerät passt.

Wenn eine der Anwendungen den Beschleuniger allein nicht zuverlässig verwenden kann, diagnostizieren Sie noch keine Nebenläufigkeit. Beheben Sie zuerst die Version des Treibers, die Gerätezuordnung, Berechtigungen, die Laufzeitkonfiguration, Codec-Unterstützung oder das Anwendungs-Backend. Ein gemeinsamer Test kann diese grundlegenden Probleme nicht von tatsächlicher Konkurrenz um Ressourcen unterscheiden.

Stellen Sie nur das Gerät bereit, das der jeweilige Workload benötigt

Weisen Sie auf Systemen mit mehreren Beschleunigern nach Möglichkeit ein bestimmtes Gerät zu, anstatt jeden Container jeder GPU auszusetzen. Überprüfen Sie bei integrierten Intel- oder AMD-Grafikeinheiten das vorgesehene Rendergerät und die Gruppenberechtigungen. Bestätigen Sie bei NVIDIA, welches sichtbare Gerät der Prozess tatsächlich auswählt.

Eine aktuelle NVIDIA-Forumsantwort zum Teilen einer GPU zwischen Containern weist darauf hin, dass gewöhnliche Containerprozesse auf dieselbe GPU zugreifen können, wenn sie beiden bereitgestellt wird. Der entscheidende betriebliche Punkt ist, dass Containergrenzen nicht automatisch einen festen Leistungsanteil schaffen.

Die Gerätesichtbarkeit sollte nach einer Neuerstellung des Containers reproduzierbar sein. Starten Sie jeden Dienst neu und bestätigen Sie, dass dasselbe Gerät mit denselben Berechtigungen angezeigt wird. Wenn eine Anwendung nach dem Neustart stillschweigend auf die CPU zurückfällt, beheben Sie die Zuordnung, bevor Sie die gemeinsame Leistung messen.

Messen Sie die Konkurrenz in den Workloads, die tatsächlich gleichzeitig ausgeführt werden

Führen Sie Immich allein aus und zeichnen Sie Verarbeitungsrate, interaktive Antwortzeit, GPU-Auslastung, Gerätespeicher, CPU-Rückfall und Temperatur auf. Führen Sie den anderen Container allein mit denselben Messwerten aus. Lassen Sie anschließend die beiden repräsentativen Jobs gleichzeitig laufen und vergleichen Sie die Veränderung, statt sich auf die theoretische Spitzenleistung zu verlassen.

Eine neuere NVIDIA-Diskussion über das Verhalten der GPU-Nutzung über mehrere Container hinweg fragt, ob zwei Container dieselben Geräte auswählen und miteinander konkurrieren können. Genau diese Grenze sollten Sie testen: Gemeinsame Sichtbarkeit bedeutet gemeinsamen Zugriff, nicht automatisch eine Zugriffskontrolle oder garantierte Kapazität.

Akzeptieren Sie die gemeinsame Nutzung, wenn beide Workloads beschleunigt bleiben, korrekt abgeschlossen werden und innerhalb Ihrer Latenz- und Temperaturziele bleiben. Wenn ein Job den VRAM erschöpft, den anderen auf die CPU zwingt, Fehler bei der Encoder-Zuweisung verursacht oder für Benutzer sichtbare Verzögerungen erzeugt, reduzieren Sie die Nebenläufigkeit, planen Sie die rechenintensiven Jobs zeitlich getrennt oder weisen Sie separate Geräte zu.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Trennen Sie den Transkodierungsdruck vom Druck durch Machine Learning

Immich kann einen Beschleuniger je nach Aufgabe unterschiedlich stark belasten, etwa beim Kodieren von Videos oder bei der Ausführung von Machine-Learning-Inferenz. Auch der andere Container kann Encoder, Recheneinheiten oder gemeinsam genutzten Speicher anders verwenden. Eine zusammengefasste „GPU-Auslastung“ kann verbergen, welche Einheit tatsächlich ausgelastet ist.

Der ZimaSpace-Leitfaden zur Validierung gemeinsam genutzter GPUs über mehrere Container hinweg bietet ein nützliches Testschema für Heimserver: Bestätigen Sie zuerst Treiber und Zuordnung und erhöhen Sie dann schrittweise die repräsentativen gleichzeitigen Sitzungen, während Sie Gerätespeicher, Temperatur, Fehler und Rückfallverhalten beobachten.

Wenn sich Videotranskodierung und ML nur selten überschneiden, kann die zeitliche Planung einfacher sein als eine Hardwarepartitionierung. Wenn beide den ganzen Tag über latenzempfindlich sind, kann ein zweiter Beschleuniger oder ein separater Host eine klarere Fehlergrenze schaffen. Die richtige Architektur hängt vom Überschneidungszeitraum ab, nicht nur davon, ob Docker beiden Containern das Öffnen des Geräts erlaubt.

Validieren Sie die gemeinsame Nutzung durch Neustarts und einen typischen Spitzenwert

Erstellen Sie einen reproduzierbaren Spitzenlasttest, etwa eine Immich-Videotranskodierung zusammen mit einer Reihe von Smart-Search- oder gesichtsbezogenen Verarbeitungsvorgängen, während der zweite Container seine anspruchsvollste normale beschleunigte Aufgabe ausführt. Zeichnen Sie Abschlussraten, Tail-Latenz, Speichernutzung, Temperatur, Fehler und die Frage auf, ob einer der Dienste auf die CPU zurückfällt.

Starten Sie die Container in beiden Reihenfolgen neu und wiederholen Sie den Test. Eine robuste Konfiguration darf nicht davon abhängen, welcher Dienst den Beschleuniger zuerst beansprucht, es sei denn, diese Priorität ist eine ausdrückliche Designentscheidung. Prüfen Sie außerdem, ob Geräteknoten und Laufzeitzuweisungen nach einem Neustart des Hosts stabil bleiben.

Behalten Sie die gemeinsame Nutzung bei, wenn die gemessene Überschneidung innerhalb der Dienstziele bleibt und thermische sowie Speicherreserven vorhanden sind. Erhöhen Sie die Nebenläufigkeit beim ersten reproduzierbaren Fehler oder bei nicht akzeptabler Latenz nicht weiter. Eskalieren Sie das Problem mit GPU-Modell, Treiber-/Laufzeitversionen, Gerätezuordnungen, VRAM-Nutzung, Workload-Typen und der genauen Kombination, die die Konkurrenz verursacht.