nndeploy: Workflow-Graph statt Klebeband für die Modell-Deployung

Welches Problem nndeploy adressiert

Ein trainiertes Modell ist selten das Produkt. Zwischen Gewichten und lauffähiger Anwendung liegen Vorverarbeitung, Modellinferenz, Nachverarbeitung, oft mehrere Modelle in einer Kette, und dazu die Frage, auf welcher Hardware das Ganze laufen soll. nndeploy setzt genau an dieser Stelle an: Das Projekt beschreibt sich selbst als Framework für die Deployung von AI-Algorithmen auf Desktop (Windows, macOS), Mobile (Android, iOS), Edge-Geräten wie NVIDIA Jetson, Ascend310B und Rockchip sowie auf Servern mit RTX-Karten, T4 oder Ascend310P.

Der zweite Adressat ist deutlicher abgegrenzt. Für Modelle oberhalb von 10B Parametern, also große Sprachmodelle und generative Bildmodelle, empfiehlt das README nndeploy ausdrücklich als visuelles Workflow-Werkzeug. Das ist eine Positionsbestimmung, die man ernst nehmen sollte: Der Nutzen liegt dort im Zusammenstecken und Abstimmen einer mehrstufigen Generierungskette, nicht im Ersetzen einer Trainings- oder Serving-Infrastruktur.

Der Graph als zentrale Datenstruktur

Kern des Entwurfs ist ein Workflow aus Knoten. Jeder Knoten kapselt einen Verarbeitungsschritt, die Kanten tragen die Daten zwischen ihnen. Das README beschreibt diesen Graphen als visuell editierbar: Knoten werden per Drag and Drop platziert, Parameter lassen sich zur Laufzeit verändern, und das Ergebnis ist unmittelbar sichtbar. Entscheidend für den Produktivbetrieb ist der zweite Teil: Der Workflow lässt sich als JSON exportieren und danach über eine C++- oder Python-API laden. Die grafische Oberfläche ist damit ein Autorierungswerkzeug, nicht die Laufzeitumgebung.

Knoten müssen nicht aus dem mitgelieferten Vorrat stammen. Das Projekt nennt Python- und C++-Knoten als Erweiterungspunkt, wobei der C++-Pfad ausdrücklich auch CUDA und Ascend C einschließt. Wer eine Vorverarbeitung in Python prototypisiert und später durch eine SIMD- oder CUDA-Variante ersetzt, ändert damit nicht die Graphstruktur, sondern nur die Implementierung des Knotens.

Für die Ausführung nennt das README drei Modi: seriell, Pipeline-parallel und task-parallel. Auf der Speicherseite stehen Zero-Copy, ein Speicherpool und Speicherwiederverwendung. Das sind keine Nebenbemerkungen, sondern die eigentliche Rechtfertigung des Frameworks. Ein Graph, der Zwischenpuffer zwischen Knoten kopiert, verliert auf Edge-Hardware mehr Leistung als jede Backend-Auswahl gewinnt. Ob diese Optimierungen im Einzelfall greifen, hängt jedoch an der Implementierung des jeweiligen Knotens, und dazu macht das README keine Zusagen.

Dreizehn Backends und was die Tabelle verschweigt

nndeploy integriert laut README dreizehn Inferenz-Backends. Die Liste umfasst ONNXRuntime, TensorRT, OpenVINO, MNN, TNN, ncnn, CoreML, AscendCL, RKNN, SNPE, TVM, PyTorch und ein internes Inferenz-Submodul. Alle sind in der Tabelle als verfügbar markiert.

Diese Breite ist der auffälligste Unterschied zu Frameworks, die eine Engine bevorzugen. Sie hat aber einen Preis, den die Tabelle nicht zeigt: Jedes Backend bringt eigene Abhängigkeiten, eigene Werkzeugketten und eigene Versionskonflikte mit. Das README greift das auf und verweist auf kompilierbare Auswahl: Der Nutzer soll entscheiden können, welche Engines überhaupt gebaut werden, um Abhängigkeiten zu reduzieren. Zusätzlich nennt das Projekt einen eigenständigen Betriebsmodus, in dem ein selbst mitgebrachtes Inferenz-Framework angebunden wird, ohne die übrigen Integrationen zu kompilieren.

Wer die Backend-Liste liest, sollte sie deshalb als Menü verstehen, nicht als Zusage. Ob TensorRT auf der Zielmaschine sinnvoll ist oder ob RKNN auf dem Rockchip-Board die richtige Wahl darstellt, entscheidet die eigene Hardware, nicht die Häkchenspalte.

Mitgelieferte Modelle und die Grenze der Liste

