{"id":37710,"date":"2026-06-24T10:03:28","date_gmt":"2026-06-24T10:03:28","guid":{"rendered":"https:\/\/lamarr-institute.org\/?post_type=blog&p=37710"},"modified":"2026-06-24T10:35:55","modified_gmt":"2026-06-24T10:35:55","slug":"optimierung-von-ki-modellen-fuer-hardware-in-der-praxis","status":"publish","type":"blog","link":"https:\/\/lamarr-institute.org\/de\/blog\/optimierung-von-ki-modellen-fuer-hardware-in-der-praxis\/","title":{"rendered":"Optimierung von KI-Modellen f\u00fcr Hardware in der Praxis"},"content":{"rendered":"\n

Da die aktuellen Entwicklungen im Bereich der KI tendenziell immer umfangreichere Systeme hervorbringen, k\u00f6nnte man leicht den Eindruck gewinnen, dass moderne KI-Anwendungen zwingend die neueste High-End-Hardware ben\u00f6tigen, 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\u00e4uft, h\u00e4ngt 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\u00e4t deutlich unterschiedliche Leistungsmerkmale aufweisen.<\/p>\n\n\n\n

Um das Potenzial solcher Modelloptimierungen, ihre Auswirkungen und ihre Funktionsweise \u201eunter der Haube\u201c zu veranschaulichen, greift dieser Blogbeitrag auf ein Beispiel aus der Praxis zur\u00fcck: eine kamerabasierte Echtzeit-Herzfrequenzsch\u00e4tzung.<\/p>\n\n\n\n


Modelloptimierung greifbar machen: Ein Live-Demonstrator<\/strong><\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Der Demonstrator selbst ist einfach aufgebaut: Eine Person sitzt vor einer gew\u00f6hnlichen Webcam, w\u00e4hrend ein KI-Modell ihr Gesicht erkennt, um subtile Ver\u00e4nderungen der Hautfarbe zu erfassen, die durch den Blutfluss unter der Haut verursacht werden. Obwohl diese Ver\u00e4nderungen f\u00fcr das menschliche Auge unsichtbar sind, lassen sie sich \u00fcber die Kamera messen. Anhand dieser Signale sch\u00e4tzt das System den Puls der Person.<\/p>\n\n\n\n

\"-<\/figure>\n\n\n\n

Auch wenn die kamerabasierte Pulssch\u00e4tzung in Echtzeit in diesem Artikel lediglich als Beispiel f\u00fcr die Auswirkungen der Modelloptimierung dient, ist sie doch ein spannendes Forschungsgebiet an sich, mit Anwendungsm\u00f6glichkeiten in der Intensivmedizin, der Gesundheits\u00fcberwachung und im Fitnessbereich. Anstatt zus\u00e4tzlicher am K\u00f6rper getragener Sensoren zu ben\u00f6tigen, l\u00e4sst sich der Puls anhand eines gew\u00f6hnlichen Kamerastroms sch\u00e4tzen, was eine kontinuierliche und kontaktlose \u00dcberwachung erm\u00f6glicht.<\/p>\n\n\n\n

Um die Auswirkungen der Modelloptimierung zu veranschaulichen, verf\u00fcgt der Demonstrator \u00fcber 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\u00fcr Echtzeitanwendungen besonders wichtig, da falsche Sch\u00e4tzungen zu sch\u00e4dlichen Entscheidungen f\u00fchren k\u00f6nnten. In unserem konkreten Fall: Wenn die Latenz zu hoch wird, st\u00fctzt sich das System m\u00f6glicherweise auf veraltete Kamerabilder, was das Risiko einer falschen Pulssch\u00e4tzung erh\u00f6ht.<\/p>\n\n\n\n

Die Gesichtsanalyse in diesem Demonstrator wird w\u00e4hrend des gesamten Prozesses von demselben Modell gest\u00fctzt. Der Demonstrator erm\u00f6glicht es Nutzer*innen jedoch, die Ausf\u00fchrungsumgebung, die \u00fcblicherweise als Backend<\/em> bezeichnet wird und das Modell ausf\u00fchrt, nahtlos zu wechseln.<\/p>\n\n\n\n


Was sind Inferenz-Backends?<\/h2>\n\n\n\n

Bevor wir uns mit den Einzelheiten befassen, sollten wir zun\u00e4chst 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\u00fccke zwischen dem KI-Modell und der physischen Hardware schl\u00e4gt.<\/p>\n\n\n\n

W\u00e4hrend das KI-Modell selbst als mathematischer Entwurf der erforderlichen Berechnungen beschrieben wird, ordnet das Backend diese Berechnungen den tats\u00e4chlichen Hardwarebefehlen zu. Dazu geh\u00f6ren 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\u00fchren sind.<\/p>\n\n\n\n

Ein anschauliches Beispiel ist die elementweise Vektormultiplikation. Dies ist eine grundlegende Operation, die in Machine-Learning-Workloads h\u00e4ufig vorkommt. Obwohl die mathematische Operation selbst immer dieselbe ist, h\u00e4ngt die Art und Weise ihrer Ausf\u00fchrung stark von der zugrunde liegenden Hardware ab. Auf einer CPU wird die Vektormultiplikation typischerweise von einer kleinen Anzahl sehr leistungsf\u00e4higer Kerne durchgef\u00fchrt. Auf einer GPU hingegen kann dieselbe Operation auf eine sehr gro\u00dfe Anzahl einfacherer Recheneinheiten verteilt werden, wodurch viele Elemente des Ergebnisvektors parallel berechnet werden k\u00f6nnen. Daher eignen sich CPUs im Allgemeinen besser f\u00fcr kleinere oder sequenzielle Aufgaben, w\u00e4hrend GPUs gut f\u00fcr gro\u00dfe, hochparallele Workloads wie Vektoroperationen geeignet sind. Je nach konkretem Anwendungsfall kann die Wahl der Hardware also einen gro\u00dfen Einfluss darauf haben, wie effizient dieselbe mathematische Operation ausgef\u00fchrt wird.<\/p>\n\n\n\n

\"-

Abbildung 1:<\/strong> Darstellung der elementweisen Vektormultiplikation auf CPU- und GPU-Hardware. Die CPU verarbeitet den Vektor sequenziell, w\u00e4hrend die GPU viele Vektorelemente gleichzeitig berechnet.<\/figcaption><\/figure>\n\n\n\n

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:<\/p>\n\n\n\n

    \n
  • PyTorch: Ist in der Regel f\u00fcr das Training von Deep-Learning-Modellen bekannt, unterst\u00fctzt nun aber auch eine effizientere Modellbereitstellung auf GPUs.<\/li>\n\n\n\n
  • ONNX Runtime: Ein standardisiertes Inferenz-Framework, das sich auf die Optimierung auf Graphenebene und die effiziente Ausf\u00fchrung auf verschiedenen Plattformen konzentriert.<\/li>\n\n\n\n
  • TensorRT: Ein Inferenz-Backend, das auf hardwareorientierte Optimierung spezialisiert ist, insbesondere f\u00fcr NVIDIA-GPUs.<\/li>\n<\/ul>\n\n\n\n


    Spezialisierte Backends f\u00fcr die Optimierung von KI-Modellen<\/h2>\n\n\n\n

    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\u00fchren und dieselbe Hardware nutzen, verhalten sie sich dennoch unterschiedlich. Der Grund daf\u00fcr ist, dass ein Modell der GPU nicht jeden einzelnen Low-Level-Schritt direkt mitteilt, den sie ausf\u00fchren muss. Stattdessen fungiert das Backend als \u00dcbersetzer zwischen dem Modell und der Hardware. Die \u00dcbersetzung liefert das gleiche Ergebnis, \u00fcbersetzt das Modell jedoch nicht auf genau dieselbe Weise in maschinenlesbaren Code. Dasselbe Modell kann \u00fcber unterschiedliche Abfolgen von Operationen, unterschiedliche Speicherlayouts und unterschiedliche GPU-Funktionen ausgef\u00fchrt werden. Einige Backends halten diesen Prozess allgemeiner und flexibler, w\u00e4hrend andere st\u00e4rker auf die Ausf\u00fchrung auf einer bestimmten Hardwareplattform spezialisiert sind.<\/p>\n\n\n\n

    Beispielsweise besteht ein Modell oft aus vielen kleineren Operationen, die nacheinander ausgef\u00fchrt werden. Ein allgemeines Backend f\u00fchrt diese Operationen m\u00f6glicherweise als separate Schritte aus. Ein spezialisierteres Backend erkennt m\u00f6glicherweise, dass einige dieser Schritte immer zusammen auftreten, und fasst sie intern zusammen, um unn\u00f6tige Bewegungen von Zwischenergebnissen durch den Speicher zu vermeiden. Dies macht die Berechnung effizienter, w\u00e4hrend das mathematische Ergebnis unver\u00e4ndert bleibt.<\/p>\n\n\n\n

    \"-

    Abbildung 2:<\/strong> Durchschnittliche FPS und Speicherauslastung des Demonstrators \u00fcber eine Laufzeit von f\u00fcnf Minuten f\u00fcr jedes Backend. Die Ergebnisse zeigen, dass die Wahl des Backends sowohl den Durchsatz als auch den Speicherverbrauch beeinflusst, obwohl das Modell und die Hardware unver\u00e4ndert bleiben.<\/figcaption><\/figure>\n\n\n\n

    Diese Unterschiede werden im Timing Monitor des Demonstrators sichtbar. Um die Auswirkungen zu quantifizieren, haben wir die durchschnittlichen FPS und die durchschnittliche Speicherauslastung \u00fcber eine Laufzeit von f\u00fcnf Minuten f\u00fcr jedes Backend gemessen.<\/p>\n\n\n\n


    Vergleich der KI-Modelloptimierung \u00fcber verschiedene Backends hinweg<\/h2>\n\n\n\n

    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\u00e4ndige Echtzeitf\u00e4higkeit des Demonstrators zu verbessern. Je nachdem, wie das Backend das Modell ausf\u00fchrt, kann ein geringerer Speicherverbrauch bei dieser spezifischen Konfiguration immer noch mit weniger g\u00fcnstigen Ausf\u00fchrungsoptionen einhergehen.<\/p>\n\n\n\n

    Durch den Einsatz von TensorRT l\u00e4sst sich der durchschnittliche Speicherbedarf sogar noch weiter auf 0,96 GB senken, w\u00e4hrend gleichzeitig fast die gleiche Bildrate wie bei PyTorch erreicht wird. Da der Demonstrator auf einem NVIDIA Jetson AGX Orin l\u00e4uft, kann TensorRT genauere Annahmen \u00fcber die verf\u00fcgbare Hardware treffen und speziell f\u00fcr diese Plattform entwickelte Optimierungen nutzen. In dieser Konfiguration erm\u00f6glicht dies TensorRT, den geringsten Speicherbedarf mit der nahezu h\u00f6chsten Bildrate zu kombinieren.<\/p>\n\n\n\n

    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\u00e4tzung, UI-Aktualisierungen und den Timing Monitor selbst. Da diese Komponenten w\u00e4hrend aller Messungen unver\u00e4ndert blieben, sind die Unterschiede zwischen den Backends im Kontext der gesamten Anwendung weiterhin sichtbar. Der isolierte Effekt auf die Modellinferenz k\u00f6nnte jedoch sogar noch st\u00e4rker sein, als die End-to-End-Messungen vermuten lassen, da Teile der gemessenen Laufzeit und des Speicherverbrauchs von allen Backends gemeinsam genutzt werden.<\/p>\n\n\n\n


    Die Bedeutung von Ausf\u00fchrungsstrategien f\u00fcr KI-Modelle<\/strong><\/h2>\n\n\n\n

    Der Demonstrator zeigt, dass die Leistung einer KI-Anwendung nicht feststeht, sobald das Modell und die Hardware ausgew\u00e4hlt sind. Selbst ohne \u00c4nderung der Modellarchitektur oder des Ger\u00e4ts kann die Art und Weise, wie das Modell ausgef\u00fchrt wird, das Verhalten des Systems sp\u00fcrbar ver\u00e4ndern.<\/p>\n\n\n\n

    Dies bringt uns zum Ausgangspunkt zur\u00fcck: Bei der Leistung moderner KI geht es nicht nur darum, leistungsst\u00e4rkere Hardware oder gr\u00f6\u00dfere Modelle einzusetzen, sondern auch darum, die verf\u00fcgbare Hardware bestm\u00f6glich zu nutzen. In unserem Fall machte der Backend-Vergleich deutlich, dass sich dasselbe Modell zur Herzfrequenzsch\u00e4tzung je nach Ausf\u00fchrungsweise auf dem Zielger\u00e4t unterschiedlich verhielt. Dies ist besonders f\u00fcr Echtzeitanwendungen relevant. Wenn die Latenz zu hoch wird, reagiert das System m\u00f6glicherweise auf veraltete Eingabedaten, was sich direkt auf die Zuverl\u00e4ssigkeit des gesch\u00e4tzten Ergebnisses auswirken kann. In kritischeren realen Szenarien k\u00f6nnten solche Zuverl\u00e4ssigkeitsprobleme schwerwiegende Folgen haben und im schlimmsten Fall sogar Menschen Schaden zuf\u00fcgen.<\/p>\n\n\n\n

    Daher sollte die Optimierung nicht als abschlie\u00dfender 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\u00dfstab: Das Modell blieb dasselbe, die Hardware blieb dieselbe, aber die Ausf\u00fchrungsstrategie bestimmte, wie benutzerfreundlich und zuverl\u00e4ssig das System wurde.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Bei der KI-gest\u00fctzten Auswertung von Herzmessdaten z\u00e4hlen Geschwindigkeit, Energieeffizienz und Zuverl\u00e4ssigkeit. Der Blogbeitrag erl\u00e4utert, wie die gezielte Optimierung von KI-Modellen f\u00fcr reale Hardwareplattformen dazu beitr\u00e4gt, medizinische Anwendungen leistungsf\u00e4hig und alltagstauglich zu machen.<\/p>\n","protected":false},"author":14,"featured_media":37702,"template":"","meta":{"_acf_changed":false,"footnotes":""},"blog-category":[1416,390,1664],"blog-tag":[],"class_list":["post-37710","blog","type-blog","status-publish","has-post-thumbnail","hentry","blog-category-alle-blogbeitraege","blog-category-grundlagen","blog-category-ki-in-gesundheit-medizin"],"acf":[],"publishpress_future_workflow_manual_trigger":{"enabledWorkflows":[]},"_links":{"self":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog\/37710","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/users\/14"}],"version-history":[{"count":0,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog\/37710\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/media\/37702"}],"wp:attachment":[{"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/media?parent=37710"}],"wp:term":[{"taxonomy":"blog-category","embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog-category?post=37710"},{"taxonomy":"blog-tag","embeddable":true,"href":"https:\/\/lamarr-institute.org\/de\/wp-json\/wp\/v2\/blog-tag?post=37710"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}