Riepilogo Tecnico: SMEPilot

Problematica

Le moderne CPU stanno integrando sempre più estensioni per matrici, come l'Arm Scalable Matrix Extension (SME), per fornire l'esecuzione di matrici ad alto throughput all'interno del pacchetto CPU. Sebbene queste estensioni offrano una via di mezzo tra gli acceleratori GPU e i convenzionali core vettoriali, non sono un sostituto universale per i core della CPU nell'inferenza di Large Language Models (LLM).

La sfida principale identificata è un disallineamento tra i requisiti eterogenei degli operatori LLM e le capacità statiche delle unità SME.

• Caratteristiche Diverse degli Operatori: L'inferenza LLM comporta fasi distinte (prefill vs. decode) e operatori (attention, FFN, MoE) con diverse intensità aritmetiche, comportamenti vettoriali e requisiti di layout.
• Contesa delle Risorse: Le unità SME e i core della CPU condividono la larghezza di banda della memoria e le gerarchie della cache. Trattare l'SME come un semplice sostituto "drop-in" dei kernel della CPU porta a prestazioni subottimali perché:
  1. Sottoutilizzo Spaziale: Gli operatori di grandi dimensioni ricchi di matrici (ad es. le GEMM di prefill) possono utilizzare simultaneamente sia SME che core della CPU, ma assegnare un intero operatore a un unico backend lascia l'altro inattivo.
  2. Bolle Temporali: Operatori come l'attention intercalano fasi ricche di matrici (che beneficiano di SME) e fasi ricche di vettori (più adatte ai core della CPU). L'esecuzione sequenziale di questi crea tempi morti ("bolle") per un'unità hardware mentre l'altra lavora.
  3. Overhead di Layout: I kernel SME richiedono layout compatti e adatti ai tile, mentre i pipeline standard degli LLM utilizzano layout di tensori convenzionali. La conversione ingenua prima di ogni invocazione SME aggiunge traffico di memoria e interrompe la località dei dati, annullando i guadagni di throughput.

Metodologia

Il documento presenta SMEPilot, un motore di inferenza LLM progettato per pianificare sistematicamente l'uso dei core SME e della CPU sulla base di un modello di performance unificato.

1. Caratterizzazione Roofline Unificata

Gli autori sviluppano un modello roofline multi-soffitto che cattura la natura accoppiata delle risorse SME e CPU:

• Calcolo Additivo, Banda Condivisa: SME e i core della CPU forniscono un throughput di matrice quasi additivo ma condividono un singolo soffitto di larghezza di banda della memoria.
• Classificazione dei Regimi: Il modello classifica gli operatori in tre regimi basati sull'intensità aritmetica ($I$):
  • Limitato dalla Memoria (Memory-bound): Operatori al di sotto del punto di cresta (ridge point) della CPU. L'SME non offre alcun beneficio poiché la larghezza di banda è il collo di bottiglia.
  • Attraversamento della Cresta Asimmetrico tra Backend (Backend-asymmetric Ridge-crossing): Operatori tra i punti di cresta della CPU e dell'SME. Questi sono limitati dal calcolo sulla CPU ma limitati dalla memoria su SME. L'Smi eleva le prestazioni fino al limite di memoria condivso.
  • Limitato dal Calcolo (Compute-bound): Operatori al di sopra del punto di cresta dell'SME. Sia i core SME che quelli della CPU possono contribuire, ed l'esecuzione mista è ottimale.
• Pianificazione Dinamica: Il modello dicta che la selezione del backend (solo CPU, solo SME o Misto) deve essere dinamica, cambiando con le forme delle richieste (ad es. lunghezza della sequenza, dimensione del batch) e i tipi di operatore.

2. Design del Runtime di SMEPilot

Per colmare il divario tra il piano guidato dal roofline e l'esecuzione effettiva, SMEPilot impiega tre tecniche chiave:

