On-Device-Inferenz gestaltet den Sensor-Stack neu

Adam J. Fleischer
|  Erstellt: August 12, 2026
At a Glance
Dieser Artikel untersucht, wie Inferenz auf dem Gerät selbst die Funktionsweise von Sensoren verändert, und hebt den Wandel vom herkömmlichen Streaming hin zur lokalen Verarbeitung für mehr Effizienz und bessere Leistung hervor. Mit Fortschritten wie gestuften Wake-up-Systemen und verbesserten Quantisierungstechniken werden Sensoren heute nach der Qualität der Daten beurteilt, die sie an lokale Modelle liefern, und nicht mehr nur nach der Reinheit ihrer Signale.
Go Deeper with AI:
On-Device-Inferenz gestaltet den Sensor-Stack neu

Kernaussagen

  • Bei Inferenz auf dem Gerät wird ein Sensor eher danach beurteilt, was er an ein benachbartes Modell liefert, als danach, wie sauber er streamt. 
  • Die Speicherbandbreite, nicht die Spitzen-TOPS, begrenzt die meisten Edge-Designs, und die 8-Bit-Quantisierung ist der Hebel, um ein Modell in den On-Chip-Speicher einzupassen.
  • Bei Always-on-Designs wird der Stromverbrauch durch gestufte Aktivierung gesenkt: Verlagern Sie jede Entscheidung auf die günstigste Stufe, die sie treffen kann, denn das Bewegen von Daten kostet mehr als die eigentliche Rechenoperation.

Inferenz verlagert sich auf das Gerät

Edge AI ist 2026 auf dem Sprung von Pilotprojekten zu Mainstream-Produkten. Von den rund 21 Milliarden vernetzten IoT-Geräten im Einsatz senden die meisten ihre Daten noch immer zur Verarbeitung vom Gerät weg. Doch speziell entwickelte Siliziumlösungen verlagern diese Arbeit an Bord: Die ersten STM32-Mikrocontroller mit einer dedizierten Neural Processing Unit (NPU) gingen Ende 2024 in die Massenproduktion, und Edge-AI-Module im günstigeren Preissegment sind auf Preisniveaus gefallen, bei denen lokale Inferenz wirtschaftlich zum Standard wird.

Sensoren speisen jetzt ein Modell

Sobald Inferenz lokal ausgeführt wird, wird ein Sensor weniger danach bewertet, wie sauber er ein Signal digitalisiert, sondern vielmehr danach, wie nützlich seine Ausgabe für das neben ihm laufende Modell ist. Das hat drei Folgen:

  • Sauberere Daten mit größerem Dynamikbereich. Modelle bestrafen Rauschen und Clipping, daher erhalten Frontends mehr Headroom. Inertial Measurement Units mit Doppelbereich (IMUs) erfassen gleichzeitig feine Vibrationen und starke Stöße, ohne dass zwischen den Bereichen Daten verloren gehen. Mikrofonanbieter erhöhen heute neben dem Signal-Rausch-Verhältnis auch die akustischen Übersteuerungsgrenzen, damit ein lautes Ereignis nicht sättigt, bevor das Modell es erfasst.
  • Rechenleistung im Sensor. Machine-Learning-Kerne und In-Sensor-Processing-Units in IMUs, AI-Engines in MEMS-Mikrofonen sowie On-Die-Vision ermöglichen es dem Bauteil, statt eines Rohdatenstroms direkt eine Entscheidung oder ein Merkmal auszugeben, sodass der Host im Schlafmodus bleiben kann.
  • Dünne, ereignisgesteuerte Ausgabe. Ereignisbasierte Bildsensoren und Wake-on-Sound-Mikrofone nutzen Bandbreite und Rechenleistung nur dann, wenn sich etwas ändert, statt rund um die Uhr zu streamen.

