Sintesi Tecnica: GF-DiT: Programmazione del Parallelismo per il Serving di Diffusion Transformer

Problema

I Diffusion Transformer (DiT) sono diventati l'architettura dominante per l'IA generativa moderna, eppure gli attuali sistemi di serving faticano a gestire efficientemente i loro carichi di lavoro eterogenei. I sistemi attuali (ad es., vLLM-Omni, SGLang Diffusion) si affidano al parallelismo statico, assegnando a ogni richiesta una configurazione GPU fissa (ad es., un determinato grado di parallelismo di sequenza) per l'intero ciclo di vita. Questo approccio non riesce ad affrontare tre fonti critiche di eterogeneità:

1. Eterogeneità delle Richieste: Le risoluzioni di output, le durate dei video e il numero di step di denoising variano significativamente, causando differenze di ordini di grandezza nella domanda computazionale.
2. Eterogeneità degli Stadi: Diversi stadi della pipeline DiT (encoder, denoising, decoder) presentano comportamenti di scaling fondamentalmente differenti. Ad esempio, il denoising beneficia di grandi gruppi di parallelismo di sequenza, mentre encoder e decoder sono spesso leggeri ed efficienti su un singolo rank.
3. Eterogeneità del Sistema: La dinamica dei carichi di lavoro (tassi di arrivo, condizioni di coda) e gli obiettivi di servizio (latenza vs. throughput vs. SLO) cambiano nel tempo. Una configurazione ottimale al momento dell'ammissione può diventare inefficiente man mano che le condizioni evolvono.

Il parallelismo statico porta al blocco Head-of-Line (HoL), in cui le richieste a lunga durata ritardano quelle più brevi, e a una scarsa utilizzazione delle risorse, dove gli stadi leggeri sprecano risorse GPU o i compiti di denoising voluminosi risultano sotto-provisionati. Il problema centrale è che i sistemi esistenti trattano il parallelismo come una decisione di deployment fissa piuttosto che come una risorsa programmabile e dinamica.

Metodologia

Il documento propone GF-DiT, un runtime programmabile tramite policy che tratta il parallelismo GPU come una risorsa programmabile di prima classe. Il sistema adatta dinamicamente il parallelismo delle richieste in esecuzione in base alle richieste del carico di lavoro e agli obiettivi di servizio. GF-DiT si basa su tre pilastri tecnici chiave:

1. Esecuzione Asincrona e Task di Traiettoria Riprogrammabili

GF-DiT decompone una richiesta DiT in un grafo di task di traiettoria (encoding, singoli step di denoising e decoding).

• Confini di Riprogrammazione: A differenza dei modelli autoregressivi LLM dove la generazione di token fornisce confini granulari, le richieste DiT espongono naturali punti di programmazione agli stadi e ai confini degli step di denoising. Il completamento di uno step produce uno stato latente semanticamente completo, permettendo al runtime di riassegnare in sicurezza le risorse.
• Prevedibilità: Le strutture di esecuzione DiT sono ampiamente deterministiche prima dell'esecuzione (risoluzione, step e traiettoria noti). Ciò consente al runtime di stimare i costi di esecuzione e le future richieste di risorse con precisione, consentendo l'adattamento online senza dover fare supposizioni.
• Modello Asincrono: Il runtime separa il piano di controllo (scheduling, tracciamento delle dipendenze) dal piano di esecuzione (worker GPU). Il completamento del dispatch è disaccoppiato dal completamento del dispositivo, permettendo alla programmazione lato CPU e alla pianificazione della migrazione di sovrapporsi all'esecuzione su GPU.

2. Collective Senza Gruppi (Group-Free Collectives - GFC)

Per rendere pratico il parallelismo dinamico, il sistema deve supportare la rapida creazione e riconfigurazione di gruppi di esecuzione senza incorrere nell'elevato overhead delle librerie di comunicazione tradizionali.

• La Sfida: Le librerie convenzionali (ad es., NCCL) richiedono la costruzione di oggetti process_group per ogni sottogruppo. Ciò comporta costi di coordinamento e inizializzazione lato host (centinaia di millisecondi) e un significativo overhead di memoria, il che è proibitivo per una riconfigurazione fine e online.
• La Soluzione: GFC elimina la costruzione esplicita del comunicatore.
  • Setup a Livello di World: Viene eseguito un singolo setup di comunicazione a livello di world all'avvio del server, allocando buffer di comunicazione simmetrici.
  • Descrittori Logici: I sottogruppi dinamici sono rappresentati da descrittori logici leggeri (ID di rank e ordinamento) piuttosto che da pesanti oggetti comunicatori.
  • Ordinamento Coerente per Coppia: Per garantire la correttezza nei gruppi sovrapposti, GFC impone che qualsiasi coppia di rank osservi le istanze collettive nello stesso ordine. Utilizza un meccanismo di segnalazione a doppio buffer attaccato agli archi dei rank (anziché ai gruppi) per gestire i token di sincronizzazione, evitando l'esplosione combinatoria dello stato.
  • Staging: Il movimento dei dati è gestito tramite buffer di staging, consentendo al runtime di pipelining le copie locali con i trasferimenti remoti e di selezionare i backend ottimali (kernel CUDA, motori di copia, TMA) in base alla dimensione del messaggio.

