Optimierung von KI-Modellen für Hardware in der Praxis

Da die aktuellen Entwicklungen im Bereich der KI tendenziell immer umfangreichere Systeme hervorbringen, könnte man leicht den Eindruck gewinnen, dass moderne KI-Anwendungen zwingend die neueste High-End-Hardware benötigen, um effizient zu laufen. In der Praxis ist die reine Rechenleistung der Hardware jedoch nur ein Teil der Gleichung. Ob eine KI-Anwendung in einer realen Umgebung gut läuft, hängt ebenso davon ab, wie gut das Modell und seine Implementierung an die Zielhardware angepasst sind. Mit den richtigen Optimierungsstrategien kann dasselbe Modell auf demselben Gerät deutlich unterschiedliche Leistungsmerkmale aufweisen.

Um das Potenzial solcher Modelloptimierungen, ihre Auswirkungen und ihre Funktionsweise „unter der Haube“ zu veranschaulichen, greift dieser Blogbeitrag auf ein Beispiel aus der Praxis zurück: eine kamerabasierte Echtzeit-Herzfrequenzschätzung.

Modelloptimierung greifbar machen: Ein Live-Demonstrator

Um die eher abstrakten Optimierungskonzepte sichtbar zu machen, haben wir einen interaktiven Live-Demonstrator entwickelt. Dabei ist zu beachten, dass es sich hierbei in erster Linie um eine technische Demonstration und nicht um ein fertiges Produkt handelt.

Der Demonstrator selbst ist einfach aufgebaut: Eine Person sitzt vor einer gewöhnlichen Webcam, während ein KI-Modell ihr Gesicht erkennt, um subtile Veränderungen der Hautfarbe zu erfassen, die durch den Blutfluss unter der Haut verursacht werden. Obwohl diese Veränderungen für das menschliche Auge unsichtbar sind, lassen sie sich über die Kamera messen. Anhand dieser Signale schätzt das System den Puls der Person.

Auch wenn die kamerabasierte Pulsschätzung in Echtzeit in diesem Artikel lediglich als Beispiel für die Auswirkungen der Modelloptimierung dient, ist sie doch ein spannendes Forschungsgebiet an sich, mit Anwendungsmöglichkeiten in der Intensivmedizin, der Gesundheitsüberwachung und im Fitnessbereich. Anstatt zusätzlicher am Körper getragener Sensoren zu benötigen, lässt sich der Puls anhand eines gewöhnlichen Kamerastroms schätzen, was eine kontinuierliche und kontaktlose Überwachung ermöglicht.

Um die Auswirkungen der Modelloptimierung zu veranschaulichen, verfügt der Demonstrator über einen Timing-Monitor. Dieses Dashboard erfasst Leistungsstatistiken, darunter den Gesamtenergieverbrauch, die Bildrate (Frames per Second, FPS) und die Latenz der Gesichtserkennung sowie der Modellinferenz. Die Latenz ist für Echtzeitanwendungen besonders wichtig, da falsche Schätzungen zu schädlichen Entscheidungen führen könnten. In unserem konkreten Fall: Wenn die Latenz zu hoch wird, stützt sich das System möglicherweise auf veraltete Kamerabilder, was das Risiko einer falschen Pulsschätzung erhöht.

Die Gesichtsanalyse in diesem Demonstrator wird während des gesamten Prozesses von demselben Modell gestützt. Der Demonstrator ermöglicht es Nutzer*innen jedoch, die Ausführungsumgebung, die üblicherweise als Backend bezeichnet wird und das Modell ausführt, nahtlos zu wechseln.

Was sind Inferenz-Backends?

Bevor wir uns mit den Einzelheiten befassen, sollten wir zunächst beschreiben, was ein Inferenz-Backend eigentlich ist. In unserem Kontext ist ein Backend (manchmal auch als Inferenz-Engine bezeichnet) die Software-Schicht, die eine Brücke zwischen dem KI-Modell und der physischen Hardware schlägt.

