OpenVINO NPU: 2,8x Perf/Watt in 12 Schritten [2026]

Wer im September 2026 einen Laptop mit Intel Core Ultra Series 3 auf dem Tisch hat, sitzt auf ungenutzter Rechenleistung. Der neue NPU-Block liefert laut Intel bis zu 50 TOPS, zusammen mit CPU-Vektoreinheiten und der integrierten Arc-GPU kommt die Plattform auf bis zu 180 TOPS. Das Problem: Ohne den richtigen Software-Stack bleibt davon fast nichts nutzbar. In diesem Tutorial richten wir OpenVINO 2026.0 und Googles LiteRT so ein, dass echte Modelle auf der NPU laufen, statt auf CPU oder GPU zu verhungern. Am Ende steht ein lauffähiges Projekt, das Inferenz auf der NPU misst und mit CPU sowie GPU vergleicht.

Der Artikel richtet sich an Entwicklerinnen und Entwickler, die bereits Python-Grundlagen mitbringen und lokale KI-Workloads effizienter machen wollen, ohne gleich eine dedizierte GPU zu kaufen. Alle Schritte funktionieren sowohl unter Windows 11 als auch unter Ubuntu 24.04 LTS oder neuer.

Bis vor Kurzem war eine NPU im Alltag kaum mehr als eine Marketingzeile auf der Verpackung. Windows-Copilot-Funktionen nutzten sie sporadisch, aber eigene Projekte liefen fast immer auf CPU oder GPU, weil die Werkzeugkette dafür fehlte oder zu instabil war. Mit OpenVINO 2026.0 und dem NPU-Delegate für LiteRT hat sich das spürbar geändert: Beide Frameworks sind inzwischen so weit ausgereift, dass sich reale Produktionsmodelle zuverlässig auf die NPU verlagern lassen, nicht nur Demo-Beispiele aus der Dokumentation.

Dieses Tutorial ist in überschaubare Etappen gegliedert: Zuerst wird die Hardware verifiziert, dann folgt die Softwareinstallation, anschließend die Modellkonvertierung und zum Schluss ein vollständiges Benchmark-Projekt samt Troubleshooting-Katalog. Wer nur einzelne Abschnitte braucht, kann direkt zum passenden Schritt springen, alle Code-Beispiele sind eigenständig lauffähig.

Was ist die Core Ultra Series 3 NPU und warum lohnt sich OpenVINO 2026?

Die Core Ultra Series 3 ist Intels erste Client-Plattform auf dem 18A-Fertigungsprozess und wurde auf der CES 2026 als AI-PC-Plattform vorgestellt. Neu ist vor allem, wie eng CPU, integrierte Arc-GPU und der fünfte NPU-Block (intern NPU 5 genannt) zusammenarbeiten: Workloads werden dynamisch auf die drei Recheneinheiten verteilt, statt starr einer einzigen Engine zugewiesen zu sein. In der Praxis heißt das, dass ein Klassifikationsmodell auf der NPU laufen kann, während die GPU parallel ein Bild rendert und die CPU den Rest der Anwendung bedient.

Genau hier setzt OpenVINO an. Das Toolkit übernimmt die Übersetzung eines trainierten Modells in eine Form, die der NPU-Treiber versteht, und kümmert sich um Speicherlayout, Quantisierung und Ausführungsplanung. Mit der Version 2026.0 hat Intel die NPU-Unterstützung deutlich ausgebaut: Ein neuer Compiler erlaubt sowohl Ahead-of-Time-Kompilierung (AOT) für minimale Startlatenz als auch dynamische On-Device-Kompilierung, wenn Flexibilität wichtiger ist als der letzte Millisekundenvorteil. Google hat parallel dazu LiteRT, den Nachfolger von TensorFlow Lite, um einen vollwertigen NPU-Support für Core-Ultra-Prozessoren erweitert und nutzt OpenVINO dafür als Backend. Damit lassen sich laut Intels Entwicklerdokumentation mehr als 90 gängige klassische ML-Modelle ohne größeren Umbau auf die NPU verlagern.

Warum lohnt sich der Aufwand? Bei einem Test mit dem kompakten Sprachmodell Gemma 4 E2B lief die Inferenz über den OpenVINO-NPU-Pfad rund 1,3-mal schneller als über LiteRTs WebGPU-Pfad auf derselben Series-3-Hardware. Noch deutlicher fällt der Effizienzgewinn aus: Bei gleicher Aufgabe erreichte die NPU eine rund 2,8-mal bessere Performance pro Watt als die integrierte GPU. Für Laptops bedeutet das spürbar längere Akkulaufzeit bei Hintergrund-KI-Aufgaben wie Transkription, Bildklassifikation oder lokalen Assistenzfunktionen.

Technisch betrachtet besteht der OpenVINO-Compiler-Stack für die NPU aus mehreren Schichten: Ein Graph-Optimierer fasst redundante Operationen zusammen, ein Quantisierer reduziert Datentypen auf INT8 oder FP16, und ein Scheduler verteilt die entstandenen Teilgraphen auf die verfügbaren Recheneinheiten des NPU-5-Blocks. Diese Schichtenarchitektur ist der Hauptgrund, warum sich derselbe Python-Code ohne Änderungen auch auf älteren NPU-Generationen ausführen lässt, nur eben mit geringerem Durchsatz, weil der Compiler die Hardware-Fähigkeiten automatisch erkennt und sich daran anpasst.

Intel steht mit diesem Ansatz nicht allein da. AMD verfolgt mit Ryzen AI eine ähnliche Strategie, Qualcomm setzt bei Snapdragon-X-Chips auf die Hexagon-NPU, und Apple integriert die Neural Engine schon seit Jahren fest in seine Silicon-Chips. Der Unterschied liegt in der Softwaretiefe: Intel hat mit OpenVINO ein Framework, das nicht nur die eigene Hardware bedient, sondern seit Jahren auch CPU und GPU verschiedener Hersteller unterstützt. Wer heute auf OpenVINO setzt, bindet sich also weniger stark an einen einzelnen Chip-Hersteller, als es bei proprietären NPU-SDKs sonst üblich ist.

