Serving rápido de grandes modelos de linguagem em PCs com GPUs de consumo

 (github.com/SJTU-IPADS)
1 pontos por GN⁺ 2023-12-21 | 1 comentários | Compartilhar no WhatsApp
  • O PowerInfer é um mecanismo de inferência híbrido CPU/GPU para servir LLMs localmente em PCs pessoais equipados com uma única GPU de consumo
  • O projeto central usa a localidade de ativação da inferência de LLMs: neurônios hot, ativados com frequência, são carregados previamente na GPU, enquanto neurônios cold, que variam conforme a entrada, são calculados na CPU
  • Nas avaliações, o PowerInfer afirma ter alcançado, com uma única RTX 4090, uma média de 13,20 tokens/s e um máximo de 29,08 tokens/s em vários LLMs, incluindo o OPT-175B, ficando 18% abaixo de uma A100
  • Em comparação com o llama.cpp, a demonstração com Falcon(ReLU)-40B-FP16 em uma RTX 4090 de 24 GB mostrou 11x de aumento de velocidade; nas avaliações, o ganho chegou a 11,69x, mantendo a precisão do modelo
  • O suporte é centrado em modelos com funções de ativação ReLU/ReGLU/Squared ReLU, com a limitação de que Mistral, Llama original, Qwen e outros ainda não são suportados

O problema que o PowerInfer busca resolver

  • PowerInfer é um mecanismo de inferência CPU/GPU para executar LLMs rapidamente em dispositivos locais
  • Ele mira PCs com uma única GPU de consumo e tem como objetivo inferência e serving de LLMs com baixa latência
  • O ponto central do projeto é que a ativação de neurônios na inferência de LLMs segue uma distribuição de lei de potência
    • Alguns neurônios hot são ativados de forma consistente em diversas entradas
    • Muitos neurônios cold variam conforme entradas específicas

Abordagem de inferência híbrida CPU/GPU

  • O PowerInfer carrega previamente os neurônios hot na GPU para acesso rápido, enquanto calcula os neurônios cold na CPU
  • Essa abordagem se concentra em reduzir os requisitos de memória da GPU e a transferência de dados entre CPU e GPU
  • Além disso, integra um preditor adaptativo e operadores esparsos cientes dos neurônios para otimizar a ativação dos neurônios e a esparsidade de cálculo
  • Na inferência híbrida CPU/GPU, todos os blocos de ativação densa são descarregados automaticamente para a GPU; depois, quando possível, as FFNs são divididas e descarregadas para a GPU

Avaliação de desempenho e demonstrações

  • Em uma única GPU RTX 4090, alcançou média de 13,20 tokens/s e máximo de 29,08 tokens/s em vários LLMs, incluindo o OPT-175B
  • O resultado é descrito como 18% abaixo de uma GPU A100 topo de linha para servidores
  • Afirma ser até 11,69x mais rápido que o llama.cpp, preservando a precisão do modelo
  • Na demonstração, o Falcon(ReLU)-40B-FP16 foi executado em uma única RTX 4090 de 24 GB, mostrando 11x de aumento de velocidade em relação ao llama.cpp
    • Tanto o PowerInfer quanto o llama.cpp foram executados no mesmo hardware e usaram totalmente a VRAM da RTX 4090
  • Em uma avaliação separada, com RTX 4090 de 24 GB, modelo ReLU FP16 e comprimento de entrada 64, o Falcon 40B teve até 11x de ganho, e o Llama 2 70B, até 3x
  • Com RTX 2080Ti de 11 GB, modelo ReLU INT4 e comprimento de entrada 8, o Falcon 40B teve até 8x de ganho, e o Llama 2 70B, até 3x

Modelos e plataformas suportados

Fluxo de instalação e execução

  • As dependências de build são CMake 3.17 ou superior, Python 3.8 ou superior e pip 19.3 ou superior
  • Builds para GPU NVIDIA usam a opção -DLLAMA_CUBLAS=ON
  • Builds para GPU AMD são baseados em ROCm/HIP e especificam -DLLAMA_HIPBLAS=ON e AMDGPU_TARGETS
  • Builds CPU-only também são possíveis
  • O comando básico de inferência consiste em especificar, no executável main, o caminho do modelo, o número de tokens de saída, o número de threads e o prompt
  • O limite de uso de VRAM da GPU é especificado com a opção --vram-budget
  • Serving, avaliação de perplexidade e geração em lote no PowerInfer suportam comandos no mesmo estilo do llama.cpp, mas o argumento -ngl é substituído por --vram-budget no PowerInfer

