🤖 AI

SMEPilot: Characterizing and Optimizing LLM Inference with Scalable Matrix Extensions

Este artículo presenta SMEPilot, un motor de inferencia de LLM que optimiza el rendimiento en CPUs con Scalable Matrix Extensions (SME) mediante la selección dinámica entre estrategias de ejecución solo CPU, solo SME o cooperativa, y empleando la partición a nivel de tesela y la reutilización de disposición para lograr una aceleración de hasta 3.94× a través de diversos modelos y plataformas.

Autores originales: Feiyang Chen, Haibo Chen

Publicado 2026-06-16

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Feiyang Chen, Haibo Chen

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

La visión general: Una nueva herramienta para máquinas antiguas

Imagina que tienes una cocina muy concurrida (una CPU de computadora moderna). Durante años, esta cocina ha dependido de un equipo de chefs generalistas (núcleos de CPU estándar) para picar verduras, revolver ollas y emplatar la comida. Son buenos en todo, pero no son súper rápidos en una tarea específica: picar enormes pilas de verduras en cuadrados perfectos (que es lo que los Modelos de Lenguaje Extensos, o LLM, necesitan hacer para "pensar").

Recientemente, la cocina recibió un nuevo equipo: un rebanador de vegetales industrial de alta velocidad (llamado SME, o Extensión de Matriz Escalable). Esta máquina puede rebanar vegetales increíblemente rápido. Sin embargo, los autores del artículo descubrieron un problema: el hecho de que tengas un rebanador no significa que debas usarlo para cada tarea.

El Problema: Si intentas usar el rebador para todo, podrías obstruir la cinta transportadora (ancho de banda de memoria) o perder tiempo preparándolo para trabajos pequeños. A veces, los chefs generalistas son en realidad más rápidos en las tareas pequeñas y complicadas.
La Solución: El equipo construyó SMEPilot. Piensa en SMEPilot como un Gerente de Cocina superinteligente. No se limita a entregarle todo al rebanador; decide exactamente qué chef hace cada trabajo, cuándo usar la máquina y cómo mantener toda la cocina funcionando sin que nadie se quede esperando.

Cómo funciona SMEPilot: Los tres trucos de magia

El artículo identifica tres formas principales en las que SMEPilot hace que la cocina funcione más rápido. Aquí están las analogías para cada una:

1. La "División de Equipo" (Partición de trabajo a nivel de Tile)

El Problema: Imagina que tienes una pizza gigante (un enorme problema matemático) para cortar.

Si le das la pizza entera al rebanador industrial, los chefs se quedan de brazos cruzados.
Si se la das a los chefs, el rebanador se queda de brazos cruzados.
Si simplemente cortas la pizza a la mitad y le das una mitad al rebanador y la otra a los chefs, el rebanador podría terminar en 1 segundo mientras que los chefs tardan 10 segundos. El rebanador simplemente espera, perdiendo tiempo.

La solución de SMEPilot: SMEPilot corta la pizza en trozos diminutos (tiles). Le da unos pocos trozos al rebanador y otros pocos a los chefs. Crucialmente, calcula exactamente cuántos trozos debe recibir cada uno para que ambos terminen exactamente al mismo tiempo. Esto mantiene tanto a la máquina como a los chefs ocupados el 100% del tiempo.

2. La "Línea de Ensamblaje" (Ejecución de Pipeline consciente de la fase)

El Problema: Hacer un sándwich implica dos pasos:

Paso A: Rebanar el pan (necesita el rebanador industrial).
Paso B: Untar la mostaza (necesita una mano humana).

En una mala cocina, esperas a que se haya rebanado toda la hogaza de pan antes de empezar a untar la mostaza. El humano se queda de brazos cruzados mientras la máquina trabaja. Luego, la máquina se queda de brazos cruzados mientras el humano unta la mostaza. Esto se llama un "burbuja temporal" (un vacío de tiempo donde no se realiza ningún trabajo).