Voraussetzungen: Hardware und Software im Überblick

Bevor es losgeht, sollten folgende Voraussetzungen erfüllt sein. Die Tabelle zeigt die getesteten Versionen, mit denen dieses Tutorial funktioniert. Wichtig ist vor allem das Zusammenspiel zwischen NPU-Treiber und OpenVINO-Version: Ein zu alter Treiber blockiert neue Compiler-Features aus OpenVINO 2026.0, während eine zu alte OpenVINO-Version den NPU-5-Block der Series 3 gar nicht vollständig erkennt und stattdessen nur eine reduzierte Feature-Untermenge anspricht.

Komponente	Mindestanforderung	Empfohlen
Prozessor	Intel Core Ultra Series 3 (X7 oder X9)	Core Ultra X9 mit NPU 5
Arbeitsspeicher	16 GB RAM	32 GB RAM
Betriebssystem	Windows 11 23H2 / Ubuntu 24.04 LTS	Windows 11 24H2 / Ubuntu 26.04 LTS
Python	Python 3.10	Python 3.12
OpenVINO Toolkit	2025.3	2026.0
LiteRT	ai-edge-litert 1.x mit NPU-Delegate	aktuellste Version aus PyPI
NPU-Treiber	Intel AI Boost Treiber (aktuelle Version)	über Windows Update oder Intel-Repository
Speicherplatz	10 GB frei	20 GB frei (für Modell-Cache)

Wichtig: Ältere Core-Ultra-Generationen (Series 1 und 2, bekannt als Meteor Lake und Lunar Lake) funktionieren mit OpenVINO grundsätzlich auch, erreichen aber die hier genannten TOPS-Werte und Effizienzgewinne nicht, da ihr NPU-Block schwächer dimensioniert ist. Wer bereits einen älteren Core-Ultra-Laptop eingerichtet hat, kann das separate Core-Ultra-NPU-Setup-Tutorial als Referenz nutzen und die hier gezeigten OpenVINO-2026-Schritte trotzdem übernehmen. Wer stattdessen eine AMD-Plattform nutzt, findet im Tutorial zu ROCm auf AMD Radeon den passenden Gegenpart, und für Apple-Silicon-Systeme lohnt sich der Vergleich mit dem Ollama-Setup auf Apple Silicon.

Schritt 1 und 2: System vorbereiten und NPU-Treiber prüfen

Als Erstes wird geprüft, ob das Betriebssystem die NPU überhaupt erkennt. Unter Windows genügt ein Blick in den Geräte-Manager unter “Neural processors”. Unter Linux lässt sich das über die Kommandozeile verifizieren.

# Linux: NPU-Gerät und Treiberstatus prüfen
ls /dev/accel/
lsmod | grep intel_vpu

# Erwartete Ausgabe (Beispiel):
# /dev/accel/accel0
# intel_vpu             172032  0

# Windows (PowerShell): NPU im Gerätemanager auflisten
Get-PnpDevice -Class "System" | Where-Object { $_.FriendlyName -like "*NPU*" -or $_.FriendlyName -like "*AI Boost*" }

Taucht kein Gerät auf, fehlt meist der aktuelle Intel-AI-Boost-Treiber. Unter Windows lässt er sich über Windows Update oder direkt von Intels Download-Center nachziehen, unter Ubuntu über das offizielle Intel-NPU-Treiber-Repository. Nach der Installation ist ein Neustart nötig, damit der Kernel-Treiber intel_vpu korrekt geladen wird.

Schritt 3 und 4: Python-Umgebung und OpenVINO 2026.0 installieren

Für ein sauberes Setup empfiehlt sich eine isolierte virtuelle Umgebung, damit spätere Projekte nicht mit anderen Paketversionen kollidieren.

# Virtuelle Umgebung anlegen
python3 -m venv openvino-npu-env
source openvino-npu-env/bin/activate      # Linux/macOS
# openvino-npu-env\Scripts\activate       # Windows PowerShell

# OpenVINO 2026.0 mit NPU-Unterstützung installieren
pip install --upgrade pip
pip install openvino==2026.0.0
pip install openvino-dev==2026.0.0

# Installation verifizieren
python -c "import openvino as ov; print(ov.__version__)"

Die erwartete Ausgabe ist schlicht die installierte Versionsnummer, in diesem Fall 2026.0.0. Schlägt der Import fehl, liegt es fast immer an einer inkompatiblen Python-Version oder an einer alten pip-Version, die das Wheel nicht korrekt auflöst.

Schritt 5 und 6: NPU-Verfügbarkeit mit OpenVINO prüfen

Bevor ein Modell konvertiert wird, sollte OpenVINO selbst bestätigen, dass es die NPU als Ausführungsziel sieht. Das folgende Skript listet alle verfügbaren Devices auf.

from openvino import Core

core = Core()
print("Verfügbare Geräte:", core.available_devices)

for device in core.available_devices:
    full_name = core.get_property(device, "FULL_DEVICE_NAME")
    print(f"{device}: {full_name}")

Typische Ausgabe auf einem Core-Ultra-Series-3-System:

Verfügbare Geräte: ['CPU', 'GPU', 'NPU']
CPU: Intel(R) Core(TM) Ultra 9 X9
GPU: Intel(R) Arc(TM) Graphics
NPU: Intel(R) AI Boost

Erscheint “NPU” nicht in der Liste, ist entweder der Treiber nicht korrekt geladen (zurück zu Schritt 2) oder OpenVINO wurde ohne NPU-Plug-in installiert. Ein pip install --force-reinstall openvino==2026.0.0 löst das in den meisten Fällen.

Schritt 7 und 8: LiteRT mit dem OpenVINO-Backend verbinden

LiteRT übernimmt in vielen bestehenden Projekten bereits die Modellausführung, etwa in mobilen und Edge-Anwendungen. Der neue OpenVINO-Delegate erlaubt es, denselben Code auf der NPU laufen zu lassen, ohne die Modell-Pipeline umzuschreiben.

