Die meisten Menschen behandeln lokale KI noch immer wie einen Luxus.
Sie kaufen eine 3.000 $ NVIDIA DGX Spark oder stapeln 800 $ Mac Minis, in der Annahme, dass autonome Intelligenz massive, zentralisierte Hardware erfordert.
Aber die Ingenieure, die physische KI tatsächlich in großem Maßstab einsetzen, bauen etwas viel Günstigeres: einen verteilten Schwarm.
- Ein Chip für 8 $ hört dem Raum zu.
- Ein weiterer Chip für 8 $ verarbeitet die Absicht lokal.
- Ein deterministisches Skript entfernt Hintergrundgeräusche.
- Ein dritter Chip führt den Bluetooth-Befehl aus.
- Das gesamte Netzwerk läuft mit dem Strom einer einzigen LED.
Das ist physische Schwarm-Architektur.
Bevor du weiterliest:
Setze ein Lesezeichen für diese Anleitung, damit du zu den Bauanleitungen am Ende zurückkehren kannst, wenn deine Teile eintreffen. Und folge
@ardchain — Ich analysiere autonome Agenten, lokale KI-Pipelines und die Systeme, die sowohl Code als auch günstige Hardware in skalierbare, automatisierte Geschäfte verwandeln.
(Hinweis: Ich habe am Ende dieses Beitrags eine vollständige, Schritt-für-Schritt-Anleitung für Hardware und Flashen eingefügt. Aber bevor du anfängst, Teile zu bestellen, musst du verstehen, wie die Architektur tatsächlich funktioniert).
Ich habe Wochen damit verbracht, das slvDev/esp32-ai GitHub-Repository und Produktions-IoT-Muster zu sezieren, um lokale Intelligenz in einem praktischen Playbook neu aufzubauen.
Anstatt ein massives, zentralisiertes Gehirn zu kaufen, verteilst du die Intelligenz in die Umgebung:
Hören → Analysieren → Weiterleiten → Ausführen
Jeder Mikrocontroller wird zu einem Knoten mit einer begrenzten Aufgabe. Jeder Chip trägt ein bestimmtes Modell. Offline-Inferenz entscheidet, welche Aktion ausgeführt wird. Die wichtige Verschiebung ist, dass dein Smart Home nicht mehr jeden Sprachbefehl durch eine teure API oder eine laute Workstation leiten muss.
Es kann ein LLM mit 28,9 Millionen Parametern vollständig offline auf einem 8 $-ESP32-S3-Chip ausführen, ohne Cloud-Bandbreite zu verbrauchen.
Die grundlegenden Muster sind nicht neu. Hardware-Ingenieure verwenden seit Jahrzehnten Mikrocontroller, I2S-Busse und BLE-Meshs. Was sich geändert hat, ist das, was jetzt in jedem Knoten sitzt. Ein Knoten kann natürliche Sprache verarbeiten, einen unordentlichen Sprachbefehl analysieren, ihn einer starren API zuordnen oder Sensordaten zu einer Entscheidung synthetisieren.
Diese Anleitung unterteilt das gesamte System vom Hardware-Engpass über das Memory Mapping, die I2S-Spracherfassung, die BLE-Ausführung bis hin zu dynamischen Schwärmen, die direkt auf Silizium erzeugt werden.
Am Ende wirst du in der Lage sein, eine physische Aufgabe zu betrachten und nicht mehr zu fragen:
"Welche API sollte ich aufrufen?"
1. PHYSISCHE KI BEGINNT MIT DEM SPEICHER-ENGPASS
Hardware-Marketing wird oft als Grund präsentiert, mehr VRAM zu kaufen. Diese Darstellung verfehlt den eigentlichen technischen Durchbruch.
Du kannst eine RTX 5090 kaufen, um ein 70B-Modell nur zum Einschalten deines Lichts auszuführen, und du wirst dafür mit Hitze, Strom und einer enormen Hardware-Rechnung bezahlen. Ein nützlicher Knoten kontrolliert, wo der Speicher abgelegt ist, welche Komponente jede Entscheidung trifft und wie Daten durch das Silizium fließen.
Stell dir vor, du bittest einen 8 $-ESP32-S3-Mikrocontroller, ein Sprachmodell auszuführen. Die herkömmliche Weisheit sagt, dass es scheitern wird. Der Chip hat nur 512 KB schnellen SRAM und 16 MB Flash. Das Modell wird nicht passen. Innerhalb eines Standard-Frameworks wird dies zu einer unmöglichen Aufgabe. Allein die Einbettungstabelle zerstört den Arbeitsspeicher.
Schwarmtechnik öffnet diesen Engpass und gibt jedem Parameter einen sichtbaren Platz.
Der Durchbruch ist architektonisch. Der Großteil der Einbettungstabelle (ungefähr 25 Millionen Parameter) wird direkt in den Flash gemappt. Der aktive Arbeitsspeicher bleibt im schnellen SRAM.
Das Ergebnis ist ein Workflow, bei dem der Chip nur etwa 450 Bytes pro Token abrufen muss.
Ein Knoten sollte eine Entscheidung treffen
Ein nützlicher physischer Knoten hat eine begrenzte Verantwortung:
- Das Weckwort finden.
- Die Absicht als niedrige, mittlere oder hohe Konfidenz klassifizieren.
- Das Bluetooth-Makro ausführen.
Jeder Knoten benötigt eine klare Eingabe, eine definierte Ausgabe und eine begrenzte Hardware-Fläche. Ein zentraler Mac Mini, der Sprache erfasst, Absichten schätzt, die Antwort entwirft und das Signal sendet, enthält mehrere Fehlerquellen. Das Debuggen bleibt schwierig, weil das gesamte Haus von einer Maschine abhängt.
Kleinere physische Grenzen zeigen genau, welcher Sensor ausgefallen ist.
Ein Edge sollte eine Absicht transportieren
Ein Edge repräsentiert Daten, die für die nächste physische Aktion erforderlich sind. Der Sprachknoten kann ein vorhersagbares JSON-Objekt zurückgeben:
1{2 "sensor": "mic-living-room",3 "confidence": 0.98,4 "intent": "open_chrome_20_tabs",5 "execution_node": "ble-host-1"6}
Schemata reduzieren die Interpretationsabweichung zwischen Chips. Freiform-Audiostreams zwingen jeden nachgelagerten Knoten, die Bedeutung des vorherigen Knotens zu rekonstruieren.
Einige Knoten sind gewöhnlicher Code
Der Workflow muss Befehle deduplizieren, Signale entprellen und Absichten fest codierten Aktionen zuordnen. Diese Operationen haben deterministische Antworten.
So sieht die Ausführungsschleife in der Praxis aus. Das I2S-Mikrofon erfasst die Stimme, das LLM analysiert die Absicht aus dem Flash-Speicher, und der C++-Code feuert den Bluetooth-Befehl ab:
1// 1. Initialisiere das 28M-Parameter-Modell aus gemapptem Flash2LLM modell = LLM_Init(FLASH_GEMAPPTE_EINBETTUNGEN);34void loop() {5 // 2. Erfasse Umgebungsaudio über I2S6 String audio = I2S_Audio_Aufnehmen();78 if (Erkenne_Weckwort(audio)) {9 // 3. Inferenz (ca. 9,5 Token/Sek.)10 String absicht = modell.generieren(audio);1112 // 4. Deterministische Ausführung13 if (absicht.indexOf("open_chrome") > -1) {14 BLE_Sende_Makro(MAC_ADRESSE, BEFEHL_OEFFNE_CHROME);15 }16 }17}
Diese einfache C++-Transformation verarbeitet den Workflow sofort und liefert bei jedem Durchlauf die gleiche Ausgabe. Das Senden derselben Aufgabe an ein anderes Modell fügt Latenz hinzu und schafft einen Fehlerpunkt. Modellknoten gehören zur Verarbeitung natürlicher Sprache und Fuzzy-Logik. Code übernimmt die BLE-Ausführung, das Entprellen und explizite Routing-Regeln.
2. DER SCHWARM: WIE VERTEILTE KNOTEN ARBEIT VERSCHIEBEN
Die meisten ernsthaften physischen KI-Graphen nehmen irgendwann die gleiche Form an. Eine Aufgabe beginnt in der Umgebung, teilt sich auf mehrere unabhängige Sensoren auf, komprimiert die physischen Beweise und übergibt das Ergebnis an eine finale Hardware-Ausführung.
Diese Form ist der Schwarm.
- Fan-out: Umgebungserfassung (I2S-Mikrofone).
- Die Barriere: Offline-LLM (Absichtsanalyse).
- Fan-in: Physische Aktion (BLE-Makros).
Dieses Muster tritt überall dort auf, wo eine Aufgabe zu komplex für starre Wenn-Dann-Regeln wird.
Erfassung sollte unabhängige Eingaben erzeugen
Ein Sensor gehört in die Erfassungsphase, wenn er der Umgebung zuhören und ein nützliches Ergebnis liefern kann, ohne das Hauptgehirn zu wecken.
Ein ESP32 kann fast stromlos kontinuierlich auf ein Weckwort hören. Einmal ausgelöst, bleibt die Orchestrierung auf dem Silizium. Der Chip zeichnet die Stimme auf, führt das Modell aus und gibt eine validierte Absicht zurück.
Reduzieren, bevor du ausführst
Nach der Erfassung der Stimme kann der Knoten mehrere widersprüchliche Interpretationen enthalten. Das Senden von rohem Audio direkt an eine Ausführungsschicht erzeugt Chaos. Die Reduktionsphase bereitet den Befehl vor.
Eine gewisse Reduktion erfolgt durch Quantisierung (4-Bit-Modelle, die in den 16 MB Flash passen). Der Ausführungsknoten erhält einen strengen Befehl, ohne die Rückverfolgbarkeit zu verlieren.
3. DEZENTRALISIERUNG IST TEIL DER ARCHITEKTUR
Ein Knoten kann die Inferenz schnell abschließen und trotzdem die falsche Aktion auslösen. Das System benötigt Regeln, um zu entscheiden, welche Befehle eine Ausführung verdienen.
Routing nach Hardware-Limit
Ein Router liest strukturierte Ausgaben und wählt den nächsten physischen Zweig. Dies hält teure Verarbeitung auf Knoten mit signifikanter Auswirkung konzentriert.
Hardware an den Knoten anpassen
Nicht jeder Raum braucht einen Apple M4-Chip. Extraktion, grundlegende Absichtsklassifizierung und enge Sprachsuchen können auf einem 8 $-ESP32 laufen. Schwere Videoverarbeitung, komplexes Denken und globale Synthese können einen stärkeren zentralen Server rechtfertigen.
Hardware-Stufung wird zu einer weiteren Eigenschaft des Schwarms.
Wissen, wann die Zentralisierung beendet werden muss
Graph-Overhead umfasst Orchestrierung, WLAN-Latenz, Router-Konfigurationen und mehr Netzwerkzustände, die zu debuggen sind. Ein zentralisierter Mac Mini ist normalerweise ausreichend, wenn du nur einen Schreibtisch hast.
Schwarmtechnik wird nützlich, wenn die Umgebung mehrere Räume, teure API-Kosten, große Sensor-Arrays oder die Notwendigkeit vollständiger Offline-Privatsphäre gewinnt.
4. DIE VOLLSTÄNDIGEN BAUANLEITUNGEN
Die Theorie ist nutzlos, wenn du nicht genau weißt, was du löten und flashen musst. Wenn du an diesem Wochenende einen lokalen KI-Knoten bauen möchtest, findest du hier die ungefilterte, Schritt-für-Schritt-technische Anleitung.
Schritt 1: Die Hardware & Verkabelung
Du benötigst genau zwei Komponenten:
- ESP32-S3-Entwicklungsboard (Muss eine Variante mit 16 MB Flash und 8 MB PSRAM sein, damit das Modell-Memory-Mapping funktioniert).
- INMP441 I2S-Mikrofonmodul.
Dies ist physische KI, was bedeutet, dass du es verdrahten musst. Das INMP441 verwendet den I2S-Bus. Löte die Verbindungen genau so:
- VDD \rightarrow 3,3V
- GND \rightarrow GND
- L/R \rightarrow GND (Zieht das Mikrofon auf den linken Kanal)
- WS \rightarrow GPIO 4 (Word Select / Frame Sync)
- SCK \rightarrow GPIO 5 (Serielle Taktung)
- SD \rightarrow GPIO 6 (Serielle Daten)
Schritt 2: Das Modell & der Flash-Vorgang
Du lädst nicht ChatGPT. Du lädst ein destilliertes Modell mit 28,9 Millionen Parametern, das ausschließlich für die Absichtsklassifizierung und strukturierte JSON-Ausgabe optimiert ist.
Du musst dich nicht mit der ESP-IDF-Toolchain herumschlagen. Du kannst die vorkompilierte Binärdatei und die Modellgewichte direkt mit esptool.py flashen.
- Versetze dein Board in den Bootloader-Modus (Halte BOOT, drücke RST, lasse BOOT los).
- Führe den genauen Flash-Befehl aus, der das Modell direkt in die 16 MB Flash-Partition mapped:
1esptool.py --chip esp32s3 --baud 921600 \2 --before default_reset --after hard_reset write_flash -z \3 --flash_mode dio --flash_freq 80m --flash_size 16MB \4 0x10000 build/firmware.bin \5 0x400000 models/intent_classifier_28M_q4.bin
Schritt 3: Der Empfänger (Home Assistant)
Nach dem Flashen benötigt der ESP32 weder WLAN noch eine Cloud-API. Wenn er eine Absicht erkennt, sendet er eine standardmäßige BTHome-kompatible BLE-Nutzlast.
Um dieses Signal zu empfangen und dein Licht tatsächlich einzuschalten:
- Führe Home Assistant mit einer Bluetooth-Integration (oder einem ESP32 BLE-Proxy) aus.
- Der Knoten wird sich automatisch als BTHome-Sensor erkennen lassen.
- Die Absicht (z. B. open_chrome, lights_off) wird als Sensorzustandsänderung angezeigt. Ordne diesen Zustand direkt deinen vorhandenen Automatisierungen zu.
Der Wert liegt darin, die Berechnung unsichtbar zu machen.
Jeder Knoten hat eine begrenzte physische Verantwortung. Jeder Chip trägt eine strukturierte Absicht. Jeder Raum hat einen Grund zu existieren. Jeder Sprachbefehl bleibt offline.
An diesem Punkt läuft dein Haus nicht mehr über eine teure API.
Es führt einen konstruierten Schwarm aus.
