DeepSeek-R1-671B-Q4_K_M auf Xeon mit ein bis zwei Arc A770 ausführen

 (github.com/intel)
2 Punkte von GN⁺ 2025-03-08 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Schnellstartanleitung für Nutzer, die IPEX-LLM portable zip/tgz verwenden wollen, um llama.cpp direkt auf Intel-GPUs auszuführen; die neuesten Pakete decken auch die Ausführung von DeepSeek-R1-671B-Q4_K_M auf Xeon mit ein bis zwei Arc A770 ab
  • Zielumgebungen sind sowohl Windows als auch Linux; beschrieben wird das Ausführen von GGUF-Modellen auf Intel Core Ultra/Intel Core der 11. bis 14. Generation sowie Intel Arc A-Series/B-Series GPUs
  • Der grundlegende Ablauf: GGUF-Modell lokal bereitstellen und dann llama-cli mit Optionen wie -ngl 99, -c 2500, -n 2048, --temp 0 ausführen
  • Das nur für Linux verfügbare FlashMoE ist ein CLI für die Ausführung von MoE-GGUF-Modellen der DeepSeek-V3/R1-Familie; für DeepSeek V3/R1 werden 380 GB CPU-Speicher, ein bis acht Arc A770 und 500 GB Speicherplatz benötigt
  • In Umgebungen mit mehreren unterschiedlichen Intel-GPUs werden standardmäßig alle GPUs genutzt; bei iGPU/dGPU-Kombinationen kann man die GPU mit ONEAPI_DEVICE_SELECTOR festlegen oder die Prüfung mit SYCL_DEVICE_CHECK=0 deaktivieren

llama.cpp mit portable zip/tgz ausführen

  • llama.cpp portable zip ist ein auf ipex-llm basierendes Paket, mit dem llama.cpp direkt auf Intel-GPUs ausgeführt werden kann
  • Es setzt auf einen portable-zip/tgz-Ablauf, der manuelle Installation reduziert; das aktuelle portable zip behandelt auch die Ausführung von DeepSeek-R1-671B-Q4_K_M auf Xeon mit einer oder zwei Arc A770
  • Validierter Hardwareumfang:
    • Intel Core Ultra processors
    • Intel Core 11th~14th gen processors
    • Intel Arc A-Series GPU
    • Intel Arc B-Series GPU

Schnellstart unter Windows

  • Es wird empfohlen, den Intel-GPU-Treiber auf die neueste Version zu aktualisieren

  • Das IPEX-LLM llama.cpp portable zip für Windows aus dem v2.3.0-nightly-Release herunterladen und entpacken

  • In cmd in den entpackten Ordner wechseln

    • cd /d PATH\TO\EXTRACTED\FOLDER

  • Nutzer mit mehreren GPUs können vor dem Ausführen die Einstellungen zur GPU-Auswahl anwenden

  • GGUF-Modell ausführen

    • Vor dem Ausführen muss ein Community-GGUF-Modell in ein lokales Verzeichnis heruntergeladen oder kopiert werden
    • Das Beispielmodell ist DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf aus bartowski/DeepSeek-R1-Distill-Qwen-7B-GGUF
    • Den Modellpfad durch den tatsächlichen Speicherort ersetzen und dann llama-cli.exe ausführen
    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
    • Die Beispielausgabe zeigt ein SYCL-Gerät Intel Arc A770 Graphics, KV-Cache, SYCL-Compute-Buffer, Sampler-Einstellungen und Informationen zur Token-Generierungsleistung

Schnellstart unter Linux

  • Es wird empfohlen, die GPU-Treiberversion zu prüfen und bei Bedarf gemäß dem Intel client GPU driver installation guide zu installieren

  • Das IPEX-LLM llama.cpp portable tgz für Linux aus dem v2.3.0-nightly-Release herunterladen und entpacken

  • Im Terminal in den entpackten Ordner wechseln

    • cd /PATH/TO/EXTRACTED/FOLDER

  • Bei Verwendung des llama.cpp portable zip unter Linux darf oneAPI nicht gesourct werden

  • GGUF-Modell ausführen

    • Wie unter Windows ein Community-GGUF-Modell wie DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf lokal bereitstellen
    • Den Modellpfad durch den tatsächlichen Speicherort ersetzen und dann ./llama-cli ausführen
    ./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
    • Die Beispielausgabe enthält Ausführungsinformationen wie die SYCL-Geräteliste, llama_kv_cache_init, llama_init_from_model, sampler chain, n_ctx = 2528, n_batch = 4096, n_predict = 2048

