Exécuter DeepSeek-R1-671B-Q4_K_M sur Xeon avec 1 à 2 Arc A770

• Document de démarrage rapide IPEX-LLM portable zip/tgz destiné aux utilisateurs qui veulent exécuter directement llama.cpp sur un GPU Intel, couvrant dans les derniers paquets jusqu’à l’exécution de DeepSeek-R1-671B-Q4_K_M sur Xeon avec 1 ou 2 Arc A770
• L’environnement cible inclut Windows et Linux, avec une procédure d’exécution de modèles GGUF sur Intel Core Ultra / 11e à 14e génération et sur les GPU Intel Arc séries A et B
• Le flux de base consiste à préparer localement le modèle GGUF, puis à lancer llama-cli avec des options comme -ngl 99, -c 2500, -n 2048, --temp 0
• FlashMoE, réservé à Linux, est un CLI conçu pour exécuter les GGUF MoE de la famille DeepSeek V3/R1 ; pour DeepSeek V3/R1, il faut 380 Go de mémoire CPU, 1 à 8 Arc A770 et 500 Go d’espace disque
• Dans un environnement avec plusieurs GPU Intel hétérogènes, tous les GPU sont utilisés par défaut ; dans une configuration iGPU/dGPU, on peut sélectionner les GPU avec ONEAPI_DEVICE_SELECTOR ou désactiver la vérification avec SYCL_DEVICE_CHECK=0

---

Exécuter llama.cpp avec le portable zip/tgz

• Le llama.cpp portable zip est un paquet basé sur ipex-llm qui permet d’exécuter directement llama.cpp sur un GPU Intel
• Il part du principe d’un flux portable zip/tgz réduisant l’installation manuelle, et la dernière version portable couvre l’exécution de DeepSeek-R1-671B-Q4_K_M sur Xeon avec un ou deux Arc A770
• Périmètre matériel validé :
  • Processeurs Intel Core Ultra
  • Processeurs Intel Core de 11e à 14e génération
  • GPU Intel Arc série A
  • GPU Intel Arc série B

Démarrage rapide sous Windows

• Il est recommandé de mettre à jour le pilote GPU Intel vers la dernière version

• Télécharger puis extraire le portable zip IPEX-LLM llama.cpp pour Windows depuis la release v2.3.0-nightly

• Dans cmd, se déplacer vers le dossier extrait

  • cd /d PATH\\TO\\EXTRACTED\\FOLDER

• Les utilisateurs de plusieurs GPU peuvent appliquer un réglage de sélection du GPU avant l’exécution

• Exécuter un modèle GGUF

  • Avant l’exécution, il faut télécharger ou copier dans un répertoire local un modèle GGUF de la communauté
  • Le modèle d’exemple est DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf depuis bartowski/DeepSeek-R1-Distill-Qwen-7B-GGUF
  • Remplacer le chemin du modèle par son emplacement réel, puis exécuter 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 sortie d’exemple affiche un périphérique SYCL Intel Arc A770 Graphics, le cache KV, le buffer de calcul SYCL, la configuration du sampler et des informations de performance de génération de tokens

Démarrage rapide sous Linux

• Il est recommandé de vérifier la version du pilote GPU et, si nécessaire, de l’installer en suivant le guide d’installation du pilote GPU client Intel

• Télécharger puis extraire le portable tgz IPEX-LLM llama.cpp pour Linux depuis la release v2.3.0-nightly

• Dans le terminal, se déplacer vers le dossier extrait

  • cd /PATH/TO/EXTRACTED/FOLDER

• Sous Linux, il ne faut pas sourcer oneAPI lorsqu’on utilise le portable zip llama.cpp

• Exécuter un modèle GGUF

  • Comme sous Windows, préparer localement un modèle GGUF de la communauté tel que DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf
  • Remplacer le chemin du modèle par son emplacement réel, puis exécuter ./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 sortie d’exemple inclut la liste des périphériques SYCL, llama_kv_cache_init, llama_init_from_model, la chaîne de samplers, ainsi que des informations d’exécution comme n_ctx = 2528, n_batch = 4096, n_predict = 2048

Exécuter DeepSeek V3/R1 avec FlashMoE

• FlashMoE est un outil en ligne de commande construit au-dessus de llama.cpp, optimisé pour exécuter des modèles MoE comme DeepSeek V3/R1

• Il est actuellement disponible sur la plateforme Linux

