2 puntos por GN⁺ 2025-03-08 | 1 comentarios | Compartir por WhatsApp
  • Documento de inicio rápido de IPEX-LLM portable zip/tgz para usuarios que quieren ejecutar llama.cpp directamente en GPU de Intel, y en los paquetes más recientes también cubre la ejecución de DeepSeek-R1-671B-Q4_K_M con 1 o 2 Arc A770 en Xeon
  • El entorno objetivo incluye tanto Windows como Linux, y guía el procedimiento para ejecutar modelos GGUF en Intel Core Ultra / 11.ª a 14.ª generación y GPUs Intel Arc Series A / Series B
  • El flujo básico consiste en preparar localmente el modelo GGUF y luego ejecutarlo con llama-cli usando opciones como -ngl 99, -c 2500, -n 2048 y --temp 0
  • FlashMoE, exclusivo de Linux, es un CLI ajustado para ejecutar GGUF MoE de la familia DeepSeek V3/R1, y para DeepSeek V3/R1 requiere 380 GB de memoria CPU, de 1 a 8 Arc A770 y 500 GB de disco
  • En entornos con varias GPU Intel mezcladas, por defecto se usan todas las GPU, así que en combinaciones iGPU/dGPU se puede seleccionar la GPU con ONEAPI_DEVICE_SELECTOR o desactivar la comprobación con SYCL_DEVICE_CHECK=0

Ejecutar llama.cpp con portable zip/tgz

  • llama.cpp portable zip es un paquete basado en ipex-llm para ejecutar llama.cpp directamente en GPU de Intel
  • Se asume el flujo de portable zip/tgz para reducir la instalación manual, y el portable zip más reciente cubre la ejecución de DeepSeek-R1-671B-Q4_K_M con 1 o 2 Arc A770 en Xeon
  • Rango de hardware validado:
    • Procesadores Intel Core Ultra
    • Procesadores Intel Core de 11.ª a 14.ª generación
    • GPU Intel Arc Series A
    • GPU Intel Arc Series B

Inicio rápido en Windows

  • Se recomienda actualizar el driver de la GPU Intel a la versión más reciente

  • Descargar y descomprimir el IPEX-LLM llama.cpp portable zip para Windows desde el release v2.3.0-nightly

  • En cmd, ir a la carpeta descomprimida

    • cd /d PATH\\TO\\EXTRACTED\\FOLDER
  • Los usuarios con varias GPU pueden aplicar la configuración de selección de GPU antes de ejecutar

  • Ejecutar un modelo GGUF

    • Antes de ejecutar, hay que descargar o copiar un modelo GGUF de la comunidad en un directorio local
    • El modelo de ejemplo es DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf de bartowski/DeepSeek-R1-Distill-Qwen-7B-GGUF
    • Sustituir la ruta del modelo por la ubicación real y ejecutar llama-cli.exe
    llama-cli.exe -m PATH\\TO\\DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf -p "A conversation between User and Assistant. The user asks a question, and the Assistant solves it. The assistant first thinks about the reasoning process in the mind and then provides the user with the answer. The reasoning process and answer are enclosed within <think> </think> and <answer> </answer> tags, respectively, i.e., <think> reasoning process here </think> <answer> answer here </answer>. User: Question:The product of the ages of three teenagers is 4590. How old is the oldest? a. 18 b. 19 c. 15 d. 17 Assistant: <think>" -n 2048  -t 8 -e -ngl 99 --color -c 2500 --temp 0 -no-cnv
    
    • La salida de ejemplo muestra 1 dispositivo SYCL Intel Arc A770 Graphics, caché KV, SYCL compute buffer, configuración del sampler e información de rendimiento de generación de tokens

Inicio rápido en Linux

  • Se recomienda revisar la versión del driver de la GPU y, si hace falta, instalarlo siguiendo la guía de instalación del driver de GPU cliente de Intel

  • Descargar y descomprimir el IPEX-LLM llama.cpp portable tgz para Linux desde el release v2.3.0-nightly

  • En la terminal, ir a la carpeta descomprimida

    • cd /PATH/TO/EXTRACTED/FOLDER
  • Al usar llama.cpp portable zip en Linux, no se debe hacer source de oneAPI

  • Ejecutar un modelo GGUF

    • Igual que en Windows, preparar localmente un modelo GGUF de la comunidad como DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf
    • Sustituir la ruta del modelo por la ubicación real y ejecutar ./llama-cli
    ./llama-cli -m /PATH/TO/DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf -p "A conversation between User and Assistant. The user asks a question, and the Assistant solves it. The assistant first thinks about the reasoning process in the mind and then provides the user with the answer. The reasoning process and answer are enclosed within <think> </think> and <answer> </answer> tags, respectively, i.e., <think> reasoning process here </think> <answer> answer here </answer>. User: Question:The product of the ages of three teenagers is 4590. How old is the oldest? a. 18 b. 19 c. 15 d. 17 Assistant: <think>" -n 2048  -t 8 -e -ngl 99 --color -c 2500 --temp 0 -no-cnv
    
    • La salida de ejemplo incluye la lista de dispositivos SYCL, llama_kv_cache_init, llama_init_from_model, sampler chain e información de ejecución como n_ctx = 2528, n_batch = 4096 y n_predict = 2048