# LiteRT mit OpenVINO-Unterstützung installieren
pip install ai-edge-litert

# Delegate laden und an OpenVINO binden
python3 - <<'EOF'
from ai_edge_litert.interpreter import Interpreter
from ai_edge_litert.interpreter import load_delegate

openvino_delegate = load_delegate("openvino_delegate.so", options={"device": "NPU"})

interpreter = Interpreter(
    model_path="model.tflite",
    experimental_delegates=[openvino_delegate]
)
interpreter.allocate_tensors()
print("Delegate aktiv:", interpreter.get_signature_list())
EOF

Falls das Delegate-Modul unter Windows nicht gefunden wird, liegt das meist an einem fehlenden Eintrag im PATH. Der OpenVINO-Delegate wird als Shared Library mit dem openvino-dev-Paket mitinstalliert, muss aber je nach Betriebssystem manuell referenziert werden.

Schritt 9 und 10: Modell für die NPU konvertieren (AOT versus On-Device)

OpenVINO 2026.0 bietet zwei Kompilierungswege für die NPU. Ahead-of-Time-Kompilierung (AOT) erzeugt eine fertige Binärdatei vorab, was die Startlatenz minimiert, aber bei jedem Treiber-Update eine Neukompilierung erfordert. On-Device-Kompilierung übersetzt das Modell erst beim ersten Start, ist dafür flexibler gegenüber Treiberwechseln.

# Modell von ONNX in das OpenVINO-IR-Format konvertieren
ovc model.onnx --output_model model_ir --compress_to_fp16 True

# AOT-Kompilierung für die NPU (minimale Startlatenz)
python3 - <<'EOF'
from openvino import Core, serialize

core = Core()
model = core.read_model("model_ir.xml")

compiled_model = core.compile_model(
    model,
    device_name="NPU",
    config={"NPU_COMPILATION_MODE_PARAMS": "aot-compile"}
)
print("AOT-Kompilierung abgeschlossen, Modell bereit für NPU")
EOF

Für die meisten Produktionsszenarien mit stabiler Treiberversion ist AOT die bessere Wahl, weil sie die Zeit bis zur ersten Inferenz (Cold Start) um teils mehrere hundert Millisekunden reduziert. Wer häufig zwischen Geräten wechselt oder Treiber-Updates automatisch einspielt, sollte bei On-Device-Kompilierung bleiben, um Kompatibilitätsprobleme zu vermeiden.

Ein weiterer Unterschied betrifft die Eingabeform: AOT-Modelle werden für eine feste Shape kompiliert, etwa exakt ein Bild mit 224 mal 224 Pixeln. Ändert sich die Eingabegröße zur Laufzeit, etwa weil eine Kamera in einer anderen Auflösung liefert, muss entweder vorher skaliert oder auf dynamische Shapes umgestellt werden, was OpenVINO 2026.0 grundsätzlich unterstützt, aber mit einem kleinen Latenz-Overhead erkauft. In der Praxis lohnt es sich, Eingaben schon vor der NPU-Inferenz auf eine feste Zielgröße zu normalisieren, statt die NPU selbst mit variablen Formen zu belasten.

Schritt 11 und 12: Inferenz ausführen und mit benchmark_app messen

OpenVINO bringt mit benchmark_app ein eingebautes Werkzeug mit, das Latenz und Durchsatz direkt auf dem Zielgerät misst, ganz ohne eigenes Messskript.

# Benchmark auf der NPU laufen lassen
benchmark_app -m model_ir.xml -d NPU -t 15

# Zum Vergleich auf CPU und GPU
benchmark_app -m model_ir.xml -d CPU -t 15
benchmark_app -m model_ir.xml -d GPU -t 15

Beispielhafte Ausgabe für den NPU-Lauf:

[Step 11/11] Dumping statistics report
Count:            4820 iterations
Duration:         15004.32 ms
Latency:
    Median:       3.02 ms
    Average:      3.11 ms
    Min:          2.87 ms
    Max:          6.44 ms
Throughput:       321.14 FPS

Die genauen Werte hängen stark vom Modell, der Eingabegröße und der Batch-Größe ab, deshalb sind sie hier als Format-Beispiel und nicht als absolute Zahl zu verstehen. Entscheidend ist der relative Vergleich zwischen den drei Geräten auf identischer Hardware.

Warum lokale NPU-Inferenz auch ein Sicherheits- und Datenschutzthema ist

Für ein Security- und Privacy-Publikum lohnt sich ein Blick über die reinen Performancezahlen hinaus. Jede Inferenz, die auf der NPU im eigenen Gerät läuft, muss nicht an eine Cloud-API gesendet werden. Das reduziert die Angriffsfläche gleich mehrfach: Es gibt keine Netzwerkübertragung, die abgefangen werden könnte, keine serverseitige Logdatei mit potenziell sensiblen Eingaben, und keine Abhängigkeit von der Verfügbarkeit eines externen Dienstes. Für Unternehmen, die unter DSGVO oder branchenspezifischen Auflagen wie NIS2 arbeiten, vereinfacht lokale Inferenz zudem die Nachweispflicht, wo personenbezogene Daten verarbeitet werden, weil sie das Gerät nie verlassen.

Das ersetzt keine grundsätzliche Absicherung der Anwendung. Ein kompromittiertes Endgerät kann weiterhin auf Modell und Zwischenergebnisse zugreifen, und wer sensible Modelle vor Diebstahl schützen will, sollte sie zusätzlich verschlüsselt ablegen und erst zur Laufzeit entschlüsseln. OpenVINOs Modell-Cache lässt sich dafür in ein Verzeichnis mit eingeschränkten Dateiberechtigungen legen, unter Linux etwa mit chmod 700 auf das Cache-Verzeichnis. Wer zusätzlich Festplattenverschlüsselung einsetzt, findet dazu Hintergründe im separaten VeraCrypt-Tutorial dieser Seite. Insgesamt gilt: Lokale NPU-Inferenz verschiebt das Vertrauensmodell weg von der Cloud, ersetzt aber nicht die grundlegende Endpoint-Sicherheit.

