2026 ist anders: On‑Device‑KI ist Standard, aber nicht alles beschleunigt gleich

Im Jahr 2026 bringen die großen Betriebssysteme KI‑Funktionen direkt aufs Gerät, und viele Apps setzen auf heterogene Beschleunigung. Unter Windows 11 stützen sich Features wie Recall und Windows Studio Effects auf die NPU, um CPU und GPU zu entlasten, mit klar definierten Mindestschwellen bei der Leistung. Unter macOS vereint Apple Silicon CPU, GPU, ein Neural Engine und einheitlichen Speicher, was gemischten Lasten zugutekommt. Unter Linux prägen die Reife von CUDA/ROCm und Vulkan weiterhin das Tempo für Kreative und Entwickler.

Die praktische Konsequenz: Es gibt keine einzige „KI‑Spezifikation“. Ein Laptop, der bei Videoschnitt mit Echtzeit‑Kameraeffekten glänzt, ist nicht automatisch die beste Wahl für die Inferenz eines großen LLM oder das Batch‑Rendering von Bildern. Dieser Leitfaden zerlegt mit überprüfbaren Kriterien, was welcher Beschleuniger leistet, wie viel Speicher 7B/13B/70B bei verschiedenen Quantisierungen wirklich benötigen und wie man das in realistische Kaufentscheidungen für die nächsten 3–6 Monate übersetzt. Außerdem erklärt er, was gängige Metriken bedeuten (TOPS, Tokens/s, Latenzen) und wie man sie auf eigene Workflows bezieht, ohne in wenig hilfreiche Architektur‑Vergleiche abzurutschen.

CPU, GPU und NPU: Zuständigkeiten und passende APIs

- CPU: Orchestriert, übernimmt Vor-/Nachverarbeitung und kann allein kleine Modelle oder Tooling (Tokenisierung, I/O) stemmen. Fehlt der Bibliothek ein beschleunigtes Backend, bleibt die CPU der universelle Notanker. Wichtig sind Gleitkommaleistung pro Thread und verfügbare Vektorbefehle; jenseits von 8–10 Threads nimmt die Effizienz bei LLMs wegen Memory‑Engpässen ab. Ebenso relevant sind Speicherlatenz und nachhaltige Bandbreite, da Prefill und KV‑Cache‑Updates selbst dann empfindlich reagieren, wenn Teile des Rechenwegs auf einem Beschleuniger laufen.

- GPU: Dominiert bei großen Tensoren und Batches; ist der Hauptweg für mittelgroße LLMs und Bildgenerierung. Unter Windows führt der „agnostische“ Weg über Windows ML mit ONNX Runtime und dessen Auswahlpolitik für Execution‑Provider; bei NVIDIA bleibt CUDA der ausgereifteste Pfad; bei AMD aktiviert ROCm HIP‑Kernels. Vulkan und WebGPU treiben die Compute‑Portabilität voran, besonders in modernen Apps und Browsern. In der Praxis erzielen GPUs besseren Durchsatz, wenn sich Anfragen bündeln lassen (Batching) oder wenn die App mehrere Tensor‑Stufen mit gut unterstützten Operatoren im gewählten Backend kettet.

- NPU: Beschleunigt latenzarme, energieeffiziente Inferenz für optimierte Modelle (Vision, Kameraeffekte, OS‑Assistenten, Teile kompakter LLMs). Unter Windows verlangen bestimmte System‑Erlebnisse eine NPU‑Schwelle von ~40 TOPS. Unter macOS koexistiert das Neural Engine mit GPU/Metal, und die Konvertierung nach Core ML entscheidet, was auf ANE versus GPU läuft. Entscheidend ist, dass der Ausführungspfad die NPU aktiv nutzt; fehlt dieser, fällt die Arbeit trotz vorhandener NPU auf GPU oder CPU zurück.

Modelle und Speicher: 7B/13B/70B in fp16, int8 und 4‑Bit – warum RAM/VRAM entscheiden

Der Speicherbedarf teilt sich in zwei Anteile: Modellgewichte und KV‑Cache. Faustregel: Gewichte ≈ Bytes_pro_Parameter×Anzahl_Parameter; fp16/bf16 ≈ 2 B/Param, int8 ≈ 1 B/Param, 4‑Bit ≈ 0,5 B/Param. Ein 7B in fp16 liegt damit bei ~14 GB nur für Gewichte; derselbe 7B in 4‑Bit sinkt auf ~3–4 GB bei leichtem Qualitätsverlust. Der KV‑Cache kann bei langen Kontexten oder hoher Gleichzeitigkeit mehrere GB addieren und lässt VRAM/RAM oft vor den Gewichten kollabieren. Er wächst mit der effektiven Kontextlänge und der Modelldepth; dimensioniere also für deinen typischen Einsatz (z. B. Tool‑Chains mit erweitertem Kontext statt kurzer Prompts).