Während das KI-Modell selbst als mathematischer Entwurf der erforderlichen Berechnungen beschrieben wird, ordnet das Backend diese Berechnungen den tatsächlichen Hardwarebefehlen zu. Dazu gehören die Planung der Operationen auf dem Hauptprozessor (CPU) und dem Grafikprozessor (GPU) sowie die Zuweisung des erforderlichen Speichers. Im Wesentlichen gibt der Entwurf vor, was zu tun ist, und das Backend teilt der Hardware mit, wie diese Aufgaben auszuführen sind.

Ein anschauliches Beispiel ist die elementweise Vektormultiplikation. Dies ist eine grundlegende Operation, die in Machine-Learning-Workloads häufig vorkommt. Obwohl die mathematische Operation selbst immer dieselbe ist, hängt die Art und Weise ihrer Ausführung stark von der zugrunde liegenden Hardware ab. Auf einer CPU wird die Vektormultiplikation typischerweise von einer kleinen Anzahl sehr leistungsfähiger Kerne durchgeführt. Auf einer GPU hingegen kann dieselbe Operation auf eine sehr große Anzahl einfacherer Recheneinheiten verteilt werden, wodurch viele Elemente des Ergebnisvektors parallel berechnet werden können. Daher eignen sich CPUs im Allgemeinen besser für kleinere oder sequenzielle Aufgaben, während GPUs gut für große, hochparallele Workloads wie Vektoroperationen geeignet sind. Je nach konkretem Anwendungsfall kann die Wahl der Hardware also einen großen Einfluss darauf haben, wie effizient dieselbe mathematische Operation ausgeführt wird.

Je nach verwendeter Hardware wirkt sich der Wechsel zwischen den Backends auf die Hardwareauslastung und damit auf die Nutzbarkeit des Demonstrators aus. In unseren Demonstrator haben wir drei verschiedene Backends integriert:

• PyTorch: Ist in der Regel für das Training von Deep-Learning-Modellen bekannt, unterstützt nun aber auch eine effizientere Modellbereitstellung auf GPUs.
• ONNX Runtime: Ein standardisiertes Inferenz-Framework, das sich auf die Optimierung auf Graphenebene und die effiziente Ausführung auf verschiedenen Plattformen konzentriert.
• TensorRT: Ein Inferenz-Backend, das auf hardwareorientierte Optimierung spezialisiert ist, insbesondere für NVIDIA-GPUs.

Spezialisierte Backends für die Optimierung von KI-Modellen

Die Statistiken im Timing Monitor zeigen die gemessenen Auswirkungen der Optimierungen auf die Hardware. Dadurch lassen sich die Auswirkungen der Optimierung auch vergleichen. Obwohl alle drei Backends dasselbe Modell ausführen und dieselbe Hardware nutzen, verhalten sie sich dennoch unterschiedlich. Der Grund dafür ist, dass ein Modell der GPU nicht jeden einzelnen Low-Level-Schritt direkt mitteilt, den sie ausführen muss. Stattdessen fungiert das Backend als Übersetzer zwischen dem Modell und der Hardware. Die Übersetzung liefert das gleiche Ergebnis, übersetzt das Modell jedoch nicht auf genau dieselbe Weise in maschinenlesbaren Code. Dasselbe Modell kann über unterschiedliche Abfolgen von Operationen, unterschiedliche Speicherlayouts und unterschiedliche GPU-Funktionen ausgeführt werden. Einige Backends halten diesen Prozess allgemeiner und flexibler, während andere stärker auf die Ausführung auf einer bestimmten Hardwareplattform spezialisiert sind.

Beispielsweise besteht ein Modell oft aus vielen kleineren Operationen, die nacheinander ausgeführt werden. Ein allgemeines Backend führt diese Operationen möglicherweise als separate Schritte aus. Ein spezialisierteres Backend erkennt möglicherweise, dass einige dieser Schritte immer zusammen auftreten, und fasst sie intern zusammen, um unnötige Bewegungen von Zwischenergebnissen durch den Speicher zu vermeiden. Dies macht die Berechnung effizienter, während das mathematische Ergebnis unverändert bleibt.

Diese Unterschiede werden im Timing Monitor des Demonstrators sichtbar. Um die Auswirkungen zu quantifizieren, haben wir die durchschnittlichen FPS und die durchschnittliche Speicherauslastung über eine Laufzeit von fünf Minuten für jedes Backend gemessen.