• Modèles MoE GGUF testés :

  • DeepSeek-V3-Q4_K_M
  • DeepSeek-V3-Q6_K
  • DeepSeek-R1-Q4_K_M.gguf
  • DeepSeek-R1-Q6_K
  • DeepSeek-V3-0324-GGUF/Q4_K_M
  • DeepSeek-V3-0324-GGUF/Q6_K

• D’autres modèles MoE GGUF sont également pris en charge

• Exigences et points d’attention

  • Configuration requise pour exécuter DeepSeek V3/R1 :
    • 380 Go de mémoire CPU
    • 1 à 8 Arc A770

    • 500 Go d’espace disque

      • Des modèles plus volumineux ou d’autres niveaux de précision peuvent nécessiter davantage de ressources
      • Sur une plateforme avec un seul Arc A770, il faut réduire la longueur de contexte pour éviter les OOM ; l’exemple ajoute -c 1024 à la fin de la commande
      • Sur une plateforme bi-socket, on peut obtenir de meilleures performances de décodage en activant SNC (Sub-NUMA Clustering) dans le BIOS et en préfixant la commande avec numactl --interleave=all
      • Lors de l’utilisation de FlashMoE, il ne faut pas non plus sourcer oneAPI

• Exécution CLI

  • Le modèle d’exemple est DeepSeek-R1-Q4_K_M.gguf, et il faut indiquer le chemin du premier fichier découpé

  ./flash-moe -m /PATH/TO/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf --prompt "What's AI?" -no-cnv
  

  • La sortie d’exemple montre le buffer KV sur 8 périphériques SYCL, pipeline parallelism enabled, les nœuds/splits du graphe, ainsi que des informations d’exécution comme n_threads = 48, n_ctx = 4096, n_batch = 4096

• Exécution en mode Serving

  ./flash-moe -m /PATH/TO/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf --serve -n 512 -np 2 -c 4096
  

  • -n est le nombre de tokens à prédire, -np le nombre de séquences décodées en parallèle, et -c la taille totale du contexte
  • Les valeurs peuvent être ajustées selon les besoins
  • La fonction Serving est disponible à partir de la build nightly v2.3.0
  • La sortie d’exemple inclut n_slots = 2, n_ctx_slot = 2048 pour chaque slot, le chargement du modèle, le chat template et l’attente du serveur sur http://127.0.0.1:8080

Sélection multi-GPU et erreurs SYCL

• Détection de périphériques SYCL différents

  • Si des GPU différents sont mélangés, l’erreur Detected different sycl devices peut apparaître
  • L’exemple correspond à une situation où deux Arc A770 et un iGPU Intel UHD Graphics 770 sont détectés ensemble
  • Si les GPU ne sont pas identiques, la charge est répartie selon la mémoire des périphériques ; dans l’exemple, l’iGPU reçoit 2/3 du calcul, ce qui dégrade fortement les performances
  • Deux options sont possibles
    • Désactiver l’iGPU pour obtenir les meilleures performances
    • Désactiver la vérification et utiliser tous les périphériques

  set SYCL_DEVICE_CHECK=0
  export SYCL_DEVICE_CHECK=0
  

• Spécifier les GPU à utiliser

  • En présence de plusieurs GPU Intel, llama.cpp s’exécute par défaut sur tous les GPU
  • Pour n’utiliser que certains GPU, définir la variable d’environnement ONEAPI_DEVICE_SELECTOR avant de lancer la commande 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"
  

  • Pour plus de détails sur la sélection multi-GPU, voir multi_gpus_selection.md

Options de performance et vérification de signature

• Immediate command lists

  • SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS détermine si des immediate command lists sont utilisées pour soumettre les tâches GPU
  • Cela peut généralement améliorer les performances, mais il peut y avoir des exceptions ; il est recommandé de tester avec et sans cette variable d’environnement pour trouver les meilleures performances
  • Windows :

  set SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
  

  • Linux :

  export SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
  

  • Pour plus d’informations, voir la documentation Intel sur les Level Zero immediate command lists

• Vérification de signature du portable zip/tgz 2.2.0

  • La version 2.2.0 du portable zip/tgz permet de vérifier la signature avec openssl
  • Avant la vérification, openssl doit être installé sur le système

  openssl cms -verify -in <portable-zip-or-tgz-file-name>.pkcs1.sig -inform DER -content <portable-zip-or-tgz-file-name> -out nul -noverify
  

[GN⁺]

Avis sur Hacker News

