Immich può condividere una GPU o un acceleratore con un altro container?

Sì, Immich può condividere una GPU o un acceleratore con un altro container quando il runtime dell’host consente l’accesso simultaneo e entrambi i carichi di lavoro rimangono entro i limiti pratici del dispositivo.

La condivisione del dispositivo non garantisce isolamento o prestazioni uniformi. Immich può usare l’accelerazione per la transcodifica video o l’inferenza di machine learning mentre un altro servizio codifica contenuti multimediali, esegue inferenza IA o usa lo stesso nodo di rendering. Esporre il dispositivo deliberatamente, testare ogni carico di lavoro singolarmente, quindi eseguire la sovrapposizione reale e controllare eventuali problemi di memoria, latenza, temperatura o driver.

Dimostra prima che ogni container possa usare l’acceleratore da solo

Prima di testare la condivisione, verifica il driver dell’host e il runtime del container con un carico di lavoro alla volta. Per Immich, attiva la funzione accelerata che intendi effettivamente usare e conferma l’utilizzo del dispositivo e la pulizia dei log dell’applicazione. Ripeti la procedura con il secondo container usando il suo normale carico di lavoro.

L’esempio del runtime per container NVIDIA relativo a più container con GPU dimostra che è possibile avviare più container con accesso alla GPU. Questo dimostra il modello del runtime, non che ogni coppia di applicazioni possa condividere equamente il dispositivo o rientrare nelle sue capacità.

Se una delle due applicazioni non riesce a usare l’acceleratore in modo affidabile da sola, non diagnosticare ancora la concorrenza. Risolvi prima i problemi relativi alla versione del driver, alla mappatura del dispositivo, alle autorizzazioni, alla configurazione del runtime, al supporto dei codec o al backend dell’applicazione. Un test condiviso non può distinguere questi problemi di base dall’effettiva contesa.

Esponi solo il dispositivo necessario a ogni carico di lavoro

Nei sistemi con più acceleratori, assegna un dispositivo specifico quando possibile invece di esporre ogni GPU a ogni container. Con la grafica integrata Intel o AMD, verifica il dispositivo di rendering previsto e le autorizzazioni del gruppo. Con NVIDIA, conferma quale dispositivo visibile viene effettivamente selezionato dal processo.

Una recente risposta sul forum NVIDIA relativa alla condivisione di una GPU tra container osserva che i normali processi dei container possono accedere alla stessa GPU quando questa è esposta a entrambi. Il punto operativo importante è che i confini dei container non creano automaticamente una quota prestazionale fissa.

La visibilità del dispositivo dovrebbe essere riproducibile dopo la ricreazione del container. Riavvia ogni servizio e conferma che venga visualizzato lo stesso dispositivo con le stesse autorizzazioni. Se dopo il riavvio un’applicazione passa silenziosamente alla CPU, correggi la mappatura prima di misurare le prestazioni condivise.

Misura la contesa nei carichi di lavoro che si sovrappongono realmente

Esegui Immich da solo e registra la velocità di elaborazione, il tempo di risposta interattivo, l’utilizzo della GPU, la memoria del dispositivo, l’eventuale ricorso alla CPU e la temperatura. Esegui l’altro container da solo con le stesse metriche. Poi sovrapponi i due processi rappresentativi e confronta le variazioni invece di affidarti al throughput teorico massimo.

Una discussione più recente di NVIDIA sul comportamento della condivisione della GPU tra container chiede se due container possano selezionare gli stessi dispositivi e competere per le risorse. È esattamente questo il limite da testare: la visibilità corrisponde all’accesso condiviso, non a un controllo automatico degli accessi o a una capacità garantita.

Accetta la condivisione quando entrambi i carichi di lavoro restano accelerati, vengono completati correttamente e rimangono entro gli obiettivi di latenza e temperatura. Se un processo esaurisce la VRAM, costringe l’altro a usare la CPU, causa errori di allocazione dell’encoder o genera blocchi percepibili dall’utente, riduci la concorrenza, pianifica i processi più pesanti in momenti diversi o assegna dispositivi separati.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Separa la pressione della transcodifica da quella del machine learning

Immich può sottoporre l’acceleratore a sollecitazioni diverse a seconda che stia codificando video o eseguendo inferenza di machine learning. Anche l’altro container potrebbe utilizzare in modo diverso i motori di codifica, le unità di calcolo o la memoria condivisa. L’utilizzo totale della “GPU” può nascondere quale motore sia effettivamente saturo.

La guida di ZimaSpace sulla convalida della GPU condivisa tra container offre un utile schema di test per i server domestici: conferma prima driver e mappatura, quindi aumenta le sessioni simultanee rappresentative monitorando la memoria del dispositivo, la temperatura, gli errori e il comportamento di fallback.

Se la transcodifica video e il machine learning si sovrappongono raramente, la pianificazione può essere più semplice del partizionamento hardware. Se entrambi sono sensibili alla latenza per tutta la giornata, un secondo acceleratore o un host separato può creare un limite agli errori più chiaro. L’architettura corretta dipende dalla finestra di sovrapposizione, non solo dal fatto che Docker consenta a entrambi i container di aprire il dispositivo.

Convalida la condivisione attraverso un riavvio e il normale picco massimo

Costruisci un picco ripetibile, ad esempio una transcodifica video di Immich insieme a un lotto di elaborazioni di Smart Search o relative ai volti, mentre il secondo container esegue il suo più intenso carico di lavoro accelerato normale. Registra le velocità di completamento, la latenza di coda, l’utilizzo della memoria, la temperatura, gli errori e l’eventuale passaggio di uno dei servizi alla CPU.

Riavvia i container in entrambi gli ordini e ripeti il test. Una configurazione affidabile non deve dipendere dal servizio che ha acquisito per primo l’acceleratore, a meno che tale priorità non sia una scelta progettuale esplicita. Verifica inoltre che i nodi del dispositivo e le assegnazioni del runtime rimangano stabili dopo il riavvio dell’host.

Mantieni la condivisione quando la sovrapposizione misurata rimane entro gli obiettivi del servizio, con margine termico e di memoria. Interrompi l’aumento della concorrenza al primo errore ripetibile o alla prima latenza inaccettabile. Per un’analisi più approfondita, indica il modello della GPU, le versioni del driver e del runtime, le mappature dei dispositivi, l’utilizzo della VRAM, i tipi di carico di lavoro e la combinazione esatta che causa la contesa.