Vergleich der KI-Modelloptimierung über verschiedene Backends hinweg

Im Vergleich zu PyTorch reduziert ONNX Runtime die durchschnittliche Speicherauslastung von 1,36 GB auf 1,13 GB. In unserem Demonstrator geht dies jedoch mit einem geringeren durchschnittlichen Durchsatz von 23,27 FPS einher, verglichen mit 28,45 FPS bei PyTorch. Dies deutet darauf hin, dass eine Reduzierung des Speicherverbrauchs allein nicht ausreicht, um die vollständige Echtzeitfähigkeit des Demonstrators zu verbessern. Je nachdem, wie das Backend das Modell ausführt, kann ein geringerer Speicherverbrauch bei dieser spezifischen Konfiguration immer noch mit weniger günstigen Ausführungsoptionen einhergehen.

Durch den Einsatz von TensorRT lässt sich der durchschnittliche Speicherbedarf sogar noch weiter auf 0,96 GB senken, während gleichzeitig fast die gleiche Bildrate wie bei PyTorch erreicht wird. Da der Demonstrator auf einem NVIDIA Jetson AGX Orin läuft, kann TensorRT genauere Annahmen über die verfügbare Hardware treffen und speziell für diese Plattform entwickelte Optimierungen nutzen. In dieser Konfiguration ermöglicht dies TensorRT, den geringsten Speicherbedarf mit der nahezu höchsten Bildrate zu kombinieren.

Dabei ist zu beachten, dass diese Messungen die gesamte Demonstrator-Pipeline beschreiben und nicht nur die isolierte Modellinferenz. Sie umfassen auch Komponenten wie Gesichtserkennung, BPM-Berechnung, Herzfrequenzschätzung, UI-Aktualisierungen und den Timing Monitor selbst. Da diese Komponenten während aller Messungen unverändert blieben, sind die Unterschiede zwischen den Backends im Kontext der gesamten Anwendung weiterhin sichtbar. Der isolierte Effekt auf die Modellinferenz könnte jedoch sogar noch stärker sein, als die End-to-End-Messungen vermuten lassen, da Teile der gemessenen Laufzeit und des Speicherverbrauchs von allen Backends gemeinsam genutzt werden.

Die Bedeutung von Ausführungsstrategien für KI-Modelle

Der Demonstrator zeigt, dass die Leistung einer KI-Anwendung nicht feststeht, sobald das Modell und die Hardware ausgewählt sind. Selbst ohne Änderung der Modellarchitektur oder des Geräts kann die Art und Weise, wie das Modell ausgeführt wird, das Verhalten des Systems spürbar verändern.

Dies bringt uns zum Ausgangspunkt zurück: Bei der Leistung moderner KI geht es nicht nur darum, leistungsstärkere Hardware oder größere Modelle einzusetzen, sondern auch darum, die verfügbare Hardware bestmöglich zu nutzen. In unserem Fall machte der Backend-Vergleich deutlich, dass sich dasselbe Modell zur Herzfrequenzschätzung je nach Ausführungsweise auf dem Zielgerät unterschiedlich verhielt. Dies ist besonders für Echtzeitanwendungen relevant. Wenn die Latenz zu hoch wird, reagiert das System möglicherweise auf veraltete Eingabedaten, was sich direkt auf die Zuverlässigkeit des geschätzten Ergebnisses auswirken kann. In kritischeren realen Szenarien könnten solche Zuverlässigkeitsprobleme schwerwiegende Folgen haben und im schlimmsten Fall sogar Menschen Schaden zufügen.

Daher sollte die Optimierung nicht als abschließender Feinschliff nach der Entwicklung eines Modells betrachtet werden. Vielmehr ist sie ein wesentlicher Bestandteil der Umsetzung von KI-Anwendungen auf realer Hardware. Der Demonstrator veranschaulicht dies im kleinen Maßstab: Das Modell blieb dasselbe, die Hardware blieb dieselbe, aber die Ausführungsstrategie bestimmte, wie benutzerfreundlich und zuverlässig das System wurde.