Das Projekt liefert nach eigener Angabe über 100 visuelle Knoten und eine Reihe bereits umgesetzter Modellketten. Genannt werden Sprachmodelle (QWen-2.5, QWen-3, mit dem Hinweis auf kleine B-Varianten), Bild- und Videogenerierung über diffusers (Stable Diffusion 1.5, SDXL, SD 3, HunyuanDiT, mit Text-zu-Bild, Bild-zu-Bild und Inpainting), Face Swapping über deep-live-cam, Paddle OCR, Objektdetektion von YOLOv5 bis YOLOv11 einschließlich YOLOx, Objektverfolgung mit FairMot, Segmentierung (RBMGv1.4, PPMatting, Segment Anything), Klassifikation mit ResNet, MobileNet, EfficientNet, PPLcNet, GhostNet, ShuffleNet und SqueezeNet sowie API-Dienste für OPENAI, DeepSeek und Moonshot.

Bemerkenswert ist die Begründung, die das README für diese Sammlung gibt: Mit wachsender Knotenzahl steige die Wiederverwendbarkeit, was die Kosten der nächsten Deployung senke. Das ist ein ehrliches Argument für ein Framework, das sich über einen Katalog definiert. Es hat aber eine Kehrseite. Die genannten Modelle sind Beispiele, keine Zusage für das eigene Netz. Ein Modell, das nicht in der Liste steht, bedeutet eigene Knotenarbeit, und die Qualität dieser Arbeit entscheidet über die Leistung der gesamten Kette.

Build und Inbetriebnahme

nndeploy ist ein CMake-Projekt in C++. Der Quellcode wird geklont, danach folgen Konfiguration und Build über CMake. Aus dem Repository-Layout und den Release-Angaben ergibt sich, dass die Versionen als Tags wie v3.0.10 vorliegen; die letzten drei Releases stammen vom April 2026 (v3.0.10 und v3.0.9) sowie vom Dezember 2025 (v3.0.8). Ein Build aus einem festen Tag ist damit möglich und gegenüber dem Hauptzweig die naheliegende Wahl.

Für Android existiert ein eigener Pfad: Das README verlinkt unter app/android/README.md eine Anleitung zur mobilen Deployung. Dort liegen auch die Screenshots der Android-Anwendung. Wer auf Android zielt, sollte diesen Pfad getrennt vom Desktop-Build behandeln, weil die Werkzeugkette eine andere ist.

Die Python-Anbindung ist Teil des Projekts, das README nennt eine C++- und eine Python-API zum Laden exportierter Workflows. Das Paket ist auf PyPI auffindbar; der entsprechende Download-Badge ist im README allerdings auskommentiert, ein Hinweis darauf, dass der Python-Vertrieb nicht der primäre Kanal ist.

Der wichtigste Konfigurationsschritt ist die Backend-Auswahl. Sie geschieht über CMake-Schalter, deren genaue Namen das README nicht auflistet. Wer das Projekt evaluiert, sollte diese Namen in der Dokumentation unter nndeploy-zh.readthedocs.io nachschlagen, bevor er den ersten Build startet, statt alle Engines zu aktivieren und anschließend Abhängigkeitsfehler zu sortieren.

Wo nndeploy die falsche Wahl ist

Die offensichtlichste Grenze ist der Umfang. Ein Team, das ein einzelnes ONNX-Modell auf einem Linux-Server hinter einer HTTP-Schnittstelle ausliefern möchte, braucht keinen Graph-Editor, keine dreizehn Backends und keinen C++-Build. Der direkte Weg über die ONNX-Runtime oder einen Python-Serving-Stack ist in diesem Fall kürzer, hat weniger bewegliche Teile und ist für neue Teammitglieder schneller zu verstehen.

Die zweite Grenze betrifft die Reife der Einzelintegrationen. Das README markiert alle Backends als verfügbar, liefert aber keine Aussage darüber, wie vollständig die jeweilige Anbindung ist oder welche Operator-Abdeckung sie erreicht. Wer ein ungewöhnliches Modell mit exotischen Operatoren auf RKNN oder SNPE bringen will, kann aus dem Repository allein nicht ableiten, ob das gelingt. Diese Frage lässt sich nur durch einen Test auf der Zielhardware beantworten.

Drittens ist der Autorierungsworkflow selbst eine Abhängigkeit. Wer Pipelines ausschließlich programmatisch beschreibt und versioniert, gewinnt durch einen GUI-Editor wenig und verliert die Möglichkeit, den Graphen in einem Code-Review zu lesen. Der JSON-Export mildert das ab, ersetzt aber kein textuelles Pipeline-Format.

