Die Auswirkungen des schnelleren Edge-First-Designs von Ultralytics YOLO26

Anfang dieser Woche hat Ultralytics offiziell Ultralytics YOLO26 vorgestellt, ein schnelleres, leichteres und kompakteres YOLO-Modell, das darauf abzielt, die Leistung von Computer-Vision-Systemen am Edge neu zu definieren. YOLO26 unterstützt dieselben zentralen Vision-Aufgaben wie frühere YOLO-Modelle, einschließlich Objekterkennung und Instanzsegmentierung.

Abb. 1: Ein Beispiel für die Verwendung von YOLO26 zur Segmentierung eines Objekts.

Der entscheidende Unterschied zwischen YOLO26 und früheren Modellen liegt in der Umgebung, für die es konzipiert wurde. Anstatt in erster Linie auf Cloud-GPUs oder benchmark-orientierte Leistung zu optimieren, wurde YOLO26 von Grund auf für den realen Einsatz auf Edge-Geräten und eingebetteter Hardware entwickelt.

Während sich Computer Vision von der Forschung in die Produktion verlagert, werden die Realitäten der Leistungsbeschränkungen immer deutlicher. Edge-Umgebungen sind durch enge Latenzbudgets, begrenzten Speicher, Strom- und Wärmebeschränkungen sowie die Notwendigkeit eines vorhersagbaren Verhaltens über verschiedene Plattformen hinweg geprägt.

In diesen Umgebungen hängt die Gesamtleistung des Systems nicht nur von der reinen Inferenzgeschwindigkeit ab, sondern auch davon, wie effizient die gesamte Pipeline arbeitet. Post-Processing-Overhead, Speicherauslastung und plattformspezifische Ausführungspfade sind oft Engpässe.

YOLO26 begegnet diesen Herausforderungen mit einem schnelleren Edge-first-Ansatz, der die gesamte Inferenz-Pipeline betrachtet, anstatt nur einzelne Modellmetriken. Durch die Fokussierung auf Edge-Optimierung, die Vereinfachung der Inferenz-Pipeline und den Verzicht auf unnötige Post-Processing-Schritte liefert YOLO26 Geschwindigkeitsverbesserungen, die in der Produktion zu geringerer Latenz und zuverlässigerem Verhalten führen.

In diesem Artikel untersuchen wir, wie sich die architektonischen Entscheidungen von YOLO26 in reale Leistungsverbesserungen übersetzen und warum eine höhere Geschwindigkeit am Edge die Möglichkeiten für Computer-Vision-Anwendungen der nächsten Generation grundlegend verändert.

Link to this sectionDie Realität des Edge-Deployments#

Das Ausführen von Computer-Vision-Modellen am Edge unterscheidet sich grundlegend vom Ausführen in der Cloud. In Cloud-Umgebungen haben Systeme normalerweise Zugriff auf leistungsstarke GPUs, große Speichermengen und stabile Hardware. Am Edge gelten diese Annahmen nicht.

Die meisten Edge-Deployments laufen auf diversen Hardware-Architekturen, nicht auf GPUs. Geräte nutzen normalerweise mehrere spezialisierte Prozessoren für verschiedene Aufgaben, die auf Effizienz und geringen Stromverbrauch optimiert sind, anstatt auf die reine Rechenleistung von Cloud-GPUs.

Latenz ist eine weitere wichtige Einschränkung. Edge-Systeme arbeiten oft unter engen Echtzeit-Grenzen, bei denen selbst kleine Verzögerungen die Reaktionsfähigkeit oder Sicherheit beeinträchtigen können. In diesen Fällen zählt die End-to-End-Latenz mehr als die reine Inferenzgeschwindigkeit. Ein Modell kann auf dem Papier schnell sein, aber dennoch schwächeln, sobald Post-Processing und Datenbewegungen hinzukommen.

