Snapdragon X2 unter Linux: Die 80-TOPS-NPU ist nicht die Story — 228 GB/s sind es

Was Arm-Linux-Nutzer sich seit der ersten X Elite gewünscht haben, hat Qualcomm auf dem Snapdragon Summit auf Maui (22.–24. September 2026) angekündigt: ein Early Developer Preview für Linux auf Snapdragon-X2-Series-Laptops, mit Treibern, die upstream wandern statt in einen Vendor-Baum.¹ Die Schlagzeile in der meisten Berichterstattung lautete „Hexagon-NPU-Support via fastRPC" und „80 TOPS für lokale KI". Diese Rahmung ist verkehrt. Für die Workloads, die darüber entscheiden, ob sich ein Local-Inference-Laptop gut anfühlt — Token-für-Token-Generierung —, steht die entscheidende Zahl in der Speicherzeile des Product Briefs, nicht in der NPU-Zeile: LPDDR5x mit 9.523 MT/s, 192 Bit breit = 228 GB/s beim X2E-96 Extreme, gegenüber 128 Bit = 152 GB/s bei beiden günstigeren X2-Elite-Varianten.²

Dieser Guide zerlegt diese Lücke so, wie es der Inference-Math-Strang dieser Seite überall tut: erst Bus-Mathematik, dann Roofline, dann Marketing.

Was Qualcomm tatsächlich angekündigt hat

Der Developer-Blog (23. September 2026) ist ungewöhnlich präzise beim Scope — und diese Präzision ist der Ehrlichkeitstest:

• Hexagon-NPU via fastRPC. Der upstream wanderte Treiber ist der fastRPC-Remote-Processor-Kanal — der Mechanismus, über den die CPU Arbeit an den Hexagon-DSP übergibt — „für On-Device-AI-Inference".¹ Was das nicht ist: ein CUDA-klasses User-Space-Stack. fastRPC upstream bedeutet, dass der Kernel mit der NPU sprechen kann; es bedeutet nicht, dass llama.cpp oder vLLM einen Tensor-Provider bekommt, der die 80 TOPS austrinkt. Qualcomms eigene GenieX-Runtime — dieselbe Woche auf Hexagon via Clairvoyance mit 3B/9B/27B-Klasse-Agent-Workloads demonstriert — ist eine Runtime für Qualcomm-Plattformen, kein Mainline-Kernel-Anspruch.³
• Adreno via Mesa. Der GPU-Support läuft über den Open-Source-Stack: Freedreno (DRM/KMS), Turnip (Vulkan) und Rusticl (das in Rust geschriebene OpenCL-Frontend in Mesa) — für „Desktop-UI, Browser-Beschleunigung, Graphics-Workloads und GPU-Compute im Lauf der Zeit".¹ Das „im Lauf der Zeit" ist tragend.
• Nur Laptops, und nur X2 Series. Die Scope-Notiz des Blogs: „diese Arbeit richtet sich auf Laptops mit Snapdragon X2 Series. Sie deckt derzeit keine Desktop-Formfaktoren, früher Snapdragon-X-Plattformen oder andere Entwicklerboards ab. Die Bereitschaft variiert zudem je nach OEM-Design und X2-Series-Variante."¹ Kein X-Elite-Backport, keine Mini-PC-Versprechen.
• Production Readiness: Ende November 2026. „Diese Arbeit ist aktuell in progress, mit Abschluss angepeilt für Ende November. Das Upstreaming wird über November 2026 hinaus weiterlaufen."¹ Erstkäufer-Hardware und Erstkäufer-Kernel-Erwartungen sollten auf dasselbe Datum kalibriert werden.

Auf Distro-Seite sagte Qualcomm-Compute-Manager Kedar Kondap auf dem Summit, dass Debian-Support noch „vor Ende des Jahres" kommt, Ubuntu sei für Anfang 2027 angepeilt. Dieses Zitat ist presseberichtet (SiliconReport, unter Berufung auf die Summit-Keynote, 24. September 2026), nicht in einem Qualcomm-Primärdokument — die Zeitleiste bis zu ihrem Auftauchen in Qualcomms Release Notes als sekundärquellig behandeln.⁴

Der Product Brief, gelesen wie ein Inference-Ingenieur

