ONNX einfach erklärt: So läuft lokale KI auf AMD, Intel und NVIDIA

Viele lokale KI-Anwendungen wirken so, als wären sie automatisch an eine bestimmte Grafikkartenmarke gebunden. In der Praxis hängt die Ausführung jedoch nicht nur vom Modell ab, sondern davon, wie dieses Modell mit der vorhandenen Hardware verbunden wird. Genau hier kommen ONNX, ONNX Runtime und sogenannte Execution Provider ins Spiel.

ONNX schafft eine standardisierte Grundlage für KI-Modelle. ONNX Runtime lädt und verarbeitet diese Modelle. Execution Provider verbinden die Runtime anschließend mit der verfügbaren CPU, GPU oder NPU. Dadurch kann lokale KI unterschiedliche Ausführungspfade für Systeme mit AMD, Intel und NVIDIA verwenden.

VANIV nutzt diese Architektur für lokale Audio-, Sprach- und Videoverarbeitung. Dieser Artikel erklärt, was ONNX ist, wie die Hardwareanbindung funktioniert und warum hardwareflexible KI nicht bedeutet, dass jeder Computer dieselbe Geschwindigkeit erreicht.

Was ist ONNX? Das offene Format für KI-Modelle

Ein universelles Format für trainierte KI-Modelle

Stell dir ONNX vereinfacht wie ein gemeinsames Dateiformat für KI-Modelle vor. MP3 hilft dabei, Audiodateien in vielen unterschiedlichen Programmen zu verwenden. JPEG erfüllt eine ähnliche Aufgabe bei Bildern. ONNX verfolgt diesen Grundgedanken für trainierte Modelle – technisch allerdings auf einer deutlich komplexeren Ebene.

ONNX steht für Open Neural Network Exchange. Das Format definiert unter anderem den Rechengraphen eines Modells, seine Operationen, Datentypen und gespeicherten Parameter. Ein Modell kann beispielsweise in PyTorch entwickelt und anschließend nach ONNX exportiert werden. Danach lässt es sich in einer ONNX-kompatiblen Runtime ausführen.

Die Analogie mit MP3 und JPEG hilft beim Verständnis, ist aber keine technische Gleichsetzung. Ein KI-Modell besteht nicht nur aus Mediendaten, sondern aus einer Struktur von Berechnungen, Ein- und Ausgaben sowie trainierten Gewichten.

Ein einfaches Beispiel aus der Spracherkennung

Angenommen, ein Spracherkennungsmodell wurde in einem bestimmten Entwicklungsframework trainiert. Ohne einen geeigneten Austauschstandard wäre die spätere Anwendung stärker an dieses Framework und dessen Laufzeit gebunden.

Nach dem Export liegt das Modell als ONNX-Datei vor. Eine Laufzeit wie ONNX Runtime kann diese Datei laden, aufbereitete Audiodaten als Eingabe verarbeiten und erkannten Text als Ausgabe liefern.

Der praktische Vorteil liegt nicht darin, dass ONNX jede technische Grenze beseitigt. Der Vorteil ist eine klarere Trennung zwischen Modellentwicklung und späterer Ausführung.

Wer steckt hinter ONNX?

ONNX wurde 2017 von Microsoft und Facebook, heute Meta, gemeinsam vorgestellt. Aus dem ursprünglichen Austauschformat entwickelte sich ein offen verwaltetes Community-Projekt unter dem Dach von LF AI & Data.

Das ist wichtig, weil ONNX kein geschlossenes Modellformat eines einzelnen Hardwareherstellers ist. Die Weiterentwicklung findet herstellerübergreifend statt und schafft eine gemeinsame technische Grundlage für unterschiedliche Frameworks, Laufzeiten und Hardwarepfade.

ONNX im Vergleich zu nativen Modellformaten

Warum reicht das ursprüngliche Framework-Format nicht immer aus?

PyTorch, TensorFlow und andere Entwicklungsumgebungen besitzen eigene Formate und Werkzeuge. Diese sind besonders für Training, Entwicklung und frameworkeigene Workflows wichtig.

ONNX wurde dagegen als Austauschformat geschaffen. Ein Modell wird in seiner Entwicklungsumgebung trainiert, nach ONNX exportiert und anschließend in einer ONNX-kompatiblen Runtime verwendet.

ONNX ersetzt das ursprüngliche Framework nicht vollständig. Es ergänzt den Entwicklungsprozess um eine portable Ausführungsschicht.

Hat ONNX auch Grenzen?