Auch der Speicher spielt eine große Rolle. Viele Edge-Geräte verfügen über begrenzten Speicher und geteilte Caches. Große Zwischentensoren und ineffiziente Speichernutzung können Systeme verlangsamen, selbst wenn das Modell selbst effizient ist.

Strom- und Wärmegrenzen stellen weitere Einschränkungen dar. Edge-Geräte laufen oft ohne aktive Kühlung und innerhalb fester Strombudgets. Die Leistung muss effizient und nachhaltig sein, nicht nur in kurzen Schüben schnell.

Darüber hinaus erfordern Edge-Deployments Konsistenz. Modelle müssen sich über Geräte und Runtimes hinweg gleich verhalten. Plattformspezifischer Code oder komplexe Post-Processing-Schritte können subtile Unterschiede einführen, die die Bereitstellung und Wartung von Systemen erschweren.

Abb. 2: Ein Blick auf die Einschränkungen beim Edge-Deployment. Bild vom Autor.

Diese Einschränkungen definieren, was Leistung am Edge wirklich bedeutet. Mit anderen Worten: Die Leistung wird durch die gesamte Pipeline definiert, nicht durch eine einzelne Metrik.

Link to this sectionWarum Edge-Vision ein anderes Leistungsmodell erfordert#

Wie hängen also die Einschränkungen des Edge-Deployments mit den Anforderungen eines für den Edge entwickelten Computer-Vision-Modells zusammen? Der Zusammenhang wird klar, sobald Modelle aus der Forschung in reale Systeme überführt werden.

In Cloud-Umgebungen wird die Leistung oft anhand von Benchmarks wie Inferenzgeschwindigkeit und Genauigkeit gemessen. Am Edge erzählen diese Metriken nur einen Teil der Geschichte. Vision-Systeme laufen typischerweise auf heterogener Hardware, bei der die neuronale Netzwerkinferenz an spezialisierte Beschleuniger ausgelagert wird, während andere Teile der Pipeline auf Allzweckprozessoren laufen.

In diesem Kontext reicht die Modellgeschwindigkeit allein nicht aus. Entscheidend ist, wie das gesamte System funktioniert, sobald das Modell bereitgestellt wurde. Ein Modell kann für sich genommen schnell erscheinen, aber dennoch schwächeln, wenn Post-Processing, Datenbewegungen oder plattformspezifische Schritte Overhead verursachen.

Deshalb erfordert Edge-Vision ein Leistungsmodell, das sich auf Systemeffizienz statt auf isolierte Benchmarks konzentriert. YOLO26 spiegelt diesen Wandel wider, indem es sich auf Edge-first-Optimierung, optimierte Inferenz und eine End-to-End-Ausführung für den realen Einsatz konzentriert.

Link to this sectionDie Grundlage für Geschwindigkeit: Ein Edge-first-Design#

Am Edge wird die Leistung dadurch definiert, wie gut ein Modell auf die tatsächliche Hardware-Architektur des Geräts abgestimmt ist. Ein Edge-first-Design stellt sicher, dass Vision-Systeme zuverlässig auf realen Plattformen laufen, unabhängig von der spezifischen Kombination der verfügbaren Prozessoren.

Ein Edge-first-Ansatz priorisiert eine vorhersagbare und effiziente Ausführung auf heterogener Hardware, anstatt Modelle, die für Cloud-GPUs optimiert wurden, nachträglich anzupassen. Einfach gesagt bedeutet dies, Operationen zu bevorzugen, die sich gut auf neuronale Netzwerkbeschleuniger übersetzen lassen, nicht-neuronale Arbeit außerhalb des Modells zu minimieren und unnötige Komplexität zu reduzieren, die die End-to-End-Ausführung verlangsamen kann.

YOLO26 wurde mit diesen Einschränkungen im Hinterkopf entwickelt. Seine Architektur konzentriert sich auf konsistente Leistung anstelle von maximalem Durchsatz unter idealen Bedingungen. Durch die Vereinfachung der Ausführungspfade und den Wegfall unnötiger Berechnungen reduziert YOLO26 den Overhead in der Inferenz-Pipeline und nutzt die verfügbare Beschleunigungs- und Speicherhierarchie des Geräts besser aus.

