🤖 AI

SMEPilot: Characterizing and Optimizing LLM Inference with Scalable Matrix Extensions

Dit artikel introduceert SMEPilot, een LLM-inferentie-engine die de prestaties op CPU's met Scalable Matrix Extensions (SME) optimaliseert door dynamisch te kiezen tussen CPU-alleen, SME-alleen of coöperatieve executiestrategieën en door middel van tile-niveau partitionering en layout-hergebruik tot 3,94× versnelling te bereiken over diverse modellen en platforms.

Oorspronkelijke auteurs: Feiyang Chen, Haibo Chen

Gepubliceerd 2026-06-16

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Feiyang Chen, Haibo Chen

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Plaatje: Een Nieuw Gereedschap voor Oude Machines

Stel je voor dat je een zeer drukke keuken hebt (een moderne computer CPU). Jarenlang heeft deze keuken vertrouwd op een team van generalistische koks (standaard CPU-kernen) om groenten te snijden, potten te roeren en gerechten te presenteren. Ze zijn goed in alles, maar ze zijn niet super snel bij één specifieke taak: het snijden van enorme bergen groenten in perfecte vierkantjes (wat Large Language Models, of LLM's, moeten doen om te "denken").

Onlangs heeft de keuken een nieuw stuk apparatuur gekregen: een hogesnelheids industriële groentesnijmachine (genaamd SME, of Scalable Matrix Extension). Deze machine kan groenten ongelooflijk snel snijden. De auteurs van het paper ontdekten echter een probleem: alleen omdat je een snijmachine hebt, betekent dat nog niet dat je hem voor elke taak moet gebruiken.

Het Probleem: Als je de snijmachine voor alles probeert te gebruiken, kun je de lopende band verstoppen (geheugenbandbreedte) of tijd verspillen aan het instellen ervan voor kleine klusjes. Soms zijn de generalistische koks eigenlijk sneller bij de kleine, lastige taken.
De Oplossing: Het team heeft SMEPilot gebouwd. Zie SMEPilot als een superintelligente Keukenmanager. Hij geeft niet zomaar alles aan de snijmachine; hij beslist precies welke kok welk werk doet, wanneer de machine gebruikt moet worden en hoe de hele keuken draaiende blijft zonder dat er iemand stilstaat te wachten.

Hoe SMEPilot Werkt: De Drie Magische Trucs

Het paper identificeert drie belangrijke manieren waarop SMEPilot de keuken sneller laat draaien. Hier zijn de analogieën voor elk van de drie:

1. De "Teamverdeling" (Tile-Level Work Partitioning)

Het Probleem: Stel je voor dat je een gigantische pizza (een enorme wiskundige opgave) moet snijden.

Als je de hele pizza aan de industriële snijmachine geeft, zitten de koks niets te doen.
Als je de hele pizza aan de koks geeft, staat de snijmachine niets te doen.
Als je de pizza simpelweg doormidden snijdt en één helft aan de snijmachine geeft en de andere helft aan de koks, kan de snijmachine de pizza in 1 seconde snijden terwijl de koks er 10 seconden over doen. De snijmachine wacht dan simpelweg, wat tijd verspilt.

De SMEPilot Fix: SMEPilot snijdt de pizza in piepkleine stukjes (tiles). Hij geeft een paar stukjes aan de snijmachine en een paar aan de koks. Cruciaal is dat hij precies berekent hoeveel stukjes elke partij krijgt, zodat beiden op exact hetzelfde moment klaar zijn. Dit houdt zowel de machine als de koks 100% van de tijd bezig.

2. De "Assemblagelijn" (Phase-Aware Pipeline Execution)

Het Probleamen: Het maken van een sandwich bestaat uit twee stappen:

Stap A: Het snijden van het brood (hiervoor is de industriële snijmachine nodig).
Stap B: Het smeren van de mosterd (hiervoor is een menselijke hand nodig).

In een slechte keuken wacht je tot de volledige broodloaf gesneden is voordat je begint met het smeren van de mosterd. De mens zit niets te doen terwijl de machine werkt. Daarna zit de machine niets te doen terwijl de mens de mosterd smeert. Dit wordt een "temporele bubbel" genoemd (een gat in de tijd waarin er geen werk wordt verricht).

De SMEPilot Fix: SMEPilot creëert een assemblagelijn. Zodra de snijmachine één plak brood heeft gesneden, geeft hij dit door aan de mens om de mosterd te smeren, terwijl de snijmachine direct begint aan de volgende plak. De machine en de mens werken tegelijkertijd aan verschillende delen van de sandwich. Dit elimineert de wachttijd.

3. De "Kant-en-klaar Lunchtrommel" (Layout-Aware Runtime)

Het Probleem: De industriële snijmachine werkt alleen als de groenten in een heel specifieke, compacte rastervorm zijn gerangschikt (een "packed" layout). Maar de rest van de keuken bewaart groenten in losse, standaard zakken.

De Slechte Manier: Elke keer als je de snijmachine wilt gebruiken, stop je, haalt de groenten uit de zak, rangschikt ze perfect in een raster, snijdt ze, en doet ze daarna weer terug in een zak. Dit "herrangschikken" kost bijna evenveel tijd als het snijden zelf, wat het snelheid voordeel tenietdoet.

De SMEPilot Fix: SMEPilot is slim over wanneer er gerangschikt moet worden.

Voor statische ingrediënten (zoals modelgewichten): Het rangschikt deze in het perfecte raster één keer wanneer de keuken opent, zodat ze direct klaar zijn voor elke bestelling.
Voor verse ingrediënten (zoals nieuwe data): Het rangschikt deze in het raster onmiddellijk wanneer ze worden gecreëerd, zodat ze klaar zijn voor de snijmachine zonder extra stappen later. Dit voorkomt de "herrangschikkingsstraf".

De Resultaten: Hoe Veel Sneller?

De onderzoekers hebben SMEPilot getest op telefoons, laptops en servers met populaire AI-modellen (zoals Llama en Qwen).

De Snelheid: SMEPilot maakte de AI tot wel 3,94 keer sneller dan de standaard manier om deze modellen op CPU's te draaien.
De Energie: Omdat het werk veel sneller wordt voltooid, verbruikt het ook minder dan de helft van de energie vergeleken met de standaardmethode.
De Vergelijking: In sommige tests was de CPU die SMEPilot draaide bijna even snel als een dedicated grafische kaart (GPU), die meestal het "zware werk" doet voor AI.

De Kernboodschap

Het paper betoogt dat SME (de nieuwe machine) geen toverstaf is die de oude koks vervangt. In plaats daarvan komt de beste prestatie voort uit een slimme manager (SMEPilot) die weet:

Wanneer de machine te gebruiken en wanneer de koks.
Hoe het werk te verdelen zodat iedereen bezig blijft.
Hoe de werkplek te organiseren zodat er geen tijd verloren gaat aan de voorbereiding.

Door dit te doen, kunnen gewone computers krachtige AI veel sneller en efficiënter draaien dan voorheen.

Technische Samenvatting: SMEPilot

Probleemstelling

Moderne CPU's integreren steeds vaker matrix-extensies, zoals de Arm Scalable Matrix Extension (SME), om een hoge doorvoer van matrix-executie binnen het CPU-pakket te bieden. Hoewel deze extensies een middenweg vormen tussen GPU-acceleratoren en conventionele vectorcores, zijn ze geen universele vervanging voor CPU-cores bij de inferentie van Large Language Models (LLM's).