• Cette configuration manque de VRAM, donc elle devra beaucoup déplacer les données entre la mémoire CPU et GPU ; les performances risquent donc de ne pas être excellentes.
  Cela dit, il existe un modèle quantifié de DeepSeek-R1 à moins de 256 Go, et ce n’est pas une version distillée : https://unsloth.ai/blog/deepseekr1-dynamic
  Il est difficile de quantifier l’écart avec le DSR1 complet en FP8, mais même le modèle quantifié en ~Q2 s’est révélé étonnamment utilisable.
  Un autre modèle qui mérite d’être mentionné est DeepSeek v2.5 : il a moins de paramètres que V3/R1, mais il faut tout de même une quantification agressive pour le faire tourner sur du matériel grand public. Quelqu’un en a récemment préparé une version : https://www.reddit.com/r/LocalLLaMA/comments/1irwx6q/deepsee...
  On peut considérer que DeepSeek v2.5 est meilleur que Llama 3 70B ; à mon avis, c’est donc un modèle que les personnes voulant faire de l’inférence en local devraient mieux connaître.

  • J’ai testé la quantification R1 d’Unsloth sur deux Xeon Gold 5218 avec 384 Go de DDR4-2666, en n’utilisant qu’environ la moitié des canaux mémoire, donc ce n’était pas une configuration optimale.
    Avec IQ2_XXS / 183 Go et un contexte de 16k, en CPU seul j’obtenais 3 tokens/s pour le traitement du prompt et 1,44 token/s en réponse ; avec CPU + NVIDIA RTX 70 Go de VRAM, 4,74 tokens/s pour le traitement du prompt et 1,87 token/s en réponse.
    Ce serait encore plus utile si Unsloth proposait une quantification similaire pour DeepSeek V3. Comme il n’a pas besoin de tokens de raisonnement, à tokens/s identiques il pourrait être globalement plus rapide.
  • Je compte essayer v2.5, et j’espère qu’il restera aussi cohérent que v3.5 même avec une quantification aussi réduite.
    J’utilise Q2_K_XL et, personnellement, je le trouve suffisamment bon. Là où il est en retrait par rapport au FP8, c’est dans l’écriture créative : si l’on soumet plusieurs fois le même prompt narratif et qu’on compare avec le FP8, la différence se voit.
    En code, le 1,58 bit produit clairement plus d’erreurs que Q2XXS ou Q2_K_XL.
  • On dépasse actuellement les 8 tokens/s, et une démo figure dans ce billet : https://www.linkedin.com/posts/jasondai_run-671b-deepseek-r1...

• https://github.com/intel/ipex-llm/blob/main/docs/mddocs/Quic...
  Pour dépasser 8 tokens/s, les exigences sont 380 Go de mémoire CPU, de 1 à 8 cartes ARC A770, et 500 Go de disque.

  • On peut aussi voir la démo dans le billet de Jason Dai : https://www.linkedin.com/posts/jasondai_with-the-latest-ipex...
  • Je me demande si une seule Intel Arc A770 suffit pour atteindre 8 tokens/s ou plus.
  • Je me demande aussi combien coûterait à peu près cette configuration.
    J’imagine que ce serait moins de 10 000 dollars, et je crois ne pas avoir vu non plus de chiffre en tokens/s.

• Je me demande quel est exactement le rôle du Xeon dans cette situation. Y a-t-il une raison pour laquelle on ne pourrait pas utiliser un autre processeur x86 ?

  • Je pense que c’est parce que la plupart des cartes mères non Xeon n’ont pas assez de canaux mémoire pour installer autant de mémoire avec des DIMM disponibles dans le commerce.
  • Les DDR4 UDIMM plafonnent à 32 Go par module, les DDR5 UDIMM à 64 Go par module, et les cartes mères non Xeon ont généralement au maximum 4 emplacements UDIMM, ce qui limite à 128 Go/256 Go par nœud.
    Les cartes mères serveur peuvent avoir jusqu’à 16 emplacements DIMM par socket et prennent en charge les RDIMM/LRDIMM, ce qui permet d’installer davantage de modules et des modules de plus grande capacité.
    Il y a bien eu des UDIMM de 128 Go lancées au plus fort du Covid.
  • Il n’y a pas beaucoup de cartes mères, à part Epyc, qui offrent une quantité totale de RAM suffisante à un prix raisonnable. Pour du test/développement, on peut acheter assez bon marché un ancien serveur Dell Xeon bi-socket d’occasion avec 512 Go de RAM.
    Après quelques minutes de recherche à l’instant, on en trouve facilement à moins de 1 500 dollars avant d’ajouter une carte vidéo ou un SSD, et on voit aussi des configurations avec 1 024 Go de RAM à moins de 2 000 dollars.
    Il faut aussi assez de lignes PCIe pour brancher au minimum plusieurs cartes PCI-Express x16 3.0 à pleine vitesse, ce qui est difficile à trouver sur une carte mère de workstation Intel mono-socket.
    On peut citer quelques configurations relativement abordables avec 512 Go de RAM. Elles consommeront beaucoup et seront bruyantes, mais c’est la même approche avec d’autres matériels x86-64 comme hp ou supermicro. En général, c’est une configuration 16 x 32 Go 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...

