Serving rápido de modelos de lenguaje grandes en PCs con GPUs de consumo

 (github.com/SJTU-IPADS)
1 puntos por GN⁺ 2023-12-21 | 1 comentarios | Compartir por WhatsApp
  • PowerInfer es un motor de inferencia híbrido CPU/GPU para servir LLM localmente en una PC personal con una sola GPU de consumo
  • Su diseño central aprovecha la localidad de activación en la inferencia de LLM: los hot neurons que se activan con frecuencia se precargan en la GPU, mientras que los cold neurons que varían según la entrada se calculan en la CPU
  • En la evaluación, PowerInfer logró un promedio de 13.20 tokens/s y un máximo de 29.08 tokens/s en varios LLM, incluido OPT-175B, con una sola RTX 4090, y afirma quedar 18% por debajo de una A100
  • Frente a llama.cpp, en una demo con Falcon(ReLU)-40B-FP16 mostró una mejora de velocidad de 11x en una RTX 4090 de 24GB; en la evaluación alcanzó hasta 11.69x manteniendo la precisión del modelo
  • El alcance de soporte se centra en modelos con funciones de activación ReLU/ReGLU/Squared ReLU, con la limitación de que Mistral, original Llama y Qwen no están soportados actualmente

El problema que PowerInfer busca resolver

  • PowerInfer es un motor de inferencia CPU/GPU para ejecutar LLM rápidamente en dispositivos locales
  • Está dirigido a PCs con una sola GPU de consumo y apunta a inferencia y serving de LLM con baja latencia
  • La clave del diseño es que la activación de neuronas en la inferencia de LLM sigue una distribución de ley de potencia
    • Algunas hot neurons se activan de forma consistente en una amplia variedad de entradas
    • Muchas cold neurons cambian según la entrada específica

Método de inferencia híbrida CPU/GPU

  • PowerInfer precarga las hot neurons en la GPU para acceso rápido, y calcula las cold neurons en la CPU
  • Este enfoque se centra en reducir los requisitos de memoria de la GPU y la transferencia de datos entre CPU y GPU
  • Además, integra un predictor adaptativo y operadores dispersos con reconocimiento de neuronas para optimizar la activación neuronal y la dispersión del cálculo
  • En la inferencia híbrida CPU-GPU, primero descarga automáticamente a la GPU todos los dense activation blocks y luego, cuando es posible, divide el FFN para descargarlo a la GPU

Evaluación de rendimiento y demo

  • En una sola RTX 4090 logró un promedio de 13.20 tokens/s y un máximo de 29.08 tokens/s en varios LLM, incluido OPT-175B
  • Explica que este resultado queda 18% por debajo de una GPU A100 de gama alta para servidores
  • Afirma ser hasta 11.69x más rápido que llama.cpp manteniendo la precisión del modelo
  • En la demo, ejecutó Falcon(ReLU)-40B-FP16 en una sola RTX 4090 de 24GB y mostró una mejora de 11x frente a llama.cpp
    • Tanto PowerInfer como llama.cpp se ejecutaron en el mismo hardware y usaron por completo la VRAM de la RTX 4090
  • En una evaluación separada, con RTX 4090 24GB, modelo ReLU FP16 y longitud de entrada 64, Falcon 40B mostró hasta 11x de mejora y Llama 2 70B hasta 3x
  • Con RTX 2080Ti 11GB, modelo ReLU INT4 y longitud de entrada 8, Falcon 40B mostró hasta 8x de mejora y Llama 2 70B hasta 3x

Modelos y plataformas compatibles

Flujo de instalación y ejecución

  • Las dependencias de compilación son CMake 3.17 o superior, Python 3.8 o superior y pip 19.3 o superior
  • La compilación para GPU NVIDIA usa la opción -DLLAMA_CUBLAS=ON
  • La compilación para GPU AMD se basa en ROCm/HIP con -DLLAMA_HIPBLAS=ON y definiendo AMDGPU_TARGETS
  • También es posible una compilación solo CPU
  • El comando básico de inferencia usa el ejecutable main especificando ruta del modelo, número de tokens de salida, cantidad de hilos y prompt
  • El límite de uso de VRAM de la GPU se define con la opción --vram-budget
  • El serving, la evaluación de perplexity y la generación por lotes de PowerInfer soportan comandos del mismo estilo que llama.cpp, pero el argumento -ngl se reemplaza por --vram-budget en PowerInfer