Dieser Ansatz verbessert auch die Zuverlässigkeit. Edge-first-Optimierung führt zu vorhersagbareren Zeitabläufen und weniger Leistungsspitzen, was für Echtzeitsysteme entscheidend ist. Anstatt auf spezialisierte Hardware oder aufwendiges Post-Processing zu setzen, um Geschwindigkeit zu erreichen, betont YOLO26 die Effizienz über die gesamte Inferenz-Pipeline hinweg.

Link to this sectionEnd-to-End-Inferenz und die Kosten des Post-Processing#

Du fragst dich vielleicht, was es bedeutet, unnötige Post-Processing-Schritte zu eliminieren. Um dies zu verstehen, lass uns einen Schritt zurücktreten und betrachten, wie herkömmliche Objekterkennungssysteme funktionieren.

In vielen Objekterkennungs-Pipelines endet die Inferenz nicht, wenn das Modell seine Vorhersagen trifft. Stattdessen gibt das Modell eine große Anzahl überlappender Bounding Boxes aus, die dann gefiltert und verfeinert werden müssen, bevor sie verwendet werden können. Diese Bereinigung erfolgt durch Post-Processing-Schritte, die außerhalb des Modells selbst ausgeführt werden.

Einer der häufigsten Post-Processing-Schritte ist Non-Maximum Suppression, oder NMS. NMS vergleicht überlappende Bounding Boxes und behält nur die sichersten Erkennungen bei, wobei Duplikate, die sich auf dasselbe Objekt beziehen, entfernt werden. Obwohl dieser Ansatz effektiv ist, führt er nach Abschluss der Inferenz zusätzliche Berechnungen ein.

Abb. 3: Verständnis von NMS. Bild vom Autor.

Am Edge hat diese zusätzliche Arbeit ihren Preis. Post-Processing-Schritte wie NMS sind nicht gut für die spezialisierten Beschleuniger geeignet, die für die neuronale Netzwerkinferenz verwendet werden, da diese auf dichte neuronale Berechnungen statt auf steuerungsintensive oder speicherintensive Operationen optimiert sind.

Infolgedessen führt NMS zu zusätzlicher Latenz und Speicher-Overhead, und die Kosten steigen mit der Anzahl der Erkennungen. Selbst wenn das Modell selbst schnell ist, kann NMS dennoch einen erheblichen Teil der Gesamtlaufzeit beanspruchen.

Post-Processing erhöht auch die Systemkomplexität. Da es außerhalb des Modells liegt, muss es für verschiedene Runtimes und Hardware-Ziele separat implementiert werden. Dies führt oft zu plattformspezifischen Codepfaden, inkonsistentem Verhalten über Geräte hinweg und anfälligeren Deployment-Pipelines.

Am wichtigsten ist, dass Post-Processing die Idee der echten End-to-End-Leistung zerstört. Die Messung der Modell-Inferenzgeschwindigkeit spiegelt nicht wider, wie sich das System in der Produktion verhält. Was letztendlich zählt, ist die Gesamtzeit vom Eingang bis zum endgültigen Ausgang, einschließlich jedes Schrittes in der Pipeline.

In diesen Situationen wird Post-Processing zu einem versteckten Engpass am Edge. Es erhöht die Latenz, verbraucht CPU-Ressourcen und verkompliziert das Deployment, während es sich außerhalb des Modells selbst befindet.

Link to this sectionWie YOLO26 NMS entfernt und warum das es schneller macht#

YOLO26 entfernt NMS, indem es die Ursache für doppelte Erkennungen angeht, anstatt sie nach der Inferenz zu bereinigen. Anstatt viele überlappende Vorhersagen zu erzeugen, die gefiltert werden müssen, wird das Modell darauf trainiert, direkt einen kleineren Satz sicherer, endgültiger Erkennungen zu generieren.

