🤖 AI

SMEPilot: Characterizing and Optimizing LLM Inference with Scalable Matrix Extensions

Este artigo apresenta o SMEPilot, um mecanismo de inferência de LLM que otimiza o desempenho em CPUs com Scalable Matrix Extensions (SME) ao selecionar dinamicamente entre estratégias de execução apenas CPU, apenas SME ou cooperativa e ao empregar particionamento em nível de tile e reutilização de layout para alcançar até 3,94× de aceleração em diversos modelos e plataformas.

Autores originais: Feiyang Chen, Haibo Chen

Publicado 2026-06-16

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Feiyang Chen, Haibo Chen

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A Visão Geral: Uma Nova Ferramenta para Máquinas Antigas

Imagine que você tem uma cozinha muito movimentada (uma CPU de computador moderna). Durante anos, esta cozinha dependeu de uma equipe de chefs generalistas (núcleos de CPU padrão) para picar vegetais, mexer panelas e montar pratos. Eles são bons em tudo, mas não são super-rápidos em uma tarefa específica: picar montanhas enormes de vegetais em quadrados perfeitos (que é o que os Grandes Modelos de Linguagem, ou LLMs, precisam fazer para "pensar").

Recentemente, a cozinha recebeu um novo equipamento: um fatiador de vegetais industrial de alta velocidade (chamado de SME, ou Extensão de Matriz Escalável). Esta máquina pode fatiar vegetais incrivelmente rápido. No entanto, os autores do artigo descobriram um problema: só porque você tem um fatiador, não significa que deva usá-lo para todas as tarefas.

O Problema: Se você tentar usar o fatiador para tudo, pode entupir a esteira transportadora (largura de banda de memória) ou perder tempo configurando-o para tarefas pequenas. Às vezes, os chefs generalistas são, de fato, mais rápidos em tarefas pequenas e complicadas.
A Solução: A equipe construiu o SMEPilot. Pense no SMEPilot como um Gerente de Cozinha super inteligente. Ele não apenas entrega tudo ao fatiador; ele decide exatamente qual chef faz qual trabalho, quando usar a máquina e como manter toda a cozinha funcionando sem que ninguém fique parado esperando.

Como o SMEPilot Funciona: Os Três Truques Mágicos

O artigo identifica três formas principais pelas quais o SMEPilot faz a cozinha funcionar mais rápido. Aqui estão as analogias para cada uma:

1. A "Divisão da Equipe" (Particionamento de Trabalho em Nível de Bloco/Tile)

O Problema: Imagine que você tem uma pizza gigante (um enorme problema matemático) para cortar.

Se você der a pizza inteira para o fatiador industrial, os chefs ficam ociosos.
Se você der para os chefs, o fatiador fica ocioso.
Se você apenas cortar a pizza ao meio e der uma metade para o fatiador e a outra para os chefs, o fatiador pode terminar em 1 segundo enquanto os chefs levam 10 segundos. O fatiador fica esperando, desperdiçando tempo.

A Correção do SMEPilot: O SMEPilot corta a pizza em fatias minúsculas (blocos/tiles). Ele dá algumas fatias para o fatiador e algumas para os chefs. Crucialmente, ele calcula exatamente quantas fatias cada um deve receber para que ambos terminem exatamente ao mesmo tempo. Isso mantém tanto a máquina quanto os chefs ocupados 100% do tempo.

2. A "Linha de Montagem" (Execução de Pipeline Consciente de Fase)

O Problema: Fazer um sanduíche envolve duas etapas:

Etapa A: Fatiar o pão (precisa do fatiador industrial).
Etapa B: Espalhar a mostarda (precisa de uma mão humana).

Em uma cozinha ruim, você espera que todo o pão seja fatiado antes de começar a espalhar a mostarda. O humano fica ocioso enquanto a máquina trabalha. Depois, a máquina fica ociosa enquanto o humano espalha a mostarda. Isso é chamado de "bolha temporal" (um intervalo de tempo onde nenhum trabalho é feito).

