Snapdragon X Elite: Ein LLM lokal auf einem PC ausführen ARM

#Warum ist der Snapdragon X Elite für einen lokalen LLM interessant?

Der Snapdragon X Elite ist ein ARM-SoC von Qualcomm: bis zu 12 Oryon-Kerne, eine integrierte Adreno-GPU, eine Hexagon-NPU mit angekündigten 45 TOPS und vor allem ein einheitlicher LPDDR5X-Speicher, den sich CPU, GPU und NPU teilen. Dieser einheitliche Speicher erinnert an den Ansatz von Apple Silicon: Alle Recheneinheiten können ohne Kopieren auf das geladene Modell zugreifen, und Sie sind nicht durch separaten VRAM von 8 oder 12 GB eingeschränkt.

Der andere Vorteil ist das thermische Verhalten. Diese Chips wurden für lüfterlose oder nahezu geräuschlose Ultraportables entwickelt, deren Akkulaufzeit bei Büroanwendungen mehrere zehn Stunden beträgt. Für ein lokales LLM, das im Hintergrund läuft – E-Mails zusammenfassen, Texte umformulieren, kleine Skripte erstellen –, eröffnet das völlig neue Möglichkeiten: kein Lüfter, der hochdreht, kein Akku, der nach zwanzig Minuten leer ist.

#Die eigentliche Herausforderung: Windows auf ARM

Das erste Hindernis ist nicht die Leistung, sondern die Softwarekompatibilität. Windows 11 auf ARM führt x86/x64-Anwendungen über eine Emulationsschicht (Prism) aus. Diese Emulation kostet jedoch Leistung und verhindert bei KI häufig die Nutzung der Hardwarebeschleunigung. Ein für x86 kompiliertes Binärprogramm mit AVX-Befehlen erkennt weder die Adreno-GPU noch die Hexagon-NPU.

Die gute Nachricht: Die wichtigsten Tools für lokale KI verfügen nun über native ARM64-Builds. Dies ist die entscheidende Unterscheidung, die Sie während des gesamten Leitfadens beachten sollten – ein Tool, das installiert werden kann, ist nicht unbedingt ein natives ARM-Tool. Bei Emulation verlieren Sie einen großen Teil des Vorteils der Maschine.

Ollama

Bietet einen nativen Windows-ARM64-Build. Die Inferenz läuft auf der Oryon-CPU; standardmäßig werden Anfragen unter http://localhost:11434 entgegengenommen, wie auf jeder anderen Plattform.

LM Studio

Bietet eine native ARM64-Version für Windows auf Snapdragon mit einer für ARM kompilierten llama.cpp-Laufzeitumgebung an.

llama.cpp

Lässt sich nativ für ARM64 kompilieren und nutzt Vektorbefehle; dies ist die für diese Chips am besten optimierte zugrunde liegende Engine.

Zu vermeiden

Jede x64-Version, die unter Prism-Emulation gestartet wird: Sie läuft, aber langsam und ohne Zugriff auf spezialisierte Hardware.

#Die Hexagon-NPU: Mythos und Realität

Das ist der Kern des Missverständnisses. Das Copilot+-Marketing stellt die 45 TOPS der Hexagon-NPU so heraus, als würde jedes lokale LLM automatisch davon profitieren. In der Praxis laufen 2026 fast alle LLMs, die Sie über Ollama oder LM Studio starten, auf den CPU-Kernen, nicht auf der NPU.

Warum? Weil die Nutzung der NPU Modelle erfordert, die speziell für die Laufzeitumgebung von Qualcomm konvertiert und quantisiert wurden (über QNN – Qualcomm AI Engine Direct – und das ONNX-Format, in der Regel über ONNX Runtime mit dem QNN-Ausführungsanbieter). Das sind nicht dieselben GGUF-Dateien, die llama.cpp verarbeitet. Die NPU ist besonders gut bei regelmäßig getakteten und vorhersehbaren Arbeitslasten; die autoregressive Textgenerierung, bei der die Speicherbandbreite ausschlaggebend ist, liegt ihr weniger gut, als man glaubt.

Was die NPU nutzt

Demos und Anwendungen, die über das Qualcomm-SDK / AI Hub mit vorkonvertierten ONNX-Modellen paketiert werden (oft kleine Modelle oder Aufgaben im Bereich Bild- und Audioverarbeitung).

Was die NPU nicht nutzt

Ollama, LM Studio und llama.cpp im Standardbetrieb: Sie nutzen die CPU (und manchmal die Adreno-GPU über experimentelle Backends).

Die tatsächliche Leistung

Auf diesen Geräten bestimmen vor allem die Oryon-Kerne und die LPDDR5X-Bandbreite Ihre Generierungsgeschwindigkeit, nicht die angegebenen TOPS der NPU.

#Voraussetzungen und Prüfungen