La solución de SMEPilot: SMEPilot crea una línea de ensamblaje. Tan pronto como el rebanador termina de procesar una rebanada de pan, se la pasa al humano para untar la mostaza, mientras el rebanador comienza inmediatamente con la siguiente rebanada. La máquina y el humano trabajan al mismo tiempo en diferentes partes del sándwich. Esto elimina el tiempo de espera.

3. El "Almuerzo Pre-Empaquetado" (Tiempo de ejecución consciente del Layout)

El Problema: El rebanador industrial solo funciona si los vegetales están dispuestos en una cuadrícula muy específica y apretada (un diseño "empaquetado" o packed layout). Pero el resto de la cocina guarda los vegetales en bolsas sueltas y estándar.

La Mala Forma: Cada vez que quieres usar el rebanador, te detienes, sacas los vegetales de la bolsa, los organizas perfectamente en una cuadrícula, los rebanas y luego los vuelves a meter en una bolsa. Este proceso de "reorganizar" toma casi tanto tiempo como el rebanado mismo, arruinando el beneficio de la velocidad.

La solución de SMEPilot: SMEPilot es inteligente sobre cuándo reorganizar.

Para ingredientes estáticos (como los pesos del modelo): Los organiza en la cuadrícula perfecta una sola vez cuando la cocina abre, para que estén listos instantáneamente para cada pedido.
Para ingredientes frescos (como nuevos datos): Los organiza en la cuadrícula inmediatamente cuando se crean, para que estén listos para el rebanador sin ningún paso adicional después. Esto evita la penalización de "reorganización".

Los Resultados: ¿Qué tan rápido es?

Los investigadores probaron SMEPilot en teléfonos, laptops y servidores utilizando modelos de IA populares (como Llama y Qwen).

La Velocidad: SMEPilot hizo que la IA fuera hasta 3.94 veces más rápida que la forma estándar de ejecutar estos modelos en CPUs.
La Energía: Debido a que termina el trabajo mucho más rápido, también utiliza menos de la mitad de la energía en comparación con el método estándar.
La Comparación: En algunas pruebas, la CPU ejecutando SMEPilot fue casi tan rápida como una tarjeta gráfica dedicada (GPU), que es la que suele realizar el "trabajo pesado" para la IA.

La Conclusión

El artículo argumenta que SME (la nueva máquina) no es una varita mágica que reemplaza a los viejos chefs. En cambio, el mejor rendimiento proviene de un gerente inteligente (SMEPilot) que sabe:

Cuándo usar la máquina y cuándo usar a los chefs.
Cómo dividir el trabajo para que todos se mantengan ocupados.
Cómo organizar el espacio de trabajo para que no se pierda tiempo en la preparación.

Al hacer esto, las computadoras ordinarias pueden ejecutar la IA poderosa de manera mucho más rápida y eficiente que antes.

Resumen Técnico: SMEPilot

Planteamiento del Problema

Las CPU modernas están integrando cada vez más extensiones de matrices, como la Extensión de Matriz Escalable de Arm (SME), para proporcionar una ejecución de matrices de alto rendimiento dentro del paquete de la CPU. Si bien estas extensiones ofrecen un punto medio entre los aceleradores de GPU y los núcleos vectoriales convencionales, no son un reemplazo universal para los núcleos de CPU en la inferencia de Modelos de Lenguaje de Gran Escala (LLM).

El desafío central identificado es un desajuste entre los requisitos heterogéneos de los operadores de LLM y las capacidades estáticas de las unidades SME.