De kernuitdaging die is geïdentificeerd, is een mismatch tussen de heterogene vereisten van LLM-operators en de statische capaciteiten van SME-units.

Diverse Operator-kenmerken: LLM-inferentie omvat verschillende fasen (prefill versus decode) en operators (attention, FFN, MoE) met variërende rekenintensiteit, vectorgedrag en lay-outvereisten.
Resource-concurrentie: SME-units en CPU-cores delen geheugenbandbreedte en cache-hiërarchieën. Het behandelen van SME als een eenvoudige "drop-in" vervanging voor CPU-kernels leidt tot suboptimale prestaties omdat:
1. Ruimtelijke Onderbenutting: Grote matrix-zware operators (bijv. prefill GEMMs) kunnen zowel SME als CPU-cores gelijktijdig gebruiken, maar het toewijzen van een volledige operator aan één backend laat de andere idle.
2. Temporele Bubbels: Operators zoals attention wisselen matrix-zware fasen (die profiteren van SME) af met vector-zware fasen (die beter geschikt zijn voor CPU-cores). Het sequentieel uitvoeren hiervan creëert dode tijd ("bubbles") voor de ene hardware-unit terwijl de andere werkt.
3. Lay-out Overhead: SME-kernels vereisen gepakte, tile-vriendelijke lay-outs, terwijl standaard LLM-pipelines conventionele tensor-lay-outs gebruiken. Naïeve conversie vóór elke SME-aanroep voegt verkeersdruk toe aan het geheugen en verstoort de datalocaliteit, wat de winst in doorvoer tenietdoet.