Für regulierte Branchen wie Gesundheitswesen oder Finanzdienstleistungen kommt ein weiterer Vorteil hinzu: Lokale Inferenz vereinfacht Audits erheblich, weil sich der komplette Datenfluss innerhalb eines einzelnen, physisch kontrollierbaren Geräts nachvollziehen lässt, statt über mehrere Netzwerksegmente und Drittanbieter-Infrastruktur hinweg. Das ersetzt zwar keine formale Zertifizierung, reduziert aber den Dokumentationsaufwand gegenüber einer verteilten Cloud-Architektur spürbar.

NPU-Inferenz in eine FastAPI-Anwendung einbinden

In den meisten Projekten läuft die Inferenz nicht isoliert in einem Skript, sondern hinter einer kleinen internen API, die andere Teile der Anwendung ansprechen. Das folgende Beispiel zeigt, wie sich ein NPU-kompiliertes Modell in einen einfachen FastAPI-Endpunkt einbetten lässt, inklusive automatischem Fallback auf CPU, falls die NPU zur Laufzeit nicht erreichbar ist.

from fastapi import FastAPI, HTTPException
import numpy as np
from openvino import Core

app = FastAPI()
core = Core()
model = core.read_model("model_ir.xml")

try:
    compiled_model = core.compile_model(model, device_name="NPU")
    active_device = "NPU"
except RuntimeError:
    compiled_model = core.compile_model(model, device_name="CPU")
    active_device = "CPU"

infer_request = compiled_model.create_infer_request()

@app.get("/health")
def health():
    return {"status": "ok", "device": active_device}

@app.post("/predict")
def predict(payload: dict):
    try:
        input_array = np.array(payload["input"], dtype=np.float32)
        result = infer_request.infer({0: input_array})
        output = list(result.values())[0]
        return {"prediction": output.tolist(), "device": active_device}
    except Exception as exc:
        raise HTTPException(status_code=400, detail=str(exc))

Gestartet wird der Dienst mit uvicorn app:app --host 0.0.0.0 --port 8000. Der /health-Endpunkt ist beim Monitoring hilfreich, weil er sofort zeigt, ob die Anwendung tatsächlich auf der NPU läuft oder unbemerkt auf CPU zurückgefallen ist, etwa nach einem Treiber-Update, das die NPU-Kompilierung fehlschlagen lässt. Für produktive Deployments empfiehlt sich zusätzlich ein Rate-Limiting vor dem Endpunkt, insbesondere wenn die API von mehreren internen Diensten gleichzeitig angesprochen wird. Eine Anleitung dazu bietet das Rate-Limiting-Tutorial dieser Seite, dessen Prinzipien sich unabhängig von der Programmiersprache auf FastAPI übertragen lassen.

Vollständiges Beispielprojekt: Bildklassifikation auf der NPU

Das folgende Skript fasst alle Schritte zu einem lauffähigen Projekt zusammen: Modell laden, auf die NPU kompilieren, Inferenz ausführen und die Ausführungszeit gegen CPU und GPU vergleichen. Die Datei kann direkt als npu_benchmark.py gespeichert und ausgeführt werden. Als Testmodell eignet sich jedes öffentlich verfügbare Klassifikationsmodell im ONNX-Format, etwa aus dem Model-Repository von Hugging Face, das vorher mit dem ovc-Befehl aus Schritt 9 ins IR-Format konvertiert wurde. Wichtig ist nur, dass die Eingabeform des Dummy-Inputs im Skript zur tatsächlichen Eingabeform des Modells passt, sonst schlägt infer_request.infer() mit einer Shape-Mismatch-Fehlermeldung fehl.

import time
import numpy as np
from openvino import Core

MODEL_PATH = "model_ir.xml"
INPUT_SHAPE = (1, 3, 224, 224)
ITERATIONS = 200

def run_inference(device_name: str) -> float:
    core = Core()
    model = core.read_model(MODEL_PATH)
    compiled = core.compile_model(model, device_name=device_name)

    dummy_input = np.random.rand(*INPUT_SHAPE).astype(np.float32)
    infer_request = compiled.create_infer_request()

    # Aufwärmphase, damit Caches und Kompilierung nicht in die Messung einfließen
    for _ in range(10):
        infer_request.infer({0: dummy_input})

    start = time.perf_counter()
    for _ in range(ITERATIONS):
        infer_request.infer({0: dummy_input})
    elapsed = time.perf_counter() - start

    avg_latency_ms = (elapsed / ITERATIONS) * 1000
    return avg_latency_ms

if __name__ == "__main__":
    core = Core()
    results = {}
    for device in ("CPU", "GPU", "NPU"):
        if device not in core.available_devices:
            print(f"{device} nicht verfügbar, übersprungen")
            continue
        latency = run_inference(device)
        results[device] = latency
        print(f"{device}: {latency:.2f} ms pro Inferenz")

    if "NPU" in results and "GPU" in results:
        speedup = results["GPU"] / results["NPU"]
        print(f"NPU ist {speedup:.2f}x schneller als GPU bei dieser Konfiguration")

Der Aufruf erfolgt schlicht über python npu_benchmark.py. Wer das Skript in eine bestehende LiteRT-Pipeline integrieren will, ersetzt den Core()-Aufruf durch den in Schritt 7 gezeigten Delegate-Mechanismus, das restliche Timing-Muster bleibt identisch.

Quantisierung mit NNCF: INT8-Modelle für die NPU vorbereiten

Die NPU spielt ihre Stärken vor allem bei quantisierten Modellen aus. Ein FP32-Modell lässt sich zwar technisch ausführen, verschenkt dabei aber einen Großteil der Effizienzvorteile, weil der NPU-Speicherbus für kleinere Datentypen ausgelegt ist. OpenVINOs Neural Network Compression Framework (NNCF) übernimmt die Post-Training-Quantisierung auf INT8, ohne dass das Modell neu trainiert werden muss.