Im Laptop‑Alltag passt ein quantisierter 7B mit 8–16 GB Prozess‑Speicher flott ins System; ein 13B möchte 16–24 GB für Komfort; ein 70B in 4‑Bit belegt bereits 40 GB nur an Gewichten und braucht Systeme mit viel einheitlichem Speicher oder Auslagerung in RAM. Hat deine GPU wenig VRAM, kann das Verschieben des KV‑Caches in den System‑RAM oder das Aufteilen zwischen GPU und CPU/NPU die Session retten, erhöht aber die Latenz. Rechne zudem den Overhead von Loader und Runtime‑Bibliotheken ein – ein paar hundert MB, die bei knappem VRAM den Ausschlag geben können.

NPU 2026: TOPS richtig einordnen – und wann die GPU vorn liegt

TOPS messen ganzzahlige Operationen pro Sekunde (typisch int8/int4) unter herstellerspezifischen Annahmen. Sie taugen, um Mindestkompatibilität zu prüfen und Klassen von Echtzeitaufgaben abzuschätzen (z. B. Kameraeffekte, Live‑Übersetzung, kleine Vision‑Netze), ersetzen aber keine aufgabenspezifischen Metriken wie Tokens/s oder P95‑Latenz deines Zielmodells. Unter Windows erzwingen Systemfunktionen wie Recall und die höhere Stufe der Studio Effects Mindestanforderungen um 40 TOPS auf der NPU, flankiert von Speicher‑ und Gerätesicherheitsvorgaben. Beim Gerätevergleich sind TOPS als Fähigkeits‑Schwelle zu lesen – nicht als lineare Leistungsskala über Marken oder Generationen hinweg.

Für mittelgroße LLMs oder Batch‑Diffusion liefert die GPU weiterhin den besten Durchsatz und die breiteste Operator‑Abdeckung. Die NPU punktet, wenn die App angepasst ist (über Windows ML/ONNX Runtime mit „prefer NPU“‑Policy oder über Core ML, sofern Layer kompatibel sind) und wenn Effizienz zählt: Häufig sieht man deutliche Energieeinsparungen gegenüber der GPU bei kontinuierlich niedriger Leistungsaufnahme, allerdings mit Grenzen bei Operatoren und Modellgröße. In Mischszenarien ist es effektiv, das schwere Prefill der GPU zu überlassen und Vision oder Post‑Processing an die NPU auszulagern – so bleibt der Verbrauch im Rahmen, ohne die wahrgenommene Latenz unnötig zu verschlechtern.

Windows, macOS und Linux: Toolchains und Kompatibilität realistisch betrachtet

- Windows (ARM und x86): Windows ML bildet eine einheitliche Schicht über ONNX Runtime und erlaubt die explizite Wahl eines Execution‑Providers (CPU, NPU, GPU via DirectML, CUDA etc.) oder eine Richtlinie für „maximale Leistung“ bzw. „maximale Effizienz“. DirectML nutzt jede GPU mit DirectX 12‑Support – nützlich für heterogene Hardware und Deployments ohne Vendor‑Bindung. Für Apps mit ONNX Runtime ist eine Policy wie MAX_EFFICIENCY oder PREFER_NPU ein pragmatischer Weg, Leistung und Laufzeit zu balancieren, ohne Operatoren umzuschreiben.

- macOS (Apple Silicon): Empfohlen ist die Konvertierung nach Core ML (mit coremltools), dann führen Metal/ANE je nach Kompatibilität aus. Einheitlicher Speicher vereinfacht gemischte Lasten (Modell auf GPU, Vorverarbeitung auf CPU/ANE), und die M5‑Generation bietet Konfigurationen bis 128 GB Unified mit höherer Bandbreite – hilfreich für lange LLM‑Kontexte und Batch‑Workloads in der Content‑Erstellung. In Projekten mit Vision, Audio und Text reduziert diese Vereinheitlichung Kopien zwischen Geräten und stabilisiert Latenzen unter Last.