• Partizionamento del Lavoro a Livello di Tile (Per affrontare l'Utilizzo Spaziale):

  • Invece di assegnare un intero operatore a un unico backend, SMEPilot partiziona il lavoro matriciale alla granularità del tile.
  • Per le operazioni GEMM, suddivide le dimensioni di output ($M$ o $N$) tra i worker SME e i core della CPU in base alla forma dell'operatore e al throughput misurato.
  • Ciò consente a entrambi i backend di contribuire allo stesso operatore senza l'overhead di sincronizzazione tra i worker.
  • Nei livelli MoE, gli esperti con pochi token (matrici sottili) rimangono sulla CPU, mentre gli esperti con molti token utilizzano l'esecuzione mista.

• Esecuzione di Pipeline Consapevole delle Fasi (Per affrontare le Bolle Temporali):

  • Applicata principalmente ai meccanismi di Attention, che contengono fasi matriciali ($QK^\top$, $PV$) e fasi vettoriali (Softmax, masking).
  • SMEPilot pianifica queste fasi in pipeline: mentre i worker SME calcolano la fase di matrice per un determinato tile, i core della CPU elaborano simultaneamente la fase vettoriale (ad es. Softmax) per un tile precedente.
  • Questo sovrappone il lavoro specifico dell'hardware, eliminando i tempi morti causati dai confini grossolani degli operatori.

• Runtime Consapevole del Layout (Per affrontare la Compatibilità del Layout):

  • Il runtime traccia i layout dei tensori come stato per minimizzare l'overhead di conversione.
  • Packing Offline: I pesi del modello statico sono impacchettati in layout adatti a SME una sola volta al caricamento, rimuovendo questo costo dal percorso critico della richiesta.
  • Packing Lato Produttore: Le attivazioni dinamiche (ad es. le voci del KV-cache) vengono impacchettate lato produttore quando il consumatore a valle è un kernel SME. Ciò evita ripetute operazioni di unpacking e repacking sui percorsi critici.

3. Generazione del Piano di Esecuzione

SMEPilot utilizza un Profiler Offline per misurare le metriche hardware (throughput, larghezza di banda) e un Planner Online per generare piani di esecuzione. Il pianificatore valuta il modello roofline per ogni operatore, dato l'attuale shape della richiesta, per determinare:

• La selezione del backend (CPU, SME o Misto).
• L'allocazione dei thread e i rapporti di partizione.
• Le dimensioni dei tile per bilanciare l'efficienza del kernel con la sovrapposizione della pipeline.

Risultati Chiave

SMEPilot è stato valutato su tre piattaforme (Apple M4 Pro, MediaTek Dimensity 9500, KunPeng 920 Server) utilizzando Llama-3.2-3B, Qwen3-4B e Qwen3-30B-A3B.

• Performance End-to-End: SMEPilot raggiunge fino a 3.94× di velocità in più rispetto al baseline llama.cpp attraverso varie configurazioni di dispositivo-modello-carico di lavoro.
• Fase di Prefill:
  • FFN GEMM: 1.42–1.67× più veloce di Apple Accelerate altamente ottimizzato (solo SME) e 6.06–7.43× più veloce di GGML (solo CPU).
  • Attention: 1.56–3.50× più veloce di FlashAttention CPU.
  • I guadagni sono guidati dalla capacità di utilizzare sia i core SME che quelli della CPU per grandi operatori matriciali.
• Fase di Decode:
  • Raggiunge fino a 3.48× di velocità in più rispetto all'inferenza solo CPU.
  • I miglioramenti sono significativi per dimensioni di batch più grandi, dove gli operatori entrano nel regime di "attraversamento della cresta", permettendo a SME di alleviare i vincoli della larghezza di banda della memoria.
• Efficienza Energetica: Su Apple M4 Pro, SMEPilot riduce il consumo energetico end-to-end a 0.485× del baseline di llama.cpp, principalmente grazie ai tempi di completamento più rapidi.
• Confronto con GPU: Su Apple M4 Pro, SMEPilot raggiunge lo 0.72–0.96× delle prestazioni dell'inferenza GPU, posizionandosi come un'alternativa valida quando le GPU non sono disponibili o sono riservate.

Significato e Rivendicazioni

Il documento sostiene che l'SME non è un sostituto universale per i core vettoriali della CPU, ma piuttosto una risorsa specializzata che richiede un'orchestrazione attenta. La significatività di SMEPilot risiede nel suo passaggio da una sostituzione statica dei kernel a una pianificazione dinamica e consapevole della forma (shape-aware):

1. Caratterizzazione Sistematica: Fornisce la prima caratterizzazione completa basata sul roofline delle CPU abilitate a SME per l'inferenza LLM, rivelando che il posizionamento degli operatori deve essere dinamico e dipendente dalla forma.
2. Esecuzione Cooperativa: Dimostra che le massime prestazioni si ottengono non scegliendo o SME o CPU, ma eseguendo cooperativamente entrambi all'interno di un singolo operatore (tramite partizione dei tile) e attraverso le fasi degli operatori (tramite pipelining).
3. Gestione dell'Overhead del Runtime: Evidenzia come i guadagni di throughput grezzi delle estensioni matriciali possano essere cancellati dai costi di conversione del layout, rendendo necessarie strategie di runtime consapevoli del layout che mantengano il packing fuori dai percorsi critici.

Gli autori concludono che le estensioni matriciali della CPU sono più efficaci quando il loro throughput viene applicato selettivamente e ammortizzato su regimi di inferenza adeguati, piuttosto che applicato uniformemente a tutte le operazioni.