Riepilogo Tecnico: FMplex – Virtualizzazione dei Modelli per il Servizio di Foundation Model Estensibili

Problema

I Foundation Model (FM) sono diventati l'ossatura per diverse applicazioni downstream nei domini del linguaggio, della visione, delle serie temporali e multimodali. Tuttavia, i sistemi esistenti per il servizio dei modelli (ad esempio, NVIDIA Triton) sono progettati attorno a un paradigma "un'istanza per task", in cui ogni task personalizzato carica una copia separata e indipendente del modello. Questo approccio è inefficiente per i FM perché:

1. Spreco di Risorse: I FM consistono in un massiccio backbone condiviso (spesso di dimensioni gigabyte) e in estensioni specifiche per il task (testine, adapter) leggere. Caricare un intero backbone per ogni task replica la componente più pesante, sprecando la memoria dell'acceleratore.
2. Efficienza Perduta: Le istanze indipendenti impediscono l'ammortizzazione dei costi di batching e di caricamento tra i vari task.
3. Interferenza e Isolamento: Il semplice co-posizionamento dei task su una GPU condivisa senza separazione logica porta all'interferenza tra i task, dove i picchi di carico di un task degradano le prestazioni degli altri.
4. Rigidità del Ciclo di Vita: Gli attuali sistemi accoppiano il ciclo di vita del task all'istanza fisica del modello, rendendo difficile aggiungere, rimuovere o modificare i task senza ridistribuire l'intero backbone.

L'articolo sostiene che il backbone del FM debba essere trattato come un substrato di sistema condiviso (analogamente a una CPU o alla memoria nella virtualizzazione dei sistemi operativi) piuttosto che come un artefatto di deployment per singolo task.

Metodologia: FMplex

Gli autori presentano FMplex, un sistema di serving che introduce la Virtualizzazione dei Foundation Model. Il concetto centrale è il Virtual Foundation Model (vFM), un'istanza di FM logicamente privata presentata a ciascun task, che è supportata da un'istanza fisica di FM condivisa.

Componenti Architetturali Chiave

1. Astrazione del Virtual Foundation Model (vFM):

   • Disaccoppiamento: Il vFM disaccoppia la vista logica del task (personalizzazione, stato, ciclo di vita) dal backbone fisico.
   • Struttura: Ogni vFM include una Virtual Queue (per il routing delle richieste), Task Extensions (encoder, decoder e adapter PEFT come LoRA) e State/Accounting (SLO, priorità, pesi).
   • Meccanismo: Quando un task invoca il proprio vFM, FMplex intercetta la chiamata, la instrada attraverso la coda virtuale ed esegue l'operazione sul backbone fisico condiviso, applicando gli adapter specifici del task secondo necessità.

2. Scheduler Batch-Aware Fair Queueing (BFQ):

   • Sfida: Gli scheduler standard per la ripartizione equa (ad esempio, Start-Time Fair Queueing) operano su base singola per richiesta e non tengono conto dei vantaggi di efficienza derivanti dal batching delle richieste, che è critico per il throughput dei FM.
   • Soluzione: BFQ è uno scheduler work-conserving che approssima la ripartizione equa ponderata ottimizzando al contempo il batching.
   • Operazione: Assegna tag di inizio/fine alle richieste in base ai pesi dei task. Forma iterativamente dei batch fino a una dimensione massima ($B_{max}$) o fino a quando un limite di SLO non verrebbe violato.
   • Gestione degli Adapter: BFQ gestisce l'incompatibilità degli adapter effettuando prima il batching delle richieste sul backbone comune e poi processando sequenzialmente le differenze degli adapter incompatibili, garantendo l'equità senza sacrificare l'efficienza del batching.
   • Supporto basato su Token: Per i FM basati su token (ad esempio, LLM), BFQ addebita il lavoro a livello di token in unità di tempo di servizio per mantenere la coerenza con i tempi di esecuzione a livello di richiesta.

3. Task-API e Stack di Servizio:

   • Task-API: Un'interfaccia di programmazione che consente agli utenti di costruire pipeline di task attaccando encoder, decoder e adapter a un vFM. Supporta sia l'inferenza che il fine-tuning utilizzando lo stesso oggetto di pipeline.
   • FMplex-Controller: Un controller a livello di cluster che gestisce il piano di deployment. Utilizza un'euristica "Max-Share" per vincolare i task a backbone fisici esistenti ogni volta che è possibile, minimizzando l'instanziazione di nuovi backbone.
   • Adattamento Elastico: Quando il carico cambia, il sistema può ricollegare il vFM di un task a un diverso backbone fisico esistente, spostando solo lo stato leggero del task (code, adapter) invece di ricaricare l'intero backbone pesante.