Características Diversas de los Operadores: La inferencia de LLM involucra fases distintas (prellenado vs. decodificación) y operadores (atención, FFN, MoE) con variaciones en la intensidad aritmética, comportamientos vectoriales y requisitos de disposición (layout).
Contención de Recursos: Las unidades SME y los núcleos de CPU comparten el ancho de banda de memoria y las jerarquías de caché. Tratar a la SME como un simple reemplazo directo ("drop-in") de los kernels de CPU conduce a un rendimiento subóptimo porque:
1. Subutilización Espacial: Los operadores de matrices grandes (por ejemplo, GEMMs de prellenado) pueden utilizar tanto SME como núcleos de CPU simultáneamente, pero asignar un operador entero a un solo backend deja al otro ocioso.
2. Burbujas Temporales: Los operadores como la atención intercalan fases intensivas en matrices (que se benefician de SME) y fases intensivas en vectores (mejor adaptadas a los núcleos de CPU). Ejecutar esto secuencialmente crea tiempos de inactividad ("burbujas") para una unidad de hardware mientras la otra trabaja.
3. Sobrecarga de Disposición (Layout): Los kernels de SME requieren disposiciones empaquetadas y aptas para teselas (tiles), mientras que las disposiciones de tensores estándar de los pipelines de LLM utilizan formatos convencionales. La conversión ingenua antes de cada invocación de SME añade tráfico de memoria y rompe la localidad de los datos, anulando las ganancias de rendimiento.

Metodología

El artículo presenta SMEPilot, un motor de inferencia de LLM diseñado para programar sistemáticamente los núcleos SME y de CPU basándose en un modelo de rendimiento unificado.

1. Caracterización de Techo (Roofline) Unificada

Los autores desarrollan un modelo de techo de techo múltiple que captura la naturaleza acoplada de los recursos SME y de CPU:

Cómputo Aditivo, Ancho de Banda Compartido: Las CPU y las unidades SME proporcionan un rendimiento de matrices casi aditivo pero comparten un único techo de ancho de banda de memoria.
Clasificación de Regímenes: El modelo clasifica los operadores en tres regímenes basados en la intensidad aritmética ( $I$ $I$ ):
- Limitado por Memoria: Operadores por debajo del punto de cresta de la CPU. La SME no ofrece beneficios ya que el ancho de banda es el cuello de botella.
- Cruce de Cresta Asimétrico de Backend: Operadores entre los puntos de cresta de la CPU y la SME. Estos están limitados por cómputo en la CPU pero limitados por memoria en la SME. La SME eleva el rendimiento hacia el límite de memoria compartido.
- Limitado por Cómputo: Operadores por encima del punto de cresta de la SME. Tanto los núcleos de CPU como los de SME pueden contribuir, y la ejecución mixta es óptima.
Programación Dinámica: El modelo dicta que la selección del backend (solo CPU, solo SME o Mixto) debe ser dinámica, cambiando con las formas de las solicitudes (por ejemplo, longitud de secuencia, tamaño de lote) y los tipos de operador.

2. Diseño del Tiempo de Ejecución (Runtime) de SMEPilot

Para cerrar la brecha entre el plan guiado por el modelo de techo y la ejecución real, SMEPilot emplea tres técnicas clave:

Partición de Trabajo a Nivel de Tesela (Abordando la Utilización Espacial):
- En lugar de asignar un operador completo a un solo backend, SMEPilot particiona el trabajo de matriz a la granularidad de la tesela (tile).
- Para las operaciones GEMM, divide las dimensiones de salida ( $M$ o $N$ ) entre los trabajadores de SME y los núcleos de CPU basándose en la forma del operador y el rendimiento medido.
- Esto permite que ambos backends contribuyan al mismo operador sin la sobrecarga de sincronización entre trabajadores.
- En las capas de MoE, los expertos con pocos tokens (matrices delgadas) permanecen en la CPU, mientras que los expertos con muchos tokens utilizan la ejecución mixta.
Ejecución de Pipeline Consciente de la Fase (Abordando las Burbujas Temporales):
- Aplicado principalmente a los mecanismos de Atención, que contienen fases de matriz ( $QK^\top$ , $PV$) y fases de vector (Softmax, enmascaramiento).
- SMEPilot realiza un pipeline de estas fases: mientras los trabajadores de SME computan la etapa de matriz para una tesela específica, los núcleos de CPU procesan simultáneamente la etapa de vector (por ejemplo, Softmax) para una tesela precedente.
- Esto solapa el trabajo específico de hardware, eliminando el tiempo de inactividad causado por los límites de grano grueso de los operadores.
Runtime Consciente de la Disposición (Abordando la Compatibilidad de Layout):
- El tiempo de ejecución rastrea las disposiciones de los tensores como un estado para minimizar la sobrecarga de conversión.
- Empaquetado Offline: Los pesos estáticos del modelo se empaquetan en disposiciones aptas para SME una sola vez durante la carga, eliminando este costo del camino crítico de la solicitud.
- Empaquetado en el Lado del Productor: Las activaciones dinámicas (por ejemplo, entradas del KV-cache) se empaquetan en el lado del productor cuando el consumidor descendente es un kernel de SME. Esto evita el desempaquetado y reempaquetado repetido en los caminos críticos.