3. Runtime Programmabile tramite Policy

GF-DiT espone un'interfaccia unificata in cui le policy di scheduling possono controllare congiuntamente l'ordinamento dei task, il posizionamento e il parallelismo.

• Interfaccia di Policy: Le policy osservano i task pronti, la disponibilità delle risorse e le stime dei costi, per poi restituire decisioni di dispatch che specificano il task e il layout di esecuzione (gruppo logico + specifica di parallelismo).
• Flessibilità: Ciò consente l'implementazione e la valutazione di diverse strategie (ad es., FCFS, Shortest Remaining Trajectory First, Earliest Deadline First) senza riscrivere il runtime sottostante o la logica del modello.
• Simulatore: Un simulatore utilizza lo stesso grafo di task e l'interfaccia di policy, ma sostituisce l'esecuzione su GPU con previsioni basate su modelli di costo, consentendo l'esplorazione e la selezione offline delle policy.

Contributi Chiave

1. Nuova Astrazione: Il documento introduce il concetto di trattare il parallelismo GPU come una risorsa programmabile di prima classe, spostando il paradigma dal deployment statico alla gestione dinamica del runtime.
2. Runtime GF-DiT: Un sistema programmabile tramite policy che abilita la riallocazione GPU online attraverso l'esecuzione asincrona e i task di traiettoria riprogrammabili.
3. Collective Senza Gruppi (Group-Free Collectives): Un'astrazione di comunicazione leggera che riduce l'overhead di formazione dei gruppi dinamici da centinaia di millisecondi a circa 60 µs, rendendo pratico il parallelismo elastico.
4. Implementazione e Valutazione: Un'implementazione completa in vLLM-Omni che dimostra miglioramenti significativi rispetto all'esecuzione a pipeline fissa.

Risultati

Valutato su carichi di lavoro di diffusione di immagini (Qwen-Image) e video (Wan2.2) su GPU H20 e A100, GF-DiT dimostra miglioramenti sostanziali rispetto ai baseline di parallelismo statico:

• Throughput: Migliorato fino a 6,01×.
• Latenza: Ridotta la latenza media fino al 95%.
• Violazioni SLO: Ridotte le percentuali di violazione degli SLO fino al 90%.
• Overhead di Comunicazione: Ridotto l'overhead di setup del gruppo di comunicazione da 778 ms a circa 60 µs.
• Efficacia della Policy: La policy EDF (Earliest Deadline First) ha ottenuto il più alto raggiungimento degli SLO (ad es., migliorando dal 7,5% all'88,8% nei carichi di lavoro video bursty), mentre SRTF (Shortest Remaining Trajectory First) ha minimizzato la latenza media in scenari specifici. I risultati confermano che nessuna singola configurazione statica è ottimale; l'adattamento dinamico è necessario.

Significato e Rivendicazioni

Il documento sostiene che la natura statica del parallelismo nei sistemi di serving DiT attuali sia un collo di bottiglia fondamentale. Trattando il parallelismo come una risorsa programmabile, GF-DiT consente ai sistemi di reagire in tempo reale alla dinamica dei carichi di lavoro e agli obiettivi di servizio.

Gli autori affermano che GF-DT rende il parallelismo elastico pratico per il serving dell'IA generativa nel mondo reale. La significatività non risiede nella proposta di nuovi kernel paralleli, ma nel fornire un substrato programmabile che permette di selezionare e riconfigurare dinamicamente i layout di esecuzione esistenti. Ciò consente un passaggio dallo "schedulare le richieste" allo "schedulare il parallelismo", garantendo che le risorse GPU fluiscano continuamente dove possono fornire il maggior beneficio, migliorando così simultaneamente throughput, latenza e raggiungimento degli SLO. Il lavoro suggerisce che i futuri sistemi di serving per l'IA generativa dovrebbero abbracciare il parallelismo gestito dal runtime come una fondamentale astrazione di sistema.