Cuantización y compatibilidad

  • PowerInfer soporta con optimización la cuantización de modelos INT4 Q4_0
  • Con el ejecutable quantize se puede cuantizar un modelo PowerInfer GGUF al formato Q4_0
  • El modo de inferencia densa tiene soporte limitado y puede usarse de forma similar a llama.cpp
  • El modo de inferencia densa no es un modo de compatibilidad para todos los modelos
    • Los modelos ReluLLaMA y ProSparse tienen una función de activación modificada
    • Los modelos Bamboo tienen una arquitectura de modelo modificada
  • También puede ejecutarse con pesos de modelo de llama.cpp para compatibilidad de inferencia, pero aclara que no hay mejora de rendimiento

Limitaciones y FAQ

  • Los modelos soportados actualmente están limitados a aquellos que usan funciones de activación ReLU/ReGLU/Squared ReLU
  • Mistral, original Llama y Qwen no están soportados actualmente
  • Si aparece CUDA_ERROR_OUT_OF_MEMORY, se puede reconstruir el índice de GPU con --reset-gpu-index
  • En la implementación actual, el offloading del modelo puede no ser tan preciso como se espera, por lo que se puede bajar un poco el valor de --vram-budget o desactivar el offloading del FFN con --disable-gpu-index
  • Explica que la caída actual en métricas de rendimiento de modelos ReLU, especialmente los de 70B, se debe a que se afinaron con solo 5B tokens en vez de los aproximadamente 2T tokens que suelen requerirse para el entrenamiento general de LLM

Actualizaciones recientes y planes

  • El 5 de enero de 2026 presentó Tiiny AI Pocket Lab y afirmó ejecutar GPT-OSS-120B int4 localmente a 20 tokens/s
  • El 27 de julio de 2025 publicó SmallThinker-21BA3B-Instruct y SmallThinker-4BA0.6B-Instruct
  • El 11 de junio de 2024 presentó el framework de inferencia optimizado para smartphones PowerInfer-2, afirmando alcanzar 11.68 tokens/s en TurboSparse-Mixtral-47B
  • Ese mismo día publicó Turbo Sparse, explicando que vuelve sparse a los modelos Mistral y Mixtral con cerca de 90% de sparsity y activa solo 4B parámetros en modelos de clase Mixtral
  • Entre los elementos completados se incluyen la publicación del código central de PowerInfer, soporte para Llama-2 y Falcon-40B, soporte para Bamboo-7B, soporte para Windows, publicación del código de evaluación de perplexity y soporte para partición online de FFN
  • Entre los elementos pendientes se incluyen soporte para text-generation-webui, soporte Metal para Mac, publicación del código para modelos OPT, publicación del código de entrenamiento del predictor y soporte Multi-GPU

