Unsere Edge-AI-Demo lief. Dann startete sie nicht mehr.

Drei Tage auf der VISION Stuttgart und eine Antwort auf meinen eigenen Test: Was hat sich verändert, während wir den Menschen am Stand zuhörten? Und was bedeutet das, wenn eine Edge-AI-Demo in den Betrieb geht?

Vor der Messe habe ich mir einen Test gestellt. Nicht „Was habt ihr gezeigt?“, sondern „Was hat sich an einem Tag verändert, während ihr den Menschen am Stand zugehört habt?“ Leicht aufzuschreiben. Weniger leicht zu bestehen.

Hier ist die Antwort, Tag für Tag, mit Zahlen. Einschließlich des Morgens, an dem der Stand nicht startete.

Vor der VISION schrieb ich darüber, was mit einer Edge-AI-Demo passiert, wenn sie den Messestand verlässt: das Licht, die Kamera, die Latenz, die fehlende Cloud. Diese vier Punkte gelten weiterhin. Hier kommt die andere Liste. Mit weniger Theorie und mehr Kabeln.

Was lief auf dem Tisch?

Vier Kameras. Auf einem NXP i.MX 95 laufen die Bildverarbeitungsmodelle. Auf einem zweiten, kleineren Board (i.MX 8M Plus) mit einer Kinara-Ara-2-Beschleunigerkarte läuft ein Sprachmodell mit 7 Milliarden Parametern, damit unser Agent Siegfried mit Besuchern sprechen kann. Alles steht auf dem Tisch, nichts geht in die Cloud. Die VISION fand vom 6. bis 8. Oktober auf der Messe Stuttgart statt.

Warum gingen die Besucher am Dienstag einfach vorbei?

Am Morgen gingen die Besucher an zwei der vier Kameras einfach vorbei. Rechtecke und markierte Gesichtspunkte ergeben für Ingenieure Sinn.

Bis zur Mittagspause steuerten dieselben Gesichtspunkte eine Sonnenbrille und einen Schnurrbart. Beide Hände eine halbe Sekunde lang hochhalten, und auf dem Bildschirm steht „HANDS UP!“, Konfetti fällt, und die Lampen am Stand blinken. Das ernste Thema wurde dadurch nicht weniger ernst. Es wurde etwas, das man selbst ausprobieren konnte.

Die Zahlen hinter dem Spaß, aus der eingeblendeten Statistik: Personenerkennung mit etwa 20 Bildern pro Sekunde auf der NPU, Gesichter mit 21, Körperhaltung mit 11. Das Gestenmodell läuft mit 5 Bildern pro Sekunde auf der CPU, weil es nie auf die NPU verlagert wurde. Ein Screenshot des ersten Builds zeigt eine CPU-Auslastung von 88 Prozent. Das ist eine Momentaufnahme, nicht die Auslastung über alle drei Tage.

Dann kam eine Idee, die wir innerhalb einer Stunde wieder verwarfen: eine Heatmap für „Wer steht hier am längsten?“, von Grün bis Rot. Sie wurde komplett rot. Menschen an einem Stand stehen nun einmal. Wir ersetzten sie durch eine Regenbogenspur: Die Farbe durchläuft alle 12 Sekunden den Regenbogen, die Punkte verblassen nach 25 Sekunden.

Dann meinte ein Besucher, es wäre cool, wenn der Stand seinen Namen vom Badge lesen und ihn begrüßen könnte. Bis zum Abend konnte er das. Offline-OCR, ein Erkennungsmodell von 3,9 MB, etwa 0,6 Sekunden pro Textzeile auf dem Board, eine Begrüßung drei bis vier Sekunden nach dem Hochhalten des Badges. Die Besucher hielten ihre eigenen Badges vor die Kamera. Auf dem Bildschirm erschien nur der Name. Auf zwölf echten Badge-Fotos las es 86 bis 100 Prozent der einzelnen Frames exakt, ohne falschen Namen. Die Zahl der Tests wuchs an diesem Abend von 50 auf 73.

