KI im Edge-Device: Was gehört ins Gerät, was in die Zentrale?

Die Frage ist nicht, ob KI ins Gerät gehört, sondern welcher Teil.

Wer ein Edge-Gerät für einen Ladepark baut oder einkauft, steht irgendwann vor der Frage: soll da KI mit hinein? Die Frage ist in dieser Form nicht beantwortbar, weil unter dem Wort drei sehr verschiedene Aufgaben zusammengefasst werden. Bekannte Fehler auf bekannte Maßnahmen abbilden ist eine Aufgabe. In einem Wissensbestand nachschlagen, wenn der Fehler eben nicht bekannt ist, ist eine zweite. Und aus Betriebsdaten verständlichen Text machen, damit ein Mensch am Montagmorgen weiß, was am Wochenende passiert ist, ist eine dritte.

Diese drei Aufgaben haben völlig unterschiedliche Anforderungen an Antwortzeit, Nachvollziehbarkeit und Rechenleistung. Wirft man sie zusammen, landet man schnell bei der Vorstellung, im Schaltschrank müsse ein großes Sprachmodell laufen – und damit bei Hardware, die dort weder wirtschaftlich noch thermisch hingehört. Trennt man sie, wird die Architektur einfach, und das Sizing des Rechners ergibt sich fast von selbst.

Dieser Beitrag zieht die Trennung durch: welche Schicht welche Aufgabe übernimmt, warum das Sprachmodell in einem Ladepark nie selbst schalten sollte, und was am Ende an Arbeitsspeicher und Rechenleistung wirklich nötig ist.

Drei Aufgaben mit drei verschiedenen Anforderungen.

Der erste Teil ist der langweiligste und der wichtigste. Ein großer Teil der Betriebsfehler an Ladepunkten ist bekannt: ein Fehlerstrom in der DC-Überwachung, ein fehlgeschlagenes Firmware-Update, eine abgerissene Backend-Verbindung, eine Autorisierung, die durchläuft, ohne dass das Fahrzeug Ladefreigabe gibt. Für solche Fälle gibt es feste Abläufe. Die gehören in eine deterministische Tabelle, die mit der Firmware versioniert und getestet wird – ohne Modell, ohne Suche, ohne Netz. Sie ist sofort, sie ist auditierbar, und sie funktioniert auch dann, wenn sonst nichts funktioniert.

Der zweite Teil ist der lange Schwanz: unbekannte oder zusammengesetzte Fehler, bei denen Kontext hilft. Was ist an diesem Standort schon einmal passiert, welche Eigenheit hat dieses Ladepunkt-Modell, welche Firmware-Version hatte welchen Nebeneffekt. Das ist eine Nachschlage-Aufgabe. Wichtig dabei: die Suchanfrage entsteht im Gerät nicht aus Alltagssprache, sondern maschinell aus strukturierten Daten – Fehlercode, Statusmeldung, Modellbezeichnung, Firmware-Stand. Also aus präzisen Fachbegriffen. Genau dafür ist eine kompakte Stichwortsuche über einen lokalen Index bereits sehr stark; eine Vektordatenbank am Standort löst hier ein Problem, das man in dieser Form nicht hat.

Der dritte Teil ist die einzige Aufgabe, für die es wirklich ein Sprachmodell braucht: aus Fakten Sprache machen. Der Tagesbericht, der Hinweis für den Techniker, die Zusammenfassung einer Störungshistorie. Hier liegt der Nutzen darin, dass ein Mensch schneller versteht – nicht darin, dass eine Maschine schneller entscheidet.

• Bekannter Fehler, bekannte Maßnahme: deterministische Tabelle, mit der Firmware versioniert und getestet.
• Unbekannter Fehler: Nachschlagen in einem kompakten lokalen Index, Anfrage maschinell aus Fehlercode und Statusmeldung.
• Formulieren für Menschen: die einzige Aufgabe, die ein Sprachmodell zwingend braucht.
• Handeln: gehört in keine dieser drei Schichten, sondern in eine eigene – siehe nächster Abschnitt.

Das Sprachmodell schlägt vor, eine deterministische Schicht entscheidet.

Soll das Gerät nicht nur beraten, sondern selbst eingreifen, wird aus einer Komfortfrage eine Sicherheitsfrage. Ein Ladepark-Controller schützt einen Netzanschluss und verteilt Leistung über Unterkreise, an denen außer Ladepunkten oft noch anderes hängt. Eine falsche Maßnahme bedeutet im besten Fall einen abgebrochenen Ladevorgang und im schlechteren eine ausgelöste Hauptsicherung. Ein Sprachmodell, das direkt schaltet, ist an dieser Stelle die falsche Architektur – unabhängig davon, wie gut sein Wissen ist.

Die tragfähige Aufteilung lautet: das Modell schlägt vor, eine deterministische Schicht entscheidet. Erlaubt ist nur, was auf einer Positivliste steht, jede Aktion mit geprüften Vorbedingungen und jede Aktion umkehrbar. Stromgrenze reduzieren ja. Sanfter Neustart eines Ladepunkts, an dem keine Transaktion läuft, ja. Alles, was Last erhöht, Schutzfunktionen anfasst oder eine laufende Abrechnung unterbricht, gehört nicht auf diese Liste – auch dann nicht, wenn der Vorschlag plausibel klingt.