Bevor Sie etwas installieren, vergewissern Sie sich, dass Sie tatsächlich einen ARM-Rechner verwenden, und prüfen Sie, wie viel RAM vorhanden ist – davon hängt ab, welche Modellgrößen Sie ausführen können, da CPU und GPU denselben Speicher nutzen.

# Architecture du processeur (doit renvoyer ARM64)
$env:PROCESSOR_ARCHITECTURE

# Mémoire physique totale, en Go
(Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB

OS

Windows 11 24H2 oder neuer, auf dem aktuellen Stand (neuere Builds verbessern die Prism-Emulation und die ARM-Unterstützung deutlich).

RAM

Mindestens 16 GB für eine komfortable Nutzung von 3B–9B-Modellen; 32 GB, um Modelle mit 20 bis 27B anzupeilen und Speicherreserven für das System zu behalten.

Speicher

Planen Sie je nach Anzahl der heruntergeladenen Modelle 10 bis 30 GB freien Speicherplatz ein (ein 7B Q4_K_M benötigt etwa 5 GB).

Realistische Erwartung

Rechnen Sie mit einer flüssigen Nutzung kleiner Modelle, einer ordentlichen Leistung bei Modellen mit 8–9 Milliarden Parametern und längeren Wartezeiten bei größeren Modellen. Die Durchsatzraten einer dedizierten GPU werden hier nicht erreicht.

#Schritt für Schritt ein lokales LLM installieren

Heute ist der einfachste und zuverlässigste Weg Ollama im nativen ARM64-Build, möglicherweise ergänzt durch eine grafische Oberfläche. Hier ist die Vorgehensweise.

1. 01
   Ollama ARM64 herunterladen

   Rufen Sie ollama.com/download auf und laden Sie das Windows-Installationsprogramm herunter. In neueren Versionen erkennt das Installationsprogramm die ARM64-Architektur und installiert die native Binärdatei. Prüfen Sie anschließend, ob der Dienst ordnungsgemäß läuft.
2. 02
   Dienst prüfen

   Öffnen Sie ein Terminal und führen Sie „ollama --version“ aus. Der Daemon lauscht auf http://localhost:11434; eine Anfrage an diese URL sollte die Antwort „Ollama is running“ liefern.
3. 03
   Ein erstes Modell herunterladen

   Beginnen Sie klein, um die vollständige Kette zu validieren, bevor Sie schwerere Modelle laden. Ein 3B-Modell in Q4_K_M ist ideal zum Testen der Reaktionsgeschwindigkeit.
4. 04
   Über die Kommandozeile chatten

   Starten Sie das Modell und prüfen Sie die Generierungsgeschwindigkeit. Wenn die Generierung flüssig läuft, steigern Sie schrittweise die Modellgröße (7B, dann 14B), solange der Arbeitsspeicher ausreicht.
5. 05
   Eine Benutzeroberfläche hinzufügen (optional)

   Installieren Sie LM Studio in der ARM64-Version für eine vollständige Benutzeroberfläche, oder verbinden Sie Open WebUI mit dem Ollama-Endpunkt, wenn Sie eine Weboberfläche bevorzugen.

# Modèle léger pour valider la chaîne
ollama pull granite4.2:3b
ollama run granite4.2:3b

# Une fois validé, monter en gamme
ollama pull qwen3.5:9b

#Empfohlene Modelle für 16–32 GB RAM

Da der Speicher vereinheitlicht ist und mit dem System geteilt wird, sollten Sie nicht davon ausgehen, dass der gesamte RAM für das Modell verfügbar ist. Halten Sie stets 4 bis 6 GB für Windows und Ihre Anwendungen frei. Die Richtwerte für den Speicherbedarf in Q4_K_M bleiben dieselben wie beim Betrieb auf einer GPU: ein 3B-Modell ≈ 2 GB, ein 9B-Modell ≈ 6–7 GB, ein 24B-Modell ≈ 14 GB.

16 GB RAM

Komfortbereich: Modelle mit 3B bis 9B in Q4_K_M. Granite 4.2 3B für schnelle Reaktionen, Qwen 3.5 9B oder Granite 4.2 8B für Qualität. Ein gpt-oss 20B (~14 GB) bleibt nutzbar, lässt aber wenig Spielraum.

32 GB RAM

Sie können Modelle im Bereich von 20–27 Milliarden Parametern bequem in Q4_K_M nutzen – gpt-oss 20B oder Mistral Small 24B (~14 GB, letzteres besonders gut im Französischen) bis hin zu Qwen 3.8 27B (~18 GB, 262k Kontext) – und lassen dabei noch reichlich Spielraum für das System. Ein dichtes Modell mit 32 Milliarden Parametern oder mehr lässt sich laden, läuft auf dieser CPU aber langsam; ein MoE wie Qwen 3.6 35B-A3B (~23 GB, 3 Milliarden aktive Parameter) bleibt deutlich schneller.

Quantisierung

Q4_K_M ist hier der beste Kompromiss zwischen Qualität, Größe und Geschwindigkeit. Wechseln Sie nur zu Q5_K_M, wenn Qualität Vorrang hat und der Arbeitsspeicher ausreicht; vermeiden Sie FP16, das auf Geräten dieser Klasse unnötig viel Speicher benötigt.

Ideale Anwendungsfälle

Umformulieren, Zusammenfassen, Übersetzen, Unterstützung bei einfachen Programmieraufgaben, Fragen und Antworten offline – Aufgaben, für die ein gutes Modell mit 9B bis 24B Parametern mehr als ausreicht.

#Akkulaufzeit und leiser Betrieb: die wahren Stärken

Hier hebt sich der Snapdragon X Elite wirklich ab. Während ein x86-Gaming-Notebook mit RTX unter KI-Last seinen Akku in wenigen Minuten leert und seine Lüfter laut aufheulen lässt, erzeugen diese ARM-Rechner Text und bleiben dabei kühl und leise – ob am Stromnetz oder im Akkubetrieb. Für die mobile Nutzung – beim Arbeiten im Zug, im Café oder in einem Besprechungsraum – ist das eine grundlegende Veränderung, nicht bloß eine graduelle Verbesserung.

Bei der reinen Geschwindigkeit können Sie mit ordentlichen, aber bescheidenen Durchsatzraten rechnen: etwa mehreren Dutzend Tokens pro Sekunde bei einem 3B-Modell, bis hinunter zu wenigen Tokens pro Sekunde bei einem dichten 24B-Modell. Das reicht mit einem kleinen Modell für flüssige Gespräche; lange Textgenerierungen mit einem großen Modell sind dagegen mühsamer. Die Latenz bis zum ersten Token bleibt dank der schnellen Oryon-Kerne im Rahmen.

Stille

Generierung ist möglich, ohne dass die Lüfter hochdrehen, bei Modellen mit niedriger TDP oft nahezu ohne Lüfterbetrieb.

Akkulaufzeit

Inferenz im Akkubetrieb ist praktikabel, während eine dedizierte GPU praktisch einen Netzanschluss erfordert. Ideal für einen mobilen lokalen Assistenten.

Thermik

Keine aggressive Drosselung bei längerer, leichter LLM-Nutzung, anders als bei x86-Ultraportables, die an ihre Leistungsgrenzen gebracht werden.

Nachteil

Der Durchsatz bleibt deutlich unter dem einer dedizierten GPU: Bei großen Modellen geht der Komfort zulasten der Tokens pro Sekunde.

#Grenzen gegenüber x86-Systemen und dedizierten GPUs

Um Enttäuschungen zu vermeiden, sagen wir es klar: Ein Snapdragon X Elite kann mit einem PC mit einer aktuellen NVIDIA-Karte nicht mithalten. Schon eine RTX 3060 mit 12 GB aus dem Einstiegssegment führt ein 14B-Modell deutlich schneller aus, und eine RTX 4090 mit 24 GB spielt in einer völlig anderen Liga. Die Stärke des Snapdragon liegt nicht in der reinen Leistung, sondern in der Leistung pro Watt und der Mobilität.

Das Ökosystem ist noch jung

Die ARM64-Unterstützung entwickelt sich schnell, ist aber noch weniger ausgereift als die x86-Unterstützung. Einige Tools, Erweiterungen oder GPU-Backends hinken noch hinterher oder sind experimentell.

Keine GPU-Beschleunigung für den Verbrauchermarkt

Das Adreno-Backend für llama.cpp steckt noch in den Anfängen; in der Praxis läuft die Inferenz hauptsächlich auf der CPU.

NPU nicht voll genutzt

Wie oben beschrieben, profitieren die gängigen LLM-Runtimes noch nicht von den 45 TOPS.

Größenbegrenzung

Bei dichten Modellen mit mehr als rund zwanzig Milliarden Parametern verschlechtert sich das Nutzungserlebnis deutlich; sehr große Modelle bleiben dedizierten GPUs vorbehalten (ein MoE mit wenigen aktiven Parametern bleibt die Ausnahme, die besser läuft).

#Weiterführende Informationen

Der Snapdragon X Elite lässt sich besser verstehen, wenn man ihn mit anderen NPU-Ansätzen vergleicht und die Grundlagen der lokalen Installation beherrscht. Diese Leitfäden führen die Überlegungen weiter:

Ryzen AI 9 HX: Taugt die NPU mit 50 TOPS wirklich für LLMs?

Das x86-Gegenstück zu dieser NPU-Debatte, mit ehrlichen Tests, deren Ergebnisse mit den Schlussfolgerungen dieses Leitfadens übereinstimmen.

Ollama installieren: Windows, macOS und Linux

Um den Ollama-Daemon und seine Befehle umfassend zu beherrschen; gilt auch für ARM64-Builds.

Die Quantisierung wählen (Q4, Q5, Q8)

Um den Kompromiss zwischen Qualität und Geschwindigkeit genauer abzustimmen – entscheidend auf einem Rechner, auf dem die CPU den Großteil der Arbeit übernimmt.