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 sechs Laptop-SKUs. 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

Decode — je ein Token, Batch 1 — liest praktisch jedes Gewicht pro Token und rechnet zwei arithmetische Operationen pro Parameter. Das ergibt eine arithmetische Intensität von ~1 Op pro Byte bei BF16: trivial bandbreitengebunden, auf jeder Hardware, für immer. Die Roofline sagt, dass die NPU fast die gesamte Zeit untätig herumliegt.

Prefill ist anders: Bei der Verarbeitung eines 4.096-Token-Prompts kann jedes Gewicht über alle 4.096 Token-Positionen wiederverwendet werden, die Intensität wächst mit der Prompt-Länge, und die 80 TOPS können real eingreifen. Hier ist die zweiseitige Begrenzung:

# Welche Phase frisst welchen Flaschenhals? X2E-96-Zahlen (228 GB/s, 80 TOPS INT8).
BW = 228.55e9      # Bytes/s
TOPS = 80e12       # INT8 Ops/s
params = {"3B": 3e9, "9B": 9e9, "27B": 27e9}
ratio = TOPS / BW  # Ops/Byte, nötig um das Rechenwerk zu sättigen
print(f"Ops:Byte-Verhältnis, um 80 TOPS bei 228 GB/s zu nutzen: {ratio:.0f}")
for name, p in params.items():
    for bits, fmt in ((16, "bf16"), (8, "int8"), (4, "int4")):
        bpb = bits / 8
        # Decode: eine Token-Position -> Gewichte einmal streamen (Intensität ~2/bpb)
        i_decode = 2 / bpb
        # Prefill mit Batch B: Gewichte einmal pro B Tokens -> Intensität ~B*2/bpb
        i_prefill = 4096 * 2 / bpb
        bound_d = "rechen" if i_decode >= ratio else "bandbreite"
        bound_p = "rechen" if i_prefill >= ratio else "bandbreite"
        tps_prefill = min(TOPS / (2 * p), 4096 * BW / (p * bpb))
        de_num = f"{tps_prefill:,.0f}".replace(",", ".")   # 13.333 (DE-Tausenderpunkt)
        print(f"{name:>3} {fmt:>5}: Decode ist {bound_d}gebunden bei {i_decode:.0f} "
              f"Ops/Byte; 4096-Tok-Prefill ist {bound_p}gebunden, Ceiling "
              f"{de_num} tok/s")

Ops:Byte-Verhältnis, um 80 TOPS bei 228 GB/s zu nutzen: 350
 3B  bf16: Decode ist bandbreitegebunden bei 1 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 13.333 tok/s
 3B  int8: Decode ist bandbreitegebunden bei 2 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 13.333 tok/s
 3B  int4: Decode ist bandbreitegebunden bei 4 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 13.333 tok/s
 9B  bf16: Decode ist bandbreitegebunden bei 1 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 4.444 tok/s
 9B  int8: Decode ist bandbreitegebunden bei 2 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 4.444 tok/s
 9B  int4: Decode ist bandbreitegebunden bei 4 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 4.444 tok/s
27B  bf16: Decode ist bandbreitegebunden bei 1 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 1.481 tok/s
27B  int8: Decode ist bandbreitegebunden bei 2 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 1.481 tok/s
27B  int4: Decode ist bandbreitegebunden bei 4 Ops/Byte; 4096-Tok-Prefill ist rechengebunden, Ceiling 1.481 tok/s

Lies das als Arbeitsteilung: Big-Batch-Prefill ist die Phase, in der die 80 TOPS ihr Geld wert sind — ein 4k-Token-Prompt wird selbst für ein 27B-Modell in unter einer Sekunde geschluckt. Das Token, das der Nutzer ansieht, ist Decode — und kommt nie in die Nähe von 350 Ops/Byte bei Batch 1; es ist ein Speicher-Streaming-Job. „80-TOPS-NPU für Laptops" ist eine Prefill-Statistik. Chat-Latenz ist eine DRAM-Statistik. Eine Agentische Workload — lange Prompts, kurze Ketten, Tool-Call-Schleifen, die den eigenen Kontext neu lesen — ist exakt das Profil, das das NPU-Fenster nur während der Prompt-Aufnahme öffnet und es durch jeden Generierungsschritt leerlaufen lässt.

Die ehrlichen Decode-Ceilings

Die kaufrelevanten Zahlen sind also geteilte Bandbreite durch Modell-Bytes. Mit einem Wirkungsgrad von 70% für dauerhaftes DRAM-Streaming (Single-User-Decode pinnt selten einen theoretischen Bus aus), auf beiden Busbreiten:

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, halbiere das für die 128-Bit-SKUs. 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.

Und das sind Ceilings — die Roofline setzt voraus, dass der fastRPC-Pfad den vollen Bus an den DSP liefert, mit den eingerechneten 70% Streaming-Wirkungsgrad. Wenn der Early-Dev-Preview-Stack am ersten Tag nur 80% dessen liefert, entsprechend herunterteilen.

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-NPU ist real, aber bei Batch 1 irrelevant; sie ist eine Prefill- und Hintergrund-Einheit. Kauf die SKU für den Bus, nicht fürs Prospekt: X2E-96 oder gar nicht für Agenten-Klasse-Workloads; die 128-Bit-X2E-88/80 sind 3B/9B-Maschinen bei INT8. 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.