Diese Entwicklungen helfen auch beim Schutz der Privatsphäre. Time-of-Flight- und Radarsensoren melden Entfernung und Bewegung, keine Bilder, und In-Sensor-Vision hält Rohpixel auf dem Die, sodass ein Anwesenheitssensor seine Aufgabe erfüllen kann, ohne dass jemals ein Kamerafeed das Bauteil verlässt.

Bandbreite, nicht TOPS, setzt die Obergrenze

Die Schlagzeilenzahl für ein Edge-AI-Bauteil ist in der Regel seine TOPS-Bewertung (Billionen Operationen pro Sekunde) — und genau daran sollte ein Design nicht dimensioniert werden. Zwei Beschleuniger mit derselben TOPS-Angabe können sehr unterschiedliche reale Durchsätze erreichen, weil die Leistung von der Speicherbandbreite, den vom Silizium unterstützten Operatoren und davon abhängt, wie gut der Compiler des Anbieters Ihr Netzwerk darauf abbildet. 

Bei den meisten Edge-Designs ist das Verschieben von Tensoren der begrenzende Faktor, sodass der Prozessor auf Speicher warten muss, lange bevor ihm die Rechenleistung ausgeht. Die Energie pro Inferenz, nicht die Spitzen-TOPS, ist die Kennzahl, die abbildet, was eine Batterie tatsächlich sieht. Hilfreich ist es, in zwei Bereiche zu denken, aufgeteilt danach, wo das Modell liegt: im On-Chip-SRAM oder im externen DRAM.

Der Mikrocontroller-Bereich

Bei einem Mikrocontroller liegt die Obergrenze im On-Chip-SRAM: oft nur 256 KB bis 512 KB. Dieses Budget muss die Aktivierungen und Arbeitsbuffer des Modells (die Laufzeit-Tensoren) aufnehmen, daher muss das Modell klein und quantisiert sein, um hineinzupassen, während seine Gewichte im Flash gespeichert werden. Die Quantisierung ist hier der Hebel: Die Umwandlung von Gewichten von 32-Bit-Gleitkomma in 8-Bit-Ganzzahlen verkleinert ein Modell um etwa das Drei- bis Vierfache bei nur geringem Genauigkeitsverlust — genug, damit ein quantisiertes Netzwerk der MobileNet-Klasse in etwa 1 MB Flash passt, wo die Gleitkomma-Version nicht hineinpasst.

Der Edge-SoC-Bereich

Bei einem größeren Edge-SoC, das Vision-Pipelines oder ein kleines Sprachmodell ausführt, verlagert sich die Einschränkung auf externes LPDDR, bei dem die Kapazität weniger zählt als die Geschwindigkeit, mit der Gewichte und Aktivierungen gestreamt werden können. Speicher ist auch eine Beschaffungsfrage. Die Neuzuteilung der DRAM-Kapazitäten hin zu AI-Rechenzentren im Jahr 2026 hat die LPDDR-Preise steigen lassen und das Angebot verknappt. Anbieter kämpfen auf der Bandbreitenseite denselben Kampf: Im Mai bezeichnete Synaptics die Speicherbandbreite als den primären Flaschenhals für die Inferenz von Sprachmodellen auf dem Gerät und verwies auf aggressive Gewichtskompression als Weg, um Durchsatz zurückzugewinnen.

Den großen Chip zuletzt aufwecken

Always-on zu bleiben, ohne die Batterie zu leeren, läuft darauf hinaus, Detektoren nach Kosten zu staffeln: Die teuren Stufen bleiben dunkel, bis eine günstigere ihnen das Recht gibt, aufzuwachen. Was auch immer kontinuierlich läuft, bestimmt die Ruhestromaufnahme des Systems, daher besteht die Aufgabe darin, diese unterste Stufe so sparsam wie möglich zu machen und sie alles darüber steuern zu lassen.

Die Mikrofon-Stufe

Ein intelligentes MEMS-Mikrofon führt ein winziges neuronales Netzwerk zur Sprachaktivitätserkennung mit einigen Dutzend Mikroampere aus, schaltet dann nur bei erkannter Sprache auf ein tieferes Modell zur Keyword-Erkennung hoch und weckt den Host erst danach.