DeepSeek V3/R1 mit FlashMoE ausführen

  • FlashMoE ist ein auf llama.cpp aufgebautes Kommandozeilentool, das auf die Ausführung von MoE-Modellen wie DeepSeek V3/R1 zugeschnitten ist

  • Derzeit ist es auf Linux-Plattformen verfügbar

  • Getestete MoE-GGUF-Modelle:

  • Andere MoE-GGUF-Modelle werden ebenfalls unterstützt

  • Anforderungen und Hinweise

    • Anforderungen für die Ausführung von DeepSeek V3/R1:
      • 380 GB CPU-Speicher
      • ein bis acht Arc A770
      • 500 GB Speicherplatz
        • Größere Modelle oder andere Präzisionen können mehr Ressourcen erfordern
        • Auf Plattformen mit einer einzelnen Arc A770 muss die Kontextlänge reduziert werden, um OOM zu vermeiden; im Beispiel wird am Ende des Befehls -c 1024 hinzugefügt
        • Auf Dual-Socket-Plattformen kann man durch Aktivieren von SNC (Sub-NUMA Clustering) im BIOS und Voranstellen von numactl --interleave=all vor den Ausführungsbefehl eine bessere Decoding-Leistung erzielen
        • Auch bei Verwendung von FlashMoE darf oneAPI nicht gesourct werden

  • CLI-Ausführung

    ./flash-moe -m /PATH/TO/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf --prompt "What's AI?" -no-cnv
    • Die Beispielausgabe zeigt Ausführungsinformationen wie KV-Buffer für acht SYCL-Geräte, pipeline parallelism enabled, graph nodes/splits, n_threads = 48, n_ctx = 4096, n_batch = 4096

  • Serving ausführen

    ./flash-moe -m /PATH/TO/DeepSeek-R1-Q4_K_M-00001-of-00009.gguf --serve -n 512 -np 2 -c 4096
    • -n ist die Anzahl der vorherzusagenden Tokens, -np die Anzahl paralleler Decoding-Sequenzen und -c die gesamte Kontextgröße
    • Die Werte können an die Anforderungen angepasst werden
    • Die Serving-Funktion ist ab dem v2.3.0 nightly build verfügbar
    • Die Beispielausgabe enthält n_slots = 2, n_ctx_slot = 2048 für jeden Slot, Modellladen, Chat-Template und den wartenden Serverstatus unter http://127.0.0.1:8080

Multi-GPU-Auswahl und SYCL-Fehler

  • Erkennung unterschiedlicher SYCL-Geräte

    • Wenn verschiedene GPUs gemischt sind, kann der Fehler Detected different sycl devices auftreten
    • Das Beispiel beschreibt eine Situation, in der zwei Arc A770 und eine Intel UHD Graphics 770 iGPU gemeinsam erkannt werden
    • Wenn die GPUs nicht identisch sind, werden Aufgaben nach Gerätespeicher zugewiesen; im Beispiel übernimmt die iGPU zwei Drittel der Rechenarbeit, wodurch die Leistung stark sinkt
    • Es gibt zwei Optionen
      • Die iGPU deaktivieren, um die beste Leistung zu erzielen
      • Die Prüfung deaktivieren und alle Geräte verwenden
    set SYCL_DEVICE_CHECK=0
export SYCL_DEVICE_CHECK=0

  • Zu verwendende GPU festlegen

    • Wenn mehrere Intel-GPUs vorhanden sind, läuft llama.cpp standardmäßig auf allen GPUs
    • Um nur bestimmte GPUs zu verwenden, vor dem Start des llama.cpp-Befehls die Umgebungsvariable ONEAPI_DEVICE_SELECTOR setzen
    • 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"