- Linux: CUDA ist bei NVIDIA weiterhin der geschmeidigste Weg; ROCm aktiviert aktuelle AMD‑Hardware, erfordert aber einen Blick in die Kompatibilitätsmatrix vor dem Kauf. Für portable Lösungen und Setups ohne CUDA/ROCm bietet Vulkan General‑Purpose‑Compute, und einige Runtimes erproben SPIR‑V‑Pfade. Im Open‑Source‑Umfeld stellen Projekte wie llama.cpp mehrere Backends (CPU/Metal/CUDA/ROCm/Vulkan) mit unterschiedlicher Reife bereit. Prüfe vor der Plattformwahl, dass dein Backend die kritischen Operatoren deines Modells unterstützt und dass Treiber, Kernel und Libraries in kompatiblen Versionen vorliegen.

Speicher, I/O und Anschlüsse: warum 1–2 TB NVMe kein Luxus sind

Modell‑Dateien belegen spürbaren Platz – auch quantisiert: 7B etwa 3–4 GB; 13B ~7–8 GB; 70B ~35–40 GB bei 4‑Bit. Wenn du zwischen Familien (Llama, Mistral, Embeddings, TTS, VAD) wechselst und mehrere Quantisierungen/Versionen vorhältst, ersparen 1–2 TB NVMe ständiges Aufräumen. Große sequentielle Reads beschleunigen den Session‑Start und das Reload nach Standby; freier Spielraum hilft Paging und Framework‑Caches. Ein einzelnes, schnelles NVMe‑Volume vereinfacht Checkpoint‑Handling und verringert die Versuchung, Modelle auf langsamere Medien zu verlagern – was später die Time‑to‑First‑Token bremst.

Bei der Konnektivität heben Thunderbolt 5 und USB4 v2.0 die Bandbreiten‑Decken für externe SSDs oder eGPUs (wo unterstützt) sowie für 8K/Hochfrequenz‑Displays an. Für KI‑Lasten ist der praktische Nutzen schneller externer Speicher bei geteiltem Bus, ohne die interne GPU auszuhungern. Setzt du auf externe Gehäuse oder Docks, prüfe Zertifizierung und Version, um Flaschenhälse zu vermeiden. Und wenn du Modelle zwischen Maschinen bewegst, lohnt ein externer NVMe‑SSD in einem TB5/USB4 v2.0‑Gehäuse: Kopier‑ und Ladezeiten verbessern sich gegenüber älterem USB deutlich bei Projekten mit vielen GB.

Nützliche Leistung messen und in Kaufprofile übersetzen

Relevante Metriken: 1) Tokens/s auf deinem Zielmodell und der anvisierten Quantisierung bei typischem Kontext; 2) Latenz des ersten Tokens (Prefill) und der Dekodierung; 3) Durchsatz pro Batch bei Bild-/Audio‑Generierung. Meide rohe TOPS oder theoretische FLOPS ohne Bezug zu deiner Pipeline (Tokenizer, KV‑Cache, Streaming). Nutze nach Möglichkeit reproduzierbare Open‑Benchmarks genau jenes Runtimes, das du verwenden willst. Ergänze Energietests, wenn Laufzeit wichtig ist: Der Abstand zwischen NPU und GPU bei dauerhaften Low‑Power‑Workloads kann entscheidend sein, selbst wenn die Gesamtzeit ähnlich bleibt.

Indikative Mindestprofile für Käufe in Q4 2026–Q1 2027: 1) Lokaler Chat 7B (4‑Bit), leichtes Multitasking: moderne 8‑Kern‑CPU, integrierte GPU oder kleine dGPU, 16 GB RAM und NPU, falls du OS‑Features nutzt; 2) Beschleunigter Code‑Assistent und Transkription: dGPU mit ≥ 8–12 GB VRAM oder Apple Silicon mit ≥ 24–32 GB Unified; 3) Batch‑Bildgenerierung und komfortabler 13B‑LLM: dGPU ≥ 16 GB VRAM oder ≥ 48–64 GB einheitlicher Speicher; 4) Lokales Labor mit 70B 4‑Bit: Systeme mit ≥ 64–96 GB effektiv (einheitlich oder RAM mit Auslagerung), mit akzeptierten Latenz‑Kompromissen. Grundregel: ausreichend Speicher vor kleinen TOPS/FLOPS‑Unterschieden priorisieren und sicherstellen, dass die geplanten APIs (Windows ML/DirectML, Core ML, CUDA/ROCm, Vulkan/WebGPU) mit deinem Software‑Stack funktionieren.