Quali componenti consentono a più modelli locali di condividere un unico acceleratore?

Più modelli locali possono condividere un unico acceleratore quando il livello di serving coordina la permanenza dei pesi in memoria, la memoria dinamica, il tempo di esecuzione e l’isolamento delle richieste tra i diversi carichi di lavoro.

Una GPU domestica può alternare un modello conversazionale, un modello di embedding, un encoder per la visione e il riconoscimento vocale. Caricare permanentemente ogni set di pesi può superare la VRAM disponibile, mentre scaricarlo a ogni richiesta rende irregolare la latenza del primo token. Un controller multimodello deve gestire le politiche di permanenza in memoria, la contabilità della memoria tra modelli, la pianificazione, l’isolamento delle cache, la prelazione e l’equità, invece di affidarsi a processi separati che competono alla cieca.

La politica di permanenza decide quali pesi restano pronti

Il controller tiene traccia delle dimensioni del modello, della frequenza di arrivo, del tempo di caricamento, dell’obiettivo di latenza e dell’utilizzo recente. I modelli più popolari restano residenti, quelli utilizzati meno spesso occupano la CPU o lo spazio di archiviazione, mentre la domanda prevista può attivare il pre-riscaldamento prima che la richiesta successiva raggiunga l’acceleratore.

il pre-riscaldamento multimodello prepara worker GPU universali per più modelli e coordina il pre-riscaldamento con un posizionamento consapevole delle espulsioni. I risultati mostrano perché evitare un caricamento a freddo può migliorare drasticamente il tempo al primo token in presenza di una domanda prevedibile. Questa distinzione resta visibile durante i test domestici successivi.

Le decisioni sulla permanenza devono includere le varianti di quantizzazione e degli adapter, perché due endpoint apparentemente simili possono contenere pesi di base diversi. Un limite di memoria rigido impedisce al caricamento proattivo di espellere la cache KV delle richieste attive. Il risultato intermedio deve restare ispezionabile prima che l’automazione proceda.

Il coordinamento della memoria tra modelli evita la frammentazione della capacità

I pesi sono per lo più stabili, mentre le attivazioni e le cache KV aumentano con la dimensione del batch e la lunghezza della sequenza. Un allocatore condiviso può mappare le pagine di memoria su richiesta, recuperare le regioni inattive ed esporre delle prenotazioni, impedendo a un modello di consumare lo spazio promesso a un altro.

il coordinamento della memoria tra modelli introduce il coordinamento della memoria tra modelli, con mappatura dinamica delle pagine virtuali in quelle fisiche e politiche di condivisione in fase di esecuzione. Il progetto spiega perché la normale condivisione della GPU a livello di processo non riesca a reagire adeguatamente alla domanda dei modelli, che cambia rapidamente. Questo limite dovrebbe essere misurato separatamente in condizioni operative realistiche.

Condividere la memoria non significa condividere i dati. I blocchi della cache KV, le cache dei prefissi, i buffer temporanei e lo stato degli adapter richiedono identificatori del tenant e del modello; altrimenti una pagina riutilizzata o una chiave della cache può divulgare il contesto o corrompere i risultati tra gli endpoint.

La pianificazione e il multiplexing degli adapter controllano il tempo di esecuzione

Un pianificatore sceglie tra la condivisione spaziale, in cui i modelli occupano contemporaneamente la memoria, e la condivisione temporale, in cui i kernel si alternano. Il batching continuo migliora il throughput, mentre la prelazione e le code con pesi proteggono una richiesta interattiva da un lungo processo in background.

il multiplexing degli adapter gestisce migliaia di adapter a basso rango su modelli di base condivisi, suddividendo in pagine i pesi degli adapter e coordinando batch eterogenei. Dimostra come la specializzazione possa condividere una quantità di stato maggiore rispetto a repliche di modelli completamente separate. La conseguenza pratica emerge quando diverse fonti competono per un contesto limitato.

Il limite critico riguarda l’interferenza tra kernel e memoria. Due modelli che entrano simultaneamente in memoria possono comunque non rispettare gli obiettivi di latenza quando competono per capacità di calcolo, larghezza di banda o motori di copia. La condivisione è utile solo quando la latenza p95 e l’equità per ciascun modello restano entro i limiti stabiliti dalla politica, non quando l’utilizzo aggregato appare semplicemente elevato.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Costruisci una matrice delle interferenze tra modelli condivisi

Misura ogni modello singolarmente, quindi esegui ogni coppia importante e la combinazione prevista di quattro modelli con richieste brevi, lunghe, a raffica e in background. Registra il tempo di caricamento a freddo, la memoria residente, la crescita della cache KV, l’utilizzo dei kernel, il throughput, la latenza p50 e p95 e le espulsioni.

Utilizza il principio dello stack instradato descritto in permanenza instradata dei modelli per assegnare una priorità e una classe di permanenza a ogni endpoint. Ripeti i test con adapter, varianti quantizzate, batching continuo e prelazione, verificando che le cache e le identità delle richieste restino isolate.

Mantieni una politica di condivisione solo quando i modelli interattivi importanti raggiungono l’obiettivo di latenza durante la combinazione peggiore prevista. Se una coppia causa continui cicli di caricamento ed espulsione, serializza quella coppia o riservale una finestra temporale invece di aumentare la concorrenza per ottenere un grafico di utilizzo migliore.