3. Generación del Plan de Ejecución

SMEPilot utiliza un Perfilador Offline para medir métricas de hardware (rendimiento, ancho de banda) y un Planificador Online para generar planes de ejecución. El planificador evalúa el modelo de techo para cada operador dada la forma actual de la solicitud para determinar:

La selección del backend (CPU, SME o Mixto).
La asignación de hilos y los ratios de partición.
El tamaño de la tesela para equilibrar la eficiencia del kernel con el solapamiento del pipeline.

Resultados Clave

SMEPilot fue evaluado en tres plataformas (Apple M4 Pro, MediaTek Dimensity 9500, KunPeng 920 Server) utilizando Llama-3.2-3B, Qwen3-4B y Qwen3-30B-A3B.

Rendimiento de Extremo a Extremo: SMEPilot logra hasta un 3.94× de aceleración sobre la línea base de llama.cpp a través de diversas configuraciones de dispositivo-modelo-carga de trabajo.
Fase de Prellenado (Prefill):
- FFN GEMM: 1.42–1.67× más rápido que Apple Accelerate altamente optimizado (solo SME) y 6.06–7.43× más rápido que GGML (solo CPU).
- Atención: 1.56–3.50× más rápido que FlashAttention CPU.
- Las ganancias son impulsadas por la capacidad de utilizar tanto SME como núcleos de CPU para grandes operadores de matrices.
Fase de Decodificación (Decode):
- Logra hasta un 3.48× de aceleración sobre la inferencia de solo CPU.
- Las mejoras son significativas para tamaños de lote más grandes donde los operadores entran en el régimen de "cruce de cresta", permitiendo que la SME alivie las restricciones de memoria.
Eficiencia Energética: En el Apple M4 Pro, SMEPilot reduce el consumo de energía de extremo a extremo a 0.485× de la línea base de llama.cpp, debido principalmente a los tiempos de finalización más rápidos.
Comparación con GPU: En el Apple M4 Pro, SMEPilot alcanza el 0.72–0.96× del rendimiento de la inferencia por GPU, posicionándose como una alternativa viable cuando las GPUs no están disponibles o están reservadas.

Significancia y Reivindicaciones

El artículo afirma que la SME no es un sustituto universal para los núcleos vectoriales de CPU, sino más bien un recurso especializado que requiere una orquestación cuidadosa. La significancia de SMEPilot radica en su cambio de un reemplazo de kernel estático a una programación dinámica sensible a la forma:

Caracterización Sistemática: Proporciona la primera caracterización completa basada en el modelo de techo para CPUs con soporte de SME para la inferencia de LLM, revelando que la ubicación de los operadores debe ser dinámica y dependiente de la forma.
Ejecución Cooperativa: Demuestra que el máximo rendimiento se logra no eligiendo ya sea SME o CPU, sino mediante la ejecución cooperativa de ambos dentro de un mismo operador (mediante la partición de teselas) y a través de las fases de los operadores (mediante el pipeline).
Gestión de la Sobrecarga del Runtime: Destaca que las ganancias de rendimiento bruto de las extensiones de matriz pueden ser borradas por los costos de conversión de disposición, lo que requiere estrategias de runtime conscientes de la disposición que mantengan el empaquetado fuera de los caminos críticos.

Los autores concluyen que las extensiones de matriz de la CPU son más efectivas cuando su rendimiento se aplica selectivamente y se amortiza a través de los regímenes de inferencia adecuados, en lugar de aplicarse uniformemente a todas las operaciones.