A Correção do SMEPilot: O SMEPilot cria uma linha de montagem. Assim que o fatiador termina de fatiar uma fatia de pão, ele a passa para o humano para espalhar a mostarda, enquanto o fatiador começa imediatamente na próxima fatia. A máquina e o humano trabalham ao mesmo tempo em partes diferentes do sanduíche. Isso elimina o tempo de espera.

3. O "Almoço Pré-embalado" (Tempo de Execução Consciente do Layout)

O Problema: O fatiador industrial só funciona se os vegetais estiverem organizados em uma grade muito específica e compacta (um layout "compactado"). Mas o restante da cozinha armazena os vegetais em sacos soltos e padrão.

O Jeito Ruim: Toda vez que você quer usar o fatiador, você para, tira os vegetais do saco, organiza-os perfeitamente em uma grade, fatia e depois os coloca de volta no saco. Esse processo de "reorganização" leva quase tanto tempo quanto o próprio fatiamento, arruinando o benefな de velocidade.

A Correção do SMEPilot: O SMEPilot é inteligente sobre quando reorganizar.

Para ingredientes estáticos (como pesos do modelo): Ele organiza os ingredientes na grade perfeita uma única vez quando a cozinha abre, para que estejam prontos instantaneamente para cada pedido.
Para ingredientes frescos (como novos dados): Ele organiza os ingredientes na grade imediatamente quando eles são criados, para que estejam prontos para o fatiador sem quaisquer etapas extras depois. Isso evita a penalidade de "reorganização".

Os Resultados: O Quão Mais Rápido?

Os pesquisadores testaram o SMEPilot em celulares, laptops e servidores usando modelos de IA populares (como Llama e Qwen).

A Velocidade: O SMEPilot tornou a IA até 3,94 vezes mais rápida do que a maneira padrão de executar esses modelos em CPUs.
A Energia: Como ele termina o trabalho muito mais rápido, também utiliza menos da metade da energia em comparação com o método padrão.
A Comparação: Em alguns testes, a CPU rodando o SMEPilot foi quase tão rápida quanto uma placa de vídeo dedicada (GPU), que é geralmente o "trabalhador pesado" para IA.

A Conclusão

O artigo argumenta que o SME (a nova máquina) não é uma varinha mágica que substitui os antigos chefs. Em vez disso, o melhor desempenho vem de um gerente inteligente (SMEPilot) que sabe:

Quando usar a máquina e quando usar os chefs.
Como dividir o trabalho para que todos permaneçam ocupados.
Como organizar o espaço de trabalho para que nenhum tempo seja desperdiçado com configuração.

Ao fazer isso, computadores comuns podem rodar IAs poderosas de forma muito mais rápida e eficiente do que antes.

Resumo Técnico: SMEPilot

Declaração do Problema

As CPUs modernas estão integrando cada vez mais extensões de matriz, como a Arm Scalable Matrix Extension (SME), para fornecer execução de matrizes de alto rendimento dentro do pacote da CPU. Embora essas extensões ofereçam um meio-termo entre aceleradores de GPU e núcleos vetoriais convencionais, elas não são uma substituição universal para núcleos de CPU em inferência de Grandes Modelos de Linguagem (LLM).

O desafio central identificado é um descompasso entre os requisitos heterogêneos dos operadores de LLM e as capacidades estáticas das unidades SME.

