Electron oder Tauri 2 und Rust? Desktop-Architektur für lokale KI

Electron und Tauri 2 im Architekturvergleich: RAM, Startzeit und Paketgröße messen, die Sicherheitsgrenzen von Rust verstehen und reproduzierbare Benchmarks für lokale KI-Anwendungen planen.

In lokalen KI-Anwendungen konkurrieren Oberfläche, Inferenz-Engine und Modelle um die Ressourcen des Rechners. Das Framework beeinflusst den Aufbau einer Anwendung, bestimmt aber nicht allein deren Speicherverbrauch oder Verarbeitungsgeschwindigkeit.

1. Stand der Messungen

Dieser Artikel enthält keinen verifizierten Benchmark unserer Anwendungen. Frühere Angaben zu Speicherverbrauch, Startzeit, Installer-Größe und Kommunikationslatenz wurden entfernt, da Rohdaten, genaue Build-Versionen und ein reproduzierbares Szenario fehlten. Der folgende Vergleich beschreibt die Architektur; das Testprotokoll ist ein Vorschlag und kein Bericht über durchgeführte Messungen.

2. Was wir tatsächlich vergleichen

Tauri garantiert nicht automatisch einen geringeren RAM-Verbrauch oder einen schnelleren Start für jede Anwendung. KI-Engines, Modellgewichte und Hilfsprozesse müssen unabhängig von der Oberfläche berücksichtigt werden.

Oberfläche von Video2X Ultimate Manager

3. Grenzen der Sicherheit und der GPU-Anbindung

Die Regeln von Safe Rust verhindern bestimmte Speichersicherheitsfehler und Data Races – vorausgesetzt, die zugrunde liegenden unsafe-Abstraktionen sind korrekt. Sie garantieren jedoch nicht, dass keine Speicherlecks, Deadlocks oder Fehler in der Reihenfolge von Operationen auftreten. FFI, C/C++-Bibliotheken, Treiber und die Verwaltung von GPU-Puffern erfordern eine eigene Prüfung.

Ein nativer Aufruf allein belegt noch keine Zero-Copy-Verarbeitung. Transfers zwischen Prozessen sowie zwischen RAM und VRAM, der Besitz der Puffer (Ownership) und die Synchronisation müssen nachvollzogen werden. Die Übergabe einer rohen Speicheradresse aus der Oberfläche stellen wir hier nicht als fertige, sichere Lösung dar. Auch die Berechtigungen von Befehlen erfordern eine Prüfung der Konfiguration.

4. Vorgeschlagenes Benchmark-Protokoll

1. Anwendungsversion, Commit, Build-Modus (Release), Framework, Betriebssystem und WebView-Version, GPU-Treiber sowie CPU, RAM und GPU dokumentieren. Gleiche Funktionen mit identischen Modellen und Eingabedaten vergleichen, die per SHA-256-Prüfsumme verifiziert sind.
2. Leere Oberfläche, geladenes Modell und identische KI-Aufgabe getrennt testen. Als Ende des Starts den Zeitpunkt definieren, an dem die Oberfläche Befehle annehmen kann; die Modellbereitschaft separat messen.
3. Je 10 Kalt- und Warmstarts durchführen. Beschreiben, wie Umgebung und Cache zurückgesetzt werden, und beide Serien getrennt halten. Alle Durchläufe, Median und Spannweite dokumentieren – auch fehlgeschlagene.
4. Speicherverbrauch des gesamten Prozessbaums und Spitzenwert während der Aufgabe erfassen. Werkzeug, Version und verwendete Speichermetrik angeben; gemeinsam genutzten Speicher nicht doppelt zählen. VRAM getrennt ausweisen. Die Installer-Größe umfasst nicht automatisch später heruntergeladene Modelle und Abhängigkeiten.
5. Skripte, Befehle, CSV-Rohdaten und Logs zusammen mit der Konfiguration veröffentlichen. Erst dann Schlussfolgerungen ziehen – beschränkt auf die getestete Hardware und das getestete Szenario.

5. Unsere Produkte nach der Migration

Unser Katalog läuft heute auf Tauri 2: Video2X Ultimate Manager und AI File Sorter sind bereits von Electron auf Tauri umgestiegen. Die Ausnahme ist VideoSorterLocal – die aktuelle Version basiert auf PySide6, die Migration auf Tauri 2 läuft. Das oben beschriebene Protokoll bleibt dennoch gültig: Der Wechsel des Frameworks allein belegt noch keinen geringeren Speicherverbrauch oder schnelleren Start – das muss gemessen werden.

Technische Quellen

Die Dokumentation erläutert Architektur und Grenzen, belegt jedoch keine Leistungswerte unserer Anwendungen.

• Tauri: Architecture
• Electron: Process Model
• Rustonomicon: What Unsafe Can Do