Warum verlegten wir die Badge-Erkennung am Mittwoch?

Die Badge-Erkennung lief auf Kamera 3, die am höchsten montiert war. Besucher mussten ihren Badge wie ein Ticket an einer Zugangsschranke vor die Linse halten. Am Mittwochmorgen wechselte sie auf Kamera 4, die niedrigste, die mehr Pixel liefert.

Das Ergebnis: Sie las Badges, die 11 bis 22 Prozent der Bildbreite einnehmen, mit etwa 1,8 Sekunden pro Versuch. Bei ungefähr einem Zehntel der Bildbreite wurden 89 bis 100 Prozent der Testframes korrekt gelesen.

Dann wurden wir gierig. Warum nicht auf allen vier Kameras Badges lesen? Wir haben es versucht. In 40 Versuchen fanden die Kameras 1 bis 3 keine einzige Textzeile. Ihre Weitwinkelobjektive sind auf die Halle fokussiert, und Software kann den Fokus nicht reparieren. Noch schlimmer: Ein Suchdurchlauf über vier vollständige Bilder dauerte auf dem Board 1,2 bis 1,5 Sekunden. Auf meinem Laptop dauert derselbe Schritt 3 bis 5 Millisekunden. Die Systemlast stieg auf 10,5 bei sechs Kernen. Entscheidung um 12:37: nur Kamera 4.

Ich habe keine Speicherbandbreite gemessen. Ich habe Sekunden gemessen. Aber die Pixel erklären es. Die Kameras liefern 1920 mal 1280. Eine Kachel auf dem Bildschirm hat 960 mal 640, etwa 0,6 Millionen Pixel. Unser Abgriff in voller Auflösung hatte 1,4 Millionen, der größte 2,5 Millionen. Viermal so viele Pixel, um dieselben kleinen Buchstaben zu lesen.

Am späten Nachmittag kam eine neue Beschwerde: Die Gesten lösen selten aus. Das Handmodell lief mit 5 Bildern pro Sekunde, und nur jedes zweite Ergebnis wurde verwendet. Das sind 2,5 pro Sekunde, und der Auslöser brauchte zwei neue Ergebnisse plus eine halbe Sekunde Halten. Eine Einstellung geändert, und es funktionierte. Außerdem änderten wir die Begrüßung zu „Servus, <name>!“ mit drei Sekunden Konfetti und ergänzten einen kleinen Hinweis „bereits begrüßt“. Denn Besucher vor der Kamera wussten nicht, ob sie erkannt worden waren.

Eine ehrliche Einschränkung: Unsere „null falschen Namen“ bedeuten Konsistenz auf zwölf Fotos, nicht von einem Menschen überprüfte Namen. Ein Lesefehler kann passieren.

Warum fiel der Chat am Donnerstagmorgen aus?

Die Stromversorgung war die wahrscheinlichste Ursache, aber wir haben die Stromaufnahme nie gemessen.

Kurz vor neun war mit dem großen Board alles in Ordnung. Der Chat auf dem Bildschirm meldete, das Modell werde noch geladen. Das kleine Board antwortete auf einen Ping, aber der Modellserver lief überhaupt nicht. Ein Neustart half nicht.

Wir trennten das kleine Board für 20 Sekunden vom Strom. Um 09:05 meldete das Modell, dass es bereit sei.

Warum hilft ein Neustart nicht? Auf diesem Board bleiben am Steckplatz der Beschleunigerkarte während eines Resets 3,3 Volt anliegen. Die Karte behält den Zustand der letzten Sitzung, und die Startprozedur des Herstellers setzt einen frisch mit Strom versorgten Chip voraus. Erst eine echte Stromunterbrechung ermöglicht einen sauberen Start. Hier muss ich vorsichtig sein: Die Logs von diesem Morgen existieren nicht mehr, sie werden bei jedem Boot gelöscht. Diese Erklärung stammt aus der späteren Analyse, nicht aus einer Aufzeichnung des Ausfalls.