Características Diversas de Operadores: A inferência de LLM envolve fases distintas (prefill vs. decode) e operadores (atenção, FFN, MoE) com variadas intensidades aritméticas, comportamentos vetoriais e requisitos de layout.
Contenção de Recursos: As unidades SME e os núcleos da CPU compartilham largura de banda de memória e hierarquias de cache. Tratar a SME como uma simples substituição direta ("drop-in") para kernels de CPU leva a um desempenho subótimo porque:
1. Subutilização Espacial: Operadores densos em matrizes (ex: GEMMs de prefill) podem utilizar tanto SME quanto núcleos de CPU simultaneamente, mas atribuir um operador inteiro a um único backend deixa o outro ocioso.
2. Bolhas Temporais: Operadores como atenção intercalam fases intensivas em matrizes (que se beneficiam da SME) e fases intensivas em vetores (melhores para núcleos de CPU). Executar esses processos sequencialmente cria tempos ociosos ("bolhas") para uma unidade de hardware enquanto a outra trabalha.
3. Sobrecarga de Layout: Kernels de SME exigem layouts compactados e favoráveis a tiles, enquanto os pipelines padrão de LLM utilizam layouts de tensores convencionais. A conversão ingênua antes de cada invocação da SME adiciona tráfego de memória e interrompe a localidade de dados, anulando os ganhos de throughput.

Metodologia

O artigo introduz o SMEPilot, um motor de inferência de LLM projetado para agendar sistematicamente núcleos SME e CPU com base em um modelo de desempenho unificado.

1. Caracterização de Roofline Unificada

Os autores desenvolvem um modelo de roofline de múltiplos tetos que captura a natureza acoplada dos recursos SME e CPU:

Computação Aditiva, Largura de Banda Compartilhada: SME e núcleos de CPU fornecem throughput de matriz quase aditivo, mas compartilham um único teto de largura de banda de memória.
Classificação de Regimes: O modelo classifica os operadores em três regimes baseados na intensidade aritmética ( $I$ $I$ ):
- Limitado por Memória (Memory-bound): Operadores abaixo do ponto de inflexão (ridge point) da CPU. A SME não oferece benefício, pois a largura de banda é o gargalo.
- Cruzamento de Inflexão Assimétrico de Backend (Backend-asymmetric Ridge-crossing): Operadores entre os pontos de inflexão da CPU e da SME. Estes são limitados por computação na CPU, mas limitados por memória na SME. A SME eleva o desempenho até o limite compartilhado de memória.
- Limitado por Computação (Compute-bound): Operadores acima do ponto de inflexão da SME. Tanto os núcleos de CPU quanto os de SME podem contribuir, e a execução mista é ideal.
Agendamento Dinâmico: O modelo dita que a seleção de backend (apenas CPU, apenas SME ou Misto) deve ser dinâmica, mudando conforme as formas de requisição (ex: comprimento de sequência, tamanho de lote) e tipos de operador.

2. Design do Runtime SMEPilot

Para preencher a lacuna entre o plano guiado pelo roofline e a execução real, o SMEPilot emprega três técnicas principais:

Particionamento de Trabalho ao Nível de Tile (Abordando a Utilização Espacial):
- Em vez de atribuir um operador inteiro a um único backend, o SMEPilot particiona o trabalho de matriz ao nível de tile.
- Para operações de GEMM, ele divide as dimensões de saída ( $M$ ou $N$ ) entre trabalhadores SME e núcleos de CPU com base na forma do operador e no throughput medido.
- Isso permite que ambos os backends contribuam para o mesmo operador sem overhead de sincronização entre trabalhadores.
- Em camadas de MoE, especialistas com poucos tokens (matrizes finas) permanecem na CPU, enquanto especialistas com muitos tokens utilizam execução mista.
Execução de Pipeline Consciente de Fase (Abordando Bolhas Temporais):
- Aplicado principalmente aos mecanismos de Atenção, que contêm fases de matriz ( $QK^\top$ , $PV$) e fases de vetor (Softmax, masking).
- O SMEPilot faz o pipeline dessas fases: enquanto os trabalhadores SME computam a etapa de matriz para um tile específico, os núcleos de CPU processam simultaneamente a etapa de vetor (ex: Softmax) para um tile precedente.
- Isso sobrepõe o trabalho específico de hardware, eliminando o tempo ocioso causado por fronteiras de operadores de granularidade grossa.
Runtime Consciente de Layout (Abordando Compatibilidade de Layout):
- O runtime rastreia layouts de tensores como estado para minimizar o overhead de conversão.
- Empacotamento Offline: Pesos estáticos do modelo são empacotados em layouts favoráveis à SME uma única vez no carregamento, removendo este custo do caminho crítico da requisição.
- Empacotamento no Lado do Produtor: Ativações dinâmicas (ex: entradas do KV-cache) são empacotadas no lado do produtor quando o consumidor subsequente é um kernel SME. Isso evita o desempacotamento e repacotamento repetidos nos caminhos críticos.