Ja. Nicht jedes Modell lässt sich vollständig und ohne Anpassung nach ONNX exportieren. Dynamische Kontrollflüsse, benutzerdefinierte Operatoren oder framework-spezifisches Verhalten können den Export und die spätere Ausführung erschweren. Zusätzlich muss der spätere Execution Provider die benötigten Modelloperationen unterstützen oder einen passenden Fallback ermöglichen.

ONNX macht ein Modell außerdem nicht automatisch schneller. Auch die verwendete ONNX-Opset-Version, die Runtime-Version und die unterstützten Operatoren müssen zusammenpassen. Das Format schafft die Grundlage für eine portable Ausführung; die tatsächliche Leistung entsteht durch Modelloptimierung, Runtime, Hardware und Execution Provider.

Diese Grenze ist kein Widerspruch zum Nutzen von ONNX. Sie zeigt lediglich, dass ein gemeinsames Modellformat nicht jede technische Aufgabe automatisch löst.

Was ONNX ist – und was nicht

ONNX allein macht aber noch keine ausführbare KI. Dafür braucht es eine Runtime – und genau die kommt jetzt.

Was ist ONNX Runtime? So werden KI-Modelle auf deiner Hardware ausgeführt

Modell und Runtime sind nicht dasselbe

Die ONNX-Datei enthält das Modell. ONNX Runtime ist die Ausführungsumgebung, die dieses Modell lädt und die Berechnungen durchführt.

Ein einfaches Bild:

Das ONNX-Modell ist der Bauplan. ONNX Runtime ist die Maschine, die den Bauplan liest und die Arbeit ausführt.

ONNX Runtime analysiert und optimiert den Modellgraphen. Anschließend führt die Runtime die Berechnungen mit den verfügbaren Execution Providern aus. Die eigentliche Anwendung stellt Eingabedaten bereit und verarbeitet die Ausgabe weiter.

Ein Spracherkennungsmodell Schritt für Schritt

Wie sieht das bei einer echten Audiodatei aus?

1. Modell laden: ONNX Runtime lädt die ONNX-Datei mit dem trainierten Spracherkennungsmodell.
2. Audio vorbereiten: Die Anwendung liest eine Audiodatei ein und wandelt sie in die vom Modell erwartete Eingabe um.
3. Inferenz ausführen: ONNX Runtime berechnet mit Unterstützung der verfügbaren Execution Provider die Modellausgabe.
4. Text erzeugen: Das Modell liefert erkannten Text oder eine Zwischenausgabe zurück, aus der die Anwendung den Text erzeugt.
5. Ergebnis weiterverarbeiten: Die Anwendung setzt die Ausgabe beispielsweise für Untertitel, Übersetzung oder weitere Sprachverarbeitung ein.

Wichtig ist die Trennung der einzelnen Arbeitsschritte: Audioimport, Aufbereitung, Modellinferenz und spätere Textverarbeitung sind nicht dasselbe. Sie können unterschiedliche Modelle, Bibliotheken und Recheneinheiten verwenden.

Warum diese Trennung wichtig ist

Modell, Runtime, Hardwareanbindung und Benutzeroberfläche bleiben getrennte Ebenen. Das ermöglicht:

• Modelle unabhängig von der Oberfläche zu aktualisieren
• unterschiedliche Execution Provider einzubinden
• dieselbe Anwendungslogik auf mehreren Hardwareplattformen einzusetzen
• Vor- und Nachbearbeitung getrennt von der Modellinferenz zu optimieren

ONNX Runtime kann ein Modell laden und ausführen. Aber wie gelangt die Berechnung auf die passende Hardware? Dafür gibt es Execution Provider.

Was ist ein Execution Provider? Die Verbindung zwischen ONNX und CPU, GPU oder NPU

Was ein Execution Provider macht

Ein Execution Provider verbindet ONNX Runtime mit einer bestimmten Hardware- oder Beschleunigungsplattform.

ONNX Runtime analysiert den Modellgraphen. Die registrierten Execution Provider melden über ihre Fähigkeiten, welche Knoten oder Teilgraphen sie ausführen können. Die Runtime ordnet ihnen anschließend unterstützte Bereiche zu. Verbleibende Operationen können von einem weiteren Provider oder vom standardmäßigen CPU Execution Provider übernommen werden.

Ein Execution Provider stellt damit nicht nur einen Namen in einer Konfigurationsdatei bereit. Er verbindet die Runtime mit optimierten Rechenkernen, Speicherverwaltung und der Zielhardware.

Die Universaladapter-Analogie