• Je me demande pourquoi on ne sort pas de GPU avec beaucoup de RAM plus grande mais plus lente. Ça permettrait de charger des modèles plus gros tout en gardant un prix encore abordable.

  • Pour quel usage, au juste ? Ce ne serait pas pour le jeu, et pour l’IA, la stratégie actuelle de Nvidia est de faire payer.
    La demande de GPU pour l’IA dépasse l’offre, et derrière l’essentiel de cette demande il y a de l’argent en surchauffe, capable d’obtenir subventions, prêts et investissements. Les fabricants de GPU peuvent capter cet argent.
    Malheureusement, la VRAM est un critère parfait pour séparer les usages légers des usages fortunés. C’est un peu comme le SSO, devenu un critère parfait pour distinguer l’entreprise du non-entreprise, avec une taxe SSO à la clé.
  • S’ils faisaient ça, il y aurait moins de raisons d’acheter des GPU plus chers.
  • Il est évidemment possible de fabriquer un GPU avec plus de VRAM, mais il n’y a pas assez de concurrence pour les y pousser. Le modèle actuel est bien plus rentable.
  • Tu n’as pas vu les infos sur AMD Halo Strix ? En IA, il est plus de deux fois plus rapide qu’une Nvidia 4090, et il est sorti la semaine dernière.

• DeepSeek a appris d’OpenAI comment nommer ses modèles ?

  • La convention est bizarre, mais elle est assez standard dans l’ensemble du secteur, surtout pour les modèles GGUF. Cela signifie que 671 milliards de paramètres ont été quantifiés en 4 bits.
    Le terme K_M semble plus spécifique à GGUF et décrit la stratégie de quantification précise.

• L’article devrait contenir un peu plus d’informations. Je me demande pourquoi toutes les valeurs de TPS sont masquées par des x, quelles performances on peut attendre de cette configuration, et comment elle se compare aux configurations de workstation bi-Epyc récemment à la mode.

  • Sur un Xeon de 5e génération (EMR) à 2 sockets, on obtient actuellement plus de 8 TPS.
  • Si quelqu’un a un lien vers la recette de workstation bi-Epyc récemment à la mode, je serais curieux de la voir.

• Vu que les valeurs de tokens/seconde sont masquées dans l’exemple de sortie, ça doit clairement tourner très bien.

• On voit apparaître quelques options pour faire tourner l’inférence de LLM et de Stable Diffusion en dehors de Nvidia. Il y a Intel Arc, la série Apple M, et maintenant AMD Ryzen AI Max.
  Il est évident que les exécuter sur Nvidia reste le plus optimal, mais comme il est difficile de trouver des cartes Nvidia avec beaucoup de VRAM à un prix raisonnable, je continue à envisager du matériel non Nvidia.
  Si l’on ne s’intéresse ni à l’entraînement ni au fine-tuning, et seulement à l’inférence, est-ce que ce genre de solutions est réellement utilisable ? Je me demande aussi si c’est possible sur une machine Linux.

  • Si l’on veut faire les choses sérieusement, il faut partir sur Nvidia.
    Cet article ressemble surtout à un rappel de la part d’Intel du type « nous aussi, on fabrique des GPU » ; la carte d’entrée de gamme en elle-même est bonne, mais l’écosystème est beaucoup trop en retard.
    Honnêtement, c’est un domaine où il est difficile de faire les choses correctement en économisant sur le budget.

• Quand des APU pour l’IA arriveront, l’intérêt pour les GPU risque de retomber rapidement.
  Avec des APU AMD Halo Strix ou Apple M3 Studio, on peut utiliser 512 Go ou 128 Go de RAM ; pourquoi acheter une Nvidia 4090 chère ?
  Nvidia a maintenu des prix élevés et des performances limitées aussi longtemps que possible, et la concurrence arrive enfin. Intel pourrait aussi fabriquer un APU avec beaucoup de RAM.
  J’espère que Nvidia commence à être un peu nerveux.