Dazu gehört ein vollständiges Protokoll: Auslöser, Vorschlag, Entscheidung, Ergebnis, mit Zeitstempel. Das ist nicht nur Fehlersuche. Es ist die Grundlage dafür, dass ein Betreiber der Automatik überhaupt vertraut, und es ist die Grundlage jeder Haftungsfrage. Automatisierung, die man nicht nachvollziehen kann, wird im Betrieb nach dem ersten unerwarteten Eingriff abgeschaltet – und ist damit wertlos.

Sizing folgt aus der Architektur, nicht aus der Modellgröße.

Ist die Trennung gemacht, ist das Sizing fast trivial. Das Regelwerk und der Wissensindex kosten praktisch nichts: ein Wissensbestand von einigen tausend Einträgen ist eine Datei im einstelligen Megabyte-Bereich, die Suche darin belegt keinen messbaren Arbeitsspeicher. Beides läuft auf der Hardware, die für OCPP-Server und Lastmanagement ohnehin im Schrank steckt.

Der einzige echte Kostentreiber ist die Textgenerierung, und dafür gibt es genau zwei Antworten. Entweder sie passiert zentral – dann braucht der Standort dafür gar nichts, nur einen Netzzugang und eine Schnittstelle. Oder sie muss offline funktionieren, dann reicht ein kleines Modell der 2- bis 4-Milliarden-Parameter-Klasse. Quantisiert belegt so ein Modell etwa zwei bis drei Gigabyte Arbeitsspeicher, läuft ohne Grafikkarte auf einer modernen CPU und antwortet in Sekunden. Für einen Hinweis an den Techniker ist das reichlich.

Was nicht in einen Schaltschrank gehört, sind Modelle der 30-Milliarden-Klasse. Rund zwanzig Gigabyte Speicherbedarf und eine Grafikkarte machen daraus eine Workstation, keine Appliance – mit entsprechender Abwärme, Stromaufnahme und Ersatzteilfrage über eine Anlagenlaufzeit von zehn Jahren. Solche Modelle sind in der Zentrale sinnvoll, nicht am Standort.

• Regelwerk und Wissensindex: wenige Megabyte, kein messbarer Arbeitsspeicher, läuft auf bestehender Hardware.
• Textgenerierung zentral: keine zusätzliche Anforderung am Standort außer Netzzugang und Schnittstelle.
• Textgenerierung lokal und offline: kleines Modell, etwa 2 bis 3 GB Arbeitsspeicher, ohne Grafikkarte machbar.
• Faustregel: 8 GB RAM tragen Regelwerk, Index und ein kleines Modell; 16 GB geben Luft für Wachstum.
• Nicht in den Schaltschrank: Modelle der 30-Milliarden-Klasse mit rund 20 GB Bedarf und Grafikkarte.

Der Tagesbericht gehört fast immer in die Zentrale.

Der Tagesbericht ist der einfachste Fall und gleichzeitig das beste Beispiel für die Trennung. Er ist nicht zeitkritisch, er muss nicht offline funktionieren, und er profitiert von einem größeren Modell, weil die Formulierung besser wird. Genau deshalb gehört er nicht ins Gerät.

Das Muster ist schlicht: das Gerät schickt die strukturierten Fakten des Tages über eine Schnittstelle an die Zentrale – geladene Energie, Anzahl und Dauer der Ladevorgänge, aufgetretene Fehler, Eingriffe des Lastmanagements, bei Bedarf Erzeugung und Bezug. Die Zentrale macht daraus Text und verschickt ihn. Das Gerät selbst kennt kein Modell und braucht keine Modell-Abhängigkeit.

Der Gewinn ist mehr als gesparte Hardware. Es gibt ein Modell zu pflegen statt eines pro Standort. Eine Verbesserung an der Formulierung wirkt sofort überall. Und fällt die Verbindung aus, kommt der Bericht später – was harmlos ist, im Unterschied zum Lastmanagement, das genau deshalb lokal bleiben muss. Diese Asymmetrie ist der eigentliche Grund für die Aufteilung: lokal gehört hin, was nicht warten kann.

Der eigentliche Gewinn ist die Rückkopplung aus dem Feld.

Nachschlagen und Formulieren sind nützlich, aber ersetzbar. Nicht ersetzbar ist etwas anderes: dass jeder gelöste Vorfall an einem Standort zu Wissen für alle Standorte wird. Wer dreißig Ladeparks betreut, löst denselben Fehler sonst dreißig Mal zum ersten Mal.

Dafür muss der Kreis geschlossen sein. Das Gerät meldet, was passiert ist, was vorgeschlagen wurde, was ausgeführt wurde und wie es ausgegangen ist. Zentral wird daraus ein kuratierter Eintrag, und der geht mit dem nächsten Update an alle Geräte. Wichtig ist die Trennung von Pflegen und Ausliefern: kuratiert wird zentral, in einem Werkzeug, das Menschen tatsächlich benutzen. Ausgeliefert wird ein kompilierter, schreibgeschützter Index. So bleibt im Feld kein Fremddienst, keine Lizenz pro Gerät und keine Abhängigkeit, die den Anbieter überleben muss.

Der Einstieg ist deshalb kein Modell, sondern eine Liste. Wer seine zehn häufigsten Betriebsfehler aufschreibt, mit der Maßnahme, die tatsächlich geholfen hat, hat den schwierigen Teil erledigt. Der Rest ist Technik – und lässt sich Schritt für Schritt ergänzen, ohne dass ein Ladepark dafür zum Versuchsfeld wird.