Stell dir ONNX Runtime wie einen Universaladapter vor. Das Modell bleibt grundsätzlich dasselbe, aber der Anschluss an die Hardware unterscheidet sich:

• CUDA oder TensorRT für NVIDIA
• MIGraphX für AMD
• OpenVINO für Intel
• DirectML als herstellerübergreifender Windows-Pfad
• CPU-Ausführung als breite Grundlage

Die Analogie erklärt das Grundprinzip. Sie bedeutet nicht, dass alle Provider denselben Funktionsumfang oder dieselbe Geschwindigkeit besitzen.

Was passiert bei nicht unterstützten Operationen?

Kann ein Execution Provider bestimmte Modelloperationen nicht übernehmen, kann ONNX Runtime unterstützte Teilbereiche einem anderen Provider oder dem CPU-Pfad zuweisen.

Welche Provider verfügbar sind und in welcher Reihenfolge sie verwendet werden, gehört zur technischen Konfiguration der Anwendung. Als VANIV-Nutzer arbeitest du mit dem daraus entstandenen Workflow; die Provider-Zuweisung läuft im Hintergrund.

CPU, GPU und NPU im Vergleich

Mit Execution Providern ist die Grundlage für hardwareflexible KI gelegt. Jetzt wird es konkret: Wie sieht die Ausführung bei NVIDIA, AMD und Intel aus?

ONNX auf NVIDIA: CUDA und TensorRT für lokale KI

CUDA als etablierter Ausführungspfad

Der CUDA Execution Provider verbindet ONNX Runtime mit NVIDIA-GPUs. CUDA ist im KI-Ökosystem weit verbreitet, weshalb viele Modelle und Anwendungen früh für diesen Pfad optimiert werden.

Für Nutzer mit NVIDIA-Hardware bedeutet das einen gut etablierten Ausführungspfad mit einem großen Software- und Entwickler-Ökosystem.

TensorRT als zusätzliche Optimierung

Der TensorRT Execution Provider nutzt NVIDIAs Inferenz-Engine, um geeignete ONNX-Modelle auf NVIDIA-GPUs zu beschleunigen. TensorRT ist eine zusätzliche Ausführungsschicht und nicht mit dem ONNX-Format gleichzusetzen.

Ob TensorRT sinnvoll eingesetzt werden kann, hängt vom Modell, den unterstützten Operationen und dem gewünschten Optimierungsaufwand ab.

Für dich bedeutet das

Besitzt du eine NVIDIA-Grafikkarte, steht dir ein weit verbreiteter ONNX-Pfad zur Verfügung. ONNX Runtime bleibt dennoch nicht auf CUDA beschränkt. Genau diese Offenheit ermöglicht herstellerübergreifende Anwendungen.

ONNX auf AMD: DirectML, ROCm und MIGraphX

DirectML unter Windows

DirectML ist ein herstellerübergreifender Windows-Pfad für DirectX-12-fähige Hardware. Dadurch ist DirectML für AMD-, Intel- und NVIDIA-Grafik relevant.

DirectML wird weiterhin unterstützt, befindet sich aber im Sustained-Engineering-Modus. Neue Funktionen für Windows-basierte ONNX-Runtime-Bereitstellungen entwickelt Microsoft über Windows ML weiter. Windows ML basiert ebenfalls auf ONNX Runtime und kann passende Execution Provider für CPU, GPU und NPU verwalten.

ROCm und MIGraphX

ROCm ist AMDs Plattform für GPU-Computing und besonders für Linux sowie fortgeschrittene AMD-Setups relevant. MIGraphX nutzt AMDs Graphoptimierung, um ONNX-Modelle auf AMD-GPUs zu beschleunigen. Der frühere ROCm Execution Provider wurde ab ONNX Runtime 1.23 entfernt; die offizielle Dokumentation empfiehlt für entsprechende Anwendungen die Migration zu MIGraphX.

Die geeignete Kombination hängt von Betriebssystem, GPU, Treibern, Runtime-Paket und Modell ab.

Für dich bedeutet das

AMD-Hardware ist nicht automatisch von lokaler KI ausgeschlossen, nur weil viele Projekte zuerst einen CUDA-Pfad anbieten. ONNX und passende Execution Provider schaffen zusätzliche Wege, die VANIV für eine hardwareflexible Architektur nutzt.

ONNX auf Intel: CPU, Grafik, NPU und OpenVINO

CPU und Intel-Grafik

Intel-CPUs können ONNX-Modelle über CPU-basierte Ausführungspfade verarbeiten. Integrierte Intel-Grafik und Intel Arc ermöglichen je nach System zusätzliche Hardwarebeschleunigung.