import nncf
import openvino as ov
import numpy as np

model = ov.Core().read_model("model_ir.xml")

def calibration_data():
    for _ in range(300):
        yield {"input": np.random.rand(1, 3, 224, 224).astype(np.float32)}

calibration_dataset = nncf.Dataset(calibration_data())
quantized_model = nncf.quantize(model, calibration_dataset)

ov.save_model(quantized_model, "model_int8.xml")
print("INT8-Modell gespeichert: model_int8.xml")

Der Kalibrierungsdatensatz sollte im Idealfall aus echten, repräsentativen Eingaben bestehen, nicht aus Zufallsdaten wie im vereinfachten Beispiel oben. Nur so lässt sich später prüfen, ob die Quantisierung die Modellgenauigkeit spürbar verschlechtert. Ein grober Richtwert aus der Praxis: Bei klassischen Bildklassifikationsmodellen bleibt der Genauigkeitsverlust durch INT8-Quantisierung meist im Bereich von unter einem Prozentpunkt, sofern der Kalibrierungsdatensatz die tatsächliche Eingabeverteilung gut abbildet. Bei stark unausgeglichenen oder sehr kleinen Kalibrierungsdatensätzen kann der Verlust deutlich größer ausfallen, weshalb sich ein separater Validierungslauf nach der Quantisierung immer lohnt.

Performance-Vergleich: NPU gegen GPU und CPU auf der Series 3

Die folgende Tabelle fasst die von Intel veröffentlichten Vergleichswerte für das Sprachmodell Gemma 4 E2B auf Core Ultra Series 3 zusammen, ergänzt um allgemeine Plattformdaten.

Metrik	NPU (OpenVINO)	GPU (LiteRT WebGPU)	Differenz
Inferenzgeschwindigkeit (Gemma 4 E2B)	Referenzwert	ca. 0,77x der NPU-Geschwindigkeit	NPU ca. 1,3x schneller
Performance pro Watt	Referenzwert	ca. 0,36x des NPU-Werts	NPU ca. 2,8x effizienter
Max. TOPS des Blocks	bis zu 50 TOPS	Teil der Plattform-GPU-Engines	Plattform gesamt bis zu 180 TOPS
Typischer Einsatzzweck	Hintergrund-KI, Dauerlast	Grafiklastige Inferenz, Rendering parallel	abhängig vom Workload

Für Dauerlast-Szenarien wie Live-Transkription, Hintergrund-Bildanalyse oder On-Device-Assistenten ist die NPU fast immer die richtige Wahl, weil der Akku dabei am wenigsten leidet. Für kurze, GPU-lastige Batch-Aufgaben mit großem Speicherbedarf bleibt die Arc-GPU relevant, insbesondere wenn das Modell nicht vollständig für die NPU quantisiert werden kann.

Lokale NPU-Inferenz gegen Cloud-Inferenz im Alltagsvergleich

Eine Frage, die in Projektmeetings fast immer auftaucht: Warum überhaupt lokal rechnen, wenn eine Cloud-API mit wenigen Zeilen Code angebunden ist? Die Antwort hängt vom Workload ab, lässt sich aber an ein paar wiederkehrenden Kriterien festmachen, die sich in der Tabelle unten gegenüberstehen.

Kriterium	Lokale NPU-Inferenz	Cloud-API-Inferenz
Laufende Kosten pro Anfrage	keine, nach Anschaffung der Hardware	nutzungsabhängig, oft pro Token oder Anfrage
Latenz	im einstelligen Millisekundenbereich, ohne Netzwerk	abhängig von Verbindung, meist zweistellig bis dreistellig
Datenschutz	Daten verlassen das Gerät nicht	Daten werden an Drittanbieter übertragen
Offline-Fähigkeit	vollständig gegeben	benötigt aktive Internetverbindung
Modellgröße/-komplexität	begrenzt durch NPU-Speicher und TOPS	praktisch unbegrenzt skalierbar
Wartungsaufwand	Treiber, Frameworks, Modell-Updates selbst verwalten	vom Anbieter verwaltet

Für Anwendungsfälle mit hohem Anfragevolumen und überschaubarer Modellgröße, etwa Live-Untertitelung, Gesichtsunschärfe in Videokonferenzen oder Dokumentenklassifikation, rechnet sich lokale NPU-Inferenz meist schon nach kurzer Zeit, weil laufende API-Kosten komplett entfallen. Für sehr große Modelle, seltene Anfragen oder Anwendungen, die ohnehin zentral in der Cloud laufen, bleibt eine API-Anbindung oft die pragmatischere Wahl. Ein hybrider Ansatz, bei dem einfache Anfragen lokal auf der NPU landen und nur komplexe Fälle an die Cloud eskaliert werden, kombiniert beide Vorteile und wird in Produktionssystemen zunehmend häufiger eingesetzt.

Ein praktisches Beispiel für diesen hybriden Ansatz: Eine Diktier-App transkribiert Sprache standardmäßig lokal auf der NPU, weil das für die meisten Alltagssätze völlig ausreicht und ohne Internetverbindung funktioniert. Erst bei Fachterminologie oder mehrsprachigen Passagen, die das lokale Modell erkennbar unsicher einstuft, wird die Anfrage an ein größeres Cloud-Modell weitergereicht. So bleibt die überwiegende Mehrheit der Anfragen kostenlos, schnell und offline nutzbar, während die Cloud-Anbindung nur für die Fälle greift, in denen sie tatsächlich einen Mehrwert bringt.

Preise und Verfügbarkeit der Core Ultra Series 3

Für alle, die noch keine passende Hardware besitzen, hier der aktuelle Marktüberblick zum Erscheinungszeitpunkt dieses Artikels.