Wir bauten einen Hinweis für den Bildschirm, und um 10:53 zog ich selbst den Stecker des kleinen Boards, um ihn zu testen. Um 10:55 war das Board wieder da und blieb hängen. Der „gute“ Kaltstart, auf den wir uns verlassen hatten, war nach einer echten Stromunterbrechung gescheitert. Wir zogen den Stecker erneut, für 30 Sekunden. Um 11:00 startete es, und alle Lüfter drehten gleichzeitig kräftig auf. Beim fehlgeschlagenen Start waren sie still geblieben.

Die Chiptemperatur vor dem Start lag beide Male bei etwa 24 Grad. Das kleine Board wurde über eine in eine Steckdosenleiste eingebaute USB-C-Buchse mit 5 Volt versorgt. Gegen 12:15 fiel am Stand der Strom aus. Danach setzte sich das Board zweimal selbst zurück, jedes Mal etwa eine Minute nach dem Start, genau dann, wenn das Modell zu laden beginnt.

Um 12:42 wechselten wir zu einem richtigen USB-C-PD-Ladegerät. Um 12:46 war das Modell bereit, und das Board setzte sich nicht noch einmal zurück.

Die Ursache war also höchstwahrscheinlich die Stromversorgung. Höchstwahrscheinlich, weil wir die Stromaufnahme nie gemessen haben. Ein beschädigtes Modul bleibt die zweite, weniger wahrscheinliche Erklärung.

Warum brauchte die Lösung eine Lösung?

Der rote Hinweis, den wir gebaut hatten, sagte sinngemäß: „Modellserver antwortet nicht. i.MX 8M Plus vom Strom trennen.“ Ich las ihn aus der Perspektive eines Mitarbeiters am Stand und sagte: Jemand, der die Demo nicht gebaut hat, wird das nicht verstehen. „Modellserver“ sagt dieser Person nichts. Der Text blieb gleich, ob man den Stecker bereits gezogen hatte oder nicht. Während das Board neu startete, gab es keine Rückmeldung und nach wiederholten Fehlschlägen keinen klaren nächsten Schritt.

Der Ersatz ist eine Karte auf dem Tisch, in einfachen Worten: alles gut, warten, das kleine Board für 20 Sekunden vom Strom trennen, und eine Zeile mit einer Telefonnummer zum Anrufen.

Was muss getestet werden, bevor eine Demo in den Betrieb geht?

Stromversorgung. Behandelt die Versorgung als Komponente, nicht als Steckdose. Ein Reset ist keine Stromunterbrechung. Haltet fest, welches Ladegerät welches Board versorgt, und messt die Stromaufnahme unter Last. Das haben wir nicht getan.

Hitze. Ein kühler Start ist kein thermischer Test. Vierundzwanzig Grad beim Start sagen nichts darüber aus, wie es um zwei Uhr nachmittags unter Last aussieht.

OCR. Genauigkeit im Labor und Genauigkeit am Stand sind unterschiedliche Zahlen. Für uns war entscheidend, wie viel vom Bild der Badge einnimmt, und der Fokus des Objektivs. Das ist Hardware.

Bandbreite. Zählt Pixel pro Sekunde wie ein Budget. Vier Kameras in voller Auflösung kosten Sekunden, nicht Millisekunden. Ein gemeinsamer Worker war besser als vier eifrige.

Menschen. Die Heatmap wurde rot. Die Hände wurden zu Konfetti. Die Idee mit dem Badge kam von einem Besucher, nicht von uns. Und die Person, die den Stand um 8:50 neu startet, ist nicht die Person, die ihn gebaut hat.

Noch etwas: Das Board hat keine Uhr. An Tag 3 lag es einen Tag zurück, deshalb trugen unsere Dateien das Datum vom Vortag.

Wenn eure Demo auf dem Tisch funktioniert: Welches Kabel steckt ihr zuletzt ein, und wer außer euch weiß, welches es ist?