Dies wird durch die Änderung der Art und Weise ermöglicht, wie Erkennungen während des Trainings erlernt werden. YOLO26 fördert eine klarere Eins-zu-Eins-Beziehung zwischen Objekten und Vorhersagen, was Redundanz an der Quelle reduziert. Infolgedessen werden doppelte Erkennungen innerhalb des Netzwerks selbst aufgelöst und nicht durch externes Post-Processing.

Das Entfernen von NMS hat unmittelbare Auswirkungen auf die Edge-Leistung. Da NMS nicht gut auf neuronale Netzwerkbeschleuniger übertragen werden kann, reduziert dessen Eliminierung die Speicherbewegung und vermeidet teure nicht-neuronale Verarbeitungsschritte. Dies senkt die End-to-End-Latenz und macht die Leistung vorhersagbarer, insbesondere auf Edge-Geräten, auf denen Post-Processing sonst einen spürbaren Teil der Gesamtlaufzeit beanspruchen kann.

Es vereinfacht auch die Inferenz-Pipeline. Mit weniger Schritten außerhalb des Modells gibt es weniger Datenbewegungen und weniger Übergaben zwischen den Komponenten. Die Ausgabe des Modells ist bereits das Endergebnis, was die Ausführung vorhersagbarer macht.

Link to this sectionEntfernen von DFL zur Ermöglichung echter End-to-End-Leistung#

Eine weitere Innovation in YOLO26 ist die Entfernung von Distribution Focal Loss (DFL), das in früheren YOLO-Modellen für die Bounding-Box-Regression verwendet wurde. Anstatt direkt eine einzelne Koordinate vorherzusagen, lernten Modelle, die DFL verwendeten, eine Verteilung möglicher Werte und leiteten dann eine endgültige Bounding Box aus dieser Verteilung ab. Dieser Ansatz trug dazu bei, die Lokalisierungsgenauigkeit zu verbessern, und war ein wichtiger Schritt in früheren Generationen.

Im Laufe der Zeit brachte DFL jedoch auch Kompromisse mit sich. Die Vorhersage von Verteilungen erhöht die Rechenlast und fügt der Modellarchitektur Komplexität hinzu, was die Inferenz auf CPUs verlangsamen und den Export der Modelle über verschiedene Deployment-Formate hinweg erschweren kann. DFL legte zudem feste Regressionsbereiche fest, was die Flexibilität bei der Erkennung sehr großer Objekte einschränken konnte.

YOLO26 entfernt DFL als Teil seines Weges hin zu einem einfacheren End-to-End-Design. Die Bounding-Box-Regression wurde so umgestaltet, dass sie direkter ist, was unnötige Berechnungen reduziert und gleichzeitig die Genauigkeit beibehält. Diese Änderung steht im Einklang mit dem NMS-freien Ansatz von YOLO26.

Link to this sectionWoher die 43 % schnellere CPU-Inferenz kommt#

In CPU-basierten Benchmarks zeigt YOLO26 eine deutliche Leistungsverbesserung gegenüber früheren YOLO-Modellen. Im Vergleich zu Ultralytics YOLO11 liefert das YOLO26 nano-Modell eine bis zu 43 % schnellere CPU-Inferenz – ein Unterschied, der sich in realen Edge-Deployments sinnvoll auswirkt.

Abb. 4: Benchmarking der CPU-Geschwindigkeit von YOLO26.

Dieser Gewinn resultiert aus der Vereinfachung der gesamten Inferenz-Pipeline anstatt der Optimierung einer einzelnen Komponente. Die End-to-End-Ausführung entfernt den Overhead durch Post-Processing, eine direktere Methode für die Bounding-Box-Regression reduziert Berechnungen und Edge-first-Design-Entscheidungen verbessern die Ausführungseffizienz auf Allzweckprozessoren.