Paper y proyectos base

  • Más detalles técnicos están resumidos en el paper de PowerInfer
  • PowerInfer usa la biblioteca de operadores modificable de ggml y el runtime de ejecución de llama.cpp
  • Se menciona a THUNLP en relación con el soporte para modelos sparse basados en ReLU
  • PowerInfer afirma estar inspirado en la investigación Deja Vu

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-21
Opiniones de Hacker News

  • En la mayoría del aprendizaje automático no existe el concepto de neuronas hot/cold, así que me tomó tiempo entenderlo, y el paper tampoco parece definirlo directamente.
    En ReLU tiene sentido pensar que si la salida suele ser 0 es “cold”, pero LLaMA originalmente no usa ReLU. Volviendo a mirar GitHub, este método en realidad funciona solo con modelos ReLU, y hay grupos que “afinan” modelos con ReLU para obtener dispersidad: https://huggingface.co/SparseLLM
    Así que no aplica a cualquier modelo que se encuentra normalmente en internet, pero el avance en sí parece grande. En el futuro quizá se mueva hacia compromisos entre modelos más grandes y funciones de activación menos ideales, y también me da curiosidad cómo se calculará la dispersidad cuando las regulaciones de EE. UU. y la UE tomen como base los FLOPs o la cantidad de parámetros.
    Como investigación futura, parece posible mantener funciones de activación existentes como SwiGLU de LLaMA, pero usar cuantización para definir las zonas de saturación como neuronas hot/cold.

    • Me da curiosidad cuándo y cómo surgieron esas regulaciones. Se siente bastante raro tener que preocuparse hasta por regulaciones sobre FLOPs/cantidad de parámetros mientras se desarrolla.
    • Es un problema bastante grande que en el README que afirma compatibilidad con LLaMA se hayan omitido la gran salvedad de que es solo para modelos ReLU.
    • En https://huggingface.co/SparseLLM/ReluFalcon-40B también dice “We utilize PowerInfer for inference”.

  • Sería genial poder correr con esto un Mixtral sin censura. En una RTX 4090 podría volverse posible usar cuantización de más de 3 bits.

    • Me pregunto por qué recibe votos negativos, si los LLM sin censura suelen rendir mejor —al menos en benchmarks— que las versiones “lobotomizadas” o alineadas.
    • En la demo corren un modelo más grande en una RTX 4090 con 24 GB de VRAM. Implementar activación dispersa en Mixture of Experts quizá no sea fácil, pero parece una dirección excelente que podría permitir procesarlo solo con CPU o incluso con GPUs mucho más baratas.
      Técnicamente, Mixtral ya tiene activación dispersa controlada por una red neuronal, pero, como en el meme de Inception, hay que “ir más profundo”.
    • Una configuración de doble GPU podría considerarse bastante de consumo general, y ojalá la soporten pronto. Con 4 bits podría entrar cómodamente incluso el espacio de contexto.
      Todo esto es un fork de llama.cpp, así que espero que algún día llegue al proyecto upstream.
    • Se ve bien: https://www.youtube.com/watch?v=q2KpPUOsBCs

  • Dicen que están trabajando en Mistral-7B; mi implementación de Mistral solo para GPU usa un poco más de 5 GB de VRAM: https://github.com/Const-me/Cgml
    Corre bastante bien en la mayoría de las GPUs de consumo, pero por ahora solo soporta Windows.

    • Se ve bastante interesante. Me pregunto si correría también en una laptop con Intel Core i7.
    • Puedes probar ollama. Usa llmcpp y solo necesita unos 4 GB.

  • Realmente genial. Aunque llama.cpp es muy querido, su forma de offloading a GPU externa es relativamente simple: procesa el prompt en la GPU y divide el modelo por la mitad.
    Es interesante que haya tanta dispersidad de activación como para poder aprovecharla, y desde una perspectiva tradicional de machine learning se suele considerar que el acceso a memoria es muy aleatorio.
    Ojalá algún día se puedan descargar las neuronas cold a la GPU integrada. También me da curiosidad que estén considerando kernels de Metal, porque pensaba que la ventaja de rendimiento venía del pool de memoria híbrido. Si no es así, parecería ayudar solo a Macs AMD viejas, aunque quizá se me esté escapando algo.

    • Sobre Apple Silicon y Metal, quizá la idea sea dividir las neuronas cold hacia CPU/Accelerate y las hot hacia GPU para aprovechar ambos.
      Si ya se usa memoria unificada y no hay copias entre GPU y CPU, la mejora de velocidad podría ser pequeña, pero sería bueno si permite usar más funciones del chip al mismo tiempo. Para evitar la degradación de rendimiento por calor, probablemente convenga usar solo los núcleos de eficiencia, y supongo que el modo de juego también funciona de una forma parecida.

  • En esta implementación parece hacer falta cierto conocimiento del modelo en sí para decidir qué partes poner en memoria del sistema y cuáles en memoria de GPU.
    Idealmente, me pregunto si esto puede calcularse automáticamente, o si los modelos futuros ofrecerán interfaces que permitan automatizar estos algoritmos de asignación. Si hay que adaptar el algoritmo a cada arquitectura de modelo, mantener este proyecto se volverá bastante difícil.

    • En general parece cierto. Proporcionan un script para combinar los pesos del “Predictor” con el modelo original, pero en la portada de GitHub no queda claro cómo se crean esos pesos.
      La mejora de velocidad de 10 veces es realmente impresionante. Si se puede reproducir en otros modelos, es muy posible que identificar neuronas hot/cold para optimizar la inferencia se vuelva una parte común del desarrollo de modelos.

  • Para quienes no van a probarlo directamente, lo importante del README es más o menos esto: PowerInfer fue probado en CPU x86-64 en Linux (AVX2), CPU x86-64 con GPU NVIDIA en Linux, y chips Apple M en macOS.
    Sin embargo, dicen que no han optimizado para Mac, así que por ahora la mejora de rendimiento no es grande. Entre las funciones que llegarán pronto están el modelo Mistral-7B y un backend de inferencia dispersa con Metal para macOS.

    • También vale la pena mencionar el modelo llama2 descargable y el archivo convert.py.

  • Es excelente la parte en la que diseñaron un motor de inferencia híbrido GPU-CPU aprovechando la distribución de “unas pocas neuronas hot que se activan de forma consistente en todas las entradas, y muchas neuronas cold que varían según la entrada”.
    La explicación es que las neuronas hot se cargan de antemano en la GPU para acceso rápido, mientras que las cold se calculan en la CPU, reduciendo mucho los requisitos de memoria de GPU y la transferencia de datos entre CPU y GPU.

  • Todos comparan con llama.cpp porque es el camino fácil. Todos deberían saber que llama.cpp es lento. Habría que compararlo con exllamav2 u otras implementaciones optimizadas.

    • En este caso, el código es literalmente una modificación de llama.cpp, así que tiene sentido compararlo con llama.cpp. No es solo que use la biblioteca de cálculo matricial ggml, sino que es un fork que usa tal cual main.cpp y el código común de llama.cpp, por lo que se puede comparar directamente.
      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... También hay una explicación de que “la mejora de velocidad de 11 veces es un poco cherry-picking, porque el código GPU de llama.cpp para Falcon 40B no está bien optimizado”.
    • exllama no admite restricciones de gramática, así que queda atado a llama.cpp.
      Además, parece que exllama también tiene efectos secundarios en términos de consistencia: https://www.reddit.com/r/LocalLLaMA/comments/17w57eu/llm_for...
    • ¿ExLlama no es solo para GPU? Esta mejora de velocidad es para el caso de uso de división GPU+CPU.
    • Si hubiera que recomendar algo más rápido y que se pueda empaquetar y distribuir dentro de una app, me pregunto qué sería lo mejor.

  • Sería realmente genial si se pudieran generar archivos predictores de dispersión para modelos arbitrarios. Por ahora parece que solo aplica a los 4 modelos que ellos procesaron.
    Viendo la página y el código, no parece que incluyan una herramienta para realizar ese paso. Por ahora pienso esperar un poco, y ojalá estas funciones terminen reintegrándose como opciones de llama.cpp. Esto no solo usa la biblioteca matricial ggml, sino que está basado en el código normal de llama.cpp.

  • Solo por la expresión “GPU de consumo” parece que podría correr en varios modelos, pero, como suele pasar con este tipo de artículos, me pregunto si en la práctica es solo para RTX 4090.

    • No se me ocurre nada que sea específicamente solo para la 4090. Normalmente lo importante es la VRAM, así que si se necesitan 24 GB, una 3090 también sirve, y dos tarjetas de 12 GB también son una opción.
      Esta técnica en sí es una forma general de permitir ejecutar modelos más grandes en GPUs más pequeñas, y mejora mucho el rendimiento del offloading a CPU. Además del caso en que ejecutaron el modelo más grande en fp16 en una 4090, al ejecutar el mismo modelo cuantizado a 4 bits en una 2080 Ti también se vio una mejora de velocidad de unas 3 veces en LLaMA.
      Así que parece muy probable que en desktop los modelos 33B se conviertan en el nuevo valor por defecto, y que incluso con una sola 3090 o 4090 se pueda correr un 70B a velocidad de chat en tiempo real.