Contributi Chiave

1. Virtualizzazione dei FM per la Condivisione del Deployment: L'introduzione dell'astrazione vFM, che consente a molteplici task indipendentemente personalizzati di condividere un singolo istanza fisica di FM mantenendo l'isolamento logico e cicli di vita indipendenti.
2. Stack di Servizio Basato sulla Condivisione: Un sistema end-to-end che integra la Task-API per la costruzione estensibile dei task e l'FMplex-Controller per il deployment del cluster consapevole della condivisione.
3. Prototipo Implementato: Un prototipo funzionale che supporta molteplici modalità (serie temporali, visione, LLM, VLM) e runtime (PyTorch, vLLM), dimostrando flessibilità attraverso eterogenei FM.
4. Valutazione Esaustiva: Una valutazione rigorosa su 7 backbone FM (16 varianti) e 92 task downstream.

Risultati Sperimentali

La valutazione è stata condotta su un cluster AWS a 16 nodi (GPU NVIDIA T4) utilizzando tracce sintetiche e reali (Azure Functions).

• Riduzione della Latenza:

  • Rispetto al Spatial Partitioning (isolamento dei task su partizioni GPU), FMplex ha ridotto la latenza fino all'80%.
  • Rispetto al Best-Effort Co-location (molteplici istanze complete su una singola GPU senza isolamento), FMplex ha ridotto la latenza fino al 33,3%.
  • Su scala di cluster, FMplex ha ridotto la latenza media del 15% e la latenza P99 del 26% rispetto al best-effort co-location.

• Efficienza delle Risorse e Scalabilità:

  • Memoria: FMplex riduce significativamente l'uso della memoria GPU. Ad esempio, il co-posizionamento di 10 task di serie temporali su un backbone condiviso richiedeva solo 1,17× la memoria di un singolo task, rispetto a 10× per un deployment indipendente.
  • Throughput: FMplex ha sostenuto fino a 6× più task a basso carico (dove la memoria è il collo di bottiglia) e 8–12% più task a carico moderato/alto (dove il calcolo è il collo di bottiglia) rispetto al best-effort co-location.
  • Equità (Fairness): Sotto pesi di servizio asimmetrici (ad esempio, 3:1), FMplex ha mantenuto punteggi di fairness di 0,97–0,98 sostenendo 84 RPS. Al contrario, il fair-sharing non batched ha ottenuto una fairness simile a soli 37 RPS, mentre la condivisione non gestita ha fatto scendere la fairness a 0,66.

• Overhead di Adattamento:

  • FMplex ha dimostrato una rapida adattabilità ai picchi di carico. Ricollegare un task a un backbone esistente ha richiesto 0,5 secondi, mentre il caricamento di una nuova istanza di backbone (come richiesto dai sistemi non basati sulla condivisione) ha richiesto ~58 secondi, causando un picco di latenza di due ordini di grandezza.

• Overhead: L'overhead di scheduling introdotto da FMplex (gestione code e calcolo tag) è stato minimo, con una media di 0,35 ms per richiesta, un valore trascurabile rispetto ai tempi di esecuzione del backbone.

Significato e Rivendicazioni

L'articolo sostiene che FMplex affronti il disallineamento fondamentale tra l'architettura dei Foundation Model (backbone pesanti e condivisi, estensioni leggere) e gli attuali sistemi di servizio (deployment per singola istanza). Trattando il backbone del FM come un substrato di virtualizzazione, FMplex consente:

• Deployment Sharing: Ammortizzare i pesanti costi di memoria e calcolo del backbone tra molteplici task.
• Isolamento dei Task: Fornire garanzie di prestazione e isolamento per task senza la penalità di risorse di una replica completa del modello.
• Flessibilità Operativa: Consentire l'aggiunta, la rimozione o la modifica dei task dinamicamente senza ridistribuire l'infrastruttura sottostante.

Gli autori posizionano FMplex non solo come un'ottimizzazione per modelli specifici, ma come uno strato di sistema generalizzabile che estende i principi classici della virtualizzazione al dominio del servizio dei Foundation Model, abilitando un'infrastruttura AI più efficiente e scalabile.