Der KI-Laptop, der keiner ist: Mein Snapdragon X Elite NPU-Debakel

Ein Erfahrungsbericht für alle, die einen „Copilot+ PC“ für lokale KI-Inferenz kaufen wollen – und warum das aktuell eine sehr schlechte Idee ist.

Das Versprechen

Microsoft und Qualcomm haben den Snapdragon X Elite massiv beworben. „Copilot+ PC“, 45 TOPS NPU-Leistung, „KI-native Hardware“ – die Marketingmaschinerie lief auf Hochtouren. Wer wie ich lokale KI-Modelle für die Entwicklungsarbeit nutzen wollte, konnte sich schwer vorstellen, dass dahinter praktisch nichts steckt. Also kaufte ich einen Lenovo Yoga Slim 7x mit Snapdragon X Elite (X1E78100) und 32 GB RAM gekauft. Was folgte, waren Wochen frustrierender Recherche, gescheiterter Versuche und Investitionen, die ich mir hätte sparen können.

Was ich wollte

Ich wollte ja gar nicht viel und habe mit Absicht bescheiden angefangen: Ein 7B-Modell (konkret Qwen2.5-Coder-7B) lokal auf dem NPU laufen lassen und über einen OpenAI-kompatiblen API-Endpoint an einen Coding-Assistenten anbinden. Schließlich, aber dazu später mehr, ist dieses Modell nicht für den Snapdragon-Stack verfügbar – jedenfalls so lange wie man die NPU nutzen möchte. Und warum sollte man dies nicht wollen. Sie ist immerhin DAS Merkmal eines „Copilot+“-PCs. Auf einem MacBook mit Apple Silicon ist das dank dem MLX-Framework ein Abend-Projekt. Auf dem Snapdragon X Elite ist es schlicht nicht möglich – jedenfalls nicht heute, und nicht mit Open-Source-Tooling.

Fehlschläge, Fehlschläge so weit das Auge reicht

llama.cpp mit QNN-Backend

Der naheliegendste Weg: llama.cpp, das de-facto-Standard-Framework für lokale LLM-Inferenz, hat mittlerweile einenPull-Request, der das QNN-Backend für Qualcomm-Hardware implementiert. Nach stundenlangem Build-Prozess, fehlenden DLLs und Debugging stellte sich heraus:

GGML_OP_MUL_MAT – die teuerste und wichtigste Operation für LLM-Inferenz – ist im QNN-Backend schlicht nicht implementiert. Der Backend meldet brav „offloaded 29/29 layers to GPU“, lädt aber in der Praxis nur 1,27 MiB des Modells auf den Accelerator. Der Rest läuft auf der CPU. Das ist kein Konfigurationsfehler, das ist fehlende Implementierung und die Beschleunigung dadurch schlichtweg nicht vorhanden.

Microsoft Olive: Eine Odyssee in drei Akten

Nachdem ich llama.cpp erst einmal zur Seite gelegt hatte, stieß ich aufMicrosoft Olive. Dies ist ein eigenes Tool zur Modelloptimierung für NPU-Inferenz des Konzerns aus Redmond. Was folgte ist symptomatisch für den gesamten Ecosystem-Zustand:

Akt 1: OOM auf 32 GB. Der Konvertierungsprozess für Qwen2.5-Coder-7B bricht mit einem Out-of-Memory-Fehler ab. Der Prozess braucht das 3-4-fache der Modellgröße im RAM gleichzeitig – auf einem Consumer-Laptop also absolut nicht realisierbar.

Akt 2: 128 GB Cloud-Server. Nach dem OOM auf dem Laptop habe ich einen dedizierten Cloud-Server mit 128 GB RAM gemietet und einAnsible Playbook für die Orchestrierungentwickelt. RAM war kein Problem mehr. Stattdessen: RuntimeError: unordered_map::at – ein Bug tief im PyTorch/Transformers ONNX-Export-Stack, ausgelöst durch inkompatible Versionen zwischen Olive, PyTorch und Transformers. Kein hilfreicher Fehlertext, nur ein C++ Exception-Name.

Akt 3: Der Fix, der keiner ist. Ein Microsoft-Mitarbeiter antwortete nach mehreren Tagen aufmein GitHub-Issueund empfahl Olive 0.11.0 mit spezifischen Paketversionen. Mit exakt diesen Versionen: gleicher Fehler. Mein Kommentar mit dem vollständigen Dependency-Stack und dem reproduzierten Fehler blieb danach unbeantwortet. Dank RAM-Crunch waren mir weitere Versuche schlicht das Geld nicht wert.