Bemerkenswert an der Series-3-Einführung ist der klare Fokus auf Edge- und Industrieanwendungen zusätzlich zum klassischen Laptop-Markt. Intel adressiert damit explizit Robotik, Fertigungsanlagen, Gesundheitswesen und Bildungseinrichtungen, also Bereiche, in denen Geräte oft ohne durchgehende Cloud-Anbindung arbeiten müssen und lokale Inferenz keine Option, sondern eine Notwendigkeit ist. Für Entwicklerteams, die Edge-Geräte mit stabilen, langlebigen Software-Stacks ausstatten müssen, ist das ein wichtiges Signal: Der OpenVINO-Support für diese Plattform ist nicht als kurzlebiges Marketing-Feature gedacht, sondern als langfristig gepflegter Teil der Intel-Roadmap.

Modellreihe	Zielsegment	Richtpreis (Laptop, ab)	Verfügbarkeit
Core Ultra X9	Flaggschiff, volle NPU-Leistung	ca. 1.299 US-Dollar	seit 27. Jänner 2026
Core Ultra X7	Mittelklasse	ca. 999 US-Dollar	seit Q1 2026, breiter Rollout H1 2026
Edge- und Industrie-Boards	Robotik, Industrie-PCs	je nach Integrator variabel	ab Q2 2026

Die genannten Preise sind US-Listenpreise für Referenzdesigns und können je nach Hersteller, Ausstattung und österreichischem Handel deutlich abweichen. Vor dem Kauf lohnt sich ein Blick in aktuelle Preisvergleiche, da Importsteuern und Wechselkurs den Endpreis in Österreich üblicherweise erhöhen. Weitere Hintergründe zu aktueller KI-Hardware und deren Einrichtung sammelt shattered.io laufend im Hardware-Ressort, unter anderem mit einem Vergleich zu lokaler KI auf der RTX 5070.

Der vollständige Quellcode von OpenVINO ist als Open-Source-Projekt auf GitHub einsehbar, offizielle Ankündigungen zu neuen Core-Ultra-Generationen veröffentlicht Intel im eigenen Newsroom.

NPU-Auslastung im Betrieb überwachen

Sobald ein Modell produktiv auf der NPU läuft, lohnt sich fortlaufendes Monitoring, um Regressionen frühzeitig zu erkennen. Unter Linux liefert das Werkzeug intel_gpu_top, das trotz des Namens auch NPU-Aktivität mit anzeigt, einen schnellen Überblick über die aktuelle Auslastung. Unter Windows übernimmt der Task-Manager ab Windows 11 24H2 diese Aufgabe direkt im Reiter "Leistung", wo die NPU als eigener Grafen neben CPU und GPU erscheint.

# Linux: NPU- und GPU-Auslastung live beobachten
sudo intel_gpu_top

# Alternative: OpenVINO-eigene Property-Abfrage im Skript
python3 - <<'EOF'
from openvino import Core

core = Core()
compiled = core.compile_model(core.read_model("model_ir.xml"), "NPU")
print("Optimale Anzahl paralleler Infer-Requests:",
      compiled.get_property("OPTIMAL_NUMBER_OF_INFER_REQUESTS"))
EOF

Der Wert OPTIMAL_NUMBER_OF_INFER_REQUESTS ist besonders bei Diensten mit mehreren gleichzeitigen Anfragen wichtig: Er gibt an, wie viele parallele Inferenz-Requests die NPU effizient verarbeiten kann, bevor zusätzliche Anfragen nur noch in eine Warteschlange laufen, statt echten Mehrwert zu bringen. Wer diesen Wert ignoriert und beliebig viele Requests gleichzeitig abfeuert, sieht in der Praxis oft steigende Latenzen, obwohl die NPU selbst gar nicht ausgelastet ist, weil interne Warteschlangen den Engpass verursachen. Ein einfacher Semaphore in der Anwendungsschicht, der die Anzahl gleichzeitiger Requests auf diesen Optimalwert begrenzt, verhindert das zuverlässig.

Für strukturiertes Logging empfiehlt sich, bei jeder Inferenz mindestens drei Werte festzuhalten: das genutzte Ausführungsgerät, die gemessene Latenz und einen Zeitstempel. Über einen Zeitraum von Tagen oder Wochen lassen sich daraus Trends erkennen, etwa ob die NPU nach einem bestimmten Windows-Update plötzlich häufiger auf CPU zurückfällt oder ob die Latenz an bestimmten Tageszeiten ansteigt, weil andere Anwendungen die Recheneinheit gleichzeitig beanspruchen. Diese Daten lassen sich mit gängigen Log-Aggregatoren wie Grafana Loki oder einer einfachen strukturierten Logdatei auswerten, ganz ohne zusätzliche Intel-spezifische Werkzeuge.

Die häufigsten Fehler beim NPU-Setup

Diese Stolperfallen tauchen in Support-Foren und eigenen Testläufen immer wieder auf. Die meisten davon lassen sich in wenigen Minuten beheben, kosten aber ohne Vorwissen oft eine ganze Debugging-Session, weil die Fehlermeldungen selten direkt auf die eigentliche Ursache hinweisen.

• Veralteter NPU-Treiber: Windows Update installiert nicht immer automatisch die neueste Intel-AI-Boost-Version. Ohne manuellen Check bleibt die NPU für OpenVINO unsichtbar.
• Falsche Python-Architektur: Eine 32-Bit-Python-Installation auf Windows verhindert das Laden der NPU-Plug-ins vollständig, auch wenn pip scheinbar fehlerfrei installiert.
• Modell nicht quantisiert: Wird ein FP32-Modell direkt auf die NPU geschickt, schlägt die Kompilierung oft fehl oder läuft extrem langsam. Die Konvertierung mit --compress_to_fp16 oder INT8-Quantisierung ist fast immer nötig.
• Cold-Start-Zeit falsch interpretiert: Wer nur eine einzelne Inferenz misst, sieht die Kompilierungszeit mit im Ergebnis und hält die NPU fälschlich für langsam. Ohne Aufwärmphase sind Benchmarks wertlos.
• Delegate-Pfad nicht gesetzt: Der LiteRT-OpenVINO-Delegate muss unter Windows explizit im Systempfad oder per absolutem Pfad referenziert werden, sonst bricht das Laden mit einer kryptischen Fehlermeldung ab.
• Mehrere OpenVINO-Versionen parallel installiert: Ein globales pip-Environment und ein virtuelles Environment mit unterschiedlichen OpenVINO-Versionen führen zu widersprüchlichen NPU-Plug-ins und undurchsichtigen Fehlern.
• Feste Eingabeform bei AOT-Modellen ignoriert: Wird ein AOT-kompiliertes Modell mit einer anderen Eingabegröße als beim Kompilieren aufgerufen, schlägt die Inferenz fehl. Wer wechselnde Größen braucht, muss auf dynamische Shapes oder On-Device-Kompilierung setzen.
• Benchmark direkt nach dem Systemstart gemessen: In den ersten Minuten nach dem Boot drosseln viele Systeme aus thermischen Gründen die volle Leistung. Für belastbare Zahlen sollte der Benchmark erst nach einigen Minuten Betrieb laufen.