Ejecutar DeepSeek V3/R1 con FlashMoE

  • FlashMoE es una herramienta de línea de comandos construida sobre llama.cpp y está orientada a ejecutar modelos MoE como DeepSeek V3/R1

  • Actualmente está disponible en la plataforma Linux

  • Modelos MoE GGUF probados:

  • También se admiten otros modelos MoE GGUF

  • Requisitos y consideraciones

    • Requisitos para ejecutar DeepSeek V3/R1:
      • 380 GB de memoria CPU
      • De 1 a 8 Arc A770
      • 500 GB de disco
        • Los modelos más grandes u otras precisiones pueden requerir más recursos
        • En una plataforma con 1 sola Arc A770, hay que reducir la longitud de contexto para evitar OOM; en el ejemplo se añade -c 1024 al final del comando
        • En plataformas de doble socket, se puede obtener mejor rendimiento de decodificación activando SNC (Sub-NUMA Clustering) en el BIOS y anteponiendo numactl --interleave=all al comando de ejecución
        • Al usar FlashMoE, tampoco se debe hacer source de oneAPI
  • Ejecución del CLI

    ./flash-moe -m /PATH/TO/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf --prompt "What's AI?" -no-cnv
    
    • La salida de ejemplo muestra información de ejecución como KV buffer de 8 dispositivos SYCL, pipeline parallelism enabled, graph nodes/splits, n_threads = 48, n_ctx = 4096 y n_batch = 4096
  • Ejecución en modo serving

    ./flash-moe -m /PATH/TO/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf --serve -n 512 -np 2 -c 4096
    
    • -n es la cantidad de tokens a predecir, -np es la cantidad de secuencias de decodificación paralela y -c es el tamaño total del contexto
    • Los valores se pueden ajustar según los requisitos
    • La función de serving está disponible desde el build nightly v2.3.0
    • La salida de ejemplo incluye n_slots = 2, n_ctx_slot = 2048 para cada slot, carga del modelo, chat template y el servidor en espera en http://127.0.0.1:8080

Selección de múltiples GPU y errores de SYCL

  • Detección de dispositivos SYCL distintos

    • Si hay GPUs distintas mezcladas, puede aparecer el error Detected different sycl devices
    • El ejemplo muestra una situación en la que se detectan juntas 2 Arc A770 y 1 iGPU Intel UHD Graphics 770
    • Si las GPU no son iguales, el trabajo se asigna según la memoria del dispositivo; en el ejemplo, la iGPU recibe 2/3 de la carga de cómputo y el rendimiento cae mucho
    • Hay dos opciones
      • Desactivar la iGPU para obtener el mejor rendimiento
      • Desactivar la comprobación y usar todos los dispositivos
    set SYCL_DEVICE_CHECK=0
    export SYCL_DEVICE_CHECK=0
    
  • Especificar qué GPU usar

    • Si hay varias GPU Intel, llama.cpp se ejecuta por defecto en todas las GPU
    • Para usar solo GPU concretas, configurar la variable de entorno ONEAPI_DEVICE_SELECTOR antes de iniciar el comando de llama.cpp
    • Windows:
    set ONEAPI_DEVICE_SELECTOR=level_zero:0
    set ONEAPI_DEVICE_SELECTOR="level_zero:0;level_zero:1"
    
    • Linux:
    export ONEAPI_DEVICE_SELECTOR=level_zero:0
    export ONEAPI_DEVICE_SELECTOR="level_zero:0;level_zero:1"
    

Opciones de rendimiento y verificación de firma

  • Immediate command lists

    • SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS determina si se usan immediate command lists para enviar trabajo a la GPU
    • En general puede mejorar el rendimiento, pero puede haber excepciones, así que se recomienda probar tanto con la variable activada como desactivada para encontrar el mejor rendimiento
    • Windows:
    set SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
    
    • Linux:
    export SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
    
  • Verificación de firma de portable zip/tgz 2.2.0

    • La versión 2.2.0 de portable zip/tgz permite verificar la firma con openssl
    • Antes de verificar, openssl debe estar instalado en el sistema
    openssl cms -verify -in <portable-zip-or-tgz-file-name>.pkcs1.sig -inform DER -content <portable-zip-or-tgz-file-name> -out nul -noverify
    

