IT
Un planner individua dove fondere il lavoro GPU nei modelli streaming
One Megakernel is Not Enough: Predicting Where to Cut for Streaming Inference · arXiv:2610.35336
In parole semplici
I modelli streaming producono risultati in più fasi, e fasi diverse possono funzionare meglio con impostazioni GPU diverse. Riunirle in un kernel persistente può ridurre il tempo perso ad avviare i kernel, ma un unico kernel enorme può adattarsi male al lavoro.
Il paper presenta un planner che usa misurazioni già disponibili e simula quando le fasi possono essere eseguite e pubblicare il risultato, per decidere quali fasi combinare. Su una GPU, ha scelto la configurazione misurata più veloce in tutti e 13 i casi di modello e dimensione del batch esaminati, tra le configurazioni che gli autori avevano implementato e verificato.
La ricerca
Quando un modello streaming produce il suo primo risultato, come andrebbero raggruppate le sue fasi sulla GPU? Fasi diverse possono procedere a velocità diverse e preferire configurazioni di avvio diverse; inoltre, la pubblicazione può dipendere dal lavoro di più fasi. Perciò, dai soli stadi del modello non è ovvio dove collocare i confini della fusione.
Il planner combina profili già disponibili, misurazioni compatibili dei kernel e una simulazione delle dipendenze dell’output per classificare configurazioni di fusione supportate senza misurarle una per una dall’inizio alla fine.
Il planner combina profili già disponibili, misurazioni compatibili dei kernel e una simulazione delle dipendenze dell’output per classificare configurazioni di fusione supportate senza misurarle una per una dall’inizio alla fine.
Su una GPU H100 NVL, la sua selezione fissata coincideva con la configurazione misurata più veloce in tutti e 13 i casi di modello e dimensione del batch esaminati, confrontando le configurazioni implementate e qualificate per ciascun modello. Il risultato supporta il metodo di classificazione all’interno di quei gruppi di validazione.
Il risultato di 13 selezioni corrette su 13 riguarda le configurazioni che gli autori hanno implementato e qualificato su una GPU H100 NVL. Non individua la scelta migliore tra configurazioni non misurate o su altre architetture GPU.
Cosa mostrano le prove
- La fusione dipende dai confini
Il planner dei confini, consapevole del momento della prima pubblicazione, seleziona quali regioni contigue di un modello streaming fondere in megakernel, quali eseguire in modo convenzionale e come ripartire la GPU tra le regioni.
La scelta conta perché le fasi possono avere velocità diverse e preferire configurazioni di avvio diverse, mentre la pubblicazione del primo risultato può dipendere da più di una fase. I confini influenzano sia l’uso delle risorse GPU sia il momento in cui il risultato può essere pubblicato.
- Classificare composizioni supportate
Invece di misurare ogni configurazione completa, il planner combina profili dell’esecuzione convenzionale, misurazioni di operatori o passaggi e dettagli d’implementazione dichiarati nel codice sorgente. Usa le misurazioni compatibili per stimare i tempi di esecuzione, costruisce composizioni supportate e simula come procedono il lavoro e le dipendenze necessarie alla pubblicazione.
Le candidate senza dati compatibili sul costo vengono escluse, quindi il risultato classifica solo configurazioni che il planner può supportare.
- In un caso vincono tre megakernel
Il confronto su NH-TTS con batch di dimensione 32 mostra perché contano sia quanto si fonde sia la sovrapposizione del lavoro. Su una GPU H100 NVL, una configurazione con tre megakernel e lavoro sovrapposto ha pubblicato il primo audio 4.05 volte prima rispetto all’esecuzione convenzionale con TensorRT e con un anticipo del 21.4% rispetto a un singolo megakernel.
In questo caso, le misurazioni mostrano che né l’esecuzione convenzionale né la fusione dell’intero modello erano la configurazione provata più veloce.
- Le selezioni coincidono con le vincitrici misurate
Gli autori hanno testato 13 casi di modello e dimensione del batch su una GPU H100 NVL, con tre modelli e tre framework. In ciascun caso, la scelta fissata dal planner coincideva con la configurazione misurata più veloce nel gruppo di configurazioni implementate e qualificate per quel modello.
Il risultato supporta la capacità del planner di selezionare tra quelle candidate misurate; non dimostra che i gruppi contenessero ogni composizione possibile.
- La sovrapposizione e la dimensione del batch contano
Due controlli hanno usato gli stessi costi di esecuzione e gli stessi gruppi di candidate, ma hanno sostituito la simulazione degli eventi con un punteggio additivo oppure eliminato la sovrapposizione. Entrambi hanno individuato 11 vincitrici misurate su 13, scegliendo l’esecuzione in serie per NH-TTS con batch 32 e 64.
Separatamente, per Qwen3-TTS quattro megakernel erano preferibili fino al batch 32, mentre l’esecuzione convenzionale era più veloce con batch 48 e 64. Questi risultati sostengono l’idea che il ruolo della sovrapposizione e il grado di fusione utile dipendano dal caso.
Dettagli
- Autori del paper originale
- Aditya Chatterjee, Anand Joseph X M, Sanjay Singh Chauhan
- Inviato ad arXiv
- Licenza
- CC BY 4.0