Die Bewegungs-Stufe

Der Machine-Learning-Kern einer IMU klassifiziert Aktivitäten direkt im Sensor und löst einen Interrupt aus. Der Host-Prozessor und jeder Beschleuniger bleiben im Tiefschlaf, bis eine interessierende Klasse auftritt.

Die Anwesenheits-Stufe

Ein 60-GHz-Radar, wie etwa Infineon’s BGT60LTR11AIP, oder ein Multi-Zonen-Time-of-Flight-Sensor übernimmt die Anwesenheitserkennung mit On-Chip-Verarbeitung und weckt eine Kamera oder eine vollständige Vision-Pipeline erst dann, wenn bestätigt ist, dass eine Person anwesend ist.

Die Einsparungen zeigen sich darin, wie diese Produkte die meiste Zeit verbringen: im Leerlauf. Zur groben Einordnung: Ein System, das einen Host zum Zuhören wach hält, liegt bei der Stromaufnahme im Milliampere-Bereich, während ein gestuftes Frontend im Leerlauf mit einigen Dutzend Mikroampere auskommt und nur für einen Bruchteil einer Sekunde Milliampere zieht, wenn tatsächlich etwas passiert. Bei einer Knopfzelle bedeutet der Unterschied zwischen Always-on und gestuft nicht Tage, sondern Jahre an Lebensdauer.

Intelligenz in die günstigste Stufe verlagern

Über Sensorik, Speicher und Energie hinweg lässt sich die Designlogik auf zwei Prinzipien verdichten, die Ihre Bauteilauswahl leiten sollten:

  • Lösen Sie jede Entscheidung so weit unten im Stack wie möglich. Jede Klassifizierung, die eine IMU, ein Mikrofon oder ein Anwesenheitssensor selbst treffen kann, ist eine, für die der Host nie aufgeweckt werden muss.
  • Das Bewegen von Daten kostet mehr als das Rechnen. Bytes, die über einen Bus oder in die Cloud geschoben werden, verbrauchen mehr Energie als die Berechnung selbst. Bevorzugen Sie daher Bauteile, die Ergebnisse statt Rohdaten melden. 

Jede Funktion, die Sie in den Sensor verlagern, muss der Host-Prozessor, der Speicher und die Schnittstelle nicht mehr tragen. Der Kompromiss ist Flexibilität. Verlagern Sie Intelligenz in den Sensor, wenn die Aufgabe stabil und gut verstanden ist. Belassen Sie sie auf dem Host, wenn sich das Modell häufig ändern wird oder im Feld nachtrainiert werden muss, wo das erneute Flashen der Firmware besser ist, als eine fest verdrahtete Engine neu aufzulegen. 

Eine Orientierung dazu, wo im Stack jedes Stück Intelligenz hingehört, bietet The Edge-Sensing BOM: What to Spec, from IMUs to Interfaces; dort wird die BOM Zeile für Zeile durchgearbeitet: IMUs, Time-of-Flight, Radar, Mikrofone, Sensor-Hubs, Speicher und Schnittstellen.

Über den Autor / über die Autorin

Über den Autor / über die Autorin

Adam Fleischer is a principal at etimes.com, a technology marketing consultancy that works with technology leaders – like Microsoft, SAP, IBM, and Arrow Electronics – as well as with small high-growth companies. Adam has been a tech geek since programming a lunar landing game on a DEC mainframe as a kid. Adam founded and for a decade acted as CEO of E.ON Interactive, a boutique award-winning creative interactive design agency in Silicon Valley. He holds an MBA from Stanford’s Graduate School of Business and a B.A. from Columbia University. Adam also has a background in performance magic and is currently on the executive team organizing an international conference on how performance magic inspires creativity in technology and science. 

Related Technical Documentation

Ähnliche Resourcen

Zur Startseite
Thank you, you are now subscribed to updates.