Live-Messererkennung mit selbst trainiertem YOLOv11-Modell

Das Projekt untersuchte die frühzeitige visuelle Erkennung von Messern in Live-Kamerabildern. Ich habe es in rund 250 Stunden eigenständig umgesetzt und mit sehr wenig Vorerfahrung in Computer Vision begonnen: Python, Datenlabeling, YOLO-Training und Edge-Deployment habe ich mir im Projektverlauf erarbeitet.

Alle Bilder wurden eigens für das Projekt aufgenommen, einschließlich Einzelbildern aus eigenen Videos. Der Datensatz enthält 731 Bilder mit Messern und 4.011 Bilder ohne Messer, aufgeteilt in 3.781 Trainings- und 961 Validierungsbilder – mit 327 gelabelten Boxen im Validierungsdatensatz. Die Labels habe ich manuell geprüft und später Auto-Labeling zur Beschleunigung eingesetzt; der Labeling-Aufwand lag bei etwa 40–60 Stunden.

Frühe Versionen stuften viele in der Hand gehaltene Gegenstände als Messer ein, weil der Datensatz zu wenige repräsentative Negativszenen enthielt. Die Erweiterung auf über 4.000 Negativbilder beseitigte den Großteil dieser Fehlerkennungen – die wirksamste Einzelmaßnahme im Projekt, und eine, die Aufnahmezeit statt Rechenleistung gekostet hat.

Eine Zwischenversion teilte die Labels in zwei Klassen auf: ein Messer, das in einer Szene liegt, und ein Messer, das in der Hand gehalten wird. Die Überlegung dahinter: Für eine Alarmierungsanwendung steckt genau in dieser Unterscheidung die Bedeutung – ein Gegenstand auf der Arbeitsplatte ist nicht dasselbe Ereignis wie ein Gegenstand in jemandes Griff.

Gemessen gegen die zusammengeführte Ein-Klassen-Version auf denselben Bildern und derselben Validierungsaufteilung hat sich die Trennung nicht ausgezahlt. Alle aggregierten Metriken verbesserten sich, nachdem die beiden Klassen wieder zu einer zusammengelegt wurden, und die Klasse ohne Hand war durchgehend die schwächere Hälfte – mit einem Bruchteil der Instanzen der Klasse mit Hand. Die Aufteilung eines kleinen Datensatzes bescherte dem Modell zwei schlecht gestützte Probleme statt eines gut gestützten.

Der Vergleich ist nicht perfekt kontrolliert: Der zusammengeführte Lauf trainierte auch 150 statt 110 Epochen. Die Richtung ist aber über Precision, Recall und beide mAP-Maße hinweg einheitlich – und das Ein-Klassen-Modell ist das, was eingesetzt wird.

Statt einer vagen Anzahl von Experimenten hier die exakte Konfiguration hinter dem eingesetzten Modell. Der Lauf dauerte 2 Stunden 23 Minuten auf der weiter unten beschriebenen Tesla T4.

Die folgenden Werte stammen aus dem Validierungsdatensatz beim besten Checkpoint. Sie beschreiben diesen Datensatz und diese Aufteilung – was sie noch nicht belegen, steht in den offenen Punkten am Seitenende.

Die aggregierten Zahlen verdecken die nützlichere Information, deshalb hier die Fehlerstruktur aus der Confusion Matrix bei der Standard-Konfidenzschwelle. Von 327 gelabelten Instanzen im Validierungsdatensatz wurden 275 erkannt und 52 übersehen.

Das größere Problem liegt in der anderen Richtung: 120 Erkennungen entfielen auf Hintergrundbereiche ohne gelabeltes Objekt. Das ist rund ein Fehlalarm auf 2,3 korrekte Erkennungen. Das Modell löst eher zu oft als zu selten aus, und für eine Alarmierungsanwendung ist das die teurere Fehlerart. Es ist außerdem der einzige Wert, der sich zwischen den beiden Trainingsläufen kaum bewegt hat – ein Hinweis darauf, dass er an den Daten liegt und nicht an der Labelstruktur. Die nächste Runde muss ihn mit schwierigeren Negativszenen angehen.

• Erkannt: 275 von 327 gelabelten Instanzen (84 %)
• Übersehen: 52 Instanzen (16 %)
• Fehlalarme auf Hintergrund: 120
• Die Zuverlässigkeit sinkt bei Verdeckung und ungewöhnlichen Messerformen

Das Modell läuft von einer Live-Webcam auf einem Lenovo Yoga Slim 6 mit beobachteten 6–10 FPS sowie auf NVIDIA-Jetson-Plattformen, unter anderem einem Orin Nano Super. Demonstriert wurde es in unbekannten Szenen bei unterschiedlichen Lichtverhältnissen und Hintergründen.

Im März 2025 habe ich nahezu alle Komponenten gebraucht beschafft und für rund 910 € einen lokalen KI-Rechner aufgebaut, statt GPU-Zeit zu mieten. Rein auf die Rechenleistung gerechnet trägt sich diese Entscheidung nicht, und das gehört klar gesagt.