3. Geração de Plano de Execução

O SMEPilot utiliza um Profiler Offline para medir métricas de hardware (throughput, largura de banda) e um Planner Online para gerar planos de execução. O planejador avalia o modelo de roofline para cada operador, dada a forma atual da requisição, para determinar:

Seleção de backend (CPU, SME ou Misto).
Alocação de threads e razões de partição.
Tamanhos de tile para equilibrar a eficiência do kernel com a sobreposição de pipeline.

Resultados Principais

O SMEPilot foi avaliado em três plataformas (Apple M4 Pro, MediaTek Dimensity 9500, KunPeng 920 Server) usando Llama-3.2-3B, Qwen3-4B e Qwen3-30B-A3B.

Desempenho End-to-End: O SMEPilot alcança até 3.94× de aceleração sobre a linha de base llama.cpp através de várias configurações de dispositivo-modelo-carga de trabalho.
Fase de Prefill:
- FFN GEMM: 1.42–1.67× mais rápido que o Apple Accelerate altamente otimizado (apenas SME) e 6.06–7.43× mais rápido que o GGML (apenas CPU).
- Atenção: 1.56–3.50× mais rápido que o FlashAttention CPU.
- Os ganhos são impulsionados pela capacidade de utilizar tanto SME quanto núcleos de CPU para grandes operadores de matriz.
Fase de Decode:
- Alcança até 3.48× de aceleração sobre a inferência apenas de CPU.
- As melhorias são significativas para tamanhos de lote maiores, onde os operadores entram no regime de "cruzamento de inflexão", permitando que a SME alivie as restrições de largura de banda de memória.
Eficiência Energética: No Apple M4 Pro, o SMEPilot reduz o consumo de energia end-to-end para 0.485× da linha de base do llama.cpp, principalmente devido aos tempos de conclusão mais rápidos.
Comparação com GPU: No Apple M4 Pro, o SMEPilot atinge 0.72–0.96× o desempenho da inferência via GPU, posicionando-se como uma alternativa viável quando GPUs estão indisponíveis ou reservadas.

Significância e Alegações

O artigo afirma que a SME não é um substituto universal para os núcleos vetoriais de CPU, mas sim um recurso especializado que requer orquestração cuidadosa. A significância do SMEPilot reside em sua mudança de substituição estática de kernel para agendamento dinâmico e consciente da forma (shape-aware):

Caracterização Sistemática: Fornece a primeira caracterização abrangente baseada em roofline de CPUs com suporte a SME para inferência de LLM, revelando que o posicionamento de operadores deve ser dinâmico e dependente da forma.
Execução Cooperativa: Demonstra que o desempenho máximo é alcançado não escolhendo ou SME ou CPU, mas sim executando cooperativamente ambos dentro de um único operador (via partição de tile) e através de fases de operadores (via pipelining).
Gestão de Overhead de Runtime: Destaca que os ganhos brutos de throughput de extensões de matriz podem ser apagados pelos custos de conversão de layout, necessitando de estratégias de runtime conscientes de layout que mantenham o empacotamento fora dos caminhos críticos.

Os autores concluem que as extensões de matriz de CPU são mais eficazes quando seu throughput é aplicado seletivamente e amortizado através de regimes de inferência adequados, em vez de serem aplicadas uniformemente a todas as operações.