Un servizio di IA locale può passare alla CPU quando la memoria della GPU è piena?

Sì, ma il failover affidabile della CPU deve essere progettato prima che la memoria della GPU si esaurisca; la maggior parte dei processi di inferenza non recupera in modo trasparente da un OOM imprevisto.

Un server AI domestico può rispondere rapidamente sulla GPU finché un prompt più lungo, un batch più grande, una richiesta di immagini o un secondo modello non consuma la VRAM rimanente. L'allocazione successiva può fallire anche se la RAM di sistema e la CPU sono inattive. La sopravvivenza della richiesta dipende dal runtime: alcuni possono collocare i pesi sulla CPU fin dall'inizio, mentre altri richiedono un worker CPU separato e un router che riprovi in sicurezza.

CPU Offload e failover della CPU risolvono problemi diversi

Il CPU offload è una strategia di collocazione del modello. Alcuni layer, tensori o componenti della pipeline risiedono nella RAM di sistema e vengono trasferiti all'acceleratore quando necessario, riducendo la VRAM richiesta per una richiesta normale. Il failover della CPU è un comportamento del servizio: quando il percorso GPU non è disponibile o rifiuta una richiesta, un altro worker la accetta ed esegue un modello compatibile con la CPU senza perdere il job.

Hugging Face Accelerate espone i metodi di CPU offload che spostano deliberatamente lo stato del modello tra la memoria della CPU e un dispositivo di esecuzione. Si tratta di un'esecuzione eterogenea pianificata, non di una risposta d'emergenza dopo un errore arbitrario dello stato CUDA. Il modello, la mappa dei dispositivi, gli hook e il budget di memoria vengono preparati prima dell'inizio dell'inferenza.

Un modello parzialmente sottoposto a offload può utilizzare già la CPU, pur dipendendo ancora dalla GPU per ogni token. Se la GPU si guasta, il processo non può necessariamente continuare sulla CPU dal token interrotto. Il vero failover di solito riavvia la richiesta su un worker pronto per la CPU. Questa distinzione spiega perché un'applicazione possa dichiarare il supporto alla CPU e restituire comunque un errore OOM invece di completare la richiesta corrente.

La VRAM può esaurirsi dopo il caricamento corretto di un modello

I pesi del modello sono solo una parte del budget di memoria. La cache key-value cresce con la lunghezza della sequenza attiva e la concorrenza, i kernel temporanei richiedono spazio di lavoro, gli encoder di immagini o audio aggiungono tensori e un allocatore di memoria può riservare blocchi per il riutilizzo. Un modello che entra in memoria all'avvio può quindi fallire con un contesto lungo o con diversi utenti simultanei.

PyTorch utilizza un allocatore di memoria con caching, quindi la memoria indicata come riservata non è identica alla memoria dei tensori attivi. La frammentazione e le allocazioni effettuate al di fuori del framework possono ridurre ulteriormente il margine utilizzabile. Un trigger di failover dovrebbe monitorare le allocazioni rifiutate e lo stato di salute del worker, non dedurre la sicurezza da un singolo valore del dashboard o dal semplice fatto che il caricamento del modello sia riuscito.

Per questo anche una regola statica del tipo “dimensione del modello inferiore alla VRAM” è incompleta. Un servizio può imporre un limite inferiore alla lunghezza del contesto, limitare le sequenze simultanee o lasciare inutilizzata una percentuale della VRAM per proteggere le allocazioni del runtime. Questi controlli prevengono più errori rispetto al passaggio reattivo alla CPU, perché mantengono il processo GPU in uno stato noto e preservano una latenza prevedibile per le richieste accettate.

Il nuovo tentativo automatico è sicuro solo quando la richiesta può essere riprodotta

Dopo un OOM, il router può contrassegnare il worker GPU come non integro, rilasciarlo o riavviarlo e riprodurre la richiesta originale su un worker CPU. Questo funziona per la normale generazione di testo quando non si è verificato alcun effetto esterno. È più complesso per le risposte in streaming, le pipeline di immagini con semi casuali o gli agenti che potrebbero aver già chiamato uno strumento.

I framework possono anche distribuire i modelli di grandi dimensioni tra i dispositivi fin dall'inizio. La big-model inference di Accelerate supporta le mappe dei dispositivi e il posizionamento su CPU o disco quando un modello supera la capacità di un singolo dispositivo. Questo approccio può mantenere attiva una richiesta all'interno di un unico grafo di esecuzione pianificato, ma sacrifica la velocità a favore della capacità e non deve essere confuso con il reindirizzamento di una richiesta fallita a un servizio separato.

La promessa del failover non è più valida quando la CPU non dispone di RAM sufficiente, il runtime non ha kernel CPU compatibili, la richiesta ha già prodotto un'azione irreversibile o la latenza CPU prevista supera il timeout del client. In questi casi, restituisci un errore di capacità controllato oppure accoda la richiesta. Riprovare silenziosamente può duplicare effetti collaterali o lasciare gli utenti in attesa molto più a lungo di quanto prometta l'interfaccia.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Dimostra il failover con un test di memoria intenzionale

Esegui un worker GPU e un worker CPU dietro un router, quindi invia una richiesta che superi il profilo della GPU senza superare la RAM di sistema. Registra il primo errore, la decisione di riprovare, l'ora di avvio sulla CPU, l'output finale e l'eventuale sopravvivenza della connessione del client. Ripeti prima con lo streaming disabilitato, quindi testa l'annullamento, il traffico simultaneo e una richiesta di un agente con uno strumento simulato.

L'esecuzione parziale sulla GPU è un utile punto di riferimento perché i runtime come l'inferenza llama.cpp possono collocare una parte configurabile del lavoro del modello sugli acceleratori mantenendo l'esecuzione sulla CPU. Confronta i profili con modello residente sulla GPU, suddivisione CPU/GPU pianificata e fallback CPU indipendente. Un modello di carico di lavoro AI ibrido aiuta a distinguere il fallback per capacità dal normale instradamento verso il cloud.

Definisci il design affidabile solo se il nuovo tentativo termina una volta sola, conserva l'identità della richiesta, evita azioni duplicate degli strumenti e ripristina il worker GPU senza interrompere i job non correlati. Se il completamento sulla CPU è troppo lento, usalo come percorso di sicurezza che preserva la coda, non come equivalente interattivo. L'obiettivo operativo è un degrado graduale, non fingere che i livelli di servizio CPU e GPU siano intercambiabili.

Domande frequenti

Svuotare la cache della GPU crea un failover?

No. Il rilascio della cache può rendere disponibili blocchi riservati inutilizzati, ma non crea l'esecuzione sulla CPU, non ripara lo stato corrotto di una richiesta e non garantisce memoria contigua sufficiente per l'allocazione successiva.

Il fallback sulla CPU produrrà la stessa risposta?

Può farlo quando vengono utilizzati gli stessi pesi, la stessa precisione, lo stesso prompt, lo stesso tokenizer e lo stesso stato di campionamento. Kernel, quantizzazione, semi o stato dello streaming riavviato differenti possono comunque modificare l'output esatto.

Un modello più piccolo è migliore del failover sulla CPU?

Spesso sì, per un servizio interattivo. Un modello GPU più piccolo può offrire una latenza prevedibile, mentre il failover sulla CPU protegge la disponibilità per le richieste eccezionali. I due meccanismi risolvono obiettivi di servizio diversi e possono essere combinati.