Methodologie

Het paper introduceert SMEPilot, een LLM-inferentie-engine die ontworpen is om SME en CPU-cores systematisch te plannen op basis van een verenigd prestatiemodel.

1. Unified Roofline Characterization

De auteurs ontwikkelen een multi-ceiling roofline model dat de gekoppelde aard van SME en CPU-resources vastlegt:

Additieve Berekening, Gedeelde Bandbreedte: SME en CPU-cores bieden bijna additieve matrix-doorvoer maar delen een enkele geheugenbandbreedte-roof.
Regime Classificatie: Het model classificeert operators in drie regimes op basis van rekenintensiteit ( $I$ $I$ ):
- Geheugen-gebonden (Memory-bound): Operators onder het CPU-rugpunt. SME biedt geen voordeel omdat bandbreedte de flessenhals is.
- Backend-asymmetrisch Rugdoorbrekend (Ridge-crossing): Operators tussen de CPU- en de SME-rugpunten. Deze zijn rekengebonden op de CPU maar geheugengebonden op de SME. SME tilt de prestaties naar de gedeelde geheugenlimiet.
- Berekeningsgebonden (Compute-bound): Operators boven het SME-rugpunt. Zowel SME als CPU-cores kunnen bijdragen, en gemengde executie is optimaal.
Dynamische Planning: Het model dicteert dat backend-selectie (alleen CPU, alleen SME, of Gemengd) dynamisch moet zijn, veranderend met de vorm van de aanvraag (bijv. sequentielengte, batchgrootte) en het type operator.

2. SMEPilot Runtime Design

Om de kloof tussen het door de roofline gestuurde plan en de werkelijke uitvoering te overbruggen, gebruikt SMEPilot drie belangrijke technieken:

Tile-Level Work Partitioning (Adresseren van Ruimtelijke Benutting):
- In plaats van een volledige operator aan één backend toe te wijzen, partitioneert SMEPilot het matrixwerk op tile-granulariteit.
- Voor GEMM-operaties splitst het de outputdimensies ( $M$ of $N$ ) tussen SME-workers en CPU-cores op basis van de operatorvorm en gemeten doorvoer.
- Dit stelt beide backends in staat om bij te dragen aan dezelfde operator zonder cross-worker synchronisatie-overhead.
- In MoE-lagen blijven experts met weinig tokens (dunne matrices) op de CPU, terwijl experts met veel tokens gebruikmaken van gemengde executie.
Phase-Aware Pipeline Execution (Adresseren van Temporele Bubbels):
- Wordt primair toegepast op Attention-mechanismen, die matrixfasen ( $QK^\top$ , $PV$) en vectorfasen (Softmax, masking) bevatten.
- SMEPilot pipelinet deze fasen: terwijl SME-workers de matrixstap voor een specifieke tile berekenen, verwerken CPU-cores gelijktijdig de vectorstap (bijv. Softmax) voor een voorafgaande tile.
- Dit overlapt hardware-specifiek werk, waardoor de idle tijd veroorzaakt door grove operator-grenzen wordt geëlimineerd.
Layout-Aware Runtime (Adresseren van Lay-out Compatibiliteit):
- De runtime houdt tensor-lay-outs bij als status om conversie-overhead te minimaliseren.
- Offline Packing: Statische modelgewichten worden eenmalig gepakt in SME-vriendelijke lay-outs tijdens het laden, waardoor deze kosten uit het kritieke pad van de aanvraag worden gehaald.
- Producer-Side Packing: Dynamische activaties (bijv. KV-cache entries) worden aan de producer-zijde gepakt wanneer de downstream consument een SME-kernel is. Dit voorkomt herhaaldelijk uitpakken en opnieuw pakken op het kritieke pad.