Quantização e compatibilidade

  • O PowerInfer oferece suporte otimizado à quantização de modelos INT4 Q4_0
  • O executável quantize pode quantizar modelos PowerInfer GGUF para o formato Q4_0
  • O modo de inferência densa tem suporte limitado e pode ser usado de forma semelhante ao llama.cpp
  • O modo de inferência densa não é um modo de compatibilidade para todos os modelos
    • Os modelos ReluLLaMA e ProSparse têm a função de ativação alterada
    • Os modelos Bamboo têm a arquitetura do modelo alterada
  • Ele também pode ser executado com pesos de modelos do llama.cpp para compatibilidade de inferência, mas afirma não haver ganho de desempenho

Limitações e FAQ

  • Os modelos atualmente suportados são limitados a modelos que usam funções de ativação ReLU/ReGLU/Squared ReLU
  • Mistral, Llama original, Qwen e outros ainda não são suportados
  • Se ocorrer CUDA_ERROR_OUT_OF_MEMORY, é possível recriar o índice da GPU com --reset-gpu-index
  • Na implementação atual, o offloading do modelo pode não ser tão preciso quanto o esperado, portanto é possível reduzir um pouco o valor de --vram-budget ou desativar o offloading da FFN com --disable-gpu-index
  • A queda atual nas métricas de desempenho dos modelos ReLU, especialmente os modelos 70B, é explicada pelo fato de terem sido ajustados com apenas 5B tokens, diferentemente dos cerca de 2T tokens necessários para o treinamento típico de LLMs

Atualizações recentes e planos

  • Em 5 de janeiro de 2026, o Tiiny AI Pocket Lab foi anunciado, afirmando executar GPT-OSS-120B int4 localmente a 20 tokens/s
  • Em 27 de julho de 2025, foram lançados o SmallThinker-21BA3B-Instruct e o SmallThinker-4BA0.6B-Instruct
  • Em 11 de junho de 2024, foi apresentado o framework de inferência otimizado para smartphones PowerInfer-2, que afirma alcançar 11,68 tokens/s no TurboSparse-Mixtral-47B
  • No mesmo dia, foi divulgado o Turbo Sparse, descrito como tornando modelos Mistral e Mixtral cerca de 90% esparsos e ativando apenas 4B parâmetros em modelos de porte Mixtral
  • Os itens concluídos incluem a abertura do código principal do PowerInfer, suporte a Llama-2 e Falcon-40B, suporte a Bamboo-7B, suporte a Windows, publicação do código de avaliação de perplexidade e suporte à divisão online de FFN
  • Os itens restantes incluem suporte a text-generation-webui, suporte a Metal para Mac, abertura do código de modelos OPT, abertura do código de treinamento do predictor e suporte a Multi-GPU