Troubleshooting: Acht Probleme und ihre Lösungen

Die folgende Liste deckt die Fehlerbilder ab, die in der Praxis am häufigsten gemeldet werden. Als erste Diagnose lohnt sich immer das Skript aus Schritt 5 und 6, weil es sofort zeigt, ob OpenVINO die NPU überhaupt sieht, bevor tiefer in Modell- oder Treiberprobleme investigiert wird.

• "NPU" fehlt in core.available_devices: Treiber neu installieren, System neu starten, danach erneut mit dem Schritt-5-Skript prüfen.
• RuntimeError bei compile_model mit device_name="NPU": Das Modell ist meist nicht kompatibel mit dem NPU-Plug-in. Erst mit ovc ins IR-Format konvertieren und FP16 oder INT8 verwenden.
• Sehr hohe erste Inferenzzeit: Normalverhalten bei On-Device-Kompilierung. Entweder auf AOT umstellen oder die erste Inferenz aus der Zeitmessung herausrechnen.
• ImportError: DLL load failed (Windows): Meist fehlen die Visual-C++-Redistributables. Aktuelle Version von Microsoft nachinstallieren und Python-Umgebung neu aktivieren.
• LiteRT-Delegate wird ignoriert, Modell läuft auf CPU: Prüfen, ob experimental_delegates korrekt übergeben wurde und ob die .so/.dll-Datei zur installierten OpenVINO-Version passt.
• Benchmark_app meldet "Device not found": Der Gerätename muss exakt "NPU" lauten, Groß-/Kleinschreibung wird nicht toleriert.
• Speicherfehler bei großen Modellen: Die NPU hat ein begrenztes internes Speicherbudget. Modelle über wenigen Milliarden Parametern sollten stärker quantisiert oder in Teilen auf CPU/GPU ausgelagert werden.
• Deutlich schlechtere Werte als in der Doku: Hintergrundprozesse wie Antivirus-Scans oder Energiesparmodi drosseln die NPU. Energieplan auf "Höchstleistung" stellen und Messung wiederholen.

Wann lohnt sich die NPU nicht?

Ehrlichkeit gehört zu einem guten Tutorial dazu: Die NPU ist kein Ersatz für jede Art von Rechenlast. Für das Training von Modellen ist sie ungeeignet, sie ist ausschließlich für Inferenz ausgelegt. Wer Modelle trainiert oder feintuned, bleibt weiterhin auf GPU oder Cloud-Instanzen angewiesen. Auch bei sehr großen Sprachmodellen im zweistelligen Milliarden-Parameter-Bereich stößt die NPU an ihre Speichergrenzen, weil sie im Gegensatz zu einer dedizierten GPU keinen eigenen großen VRAM-Pool besitzt, sondern sich den System-RAM mit CPU und GPU teilt.

Auch bei Workloads mit stark schwankender Eingabegröße, etwa Objekterkennung mit variabler Bildauflösung, kann die NPU im Vergleich zur GPU ins Hintertreffen geraten, weil AOT-kompilierte Modelle auf eine feste Eingabeform ausgelegt sind. Hier hilft entweder On-Device-Kompilierung mit dynamischen Formen oder ein Preprocessing-Schritt, der Eingaben vor der Inferenz auf eine einheitliche Größe bringt. Als Faustregel gilt: Kleine bis mittelgroße Modelle mit stabiler Eingabeform und Dauerlastcharakter profitieren am meisten von der NPU, große, unregelmäßige oder trainingsintensive Workloads gehören weiterhin auf die GPU.

Erweiterte Tipps für Produktionsumgebungen

Wer über ein einzelnes Testskript hinausgeht, sollte einige zusätzliche Punkte beachten, die sich in eigenen Testläufen und in Rückmeldungen aus der OpenVINO-Community als besonders relevant erwiesen haben. Erstens lohnt sich ein automatisches Fallback: Ist die NPU zur Laufzeit nicht verfügbar (etwa in einer VM oder auf älterer Hardware), sollte die Anwendung stillschweigend auf GPU oder CPU zurückfallen, statt abzustürzen. OpenVINOs AUTO-Device-Plug-in übernimmt das automatisch, wenn device_name="AUTO:NPU,GPU,CPU" gesetzt wird.

