Edge AI vs. Cloud AI ist eine der ersten Architekturentscheidungen in jedem IoT-Projekt mit Machine Learning, und eine Fehlentscheidung zeigt sich später in trägen Alarmen, hohen Bandbreitenrechnungen oder Datenschutzprüfungen, die das Deployment blockieren. Dieser Vergleich erklärt, wo welcher Ansatz bei Latenz, Datenschutz, Kosten und Modellgröße überlegen ist, gibt Ihnen eine Checkliste für die Entscheidung an die Hand und zeigt ein hybrides Muster, bei dem Edge-Ergebnisse über MQTT zu Cloud-Modellen fließen.
Die beiden Ansätze in Kürze
Edge AI führt die Inferenz auf dem Gerät oder auf einem Gateway daneben aus. Die Sensordaten bleiben lokal, und das Gerät veröffentlicht Schlussfolgerungen: ein Klassenlabel, einen Anomaliewert, eine Anzahl. Wenn Sie eine Einführung brauchen, beginnen Sie mit was Edge AI ist.
Cloud AI sendet Daten an Server, auf denen Modelle mit praktisch unbegrenzter Rechenleistung laufen. Das Gerät ist eine Datenquelle; die Intelligenz sitzt zentral.
In der Praxis sind nur sehr wenige Produktivsysteme rein das eine oder das andere. Die nützliche Frage lautet, welche Entscheidungen wohin gehören.
Edge AI vs. Cloud AI im direkten Vergleich
| Faktor | Edge AI | Cloud AI |
|---|---|---|
| Latenz | Millisekunden, kein Netzwerk-Roundtrip | Netzwerk-Roundtrip plus Warteschlangen; abhängig von der Konnektivität |
| Funktioniert offline | Ja | Nein |
| Bandbreite | Gering; nur Ergebnisse verlassen das Gerät | Hoch, wenn Rohdaten (Video, Audio, hochfrequente Vibration) gestreamt werden |
| Datenschutz | Rohdaten bleiben vor Ort | Rohdaten verlassen den Standort und müssen bei Übertragung und Speicherung geschützt werden |
| Modellgröße | Begrenzt durch Speicher und Energie des Geräts | Große Modelle, Ensembles und LLMs sind praktikabel |
| Geräteübergreifender Kontext | Nur das, was ein Gerät sieht | Korreliert alle Geräte, Standorte und Historie |
| Modelle aktualisieren | Flotten-Rollout, Versionierung, Rollback | Ein einziges Deployment |
| Hardwarekosten | Pro Gerät; Beschleuniger erhöhen die Kosten | Gemeinsame Infrastruktur; Bezahlung für Rechenleistung und Übertragung |
| Betriebskosten | Nach dem Deployment überwiegend fix | Steigen mit Datenvolumen und Inferenzrate |
| Monitoring | Schwieriger; erfordert Telemetrie von den Geräten | Einfacher; Logs und Metriken liegen zentral |
Keine dieser Zeilen ist für sich allein ausschlaggebend. Ein Sicherheitsstopp, der innerhalb weniger zehn Millisekunden reagieren muss, gehört unabhängig von den Kosten an die Edge. Eine flottenweite Prognose, die die Historie jedes Standorts benötigt, gehört unabhängig von der Latenz in die Cloud.
Latenz und Zuverlässigkeit
Edge-Inferenz ist durch die Rechenleistung des Geräts begrenzt, und diese Grenze ist vorhersehbar. Cloud-Inferenz hängt vom Netzwerk ab, und das ist es nicht. Mobilfunkverbindungen, überlastetes Fabrik-WLAN und Wartungsfenster verursachen Verzögerungen oder Ausfälle. Wenn auf eine Vorhersage eine physische Aktion folgt, etwa ein Teil ausschleusen, ein Förderband stoppen oder ein Ventil öffnen, behalten Sie die Entscheidung an der Edge und behandeln die Cloud als Empfänger des Ergebnisses.
Datenschutz und Data Governance
Kameras und Mikrofone sind die eindeutigsten Fälle. Videos von Menschen an eine Drittanbieter-Cloud zu senden wirft Fragen zu Einwilligung, Aufbewahrung und Datenstandort auf, im DACH-Raum vor allem im Licht der DSGVO und oft auch der Mitbestimmung durch den Betriebsrat. Die Erkennung lokal auszuführen und „2 Personen in Zone B“ zu veröffentlichen vermeidet die meisten davon. Dieselbe Logik gilt für Produktionsdaten, die ein Hersteller als vertraulich betrachtet: Eine Fehlerquote ist weniger sensibel als Bilder eines neuen Produkts.
Kosten: Wohin das Geld fließt
Bei Edge AI fallen die Kosten vorab für Hardware und Engineering an: Beschleuniger, robuste Gehäuse und die Arbeit, Modelle zu verkleinern. Bei Cloud AI werden die Kosten zu laufenden Ausgaben, die mit dem Datenvolumen wachsen. Bei kontinuierlichen, hochfrequenten Signalen wie Video ist es meist die teure Option, alles in die Cloud zu streamen. Bei spärlichen Daten, etwa einem Messwert alle paar Minuten, kann Cloud-Inferenz günstiger sein, weil Sie an keinem Standort intelligentere Hardware brauchen. Schätzen Sie beides mit Ihren eigenen Datenraten ab, statt sich auf Faustregeln zu verlassen.
Modellgröße und Leistungsfähigkeit
Mikrocontroller führen Modelle aus, die in Kilobytes gemessen werden; GPU-Edge-Module führen Erkennungsmodelle mit Millionen Parametern aus; die Cloud führt alles aus, was Sie sich leisten können, einschließlich großer Sprachmodelle. Erfordert die Aufgabe breites Weltwissen, langen Kontext oder Schlussfolgerungen über viele Quellen, gehört sie in die Cloud. Handelt es sich um eine eng umrissene Wahrnehmungsaufgabe wie „Ist dieses Geräusch ungewöhnlich?“, ist ein kleines Edge-Modell oft genauso genau. Was TinyML ist erklärt, wie klein das werden kann.
Entscheidungs-Checkliste
Gehen Sie diese Fragen für jede Vorhersage Ihres Systems durch:
- Hängt eine Aktion innerhalb einer Sekunde von der Vorhersage ab? Wenn ja, Edge.
- Muss das System ohne Internet weiterarbeiten? Wenn ja, Edge.
- Sind die Rohdaten sensibel oder reguliert? Wenn ja, bevorzugt Edge, und abgeleitete Ergebnisse veröffentlichen.
- Ist die Rohdatenrate hoch (Video, Audio, Sensoren im kHz-Bereich)? Wenn ja, bevorzugt Edge.
- Braucht die Vorhersage Daten vieler Geräte oder eine lange Historie? Wenn ja, Cloud.
- Braucht das Modell mehr Speicher, als Ihre Geräteklasse hat? Wenn ja, Cloud oder ein Edge-Gerät der Gateway-Klasse.
- Ändert sich das Modell wöchentlich? In der Cloud lässt es sich leichter iterieren; die Edge braucht eine solide Update-Pipeline.
Die meisten Projekte landen bei einer Aufteilung: Wahrnehmung an der Edge, Kontext und Planung in der Cloud.
Das hybride Muster: Edge-Ergebnisse fließen über MQTT zu Cloud-Modellen
Die hybride Architektur hat drei Schichten:
- Edge-Geräte führen Wahrnehmungsmodelle aus und veröffentlichen kompakte Ergebnisse auf Topics wie
site/area/line/device/inference. - Ein Broker verteilt diese Ergebnisse. Geräte müssen nie wissen, wer sie konsumiert.
- Cloud-Konsumenten abonnieren die Ergebnisse vieler Geräte und führen Modelle der zweiten Stufe aus: flottenweite Anomalieerkennung, Prognosen, Korrelation von Grundursachen oder ein LLM, das Ereignisse für das Bedienpersonal zusammenfasst.
In der Fabrik ist diese Topic-Struktur idealerweise Teil eines Unified Namespace (UNS): Die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/inference. Cloud-Modelle, MES und Leitstand finden die Edge-Ergebnisse dann an derselben Stelle wie die übrigen Maschinendaten; siehe Sparkplug B und Unified Namespace.
Die Cloud kann auch Entscheidungen zurücksenden: einen neuen Schwellenwert, die Anforderung einer Rohdatenprobe oder einen Hinweis auf ein Modell-Update, veröffentlicht auf einem Befehls-Topic, das das Gerät abonniert.
MQTT eignet sich dafür, weil Edge-Ergebnisse kleine, häufige Ereignisse mit vielen Konsumenten sind. Ein Cloud-MQTT-Broker sitzt ganz natürlich zwischen den Schichten, sodass sich Edge-Geräte ausgehend über TLS verbinden und in den Standortnetzen keine eingehenden Ports nötig sind.
Beispiel: ein Aggregator auf der Cloud-Seite
Dieser Python-Worker abonniert die Inferenzergebnisse aller Geräte unter einem Präfix und wendet eine einfache Regel der zweiten Stufe auf die gesamte Flotte an: Melden mehrere Geräte derselben Linie innerhalb eines kurzen Zeitfensters Anomalien, veröffentlicht er einen Alarm auf Linienebene. Eine solche Korrelation kann kein einzelnes Edge-Gerät leisten.
import json
import time
import uuid
from collections import defaultdict, deque
import paho.mqtt.client as mqtt
PREFIX = "connectmq/demo/3f9c1a7e" # use your own unique prefix
SUB = f"{PREFIX}/+/+/+/inference" # site/area/device/inference
WINDOW_S, MIN_DEVICES = 120, 2
recent = defaultdict(deque) # line key -> deque of (ts, device)
def on_connect(client, userdata, flags, reason_code, properties):
print("connected:", reason_code)
client.subscribe(SUB, qos=1)
def on_message(client, userdata, msg):
_, _, _, site, area, device, _ = msg.topic.split("/")
result = json.loads(msg.payload)
if result.get("label") == "normal":
return
key = f"{site}/{area}"
now = time.time()
q = recent[key]
q.append((now, device))
while q and now - q[0][0] > WINDOW_S:
q.popleft()
devices = {d for _, d in q}
if len(devices) >= MIN_DEVICES:
alert = {"scope": key, "devices": sorted(devices), "window_s": WINDOW_S,
"reason": "correlated anomalies"}
client.publish(f"{PREFIX}/{site}/{area}/alerts", json.dumps(alert), qos=1)
print("ALERT", alert)
q.clear()
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"cloud-agg-{uuid.uuid4().hex[:6]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Das Beispiel nutzt den öffentlichen MQTT-Broker broker.connectmq.com, der für Tests und Prototypen gedacht ist; senden Sie dort keine Produktionsdaten. Simulieren Sie zwei Edge-Geräte, die Anomalien melden:
P=connectmq/demo/3f9c1a7e
mosquitto_pub -h broker.connectmq.com -p 1883 -i dev-a-81 -q 1 \
-t "$P/site1/pumps/pump-01/inference" -m '{"label":"bearing_wear","score":0.81}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i dev-b-82 -q 1 \
-t "$P/site1/pumps/pump-02/inference" -m '{"label":"cavitation","score":0.77}'
Der Aggregator gibt einen Linienalarm aus und veröffentlicht ihn. Wenn ein Worker nicht ausreicht, betreiben Sie mehrere Instanzen mit einer MQTT-5-Shared-Subscription wie $share/agg/connectmq/..., damit der Broker die Nachrichten zwischen ihnen verteilt; bei ConnectMQ sind Shared Subscriptions ab dem Plan Serverless (Paid) verfügbar. Beachten Sie, dass ein zustandsbehafteter Korrelator wie dieser darauf angewiesen ist, dass Nachrichten derselben Linie beim selben Worker ankommen. Partitionieren Sie daher nach Topic, statt blind zu teilen.
Häufige Fehler bei hybriden Architekturen
- Rohdaten „für alle Fälle“ streamen. Senden Sie Rohdatenproben nur auf Anforderung oder bei Anomalien, über ein separates Topic.
- Zeitkritische Entscheidungen der Cloud überlassen. Behalten Sie den Reflex an der Edge und nutzen Sie die Cloud für Richtlinien.
- Keine Versionsfelder. Jedes Ergebnis sollte die Modellversion nennen, die es erzeugt hat, damit Cloud-Modelle Änderungen berücksichtigen können.
- Limits für die Nachrichtengröße ignorieren. Ergebnisse sollten deutlich unter dem Limit Ihres Brokers liegen; auf dem öffentlichen MQTT-Broker beträgt es 64 KB.
- Nicht authentifizierte Befehls-Topics. Alles, was das Verhalten von Geräten ändern kann, muss über einen privaten Broker mit Zugangsdaten und TLS laufen.
Mehr darüber, wie sich diese Schichten in ein vollständiges AIoT-System einfügen, lesen Sie im Leitfaden zu KI und IoT. Wenn Sie bei der Hardwareauswahl angekommen sind, vergleichen Sie Boards im Vergleich von Edge-AI-Hardware.
Edge und Cloud mit ConnectMQ verbinden
Das hybride Muster funktioniert nur, wenn die Verbindung zwischen Edge und Cloud zuverlässig und sicher ist. ConnectMQ bietet einen verwalteten MQTT-Broker mit MQTT 5, TLS auf Port 8883 und Shared Subscriptions in den kostenpflichtigen Plänen, damit Sie sich auf Modelle statt auf den Broker-Betrieb konzentrieren können. Erstellen Sie einen Broker im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte.
Häufig gestellte Fragen
Ist Edge AI besser als Cloud AI?
Keines von beiden ist grundsätzlich besser. Edge AI punktet bei Latenz, Offline-Betrieb und Datenschutz; Cloud AI bei Modellgröße, geräteübergreifendem Kontext und einfacher Iteration. Die meisten IoT-Systeme nutzen beides.
Kann ich in der Cloud beginnen und später an die Edge wechseln?
Ja, das ist ein gängiger Weg. Legen Sie zuerst das Format der Ergebnisnachrichten fest, damit Cloud-Konsumenten weiterhin dieselben Nachrichten auf denselben Topics erhalten, wenn die Inferenz auf das Gerät wandert.
Was sollte ein Edge-Gerät an die Cloud senden?
Inferenzergebnisse mit Zeitstempel, Konfidenz und Modellversion, einen regelmäßigen Heartbeat und Rohdatenproben nur auf Anforderung oder wenn eine Anomalie erkannt wurde.
Braucht hybride Edge-Cloud-KI einen Message Broker?
Nicht zwingend, aber ein Broker entkoppelt Geräte von Konsumenten, fängt unterbrochene Verbindungen mit QoS und Sessions ab und lässt Sie neue Cloud-Konsumenten hinzufügen, ohne die Geräte anzufassen.