3. Execution Plan Generation

SMEPilot gebruikt een Offline Profiler om hardwaremetrieken (doorvoer, bandbreedte) te meten en een Online Planner om executieplannen te genereren. De planner evalueert het roofline-model voor elke operator gegeven de huidige aanvraagvorm om te bepalen:

Backend-selectie (CPU, SME, of Gemengd).
Thread-allocatie en partitie-ratio's.
Tile-groottes om een balans te vinden tussen kernel-efficiëntie en pipeline-overlap.

Belangrijkste Resultaten

SMEPilot werd geëvalueerd op drie platforms (Apple M4 Pro, MediaTek Dimensity 9500, KunPeng 920 Server) met behulp van Llama-3.2-3B, Qwen3-4B en Qwen3-30B-A3B.

End-to-End Prestaties: SMEPilot bereikt tot wel 3,94× versnelling ten opzichte van de llama.cpp baseline over diverse device-model-workload configuraties.
Prefill Fase:
- FFN GEMM: 1,42–1,67× sneller dan geoptimaliseerde Apple Accelerate (SME-only) en 6,06–7,43× sneller dan GGML (CPU-only).
- Attention: 1,56–3,50× sneller dan FlashAttention CPU.
- De winst wordt gedreven door het vermogen om zowel SME als CPU-cores te gebruiken voor grote matrix-operators.
Decode Fase:
- Bereikt tot wel 3,48× versnelling ten opzichte van CPU-only inferentie.
- De verbeteringen zijn significant voor grotere batchgroottes waar operators in het "ridge-crossing" regime terechtkomen, waardoor SME de geheugengebonden beperkingen kan verlichten.
Energie-efficiëntie: Op de Apple M4 Pro reduceert SMEPilot het end-to-end energieverbruik tot 0,485× van de llama.cpp baseline, primair dankzij snellere voltooiingstijden.
GPU Vergelijking: Op de Apple M4 Pro bereikt SMEPilot 0,72–0,96× de prestaties van GPU-inferentie, wat het een levensvatbaar alternatief maakt wanneer GPU's niet beschikbaar zijn of gereserveerd zijn.

Betekenis en Claims

Het paper claimt dat SME geen universele vervanging is voor CPU vector-cores, maar eerder een gespecialiseerde resource die zorgvuldige orchestratie vereist. De betekenis van SMEPilot ligt in de verschuiving van statische kernelvervanging naar dynamische, vorm-bewuste planning:

Systematische Karakterisering: Het biedt de eerste uitgebreide roofline-gebaseerde karakterisering van SME-ondersteunde CPU's voor LLM-inferentie, waarbij wordt aangetoond dat de plaatsing van operators dynamisch en vorm-afhankelijk moet zijn.
Coöperatieve Executie: Het demonstreert dat de hoogste prestaties worden behaald, niet door te kiezen tussen of SME of CPU, maar door coöperatief beide uit te voeren binnen een enkele operator (via tile-partitionering) en over operator-fasen heen (via pipelining).
Beheer van Runtime Overhead: Het benadrukt dat de ruwe doorvoerwinst van matrix-extensies tenietgedaan kan worden door de kosten van lay-out conversie, wat lay-out-bewuste runtime-strategieën noodzakelijk maakt die het pakken buiten het kritieke pad houden.

De auteurs concluderen dat CPU matrix-extensies het meest effectief zijn wanneer hun doorvoer selectief en geamortiseerd wordt toegepast op geschikte inferentie-regimes, in plaats van uniform op alle operaties te worden toegepast.