Zweitens: Für Dauerbetrieb in Edge-Geräten (Robotik, Industrie-PCs, die laut Intel ab Q2 2026 mit Series-3-Chips ausgeliefert werden) lohnt sich AOT-Kompilierung kombiniert mit einem versionsfixierten Treiber-Image, damit ein automatisches Update nicht ungeplant die Kompilierungscaches invalidiert. Wer im selben Projekt zusätzlich große Modelle auf dedizierter Hardware trainiert, findet im Tutorial zur Multi-GPU-KI-Workstation die passende Ergänzung für die Trainingsseite, während sich für Cloud-Skalierung ein Blick auf TPU-Ironwood-Setups lohnt. Drittens: Beim Deployment mehrerer Modelle gleichzeitig teilt sich die NPU ihre TOPS-Kapazität, weshalb sich ein einfacher Scheduler lohnt, der priorisierte Modelle zuerst einreiht. Viertens: INT8-Quantisierung mit OpenVINOs Neural Network Compression Framework (NNCF) reduziert nicht nur die Modellgröße, sondern verbessert auf der NPU oft auch die Latenz spürbar, weil weniger Daten durch den Speicherbus müssen. Wer Genauigkeitseinbußen scheut, sollte NNCFs Post-Training-Quantisierung mit einem kleinen Validierungsdatensatz gegenprüfen, bevor das Modell produktiv geht. Fünftens: Für Logging und Monitoring in Produktion lohnt es sich, das aktive Ausführungsgerät (NPU, GPU oder CPU) bei jeder Anfrage mitzuloggen, wie im FastAPI-Beispiel weiter oben gezeigt. Ohne dieses Signal fällt ein stiller Fallback auf CPU oft erst auf, wenn Nutzer sich über spürbar langsamere Antwortzeiten oder höhere Serverlast beschweren.

Damit ist der komplette Weg von der leeren Python-Umgebung bis zum benchmarkten, produktionstauglichen NPU-Setup abgedeckt: Treiber prüfen, OpenVINO 2026.0 installieren, LiteRT anbinden, Modell konvertieren und quantisieren, Inferenz messen und in eine echte API einbetten. Wer die Schritte einmal durchlaufen hat, kann das Setup-Skript aus dem Beispielprojekt als Vorlage für weitere Modelle wiederverwenden, ohne die Grundkonfiguration erneut aufzusetzen.

Häufig gestellte Fragen

Funktioniert OpenVINO 2026 auch mit älteren Core-Ultra-Generationen?
Ja, grundsätzlich unterstützt OpenVINO auch Series 1 und Series 2. Die TOPS-Werte und die hier gezeigten Effizienzgewinne gelten aber spezifisch für die neue Series-3-NPU mit ihrem NPU-5-Block, ältere Generationen liegen bei Durchsatz und Effizienz merklich darunter.

Brauche ich zwingend LiteRT, oder reicht reines OpenVINO?
Reines OpenVINO genügt für die meisten eigenständigen Projekte. LiteRT lohnt sich vor allem, wenn bereits eine bestehende TensorFlow-Lite- oder LiteRT-Pipeline existiert und diese ohne Umbau auf die NPU verlagert werden soll, etwa in mobilen oder plattformübergreifenden Apps.

Läuft das Tutorial auch unter macOS?
Nein. Die Core-Ultra-NPU und der zugehörige Treiber sind Intel-x86-spezifisch und stehen auf Apple-Silicon-Systemen nicht zur Verfügung. Für Apple-Hardware ist stattdessen Apples eigenes MLX-Framework der passende Weg, lokale Modelle auf der Neural Engine auszuführen.

Wie groß darf ein Modell für die NPU maximal sein?
Eine feste Obergrenze nennt Intel nicht, in der Praxis laufen komprimierte Modelle im niedrigen einstelligen Milliarden-Parameter-Bereich stabil. Größere Modelle sollten quantisiert oder teilweise auf CPU/GPU ausgelagert werden, da die NPU sich den Systemspeicher mit den anderen Recheneinheiten teilt.

Ist AOT-Kompilierung immer die schnellere Option?
Für den ersten Aufruf ja, weil die Kompilierungszeit vorab anfällt. Bei häufigen Treiber-Updates oder wechselnder Hardware kann On-Device-Kompilierung im Alltag praktischer sein, weil sie sich automatisch anpasst, ohne dass ein Cache manuell invalidiert werden muss.

Kann ich die NPU und die GPU gleichzeitig für unterschiedliche Modelle nutzen?
Ja. OpenVINO erlaubt es, mehrere compiled_model-Instanzen mit unterschiedlichen device_name-Werten parallel zu betreiben, solange genügend Speicher und TOPS-Budget vorhanden sind. In der Praxis bewährt sich das etwa, wenn ein kleines Modell dauerhaft auf der NPU läuft, während die GPU sporadisch größere Batch-Jobs übernimmt.

Was kostet ein Einstiegssystem mit Core Ultra Series 3?
Laptops mit dem Core Ultra X7 starten laut Intels Launch-Preisen bei rund 999 US-Dollar, Flaggschiff-Modelle mit X9 bei rund 1.299 US-Dollar. Der tatsächliche Preis in Österreich hängt vom jeweiligen Gerätehersteller ab und liegt durch Importkosten und Wechselkurs meist über dem US-Listenpreis.

Lohnt sich der Umstieg, wenn ich bisher alles auf der GPU laufen lasse?
Für Dauerlast-Aufgaben mit moderater Modellgröße lohnt sich der Wechsel fast immer, da die NPU laut den hier gezeigten Werten bei Gemma 4 E2B rund 2,8-mal effizienter pro Watt arbeitet. Bei sehr großen oder stark grafiklastigen Modellen bleibt die GPU oft die praktikablere Wahl.

Muss ich mein bestehendes ONNX-Modell komplett neu bauen?
Nein. Der Weg über ovc zur Konvertierung ins OpenVINO-IR-Format funktioniert mit den meisten Standard-ONNX-Exporten aus PyTorch oder TensorFlow, ohne dass die ursprüngliche Modellarchitektur verändert werden muss. Lediglich bei sehr exotischen Operatoren kann eine manuelle Anpassung nötig sein.

Was passiert, wenn während der Inferenz die NPU-Treiber aktualisiert werden?
Bei On-Device-Kompilierung passt sich das System automatisch an den neuen Treiber an, mit einer kurzen Neukompilierung beim nächsten Start. Bei AOT-kompilierten Modellen kann ein größeres Treiber-Update dagegen dazu führen, dass die vorkompilierte Binärdatei ungültig wird und neu erzeugt werden muss, weshalb Produktionsumgebungen Treiber-Updates idealerweise kontrolliert und nicht automatisch einspielen sollten.