Der Vergleich mit ONNX Runtime allein

Die naheliegende Alternative ist der Verzicht auf ein Framework: ONNX Runtime direkt einbinden, Vor- und Nachverarbeitung in der Anwendung schreiben, pro Zielplattform getrennt bauen. Der Unterschied liegt nicht in der Geschwindigkeit der Inferenz, sondern in der Struktur. ONNX Runtime führt ein Modell aus, nndeploy beschreibt eine Kette. Sobald mehrere Modelle hintereinander laufen, Zwischenergebnisse über Puffer wandern und dieselbe Kette auf Desktop und Mobile laufen soll, muss die Anwendung bei der direkten Anbindung selbst leisten, was nndeploy als Graph modelliert: Ausführungsreihenfolge, Pufferverwaltung, Backend-Auswahl.

Der zweite Unterschied ist die Plattformabdeckung. ONNX Runtime deckt einen Teil der genannten Ziele ab, aber nicht AscendCL, RKNN oder SNPE. Wer diese Geräte bedienen muss, schreibt bei direkter Anbindung pro Backend eine eigene Integrationsschicht. nndeploy nimmt diese Schicht ab, verlangt dafür aber, dass man sein Graphmodell übernimmt.

Der dritte Unterschied ist die Sprache. nndeploy ist in C++ geschrieben und mit CUDA-, Ascend-C- und SIMD-Knoten ausgestattet. Für Teams, die ohnehin in C++ arbeiten, ist das ein Vorteil. Für Python-zentrierte Teams bedeutet es, dass der Kern außerhalb der gewohnten Werkzeugkette liegt, auch wenn eine Python-API existiert.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Die Release-Historie zeigt ein Muster, das man kennen sollte: v3.0.8 im Dezember 2025, dann v3.0.9 und v3.0.10 am selben Tag im April 2026. Zwei Tags an einem Tag deuten auf eine kurzfristige Korrektur hin. Das ist kein Qualitätsurteil, aber ein Hinweis darauf, dass innerhalb einer Minor-Version nachgelegt wird und man nicht jeden Tag als stabilen Stand behandeln sollte. Der letzte Push ins Repository datiert auf August 2026, das Projekt ist also aktiv und nicht archiviert.

Die Wartungslast liegt beim Nutzer an zwei Stellen. Erstens bei den Backend-Abhängigkeiten: Jede Engine, die man einkompiliert, bringt eigene Versionsanforderungen mit, und ein Upgrade des Frameworks kann ein Upgrade der Engines nach sich ziehen. Wer nur ein Backend aktiviert, hält diesen Aufwand klein. Zweitens bei den eigenen Knoten: Selbstgeschriebene C++-, CUDA- oder Ascend-C-Knoten müssen bei API-Änderungen im Framework nachgezogen werden.

Lizenzseitig steht nndeploy unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber die Beibehaltung der Lizenzhinweise und enthält eine ausdrückliche Patentgewährung. Wichtig ist, dass diese Lizenz nur das Framework selbst betrifft. Die einkompilierten Backends und die mitgelieferten Modellimplementierungen haben eigene Lizenzen, und gerade bei generativen Modellen und Face-Swapping-Anwendungen sind die Gewichtslizenzen oft restriktiver als der Code. Das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenzprüfung pro Backend und pro Modell erfolgen muss.

Vor einem Einsatz sollte man drei Dinge konkret verifizieren: ob die eigene Zielhardware in der Backend-Tabelle auftaucht, ob das eigene Modell in der Liste der umgesetzten Ketten steht oder eigene Knotenarbeit erfordert, und ob der Build mit abgeschalteten Backends auf dem Zielsystem durchläuft. Der dritte Punkt ist der aufschlussreichste, weil er zeigt, wie viel Abhängigkeitsballast das Projekt in der eigenen Umgebung tatsächlich hinterlässt.

Redaktionelles Fazit

Wer Pipelines für mehrere Plattformen pflegt und die Graph-Struktur lieber einmal beschreibt als pro Zielgerät neu zu schreiben, findet in nndeploy ein passendes Gerüst. Wer nur ein einzelnes ONNX-Modell auf einem Server ausliefern will, trägt mit dem vollständigen Build mehr Abhängigkeiten ein als nötig. Vor dem ersten Commit sollte man prüfen, ob die eigene Zielplattform in der Backend-Tabelle auftaucht, ob die Modellliste das eigene Netz enthält und ob der Build mit abgeschalteten Backends auf dem Zielsystem durchläuft.

Offizielle Quellen

1. License: Apache-2.0
2. nndeploy/nndeploy on GitHub
3. Project website
4. README
5. Releases