Der X2-Elite-Product-Brief listet sieben Laptop-SKUs — X2E-96-100, X2E-94-100, X2E-90-100, X2E-88-100, X2E-84-100, X2E-80-100 und X2E-78-100. Die drei hier hervorgehobenen (X2E-96-100, X2E-88-100, X2E-80-100 — zur Zeit der Erstellung diejenigen mit verfügbarer Geräte-Verfügbarkeit) listen alle dieselbe 80 TOPS (INT8) Hexagon-NPU; der Brief führt zudem zwei 85-TOPS-Teile (X2E-90-100, X2E-84-100), die an der Decode-Arithmetik unten nichts ändern. Die Speicherzeile ist die einzige Differenz — und die einzige, die die Decode-Geschwindigkeit vorhersagt:²

Die Bus-Mathematik ist keine Marketing-Arithmetik — sie ist Datenblatt-Multiplikation, und wir haben sie gerechnet:

# LPDDR5x-Transferrate aus dem Product Brief, je Busbreite
rate_mt_s = 9523          # MT/s, bei allen SKUs des Briefs identisch
for bits in (192, 128):
    gb_s = rate_mt_s * 1e6 * (bits // 8) / 1e9   # Transfers/s * Bytes/Transfer
    print(f"{bits}-Bit-Bus: {gb_s:.2f} GB/s")

192-Bit-Bus: 228.55 GB/s
128-Bit-Bus: 152.37 GB/s

Beides passt zum Datenblatt (228 / 152 GB/s gerundet). Aber ein X2E-88 und ein X2E-96 bewerben dieselbe 80-TOPS-NPU mit einem 33% niedrigeren Decode-Bandbreitenbudget. Wer ein X2-Laptop für lokale Inferenz kauft, für den ist der SKU-Split — nicht die TOPS-Spalte — die relevante Spezifikation. Die konfigurierte Kapazität des Extreme (48 GB laut Brief, 128+ GB Maximum) ist der zweite Unterscheidungsfaktor: Ein 27B-INT4-Modell plus KV-Cache plus OS passt bei 48 GB bequem hinein, während 16-GB-Klasse-SKUs an der 9B-Stufe kappen, noch bevor irgendeine Bandbreiten-Diskussion beginnt.

Die 80-TOPS-Prefill-Falle

Beim Decode mit Batch eins werden die meisten Modellgewichte pro Token aus dem Speicher gelesen, sofern das Modell nicht in On-Chip-Caches passt. Die reine BF16-Gewichtsintensität liegt ungefähr bei einer Operation pro Byte; DRAM-Bandbreite kann daher dominieren. Tatsächliche Auslastung und Geschwindigkeit hängen auch von KV-Zugriffen, Kernels, Quantisierung und Cache-Verhalten ab.

Prefill kann Gewichte über Prompt-Positionen wiederverwenden. Qualcomm spezifiziert 80 TOPS für INT8; BF16- und INT4-Rechenpeaks folgen daraus nicht. Die folgende idealisierte Rechnung nur für INT8 verwendet 80 TOPS und den nominellen Speicherbus. Attention, KV-Traffic und Runtime-Overhead fehlen:

# Idealized X2E-96 INT8-only exercise: peak 228.55 GB/s and 80 TOPS.
BW, TOPS, B = 228.55e9, 80e12, 4096
for label, p in (("3B", 3e9), ("9B", 9e9), ("27B", 27e9)):
    # Weight-only model: 2 operations per parameter and token.
    prefill_tps = min(TOPS/(2*p), B*BW/p)
    print(f"{label}: {prefill_tps:,.0f} tok/s; {B/prefill_tps:.2f} s for {B:,} tokens")

3B: 13,333 tok/s; 0.31 s for 4,096 tokens
9B: 4,444 tok/s; 0.92 s for 4,096 tokens
27B: 1,481 tok/s; 2.76 s for 4,096 tokens

Für 4.096 Token ergibt der ideale INT8-Prefill rechnerisch etwa 0,31 s für 3B, 0,92 s für 9B und 2,76 s für 27B, jeweils vor Overhead. Beim Decode mit Batch eins ist die arithmetische Intensität deutlich geringer, sodass der Speicherbus begrenzen kann. Daraus folgt weder, dass die NPU bei der Generierung untätig ist, noch dass Linux den Hersteller-Peak erreicht.

Illustrative Decode-Bandbreitenschätzungen

Ein einfaches Bandbreitenmodell teilt die nutzbare DRAM-Bandbreite durch die Modellgewichte. Wir nehmen 70 % des publizierten Bus-Peaks an; Qualcomm nennt dies nicht als gemessenen LLM-Wirkungsgrad. Die folgenden Werte sind bedingte Szenarien, keine Hardware-Obergrenzen oder Benchmarks:

EFF = 0.70  # Anteil der theoretischen Bandbreite im Single-Stream-Decode
de = lambda s: s.replace(".", ",")   # Dezimaltrenner Deutsch in der Ausgabe
for bus, bw in (("X2E-96 192 Bit", 228.55e9), ("X2E-88/80 128 Bit", 152.37e9)):
    print(de(f"--- {bus}: {bw/1e9:.1f} GB/s, Decode bei {EFF:.0%} Wirkungsgrad ---"))
    for name, p in (("3B", 3e9), ("9B", 9e9), ("27B", 27e9)):
        row = []
        for bits, fmt in ((16, "bf16"), (8, "int8"), (4, "int4")):
            tps = EFF * bw / (p * bits / 8)
            row.append(de(f"{fmt} {tps:5.1f}"))
        print(f"  {name:>3}: " + " | ".join(row) + "   tok/s")

--- X2E-96 192 Bit: 228,6 GB/s, Decode bei 70% Wirkungsgrad ---
   3B: bf16  26,7 | int8  53,3 | int4 106,7   tok/s
   9B: bf16   8,9 | int8  17,8 | int4  35,6   tok/s
  27B: bf16   3,0 | int8   5,9 | int4  11,9   tok/s
--- X2E-88/80 128 Bit: 152,4 GB/s, Decode bei 70% Wirkungsgrad ---
   3B: bf16  17,8 | int8  35,6 | int4  71,1   tok/s
   9B: bf16   5,9 | int8  11,9 | int4  23,7   tok/s
  27B: bf16   2,0 | int8   4,0 | int4   7,9   tok/s

Drei Schlüsse fallen direkt aus der Tabelle:

• Die 3B-Stufe ist, wo sich die Plattform gut anfühlt. ~27 tok/s BF16 auf dem 192-Bit-Teil; über 50 tok/s bei INT8, sofern der NPU-Pfad wirklich Ende-zu-Ende verdrahtet ist. Interaktives Chat-Territorium.
• 9B ist benutzbar, aber nicht flott. ~9 tok/s BF16, ~18 bei INT8. Okay für Tool-Work im Hintergrund, zäh als primäre Chat-Oberfläche. Das kartiert auf Qualcomms eigene GenieX-Demo-Stufen, die 3B-Klasse-Modelle auf Echtzeit-Aufgaben setzen, 9B auf Tool-Einsatz und 27B-Klasse für komplexe Agenten-Arbeit reservieren — mit dem Vorbehalt, dass die GenieX-Zahlen aus Qualcomms Windows-Runtime auf Hexagon stammen, nicht aus dem Mainline-Linux von heute.³
• 27B ist quantalisierungspflichtig. ~3 tok/s bei BF16 sind ein Diaprojektor; ~12 tok/s bei INT4 sind auf dem Extreme echt benutzbar, multipliziere das für die 128-Bit-SKUs mit zwei Dritteln. Die Bandbreiten-Decke ist der Grund, warum „braucht Quant" beim 27B kein Vorbehalt ist — sie ist die ermöglichende Bedingung, derselbe Gewichtsstrom-gegen-Mathematik-Trade, den unser Quantisierungs-Guide aus ersten Prinzipien herleitet.

Die strikte Bandbreitenobergrenze würde 100 % des publizierten Bus-Peaks einsetzen. Die 70-%-Werte oben sind angenommene Szenarien; reale NPU-Leistung unter Linux hängt zusätzlich von User-Space-Runtimes, Kernels, KV-Traffic und Thermik ab. Gemessene Snapdragon-X2-Linux-Tokenraten sind hier nicht belegt.

Was „NPU-Support via fastRPC" bedeutet — und was nicht

Der Architektur-Ehrlichkeitstest, weil es der meistübersprungene Absatz der Berichterstattung ist:

fastRPC ist Qualcomms seit Langem bestehender Remote-Procedure-Call-Transport zu Hexagon-DSPs — der Kernel öffnet einen Kanal, der Userspace marshallt einen Aufruf, der DSP führt ihn mit geteilten Speicherpuffern aus. Es upstream zu bringen bedeutet: Standard-Kernel können die NPU erreichen. Es bedeutet nicht: dass ein NPU-Tensor-Provider im Mainline existiert, wie KMD/UMD-Paare für AMD- oder Intel-GPUs, sodass llama.cpp ihn automatisch findet und nutzt. Qualcomms High-Level-Pfad ist der eigene SDK-/Runtime-Stack (GenieX & Co.), und der Blog verspricht das Enablement-Level, nicht das Ökosystem-Ergebnis — „GPU-Compute im Lauf der Zeit".¹

Der realistische Inference-Stack auf Linux ist damit kurzfristig:

1. CPU (Oryon) via llama.cpp — funktioniert zuerst, profitiert von 12 großen Arm-Kernen und demselben 228-GB/s-Bus, aber eine CPU liest bf16 gut und int4 schlecht gegenüber einem Fixfunktions-Pfad.
2. Adreno-GPU via Mesa — Turnip-Vulkan ist, wo llama.cpps Vulkan-Backend landet; Rusticl gibt OpenCL. Die Compute-Qualität ist Upstream-Qualität: besser werdend, regressionsanfällig und exakt das, was „im Lauf der Zeit" einräumt. Die X2-90 bei 1,85 GHz ist eine taugliche iGPU; sie ist keine 503-TFLOPS-Discrete-Karte (siehe unser GPU-Modell-Effizienz-Playbook, wie hohe Ops:Byte-Verhältnisse aussehen, wenn Compute real ist).
3. Hexagon-NPU via fastRPC + Qualcomm-Stack — der 80 TOPS minus Ineffizienz-Pfad, daran hängend, wie viel von Qualcomms User-Space-Stack für Linux ausgeliefert wird. Beobachte die Release Notes, nicht die Keynote.

Nichts davon ist ein Rügel. Upstream-first ist strukturell besser als der Out-of-Tree-Zustand der X1-Generation, und „die Bereitschaft variiert je nach OEM-Design und Variante" ist der ehrlichste Satz in Qualcomms Ankündigung. Aber die Strecke zwischen „der Kernel kann mit dem DSP sprechen" und „meine tok/s sind gestiegen" wird in Quartalen gemessen — das eigene Production-Readiness-Ziel Ende November deckt den Transport, nicht das Tensor-Ökosystem.

Der Enablement-Langschwanz

Jenseits von CPU/GPU/NPU: Videocodec-Blöcke, Kamera-ISPs, externes DisplayPort-Tunneling und Suspend/Resume sind historisch die Last-Mile-Positionen jeder Arm-Laptop-Enablement-Anstrengung, und nichts in der Ankündigung behauptet etwas anderes. Die Workflow-Dokumentation, die Qualcomm veröffentlicht hat (Build-Flow plus Deployment), ist das richtige Signal zum Beobachten: Wenn Codec-Offload und Kamera in den Release Notes auftauchen, überschreitet die Plattform die Schwelle vom „Developer Preview" zum „Daily Driver" auch für Nicht-Inferenz-Nutzer. Bis dahin lautet die ehrliche Zusammenfassung von Linux auf X2 im September 2026: bootet, beschleunigt die UI über Mesa, erreicht die NPU über einen Kernel-Kanal und hat eine datierte Roadmap — Production-Readiness November 2026, Debian in diesem Jahr, Ubuntu Anfang 2027.¹⁴

Das Fazit

Für lokale Inferenz ist die X2-Generation die erste der Windows-Mauer entkommene Arm-Laptop-Plattform, bei der die Physik stimmt: 228 GB/s Unified-LPDDR5x in einem lärmarmen Leistungsbudget ist Apple-M-artige Bandbreiten-Ökonomie, und die 48-GB-Konfiguration des Extreme räumt die Speichermauer ab, die 16-GB-X1-Geräte für 27B-Klasse erledigt hat. Die 80-TOPS-INT8-Angabe allein sagt wenig über die Batch-1-Decode-Leistung. Für bandbreitengebundene lokale Workloads bietet der X2E-96 laut Datenblatt ein Drittel mehr Busbandbreite als die 128-Bit-Varianten X2E-88/80; nutzbare Modellgröße und Tempo hängen zusätzlich von eingebautem RAM, Quantisierung, Linux-Runtime und gemessener nachhaltiger Leistung ab. Und kalibriere die Erwartungen auf Qualcomms eigenen Kalender — Ende November 2026 Production-Readiness, mit einem Open-Source-Stack, der auf einer längeren Uhr reift, als der Ankündigungszyklus zugibt.