Ein Intel-System ist daher nicht automatisch auf reine CPU-Inferenz beschränkt.

NPUs in modernen Intel-Systemen

NPUs sind auf energieeffiziente KI-Inferenz spezialisiert. Sie werden besonders in Laptops und kompakten Systemen relevant. Die tatsächliche Nutzbarkeit hängt vom Modell und vom unterstützten Ausführungspfad ab.

Eine NPU ersetzt nicht automatisch eine leistungsstarke GPU. Sie bietet einen anderen Schwerpunkt: effiziente lokale Inferenz bei geringerem Energieverbrauch.

OpenVINO

OpenVINO ist ein auf Intel-Hardware optimiertes Toolkit und kann als Execution Provider in ONNX Runtime eingebunden werden. Der aktuelle OpenVINO Execution Provider unterstützt die Beschleunigung auf Intel-CPUs, Intel-GPUs und Intel-NPUs.

Für dich bedeutet das

VANIV kann vorhandene Intel-Hardwarepfade in denselben lokalen Projektablauf integrieren. Der Nutzer arbeitet mit einer einheitlichen Oberfläche, während die technische Ausführung an das vorhandene System angepasst wird.

Hardwareunterstützung und Geschwindigkeit: Warum Systeme unterschiedlich schnell sind

Ein älterer Laptop erreicht nicht plötzlich dieselbe Geschwindigkeit wie eine leistungsstarke Workstation. Das ist kein Kompatibilitätsproblem, sondern eine normale Folge unterschiedlicher Hardware.

Was bedeutet das konkret für deinen Computer?

Die Geschwindigkeit hängt vor allem von drei Bereichen ab:

Kompatibilität und Leistung sind verschiedene Fragen

Ein System kann einen Workflow grundsätzlich unterstützen und trotzdem deutlich länger für die Verarbeitung benötigen.

Beispiele:

• integrierte Grafik besitzt häufig weniger verfügbare Rechenleistung
• eine dedizierte GPU kann parallele Modellberechnungen schneller ausführen
• größere Modelle benötigen mehr RAM oder VRAM
• nicht unterstützte Modellteile können auf dem CPU-Pfad weiterlaufen, dort aber langsamer sein

Warum dieser Artikel keine pauschalen GPU-Duelle enthält

Eine Aussage wie „GPU A ist immer schneller als GPU B“ wäre ohne kontrollierte Messbedingungen wenig seriös. Für einen belastbaren Vergleich müssten mindestens Workflow, Modell, Treiber, Execution Provider, Einstellungen und Testmaterial identisch sein.

Konkrete Grafikkartenvergleiche gehören deshalb in eigene Benchmark- und Kaufberatungsartikel.

Warum ONNX für lokale KI wichtig ist

Lokale Verarbeitung

ONNX-Modelle und ONNX Runtime können vollständig lokal bereitgestellt werden. Die Modellinferenz muss deshalb nicht zwingend in einer Cloud stattfinden.

Das ist besonders bei Audio- und Videodateien relevant. Große Quelldateien müssen nicht für jeden Verarbeitungsschritt an einen externen Dienst übertragen werden.

Kontrolle über Dateien und Arbeitsabläufe

Lokale Verarbeitung gibt dir mehr Kontrolle über Quelldateien, Zwischenstände und Exporte. Gleichzeitig reduziert sie die Abhängigkeit von Uploadgeschwindigkeit und Verfügbarkeit externer Dienste.

Lokale Verarbeitung ist kein automatisches Sicherheitsversprechen. Sie schafft jedoch eine technische Grundlage dafür, dass sensible Mediendaten nicht für die eigentliche Inferenz an einen Cloud-Anbieter gesendet werden müssen.

Hardwareflexibilität

Software und Workflow müssen nicht dauerhaft an einen einzelnen GPU-Hersteller gekoppelt sein. Modelle, Runtime und Hardwarepfad bleiben getrennte Komponenten.

Dadurch kann dieselbe Anwendung unterschiedliche Systeme ansprechen, ohne für jeden Hersteller eine völlig andere Benutzeroberfläche zu benötigen.

Wartbare Desktop-Architektur

Neue Execution Provider, Hardwaregenerationen und Modellversionen können in dieselbe Grundarchitektur eingebunden werden. Das erleichtert die Weiterentwicklung lokaler Desktop-Software und verhindert eine unnötig enge Bindung an einzelne Plattformen.

