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

Sì, i carichi di lavoro correlati a Home Assistant possono talvolta condividere una GPU con un altro container, ma la risposta dipende dal percorso dell'acceleratore e dal confine di virtualizzazione.

Di norma, Home Assistant Core non necessita di una GPU; l'acceleratore viene solitamente utilizzato da Frigate, per la visione o l'intelligenza artificiale locali, l'elaborazione multimediale o un altro servizio complementare. Su Linux, spesso è possibile consentire a più container di accedere allo stesso dispositivo di rendering e lasciare che il driver pianifichi i carichi di lavoro. Una macchina virtuale a cui viene assegnato un intero dispositivo PCIe tramite passthrough segue un modello diverso e può rendere quel dispositivo non disponibile all'host e agli altri guest. Identifica il consumatore effettivo prima di modificare i permessi.

Identifica innanzitutto quale carico di lavoro di Home Assistant necessita davvero dell'acceleratore

Non assegnare una GPU al container di Home Assistant Core solo perché l'host ne possiede una. Identifica il processo che la utilizzerà: decodifica video di Frigate, rilevamento di oggetti con OpenVINO, un servizio locale per il linguaggio o la visione, elaborazione vocale o un altro container chiamato da Home Assistant. La mappatura del dispositivo dovrebbe appartenere al container e al confine di sicurezza di quel carico di lavoro.

Le implementazioni di Frigate mostrano chiaramente il modello del percorso del dispositivo: l'accelerazione hardware dipende dalla visibilità di uno specifico dispositivo di rendering lungo tutto lo stack dei container. Un'aggiornata guida al passthrough dell'iGPU per Frigate mostra perché la visibilità del dispositivo, i permessi dei gruppi e i livelli di virtualizzazione debbano essere verificati, anziché dedotti dal semplice fatto che l'host disponga di una GPU.

Se Home Assistant coordina il servizio accelerato solo tramite API o MQTT, Core non necessita affatto dell'accesso diretto al dispositivo. Mantenere la mappatura della GPU nel container che la utilizza riduce i privilegi e facilita l'isolamento dei guasti.

I dispositivi di rendering Linux condivisi e il passthrough dell'intera GPU a una macchina virtuale sono modelli diversi

Con i container Linux, mappare un nodo di rendering come /dev/dri/renderD128 in più di un container può consentire a entrambe le applicazioni di inviare carichi di lavoro tramite il driver dell'host. Condividono un pianificatore e risorse di memoria, non ricevono ciascuna una GPU fisica indipendente. La sicurezza di questa configurazione per un determinato carico di lavoro dipende comunque dal comportamento del driver e dell'applicazione.

Una guida al passthrough della GPU in LXC rende esplicito il confine del container: l'host mantiene il driver reale della GPU, mentre un container riceve nodi di dispositivo selezionati come /dev/dri/renderD128. Questo modello con dispositivo di rendering condiviso consente a più container di accedere allo stesso percorso dell'acceleratore, ma questi continuano a competere per i motori della GPU, la larghezza di banda della memoria e i limiti specifici del produttore.

Il passthrough PCIe dell'intero dispositivo a una macchina virtuale è diverso. Un'attuale guida pratica a Proxmox VFIO descrive questo trasferimento come proprietà esclusiva della GPU da parte di una macchina virtuale, eliminando il normale percorso di condivisione tramite il driver dell'host per quella scheda. SR-IOV, dispositivi mediati, vGPU o funzionalità simili possono creare un altro modello di condivisione sull'hardware supportato, ma sono capacità separate e non devono essere date per scontate con il passthrough ordinario.

Verifica visibilità e permessi in entrambi i container prima di testare le prestazioni

Avvia separatamente ciascun consumatore dell'acceleratore e controlla dall'interno del container il nodo del dispositivo, i permessi dell'utente e dei gruppi, le librerie del driver e il report hardware dell'applicazione. Un container privilegiato non è un valido sostituto della comprensione del dispositivo di rendering e dei gruppi necessari. Concedi il livello minimo di accesso al dispositivo che consenta il funzionamento del carico di lavoro previsto.

Lo stesso flusso di lavoro per la mappatura dei dispositivi LXC verifica il nodo di rendering dall'interno del container e raccomanda di eseguire il test con l'account di servizio effettivo, anziché affidarsi alla sola visibilità sull'host. Usa questo metodo per confermare l'accesso all'acceleratore a livello di container prima di confrontare le prestazioni; un dispositivo elencato sull'host non dimostra che l'applicazione possa aprirlo.

Considera superata la fase di verifica della visibilità solo quando entrambi i container dimostrano indipendentemente di utilizzare l'hardware. Se uno passa silenziosamente alla CPU, correggi la mappatura o la configurazione del driver prima di eseguire un test di concorrenza. In caso contrario, il fallback alla CPU può far sembrare che la condivisione della GPU funzioni, mentre in realtà l'host sta eseguendo uno dei carichi di lavoro via software.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Esegui test separati e simultanei per individuare il limite di condivisione

Misura innanzitutto ciascun carico di lavoro da solo: tempo di elaborazione dei fotogrammi, velocità di codifica e decodifica, utilizzo dell'acceleratore, uso della memoria, temperatura, consumo energetico e latenza dell'applicazione. Poi esegui entrambi contemporaneamente al loro normale picco. La configurazione condivisa è accettabile solo quando il carico di lavoro critico correlato a Home Assistant rispetta i propri tempi limite e nessuna delle due applicazioni inizia a generare errori o a ricorrere a un fallback.

Il test esistente di ZimaSpace sulla condivisione di una GPU tra container fornisce la stessa regola operativa: la visibilità del dispositivo è solo il primo requisito; la stabilità durante l'esecuzione simultanea e la contesa per le risorse determinano se la condivisione sia davvero utile.

Mantieni un acceleratore condiviso quando entrambi i consumatori restano entro i limiti di latenza e memoria durante la sovrapposizione reale. Separali quando un processo causa fotogrammi persi, ritardi nell'inferenza, ripristini del driver, errori di memoria insufficiente, throttling termico o fallback imprevedibili. Se la GPU viene assegnata interamente a una macchina virtuale tramite passthrough, riprogetta il livello di virtualizzazione o aggiungi un altro acceleratore, invece di tentare di mappare in un secondo container il dispositivo fisico già assegnato.