Windows AI Foundry: Microsofts eigene Antwort

Nachdem ich genug Zeit mit sinnlosen Versuchen verbracht hatte, veröffentlichte Microsoft zwischenzeitlich Windows AI Foundry – Das offizielle Tool zum Ausführen von Modellen auf „AI PCs“. Ein „foundry model list“ zeigt den Zustand des Ecosystems in einer einzigen Tabelle. Nur sehr wenige Modelle sind überhaupt für die Qualcomm-NPU optimiert, alle anderen Modelle laufen nur auf der CPU – oder in anderen Worten deutlich langsamer als nötig.

Das ist Microsofts eigenes Tool, auf Microsofts eigenem Betriebssystem, auf Hardware die Microsoft als „Copilot+ PC“ vermarktet – und selbst hier läuft das Modell „der Wahl“ – die eigentlich keine ist – nur auf der CPU. Wer einen Code-Assistenten mit einem aktuellen Coder-Modell auf dem NPU betreiben will, hat schlicht Pech.

Qualcomm AI Hub – Ein Zoo aus Modellen

Also versuche ich mein Glück bei Qualcomm selbst – jemand muss doch Interesse an einem sinnvollen Einsatz der Hardware haben… Und tatsächlich gibt es den Qualcomm AI Hub. Dies ist Qualcomms eigene Plattform für fertige NPU-Binaries. Klingt gut – bis man sich genauer damit befasst:

Veraltete Modelle. Qualcomm’s eigenener Model-Zoo bietet nur wenige aktuelle Modelle. Das Vorzeige-LLM auf dem Hub ist Mistral 7B Instruct v0.3 – veröffentlicht im September 2023. Im März 2026 ist das zwei Generationen alt. Qwen2.5-Coder, Llama 3.3, Gemma 3 – Fehlanzeige. Die Modell-Pipeline ist eingefroren auf dem Stand von vor zwei Jahren.

Falscher Chip. Der Snapdragon X Elite (X1E78100) – verbaut in Millionen von Copilot+ PCs – ist offiziell nicht gelistet. Der AI Hub zielt hauptsächlich auf den den Snapdragon 8 Elite, der in Mobilgeräten verbaut ist. Der Chip in meinem teuren „AI PC“ ist für Qualcomms eigene KI-Plattform eine Randnotiz.

Proprietäre Lizenz. Die herunterladbaren Modelle stehen unter der „Qualcomm AI Hub Proprietary License“ – kein Open-Source, kein eigenes Fine-Tuning, keine Anpassung möglich – dafür ist ein langwieriger Registrierungsprozess mit zig Lizenz-Zustimmungen nötig.

llama.cpp zur Rettung? Der Hexagon-Backend auf Windows

Während der Wochen, in denen ich die verschiedenen Ansätze durchprobierte und diesen Blogpost schrieb, wurde tatsächlich eineoffizielle Anleitung für das Hexagon-Backendauf „Windows on Snapdragon“ in llama.cpp veröffentlicht. Die Anleitung ist detailliert, technisch solide – aber und das ist der springende Punkt: Es ist eine Signierung des Treibers von Nöten. Für Privatleute bedeutet dies:

bcdedit /set TESTSIGNING ON

Um den NPU unter Windows nutzen zu können, muss Secure Boot deaktiviert werden.

Der Grund: Die kompilierten Binaries müssen mit einem selbst signierten Zertifikat signiert werden, das im Windows-Treiber-Test-Modus akzeptiert wird. Dafür muss das System in den Test-Signing-Modus versetzt werden – und dafür muss Secure Boot deaktiviert sein.

Das ist keine Kleinigkeit. Secure Boot ist eine fundamentale Sicherheitsfunktion moderner Systeme, die verhindert dass beim Systemstart nicht signierter Code ausgeführt wird. Sie schützt vor Bootkits, Rootkits und anderen tief im System verankerten Angreifern. Microsoft selbst empfiehlt ausdrücklich Secure Boot aktiviert zu lassen – und die Copilot+ PC Zertifizierung setzt Secure Boot voraus.

Um zusammenzufassen: Um die NPU-Funktion zu nutzen für die der Laptop beworben wurde, soll man die Sicherheitsfunktion deaktivieren, die Microsoft für eben diesen Laptop vorschreibt. Das ist absolut kein Angriff auf die Entwickler, die diese Anleitung geschrieben haben. Ich bin dankbar für diese Entwicklungen und die investierte Zeit.