1 comentarios

 
GN⁺ 2025-03-08
Opiniones en Hacker News
  • Es muy probable que esta configuración no tenga un rendimiento demasiado bueno porque le falta VRAM, así que tiene que mover muchos datos entre la memoria de la CPU y la de la GPU.
    Aun así, existe un modelo cuantizado de DeepSeek-R1 de menos de 256 GB, y no es una versión destilada: https://unsloth.ai/blog/deepseekr1-dynamic
    Es difícil cuantificar la diferencia frente al DSR1 completo en FP8, pero incluso el modelo cuantizado a ~Q2 resultó bastante usable, más de lo esperado.
    Otro modelo que vale la pena mencionar es DeepSeek v2.5; tiene menos parámetros que V3/R1, pero para correrlo en hardware de consumo todavía hace falta una cuantización agresiva. Alguien lo preparó recientemente: https://www.reddit.com/r/LocalLLaMA/comments/1irwx6q/deepsee...
    DeepSeek v2.5 podría considerarse mejor que Llama 3 70B, así que creo que quienes quieran correr inferencia local deberían conocerlo más.

    • Probé la cuantización R1 de Unsloth con doble Xeon Gold 5218 y 384 GB de DDR4-2666; no era una configuración óptima porque usaba solo alrededor de la mitad de los canales de memoria.
      Con IQ2_XXS / 183 GB y contexto de 16k, usando solo CPU, el procesamiento de prompts fue de 3 tokens/s y la respuesta de 1.44 tokens/s; con CPU + NVIDIA RTX con 70 GB de VRAM, el procesamiento de prompts fue de 4.74 tokens/s y la respuesta de 1.87 tokens/s.
      Creo que sería más útil si Unsloth sacara una cuantización similar para DeepSeek V3. Como no necesita tokens de razonamiento, podría ser más rápido en términos generales aun con los mismos tokens/s.
    • Tengo pensado probar v2.5, y ojalá sea tan coherente como v3.5 incluso cuantizado a ese tamaño.
      Estoy usando Q2_K_XL y, personalmente, me parece suficientemente bueno. Donde queda por detrás de FP8 es en escritura creativa; si le das varias veces el mismo prompt de historia y lo comparas con FP8, se nota la diferencia.
      En programación, 1.58 bits comete claramente más errores que Q2XXS o Q2_K_XL.
    • Actualmente supera los 8 tokens/s, y hay una demo en esta publicación: https://www.linkedin.com/posts/jasondai_run-671b-deepseek-r1...
  • https://github.com/intel/ipex-llm/blob/main/docs/mddocs/Quic...
    Los requisitos para superar los 8 tokens/s son 380 GB de memoria de CPU, de 1 a 8 ARC A770 y 500 GB de disco.

    • También se puede ver la demo de la publicación de Jason Dai: https://www.linkedin.com/posts/jasondai_with-the-latest-ipex...
    • Me pregunto si una sola Intel Arc A770 es suficiente para alcanzar 8 tokens/s o más.
    • Me pregunto aproximadamente cuánto costaría esta configuración.
      Supongo que menos de 10,000 dólares, y creo que tampoco vi cifras de tokens/s.
  • Me da curiosidad qué papel cumple exactamente Xeon en esta situación. ¿Hay alguna razón por la que no se pueda usar otro procesador x86?

    • Creo que es porque la mayoría de las placas madre que no son Xeon no tienen suficientes canales de memoria como para instalar esta cantidad de memoria con DIMM que se puedan conseguir comercialmente.
    • Los DDR4 UDIMM llegan hasta 32 GB por módulo, los DDR5 UDIMM hasta 64 GB por módulo, y las placas madre que no son Xeon normalmente tienen como máximo 4 ranuras UDIMM, así que el límite por nodo es 128 GB/256 GB.
      Las placas madre de servidor tienen hasta 16 ranuras DIMM por socket y soportan RDIMM/LRDIMM, así que pueden alojar más módulos y módulos de mayor capacidad.
      En el pico de la pandemia sí hubo lanzamientos de UDIMM de 128 GB.
    • No hay muchas placas madre, aparte de Epyc, que ofrezcan suficiente RAM total a un precio razonable. Para pruebas/desarrollo se puede comprar bastante barato un servidor Dell usado, dual socket, con Xeon antiguo y 512 GB de RAM.
      Acabo de buscar unos minutos y se ven fácilmente opciones por menos de 1500 dólares antes de agregar la tarjeta de video o SSD, y también configuraciones con 1024 GB de RAM por menos de 2000 dólares.
      Como mínimo, para poner varias tarjetas PCI-Express x16 3.0 a velocidad completa también hacen falta suficientes líneas PCIe, y eso es difícil de encontrar en placas madre Intel workstation de un solo socket.
      Como ejemplo, se pueden mencionar algunas configuraciones relativamente baratas con 512 GB de RAM. Van a consumir mucha energía y hacer ruido, pero el mismo enfoque aplica a otro hardware x86-64 como HP o Supermicro. Normalmente son configuraciones de 16 x 32 GB DDR4 DIMM.
      https://www.ebay.com/itm/186991103256?_skw=dell+poweredge+t6...
      https://www.ebay.com/itm/235978320621?_skw=dell+poweredge+r7...
      https://www.ebay.com/itm/115819389940?_skw=dell+poweredge+r7...
  • Me pregunto por qué no sacan una GPU con mucha RAM más grande pero más lenta. Así podrían alojarse modelos más grandes y el precio seguiría siendo manejable.

    • ¿Para qué serviría eso? No sería para juegos, y si es para IA, la postura actual de Nvidia es que pagues.
      La demanda de GPU para IA supera a la oferta, y detrás de la mayor parte de esa demanda hay dinero sobrecalentado que puede recibir subsidios, préstamos o inversiones. Los fabricantes de GPU pueden quedarse con ese dinero.
      Lamentablemente, la VRAM es un criterio perfecto para separar el uso liviano del uso con presupuesto. Es parecido a cómo el SSO se volvió un criterio perfecto para separar lo empresarial de lo no empresarial y aplicar el impuesto SSO.
    • Si las fabricaran así, habría menos incentivo para comprar GPU más caras.
    • Claro que es posible fabricar GPU con más VRAM, pero no hay suficiente competencia como para que tengan que hacerlo. La forma actual es mucho más rentable.
    • ¿No viste lo de AMD Halo Strix? En IA es más de dos veces más rápida que la Nvidia 4090 y salió la semana pasada.
  • ¿DeepSeek aprendió de OpenAI cómo ponerles nombre a los modelos?

    • La convención es rara, pero es bastante estándar en toda la industria, sobre todo en modelos GGUF. Significa que 671B parámetros fueron cuantizados a 4 bits.
      El término K_M parece más específico de GGUF y describe la estrategia concreta de cuantización.
  • Al artículo le falta un poco más de información. Me pregunto por qué todas las cifras de TPS están tapadas con x, qué rendimiento se puede esperar de esta configuración y cómo se compara con las configuraciones recientes y populares de workstation dual Epyc.

    • Actualmente, con Xeon de 5.ª generación (EMR) de 2 sockets se obtienen más de 8 TPS.
    • Si tienes un enlace a la receta de esa workstation dual Epyc que se volvió popular recientemente, me gustaría verla.
  • Al ver que en la salida de ejemplo ocultaron el valor de tokens/segundo, seguro corre muy bien.

  • Parece que hay varias opciones para ejecutar inferencia de LLM y Stable Diffusion fuera de Nvidia. Intel Arc, la serie M de Apple y ahora también AMD Ryzen AI Max.
    Está claro que correrlo en Nvidia es lo más optimizado, pero como es difícil conseguir tarjetas Nvidia con mucha VRAM a un precio razonable, uno sigue pensando en equipos que no sean Nvidia.
    Si no te interesa el entrenamiento ni el fine-tuning y solo haces inferencia, ¿estas soluciones son realmente utilizables? También me da curiosidad si es posible en una máquina Linux.

    • Si vas en serio, lo correcto es ir por Nvidia.
      Este artículo básicamente se siente como un recordatorio de Intel de “también hacemos GPU”, y aunque sus tarjetas económicas en sí son buenas, el ecosistema está demasiado atrasado.
      Sinceramente, este es un ámbito en el que es difícil ahorrar presupuesto y hacerlo bien.
  • Creo que cuando salgan APU para IA, el interés por las GPU se va a enfriar rápido.
    Con AMD Halo Strix o una APU Apple M3 Studio puedes usar 512 GB o 128 GB de RAM; ¿por qué comprar una Nvidia 4090 cara?
    Nvidia ha mantenido los precios altos y el rendimiento bajo todo el tiempo que pudo, y recién ahora le llega la competencia. Intel también puede fabricar una APU con muchísima RAM.
    Espero que Nvidia esté un poco nerviosa.