Wie VANIV ONNX für lokale Audio- und Videoverarbeitung nutzt

Ein Workflow – drei Hardwarewelten

Stell dir drei Arbeitsplätze vor:

Alle drei Nutzer arbeiten mit derselben VANIV-Oberfläche, denselben Projektfunktionen und demselben grundlegenden Workflow. Die Verarbeitung nutzt die jeweils vorhandene Hardware. Die Geschwindigkeit unterscheidet sich, der Arbeitsablauf bleibt konsistent.

Mehrere KI-Schritte – ein lokales Projekt

VANIV verbindet unter anderem:

• lokale Spracherkennung
• Sprechererkennung und Sprecherzuordnung
• Videos mit KI übersetzen
• Text-to-Speech und Offline-KI-Stimmen
• lokales Voice Cloning
• Video-Dubbing
• Multi-Speaker-Dubbing
• Timing-Anpassung
• Audio-Mix und Export

Nicht jeder Schritt verwendet zwingend dasselbe Modell oder denselben Execution Provider. Der Mehrwert besteht darin, dass daraus für dich ein durchgängiges lokales Projekt entsteht.

Keine zwingenden Cloud-Uploads

• Quelldateien und Exporte bleiben auf deinem eigenen System.
• Große Videos müssen nicht für jeden Verarbeitungsschritt erneut hochgeladen werden.
• Für die lokale KI-Berechnung entstehen keine zwingenden nutzungsabhängigen Cloudgebühren.
• Vertrauliche Medien müssen für die Modellinferenz nicht an einen externen Dienst übertragen werden.

Für wen VANIV interessant ist

VANIV richtet sich an Menschen und Teams, die mit Audio, Sprache oder Video arbeiten und lokale KI auf AMD-, Intel- oder NVIDIA-Hardware nutzen möchten.

Dazu gehören unter anderem:

• Content Creator und Video-Produzenten
• Unternehmen mit Schulungs-, Support- und Marketingvideos
• Agenturen und Lokalisierungsteams
• Entwickler und KI-Enthusiasten
• Nutzer, die freie Hardwarewahl bevorzugen
• Teams, die lokal statt dauerhaft cloudabhängig arbeiten möchten

Lokale KI auf deiner Hardware nutzen
VANIV verbindet Spracherkennung, Übersetzung, Voice Cloning und Video-Dubbing in einem lokalen Workflow – auf AMD, Intel oder NVIDIA.
Lokale KI auf deiner Hardware testen →

Welche Hardware eignet sich für lokale KI?

Die richtige Hardware hängt von deinem Workflow ab

Dieser Artikel gibt bewusst nur eine Orientierung. Detaillierte Kaufberatung findest du in den VANIV-Hardware-Guides:

• Lokale KI Hardware: Welche Komponenten brauchst du?
• GPU für lokale KI: Grafikkarten und VRAM
• Wie viel RAM braucht lokale KI?
• CPU und System für lokale KI
• SSD für lokale KI und große Medienprojekte

Die Hardware-Übersicht führt dich von dort zu den ausführlichen RAM-, CPU- und SSD-Guides.

Häufige Fragen zu ONNX

Fazit: ONNX macht lokale KI hardwareflexibel

Zusammengefasst:

• ONNX macht trainierte KI-Modelle leichter austauschbar.
• ONNX Runtime lädt, optimiert und führt diese Modelle aus.
• Execution Provider verbinden die Runtime mit CPU, GPU oder NPU.

Das Ergebnis ist eine Architektur, die unterschiedliche Hardwarepfade für AMD, Intel und NVIDIA verwenden kann. Die Geschwindigkeit bleibt vom jeweiligen System abhängig, der grundlegende Workflow muss aber nicht für jeden Hersteller neu erfunden werden.

VANIV setzt genau darauf. Spracherkennung, Übersetzung, Text-to-Speech, Voice Cloning und Video-Dubbing werden in einem lokalen Workflow verbunden, der die vorhandene AMD-, Intel- oder NVIDIA-Hardware nutzt. Du wählst die Hardware, VANIV macht den Rest.

Lokale KI auf deiner eigenen Hardware nutzen
VANIV verbindet Audio-, Sprach- und Videoverarbeitung in einem lokalen Workflow – auf AMD, Intel oder NVIDIA.
Lokale KI auf deiner Hardware testen →

AMD, Intel, NVIDIA und die jeweiligen Marken sind Eigentum ihrer jeweiligen Inhaber. VANIV ist ein unabhängiges Produkt und steht in keiner geschäftlichen Verbindung zu diesen Unternehmen.