Artigo e projetos base

  • Mais detalhes técnicos estão reunidos no artigo do PowerInfer
  • O PowerInfer usa a biblioteca de operadores modificáveis do ggml e o runtime de execução do llama.cpp
  • A THUNLP é mencionada no suporte a modelos esparsos baseados em ReLU
  • O PowerInfer afirma ter sido inspirado pela pesquisa Deja Vu

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-21
Opiniões no Hacker News

  • Na maior parte do machine learning, não existe o conceito de neurônios hot/cold, então levou um tempo para entender, e o artigo também parece não defini-lo diretamente.
    Em ReLU, se a saída é frequentemente 0, dá para considerar isso “cold”, então faz sentido, mas o LLaMA original não usa ReLU. Olhando novamente o GitHub, esse método na verdade só funciona em modelos ReLU, e há um grupo que “faz fine-tuning” do modelo para ReLU a fim de obter esparsidade: https://huggingface.co/SparseLLM
    Portanto, não se aplica a qualquer modelo comum que você encontre na internet, mas o avanço em si parece grande. No futuro, talvez haja uma migração para um compromisso entre modelos maiores e funções de ativação menos ideais, e também fico curioso sobre como a esparsidade será calculada quando regulações dos EUA e da UE usarem FLOPs ou número de parâmetros como critério.
    Como pesquisa futura, parece possível manter as funções de ativação existentes, como a SwiGLU do LLaMA, mas usar quantização para definir regiões de saturação como neurônios hot/cold.

    • Fico curioso sobre quando e como esse tipo de regulação surgiu. Parece bem estranho ter que se preocupar até com regulação de FLOPs/número de parâmetros durante o desenvolvimento.
    • Em um README que afirma compatibilidade com LLaMA, omitir a grande ressalva de que é apenas para modelos ReLU é um problema bastante sério.
    • Em https://huggingface.co/SparseLLM/ReluFalcon-40B também está escrito “We utilize PowerInfer for inference”.

  • Seria muito bom se desse para rodar um Mixtral sem censura com isso. Em uma RTX 4090, talvez até seja possível quantização acima de 3 bits.

    • Fico curioso por que alguém daria downvote, já que LLMs sem censura geralmente se saem melhor, pelo menos em benchmarks, do que versões “lobotomizadas” ou alinhadas.
    • Na demo, eles rodam um modelo maior em uma RTX 4090 com 24 GB de VRAM. Implementar ativação esparsa em Mixture of Experts pode não ser fácil, mas parece um ótimo caminho que poderia permitir processamento só na CPU ou até em GPUs muito mais baratas.
      O Mixtral, tecnicamente, já tem ativação esparsa controlada por uma rede neural, mas, como no meme de Inception, é preciso “ir mais fundo”.
    • Dá para considerar dual GPU como uma configuração comum de consumidor, e espero que haja suporte em breve. Em 4 bits, daria para encaixar até um espaço de contexto folgado.
      Como tudo isso é um fork do llama.cpp, espero que um dia entre no projeto upstream.
    • Parece bom: https://www.youtube.com/watch?v=q2KpPUOsBCs

  • Como dizem que estão trabalhando no Mistral-7B, minha implementação do Mistral dedicada a GPU usa pouco mais de 5 GB de VRAM: https://github.com/Const-me/Cgml
    Roda bastante bem na maioria das GPUs de consumidor, mas no momento só tem suporte a Windows.

    • Parece bem interessante. Fico curioso se rodaria em um notebook com Intel Core i7.
    • Você pode experimentar o ollama. Ele usa llmcpp e precisa de apenas cerca de 4 GB.

  • Muito legal. O llama.cpp é amado, mas seu esquema de offloading para GPU dedicada é relativamente simples: processa o prompt na GPU e divide o modelo no meio.
    É interessante que a esparsidade de ativação seja grande o suficiente para ser aproveitada, e, pela visão tradicional de machine learning, o acesso à memória costuma ser visto como muito aleatório.
    Seria bom se algum dia fosse possível fazer offload dos neurônios cold para a GPU integrada. Também me deixa curioso o fato de considerarem kernels Metal, porque eu achava que a vantagem de desempenho vinha do pool de memória híbrido. Se não for isso, parece que só ajudaria Macs AMD mais antigos, mas talvez eu esteja deixando algo passar.

    • Sobre Apple Silicon e Metal, a ideia pode ser dividir neurônios cold para CPU/Accelerate e neurônios hot para GPU, aproveitando ambos.
      Se não houver cópia entre GPU e CPU e o sistema já usar memória unificada, o ganho de velocidade pode ser pequeno, mas seria bom conseguir usar mais recursos do chip ao mesmo tempo. Para evitar queda de desempenho por calor, talvez seja melhor usar só os núcleos de eficiência, e o modo de jogo provavelmente funciona assim também.

  • Nesta implementação, parece ser necessário algum conhecimento sobre o próprio modelo para decidir quais partes colocar na memória do sistema e quais colocar na memória da GPU.
    Idealmente, fico curioso se isso poderia ser calculado automaticamente, ou se modelos futuros passarão a fornecer uma interface que permita automatizar esses algoritmos de alocação. Se o algoritmo tiver que ser ajustado para cada arquitetura de modelo, a manutenção deste projeto ficará bem trabalhosa.

    • Parece em grande parte correto. Eles fornecem um script para combinar os pesos do “Predictor” com o modelo original, mas na página inicial do GitHub não fica claro como esses pesos são produzidos.
      A aceleração de 10 vezes é realmente impressionante. Se for reproduzível em outros modelos, identificar neurônios hot/cold para otimização de inferência provavelmente se tornará uma parte comum do desenvolvimento de modelos.

  • Para quem não vai testar diretamente, a parte importante do README é mais ou menos esta: o PowerInfer foi testado em CPUs x86-64 no Linux (AVX2), em CPUs x86-64 no Linux com GPUs NVIDIA e em chips Apple M no macOS.
    Porém, dizem que a otimização para Mac ainda não foi feita, então o ganho de desempenho atual não é grande. Entre os recursos que serão adicionados em breve estão o modelo Mistral-7B e um backend Metal de inferência esparsa para macOS.

    • Também vale mencionar o modelo llama2 disponível para download e o arquivo convert.py.

  • É excelente a parte em que eles projetaram um motor de inferência híbrido GPU-CPU usando a distribuição de “um pequeno número de neurônios hot que são ativados de forma consistente em todas as entradas e um grande número de neurônios cold que variam conforme a entrada”.
    A explicação é que os neurônios hot são pré-carregados na GPU para acesso rápido, enquanto os neurônios cold são calculados na CPU, reduzindo bastante os requisitos de memória da GPU e a transferência de dados entre CPU e GPU.

  • Todo mundo compara com llama.cpp porque é o caminho mais fácil. Todos precisam saber que llama.cpp é lento. A comparação deveria ser com exllamav2 ou outras implementações otimizadas.

    • Neste caso, como o código é literalmente uma modificação do llama.cpp, faz sentido comparar com o llama.cpp. Não é só usar a biblioteca de cálculo matricial ggml; é um fork que usa main.cpp e o código geral do llama.cpp praticamente como estão, então dá para comparar diretamente.
      https://github.com/ggerganov/llama.cpp/pull/4543 [Review] Merge PowerInfer with llama.cpp mainline #4543
      https://github.com/ggerganov/llama.cpp/discussions/4534#disc... Há também uma explicação dizendo que “a melhoria de velocidade de 11 vezes é um pouco cherry-picked, porque o código de GPU do llama.cpp para Falcon 40B não é bem otimizado”.
    • O exllama não oferece suporte a restrições de gramática, então fica preso ao llama.cpp.
      Além disso, parece haver efeitos colaterais no exllama do ponto de vista de consistência: https://www.reddit.com/r/LocalLLaMA/comments/17w57eu/llm_for...
    • O ExLlama não é exclusivo para GPU? Esse ganho de velocidade é para o caso de uso com divisão GPU+CPU.
    • Fico curioso para saber o que seria uma boa recomendação se a ideia for algo mais rápido e que possa ser empacotado e distribuído junto com um app.

  • Seria muito legal se fosse possível gerar um arquivo preditor de esparsidade para qualquer modelo. Por enquanto, parece valer apenas para os 4 modelos que eles processaram.
    Pelo que se vê na página e no código, não parece haver uma ferramenta incluída para executar essa etapa. Por ora, pretendo esperar um pouco, e seria bom se esses recursos acabassem sendo mesclados de volta como opções do llama.cpp. Isto não usa apenas a biblioteca matricial ggml; é baseado no código comum do llama.cpp.

  • Só pela expressão “GPU de consumo”, parece que daria para rodar em vários modelos, mas, como costuma acontecer com textos desse tipo, fico pensando se na prática isso é exclusivo da RTX 4090.

    • Não me vem à cabeça nada que seja exclusivo da 4090. Normalmente o que importa é a VRAM; se forem necessários 24 GB, uma 3090 também serve, e duas placas de 12 GB também são uma opção.
      A técnica em si é uma abordagem geral que permite rodar modelos maiores em GPUs menores e melhora bastante o desempenho de offloading para a CPU. Além do caso de rodar o maior modelo em fp16 numa 4090, rodar o mesmo modelo com quantização de 4 bits numa 2080Ti também mostrou uma melhoria de cerca de 3 vezes em relação ao LLaMA.
      Por isso, em desktops, parece bem provável que modelos 33B se tornem o novo padrão, e que, mesmo com uma única 3090 ou 4090, seja possível rodar 70B em velocidade de chat em tempo real.