Performance-Optionen und Signaturprüfung

  • Immediate command lists

    • SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS legt fest, ob immediate command lists für die Übermittlung von GPU-Arbeit verwendet werden
    • In der Regel kann dies die Performance verbessern, es kann aber Ausnahmen geben; empfohlen wird, sowohl mit aktivierter als auch deaktivierter Umgebungsvariable zu testen, um die optimale Performance zu finden
    • Windows:
    set SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
    • Linux:
    export SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1

  • Signaturprüfung für portable zip/tgz 2.2.0

    • Für portable zip/tgz Version 2.2.0 kann die Signatur mit openssl überprüft werden
    • Vor der Prüfung muss openssl auf dem System installiert sein
    openssl cms -verify -in <portable-zip-or-tgz-file-name>.pkcs1.sig -inform DER -content <portable-zip-or-tgz-file-name> -out nul -noverify

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-08
Hacker-News-Kommentare

  • Bei dieser Konfiguration ist die VRAM-Kapazität zu knapp, sodass viele Daten zwischen CPU- und GPU-Speicher verschoben werden müssen; die Performance dürfte also nicht besonders gut sein
    Trotzdem gibt es ein auf unter 256 GB quantisiertes Modell von DeepSeek-R1, keine destillierte Version: https://unsloth.ai/blog/deepseekr1-dynamic
    Es ist schwer, den Unterschied zum vollständigen FP8 DSR1 quantitativ zu erfassen, aber selbst ein etwaiges ~Q2-quantisiertes Modell war brauchbarer als erwartet
    Ebenfalls erwähnenswert ist DeepSeek v2.5: Es hat zwar weniger Parameter als V3/R1, benötigt auf Consumer-Hardware aber weiterhin aggressive Quantisierung. Kürzlich hat jemand so etwas erstellt: https://www.reddit.com/r/LocalLLaMA/comments/1irwx6q/deepsee...
    Man kann durchaus argumentieren, dass DeepSeek v2.5 besser als Llama 3 70B ist, daher sollte man sich damit stärker beschäftigen, wenn man lokale Inferenz betreiben will

    • Ich habe die Unsloth-R1-Quantisierung mit zwei Xeon Gold 5218 und 384 GB DDR4-2666 getestet; dabei wurde nur etwa die Hälfte der Speicherkanäle genutzt, also keine optimale Konfiguration
      Mit IQ2_XXS / 183 GB und 16k Kontext erreichte ich bei reinem CPU-Betrieb 3 Token/s bei der Prompt-Verarbeitung und 1,44 Token/s bei der Antwortgenerierung; mit CPU + NVIDIA RTX 70 GB VRAM waren es 4,74 Token/s bei der Prompt-Verarbeitung und 1,87 Token/s bei der Antwortgenerierung
      Wenn Unsloth eine ähnliche Quantisierung auch für DeepSeek V3 veröffentlicht, wäre das wohl noch nützlicher. Da keine Inferenz-Token nötig sind, könnte es bei gleicher Token/s-Rate insgesamt schneller sein
    • Ich werde v2.5 wohl einmal ausprobieren und hoffe, dass es selbst bei so starker Quantisierung so konsistent wie v3.5 bleibt
      Ich nutze Q2_K_XL und finde es persönlich gut genug. Schwächer als FP8 ist es vor allem beim kreativen Schreiben; wenn man denselben Story-Prompt mehrmals eingibt und mit FP8 vergleicht, sieht man den Unterschied
      Beim Coding erzeugt 1,58 Bit eindeutig mehr Fehler als Q2XXS oder Q2_K_XL
    • Derzeit werden mehr als 8 Token/s erreicht, und dieser Beitrag enthält eine Demo: https://www.linkedin.com/posts/jasondai_run-671b-deepseek-r1...

  • https://github.com/intel/ipex-llm/blob/main/docs/mddocs/Quic...
    Die Anforderungen für mehr als 8 Token/s sind 380 GB CPU-Speicher, 1 bis 8 ARC A770 und 500 GB Festplattenspeicher

    • Dort ist auch die Demo aus dem Beitrag von Jason Dai zu sehen: https://www.linkedin.com/posts/jasondai_with-the-latest-ipex...
    • Ich frage mich, ob für mehr als 8 Token/s wirklich schon eine einzelne Intel Arc A770 ausreicht
    • Ich frage mich, was diese Konfiguration ungefähr kostet
      Vermutlich unter 10.000 US-Dollar, und ich glaube auch keine Token/s-Zahl gesehen zu haben

  • Ich frage mich, welche Rolle der Xeon hier genau spielt. Gibt es einen Grund, warum man nicht einfach einen anderen x86-Prozessor verwenden kann?

    • Vermutlich deshalb, weil die meisten Mainboards ohne Xeon nicht genügend Speicherkanäle haben, um mit kommerziell erhältlichen DIMMs so viel RAM zu bestücken
    • DDR4-UDIMMs gehen pro Modul bis maximal 32 GB, DDR5-UDIMMs bis maximal 64 GB, und Mainboards ohne Xeon haben in der Regel höchstens 4 UDIMM-Slots, sodass pro Node bei 128 GB bzw. 256 GB Schluss ist
      Server-Mainboards können bis zu 16 DIMM-Slots pro Sockel haben und unterstützen RDIMM/LRDIMM, sodass mehr Module und Module mit höherer Kapazität eingesetzt werden können
      Auf dem Höhepunkt von Corona gab es allerdings einmal 128-GB-UDIMMs
    • Mainboards, die genug GesamtrAM zu einem vernünftigen Preis bieten, gibt es abseits von Epyc nicht viele. Für Tests/Entwicklung kann man gebrauchte ältere Dell-Dual-Socket-Server mit Xeon und 512 GB RAM ziemlich günstig bekommen
      Ich habe gerade ein paar Minuten gesucht, und selbst vor Einrechnung von Grafikkarten oder SSDs findet man leicht Angebote unter 1.500 Dollar, und Konfigurationen mit 1.024 GB RAM auch unter 2.000 Dollar
      Man braucht außerdem genug PCIe-Lanes, wenn man mehrere Karten mit voller PCI-Express-x16-3.0-Geschwindigkeit betreiben will, und das ist bei Intel-Workstation-Mainboards mit nur einem Sockel schwer zu finden
      Als Beispiele hier ein paar relativ günstige Konfigurationen mit 512 GB RAM. Sie werden viel Strom verbrauchen und laut sein, aber mit anderer x86-64-Hardware wie von hp oder supermicro fährt man denselben Ansatz. Meist sind das 16 x 32-GB-DDR4-DIMMs
      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...

  • Ich frage mich, warum es keine GPUs mit viel mehr, aber langsamerem RAM gibt. Damit ließen sich größere Modelle unterbringen, und der Preis könnte trotzdem noch bezahlbar bleiben

    • Wofür sollte das gebraucht werden? Für Gaming eher nicht, und bei AI heißt Nvidias Ansatz derzeit eben: zahlen
      Die Nachfrage nach AI-GPUs ist höher als das Angebot, und hinter dem Großteil dieser Nachfrage steht überhitztes Geld in Form von Subventionen, Krediten oder Investorengeldern. GPU-Hersteller können sich dieses Geld holen
      Leider ist VRAM ein perfektes Kriterium, um leichte Nutzung von zahlungskräftiger Nutzung zu trennen. Ähnlich wie SSO ein perfektes Kriterium ist, um Enterprise von Nicht-Enterprise zu unterscheiden, und dadurch eine SSO-Steuer entsteht
    • Das würde den Anreiz verringern, teurere GPUs zu kaufen
    • GPUs mit mehr VRAM zu bauen ist natürlich möglich, aber es gibt nicht genug Wettbewerb, um das tatsächlich tun zu müssen. Das aktuelle Modell ist deutlich profitabler
    • Hast du die Nachrichten zu AMD Halo Strix nicht gesehen? Bei AI ist das mehr als doppelt so schnell wie eine Nvidia 4090, und es kam letzte Woche heraus

  • Hat DeepSeek die Benennung von Modellen von OpenAI gelernt?

    • Die Konvention ist zwar etwas seltsam, aber branchenweit, besonders bei GGUF-Modellen, ziemlich standardisiert. Das bedeutet, dass 671B Parameter auf 4 Bit quantisiert wurden
      Der Begriff K_M scheint spezifischer für GGUF zu sein und beschreibt die konkrete Quantisierungsstrategie

  • Im Artikel sollten mehr Informationen stehen. Ich frage mich, warum die TPS-Werte alle mit x ausgeblendet sind, welche Leistung man von dieser Konfiguration erwarten kann und wie sie sich im Vergleich zu den zuletzt populären Dual-Epyc-Workstation-Setups schlägt

    • Aktuell kommt man auf einem 2-Sockel-Xeon der 5. Generation (EMR) auf über 8 TPS
    • Wenn es einen Link zu dem Rezept für die angeblich zuletzt populären Dual-Epyc-Workstations gibt, würde ich ihn mir gern ansehen

  • Dass im Beispiel-Output die Tokens/s-Werte verdeckt wurden, lässt wohl eindeutig darauf schließen, dass es ziemlich gut läuft.

  • Es scheint inzwischen einige Optionen zu geben, um LLM- und Stable-Diffusion-Inferenz auch außerhalb von Nvidia laufen zu lassen. Da wären Intel Arc, Apples M-Serie und jetzt auch AMD Ryzen AI Max.
    Dass es auf Nvidia am besten optimiert läuft, ist klar, aber bezahlbare Nvidia-Karten mit viel VRAM sind schwer zu bekommen, daher denkt man immer wieder über Nicht-Nvidia-Hardware nach.
    Wenn man sich nicht für Training oder Fine-Tuning interessiert und nur Inferenz machen will: Sind solche Lösungen in der Praxis wirklich brauchbar? Und geht das auch auf einer Linux-Maschine?

    • Wenn man es ernst meint, sollte man zu Nvidia greifen.
      Dieser Artikel erinnert im Grunde eher daran, dass Intel auch GPUs baut; die Budget-Karten an sich sind gut, aber das Ökosystem hinkt viel zu weit hinterher.
      Ehrlich gesagt ist das ein Bereich, in dem man kaum mit kleinem Budget etwas Vernünftiges hinbekommt.

  • Wenn APUs für KI auf den Markt kommen, dürfte das Interesse an GPUs schnell nachlassen.
    Mit AMD Halo Strix oder einer Apple M3 Studio APU kann man 512 GB bzw. 128 GB RAM nutzen — warum sollte man dann eine teure Nvidia 4090 kaufen?
    Nvidia hat die Preise so lange wie möglich hoch und die Leistung niedrig gehalten, und erst jetzt kommt Konkurrenz auf. Intel könnte ebenfalls eine APU mit sehr viel RAM bauen.
    Hoffentlich wird Nvidia langsam etwas nervös.