On-Device-AI: Lokale Inferenz mit ONNX Runtime

Warum lokal?

Fuer Live- und Broadcast-Setups ist Cloud-Inferenz oft der falsche Weg: Netzlatenz ist unberechenbar, Tokenkosten summieren sich, und Audio- oder Bildmaterial soll das Studio nicht verlassen. On-Device-Inferenz loest alle drei Probleme — wenn die Werkzeugkette stimmt.

Die gemeinsame Grundlage: ONNX

Beide geforkten Repositories bauen auf demselben Fundament. ONNX (Open Neural Network Exchange) ist das Austauschformat: Modelle aus PyTorch oder TensorFlow werden einmal konvertiert und laufen dann ueberall, wo eine ONNX Runtime existiert. Die Runtime waehlt pro Geraet einen Execution Provider — NPU, GPU (etwa via DirectML) oder CPU.

Windows Machine Learning (2018) war der erste Anlauf: eine Windows-Runtime-API ueber ONNX Runtime und DirectML, mit Samples von SqueezeNet bis YOLOv4 und Werkzeugen wie WinMLRunner (CLI-Validierung) und dem WinML Dashboard (Modellkonvertierung). Diese APIs sind heute durch die neue Windows-ML-Generation im Windows App SDK abgeloest.

Foundry Local (aktuell) ist die konsequente Weiterentwicklung: eine rund 20 MB grosse Runtime, die Modellbeschaffung, Caching, Versionierung und Hardware-Erkennung komplett uebernimmt. Native SDKs fuer C#, JavaScript, Python und Rust, dazu eine OpenAI-kompatible API — bestehender OpenAI-SDK-Code laeuft mit minimalen Aenderungen lokal.

Praktische Abgrenzung

Foundry Local ist fuer Single-User-Clients gebaut. Fuer Server-Szenarien mit vielen gleichzeitigen Nutzern sind Runtimes wie vLLM oder Triton die richtige Wahl — sie beherrschen Request-Queuing und Continuous Batching. Die Faustregel: Laeuft das Modell auf dem Geraet der Person, die es benutzt, ist Foundry Local passend; bedient es viele Personen gleichzeitig, gehoert es auf einen Inferenz-Server.

Relevanz fuer ARV

Der spannendste Pfad fuer dieses Archiv ist Whisper on-device: lokale Echtzeit-Transkription von Sets und Transmissions, ohne Audio in eine Cloud zu senden — als Grundlage fuer durchsuchbare Tracklists und Untertitel.