Eine T4-vergleichbare Cloud-Instanz kostet derzeit etwa 0,20 bis 0,76 $ pro Stunde On-Demand. In der Mitte dieser Spanne liegt der Break-even der 910 € bei rund 3.300 GPU-Stunden – 137 Tage Dauerlast. Über alle Läufe dieses Projekts habe ich in der Größenordnung von 100 Stunden gerechnet. Diese Rechenzeit zu mieten hätte etwa 30 € gekostet. Pro tatsächlich genutzter Stunde war die Workstation damit rund dreißigmal teurer als Miete.

Drei Punkte rechtfertigen sie trotzdem, und keiner davon ist der Stundenpreis. Erstens besteht der Datensatz aus Videoaufnahmen in meiner eigenen Wohnung und zeigt mich und mein Umfeld; diese Daten einem fremden Anbieter zu übergeben wollte ich nicht. Zweitens hat ein Grenzkostensatz von null meine Arbeitsweise verändert – das Klassenexperiment weiter oben, das nützlichste Ergebnis dieses Projekts, ist nur entstanden, weil ein zusätzlicher Trainingslauf nichts kostete. Bei abgerechneter Rechenzeit hätte ich weniger ausprobiert und weniger gelernt. Drittens sind 910 € der Preis für einen vollständigen Rechner, nicht für GPU-Stunden: Ryzen 7 5800X, 64 GB RAM und die 1-TB-SSD tragen auch CAD-Arbeit und Slicing, den vollen Betrag diesem Projekt zuzurechnen überzeichnet die Kosten. Die Cloudpreise lagen zum Entscheidungszeitpunkt außerdem deutlich höher als heute.

Die ehrliche Schlussfolgerung ist eine Regel, kein Urteil: Für ein Projekt dieser Größe ohne Datenschutzauflage ist Mieten bei den heutigen Preisen die richtige Wahl, und ich würde mieten. Der Kauf war durch diese Auflage und durch den Wert unbegrenzter Iteration begründet – nicht durch die Rechnung.

Ein Prototyp beantwortet die Frage „erkennt er es?". Ein Betreiber fragt „was kostet der Betrieb?" – und meine eigene Fehlalarmrate beantwortet das, denn in einem Alarmierungssystem verbraucht jeder Fehlalarm die Aufmerksamkeit eines Menschen. Die folgende Rechnung arbeitet mit offengelegten Annahmen, nicht mit echten Kundenzahlen, und sie hat verändert, welche Entwicklungsarbeit ich als Nächstes für sinnvoll halte.

Angenommenes Szenario: ein überwachter Eingangsbereich eines Gewerbegebäudes, vier Kameras, rund 312 Betriebsstunden im Monat. Ein bewertetes Bild pro Sekunde und Kamera, 30 Sekunden Sichtprüfung je Alarm, 20 € pro Stunde Personalkosten inklusive Nebenkosten. Hardware zu den Preisen, die ich tatsächlich bezahlt habe: 250 € je Jetson Orin Nano Super, dazu geschätzt 50 € je Kameramodul. Montage, Netzwerk und Gehäuse sind nicht enthalten.

Die Hardware ist nicht das Problem. Vier Knoten kosten einmalig 1.200 €. Ohne jede Filterung erzeugt eine Fehlalarmrate von 12,5 % pro Bild etwa 1.800 Alarme pro Stunde über vier Kameras – das sind fünfzehn dauerhaft gebundene Personen, womit die Frage geklärt ist, ob das unbearbeitete Modell betriebsfähig ist. Verlangt man drei Erkennungen in Folge, bevor ein Alarm ausgelöst wird, kostet das keine zusätzliche Hardware und senkt den Wert auf 28 Alarme pro Stunde, also rund 1.460 € Prüfaufwand im Monat. Die einmaligen Hardwarekosten sind damit in weniger als einem Monat von den Personalkosten überholt.

Die interessante Folge ist nichtlinear. Weil ein Drei-Bild-Filter die Rate pro Einzelbild in die dritte Potenz erhebt, halbiert eine Halbierung der Fehlalarmrate nicht die Prüfkosten – sie senkt sie um den Faktor acht, von rund 1.460 € auf etwa 180 € im Monat. Damit wird aus „das Modell etwas verbessern" eine bezifferte Rendite, und die günstige Maßnahme rückt vor die naheliegende: erst filtern zum Preis von null, dann etwa 40 bis 60 Stunden zusätzliche Aufnahmen von Negativszenen, und erst danach überhaupt die Frage nach einem größeren Modell.

• Investition: einmalig 1.200 € für vier Knoten, zu den von mir bezahlten Preisen
• Die Betriebskosten werden von menschlicher Aufmerksamkeit bestimmt, nicht von Hardware oder Energie
• Eine Halbierung der Fehlalarmrate bringt beim Prüfaufwand etwa Faktor acht
• Die wirksamste günstige Maßnahme ist zeitliche Filterung und kostet nichts in der Umsetzung

Das Projekt hat eine funktionierende Live-Demonstration, eine gemessene Ausgangsbasis von mAP@0,5 = 0,844 und wiederverwendbare Trainingshardware hervorgebracht. Die übertragbarste Erkenntnis: Die Zusammensetzung der Daten war wichtiger als Modellgröße oder ausgefeilte Labels. Die entscheidenden Fortschritte kamen durch tausende passender Negativszenen und durch das Vereinfachen der Labelstruktur, nicht durch ihr Verfeinern. Das Modell ist YOLOv11-S – die kleine Variante – und sie ist nicht der begrenzende Faktor.