Misurare il collo di bottiglia prima di spostare il lavoro sulla GPU

Un modello può superare la memoria della GPU, un flusso video può essere più rapido da elaborare di quanto consenta il processore e le chiamate ripetute a un modello possono impiegare tempo per preparare il testo o recuperare uno stato salvato.

Ogni problema suggerisce un uso diverso della memoria e del calcolo, con i relativi costi di trasferimento o preparazione.

In quattro studi, il primo passo utile è misurare dove uno specifico carico di lavoro impiega tempo.

Collocare i dati, preparare il lavoro in anticipo, spostare l’elaborazione del testo sulla GPU e riutilizzare uno stato remoto modificano costi diversi; risparmiare calcolo non riduce di per sé la memoria occupata dai dati né garantisce una risposta più rapida.

Immagina di gestire un chatbot il cui modello supera la memoria della GPU, mentre un altro servizio risponde a domande su un flusso video in diretta. Un assistente di programmazione aggiunge un’ulteriore complicazione: invia gran parte della stessa lunga conversazione in chiamate successive al modello.

Sono problemi concreti di capacità e latenza. Tenere i dati del modello vicino alla GPU può accelerare la generazione; tenere pronto il video può velocizzare una risposta successiva; riutilizzare una conversazione precedente può ridurre il lavoro del modello. Ogni scelta occupa una risorsa o sposta dati prima di produrre un beneficio.

Una risposta lenta non ne identifica la causa. Quando la memoria della GPU si riempie, recuperare un’altra pagina può richiedere di liberarne una già presente.

In un servizio video, preparare ogni fotogramma in arrivo per ogni possibile domanda può consumare la capacità di elaborazione necessaria per stare al passo con il flusso. Nelle chiamate ripetute a un modello, il testo deve comunque essere convertito nei dati di input del modello e recuperare un risultato salvato può richiedere tempo.

La domanda comune è dove collocare il lavoro e quando svolgerlo, rispettando i limiti di uno specifico carico di lavoro.

I quattro studi modificano aspetti diversi di questa decisione. Ember cambia dove risiedono i dati gestiti quando la GPU ha memoria insufficiente.

StreamAhead decide quanta elaborazione video completare prima che arrivi una domanda, creando rappresentazioni salvate riutilizzabili. GraphTok sposta la conversione del testo dal processore host alla GPU, cambiando così dove viene eseguito il calcolo.

Uno studio sulla cache remota chiede se caricare lo stato salvato del modello sia più rapido che ricalcolarlo. Non si può attribuire a queste scelte un’unica promessa di velocità: riducono lavori diversi e comportano costi diversi.