Das Problem ist das offensichtliche Desinteresse von Microsoft und Qualcomm. Eigentlich sollte man erwarten, dass die Unternehmen im Wettbewerb um Entwickler alles daran setzen mit der AI-Community zusammen zu arbeiten. Statt die großartige Arbeit Freiwilliger mit der eigenen AI Foundry zu untergraben, hätte IMHO Microsoft schon zum Marktstart der Copilot+-PCs mit llama.cpp und anderen Projekten zusammenarbeiten müssen, um sicherzustellen, dass diese rechtzeitig einsetzbar sind. Dies ist mehr als zwei Jahre danach immer noch nicht sinnvoll der Fall.

Das eigentliche Problem

Das ist kein Bug. Das ist ein Ecosystem-Versagen – und eines das mich reales Geld für Laptop und Cloud-Server-Stunden gekostet hat. Zugegeben, dass Lenovo Yoga Slim 7x ist eine großartige Maschine, die mich noch lange begleiten wird, nur kann ich sie leider nicht sinnvoll für ihren eigentlichen Zweck einsetzen.

Qualcomm hat Hardware verkauft, deren Software-Stack für den angepriesenen Use-Case nicht existiert. Microsoft hat Geräte unter dem „Copilot+ PC“-Label vermarktet, ohne sicherzustellen, dass offene KI-Workloads darauf laufen. Der NPU ist real – die 45 TOPS sind messbar. Aber ohne funktionierenden Software-Stack ist das eine Zahl auf einem Datenblatt.

Der Oryon-CPU im Snapdragon X Elite ist tatsächlich sehr schnell. llama.cpp läuft auf CPU mit 15-25 tok/s für ein 7B-Modell – das ist für viele Anwendungsfälle brauchbar. Aber das hat nichts mit dem NPU-Versprechen zu tun, für das das Gerät vermarktet wurde – jedenfalls nicht für mich als Entwickler.

Und die nächste Generation? Snapdragon X2 mit 80 TOPS

Qualcomm hat auf der CES 2026 den Snapdragon X2 Elite vorgestellt – mit 80 TOPS NPU-Leistung, fast doppelt so viel wie die 45 TOPS der ersten Generation. Die Marketingmaschine läuft wieder auf Hochtouren. Die entscheidende Frage ist: Was nützen 80 TOPS, wenn der Software-Stack dieselben fundamentalen Probleme hat?

Letztlich sind 80 TOPS dann auch nur eine größere Zahl auf demselben kaputten Fundament. Wer heute ein Snapdragon X2 Gerät kauft, geht dieselbe Wette ein: dass das Ecosystem irgendwann aufholt. Meine Erfahrung mit der ersten Generation legt nahe, dass diese Wette nicht aufgeht.

Hoffnung auf Microsoft Build 2026?

Die Microsoft Build findet am 2.–3. Juni 2026 in San Francisco statt, und der gerade veröffentlichte Session-Katalog deutet darauf hin, dass Microsoft die massiven Probleme des NPU-Ökosystems endlich angehen will. Die Session„Local Models, Developer Control, and the Future of AI Runtimes„macht dabei die größte Hoffnung. Auch„Train and deploy custom OSS reasoning models with Foundry„klingt nach einer Leuterung in Redmond – Hoffen wir nur, dass es sich bei den Modellen um aktuelle Modelle handelt, die dann auch noch für die NPU optimiert sind.

Meine Empfehlung

Wenn du lokale KI-Inferenz mit offenen Modellen und Open-Source-Tooling betreiben willst: Kauf kein Copilot+ PC mit Snapdragon X Elite – nicht für diesen Use-Case, nicht heute. Auch wenn ich kein Fan von Apple-Produkten bin: Ein MacBook mit Apple Silicon ist der Stand der Technik für lokale LLM-Inferenz auf Laptops. Wenn du mobil bleiben willst und Apple’s Walled Garden umschiffen möchtest, werfe einen Blick in Richtung Intel und AMD. Beide stehen deutlich besser da als Qualcomm. Alternativ gibt es natürlich noch zahlreiche stationäre KI-Workstations verschiedener Hersteller. Für mich immer noch eine bessere Alternative als meine Kreditkarte bei den verschiedenen KI-Modellanbietern zu hinterlegen.

Der Snapdragon X Elite NPU mag in zwei oder drei Jahren, mit ausgereiftem Software-Stack, eine interessante Option sein. Heute ist er für Open-Source-LLM-Inferenz Marketing ohne Substanz.