Zusammen reduzieren diese Änderungen die Latenz, verringern die CPU-Arbeitslast und führen zu einer schnelleren, konsistenteren Leistung auf realer Edge-Hardware.

Link to this sectionDie Auswirkungen von YOLO26 auf Edge-Deployment und Exporte#

Die Leistungsgewinne von YOLO26 gehen über eine schnellere Inferenz hinaus. Durch die Vereinfachung des Modells und die Reduzierung des Speicher-Overheads wird es einfacher bereitzustellen und zuverlässiger in Edge-Umgebungen auszuführen.

Das End-to-End-Design von YOLO26 vereinfacht auch den Export. Mit weniger Hilfskomponenten und ohne externe Post-Processing-Schritte sind exportierte Modelle vollständig in sich geschlossen. Dies reduziert plattformspezifische Abhängigkeiten und trägt dazu bei, ein konsistentes Verhalten über Runtimes und Hardware-Ziele hinweg sicherzustellen.

In der Praxis bedeutet dies, dass YOLO26 einfacher auf Edge-Geräten wie Kameras, Robotern und eingebetteten Systemen bereitgestellt werden kann, wobei verschiedene Exportformate genutzt werden. Was du exportierst, ist das, was du ausführst – mit weniger Integrationsschritten und weniger Risiko für Deployment-Drift.

Link to this sectionSchnellere Edge-Inferenz ermöglicht Robotik und industrielle Vision AI#

Bisher haben wir betrachtet, wie das Edge-first-Design von YOLO26 die Leistung auf Systemebene verbessert. Die wahre Wirkung liegt jedoch darin, wie es Vision AI einfacher macht, in reale Anwendungen integriert zu werden.

Zum Beispiel in der Robotik und in industriellen Umgebungen arbeiten Vision-Systeme oft unter strengen Echtzeit-Grenzen. Entscheidungen müssen schnell und konsistent getroffen werden, bei begrenzter Rechenleistung und ohne auf Cloud-Konnektivität angewiesen zu sein. Mit Ultralytics YOLO26 wird die Erfüllung dieser Anforderungen praktisch möglich.

Anwendungen wie Roboternavigation und Objektmanipulation profitieren von geringerer Latenz und vorhersagbarerer Inferenz, was Robotern ermöglicht, flüssig auf Änderungen in ihrer Umgebung zu reagieren. Ähnlich können Vision-Modelle in industriellen Umgebungen direkt an Produktionslinien laufen, um Defekte zu erkennen, Komponenten zu verfolgen und Prozesse zu überwachen, ohne Verzögerungen oder zusätzliche Komplexität einzuführen.

Indem YOLO26 schnelle, zuverlässige Inferenz auf Edge-Hardware ermöglicht, hilft es, Vision AI zu einem natürlichen Bestandteil von Robotik- und Industriesystemen zu machen, anstatt sie zu einer Herausforderung in Bezug auf Bereitstellung und Wartung zu machen.

Link to this sectionWichtige Erkenntnisse#

YOLO26 wurde für den Edge gebaut, wo reale Einschränkungen wie Latenz, Speicher und Zuverlässigkeit definieren, was möglich ist. Durch die Ausrichtung des Modells auf CPU-first-Ausführung, End-to-End-Inferenz und einfacheres Deployment macht YOLO26 Vision AI praktisch in echte Systeme integrierbar. Dieser Edge-first-Ansatz ermöglicht eine breite Palette von Anwendungen, von Robotik und industrieller Vision bis hin zu eingebetteter und On-Device-KI, wo Leistung und Vorhersagbarkeit am wichtigsten sind.

Tritt unserer wachsenden Community bei und erkunde unser GitHub-Repository für praktische KI-Ressourcen. Um noch heute mit Vision AI zu entwickeln, erkunde unsere Lizenzoptionen. Erfahre, wie KI in der Landwirtschaft den Ackerbau verändert und wie Vision AI im Gesundheitswesen die Zukunft gestaltet, indem du unsere Lösungsseiten besuchst.