Exowatt übertrifft Frontier-Modelle bei der Genauigkeit mit serverlosem Modell-Customizing von SageMaker

Exowatt baut modulare, dispatchbare Solarsysteme, die zuverlässige Energie für energieintensive Anwendungen wie KI-Rechenzentren liefern. Sein Flaggschiffprodukt, das Exowatt P3, fängt Solarenergie über optische Linsen ein, speichert sie als Wärme in einem thermischen Langzeitakku und gibt Strom on demand über eine Wärmekraftmaschine ab. Im Gegensatz zu netzgekoppelten Photovoltaik-Solarsystemen versorgt das P3 Rechenzentren direkt hinter dem Zähler, sodass Rechenzentren online gehen können, ohne in mehrjährigen Warteschlangen für den Netzanschluss zu warten. Exowatt baut eine Flotte von KI-Agenten auf, die Live-Alarme überwachen und einstufen und Betriebentscheidungen für Solarsysteme unterstützen – oft am Edge mit begrenzter oder keiner Konnektivität. Da die Flotte von Prüfständen hin zur Fertigung und zu Tausenden von im Feld eingesetzten Einheiten skaliert, muss die Intelligenzschicht, die diese Systeme betreibt, mitwachsen.

In diesem Beitrag zeigen wir, wie Exowatt das serverlose Modell-Customizing von Amazon SageMaker AI nutzte, um eine wiederholbare KI-Pipeline aufzubauen. Die Pipeline erzeugt aufgabenspezifische feinabgestimmte Modelle für zwei Bereitstellungsziele, Edge und Cloud, und erreicht damit eine höhere Genauigkeit als Frontier-Modelle bei bis zu 49× niedrigeren Kosten.

Die beiden hier beschriebenen Modelle sind die ersten Ergebnisse dieser Pipeline und nicht das Endziel. Das dauerhaftere Ergebnis des Projekts war die Pipeline selbst: ein wiederholbarer Weg von den Rohbetriebsdaten zu einem zertifizierten Trainingsdatensatz, einem feinabgestimmten Modell und einem evaluierten Bereitstellungsartefakt. Exowatt kann diesen Weg nun in Tagen statt Monaten durchlaufen. Alarm-Triage und Energiemarktanalyse sind zwei von vielen schmalen, hochwertigen Aufgaben, auf die derselbe Ansatz anwendbar ist.

Die Herausforderung: KI auf physischer Energieinfrastruktur

Das Energiemanagementsystem (EMS) von Exowatt läuft über eine wachsende Flotte von Betriebsstandorten. Jeder Standort erzeugt kontinuierlich Alarme: eine Hardwarekomponente außerhalb der Spezifikation, eine unterbrochene Verbindung, eine Spannungsmessung außerhalb des Bereichs und ähnliche Ereignisse. Da die Flotte auf Tausende von Feldeinheiten skaliert, kann ein menschlicher Bediener nicht jeden Standort in Echtzeit überwachen. Exowatt benötigte einen KI-Agenten, der den Alarmzustand an jedem Standort lesen und die richtige nächste Aktion autonom und zuverlässig ergreifen oder empfehlen kann.

Ein Frontier-Modell konnte dieses Problem aus drei Gründen nicht lösen:

1. Die Aufgabe ist schmal und proprietär. Die Alarm-Triage auf dem EMS von Exowatt hängt von dessen spezifischer Hardware, Daten und Betriebslogik ab. Ein universelles Frontier-Modell ist dafür nicht spezialisiert.
2. Er muss am Edge laufen, ohne GPU und oft ohne Internet. Viele Standorte haben eine begrenzte oder intermittierende Konnektivität, sodass ein Agent, der von einem Cloud-Aufruf an ein Frontier-Modell abhängt, den Bediener ohne Abdeckung lässt, sobald die Verbindung abbricht.
3. Die Kosten skalieren nicht auf Flottenebene. Jede Betriebentscheidung an ein Frontier-Modell über Tausende von Standorten hinweg zu leiten, ist für eine sich kontinuierlich wiederholende Entscheidung nicht wirtschaftlich.

Aus diesem Grund wandte sich Exowatt dem Modell-Customizing zu. Der anfängliche Feinabstimmungs-Workflow von Exowatt erforderte die Auswahl eines Open-Weight-Modells, den Aufbau eines Containers und die Erstellung eines eigenen Trainingsrezepts, bevor ein Experiment laufen konnte. Dies war ein großes Hindernis für die Modell-Experimentation. Zudem mussten sie die GPU-Hardwareanforderungen für die Feinabstimmung festlegen. Als das Team das Tempo der Experimente erhöhte, erforderte jeder Lauf zunächst die Wahl eines bestimmten GPU-Instanztyps und dann das Warten, bis diese selbst gewählte Kapazität verfügbar wurde. Wenn ein gewählter Instanztyp nicht verfügbar war, konnte dies den Start eines Laufs verzögern oder ihn vollständig blockieren.

Sie benötigten ein Modell, das klein genug ist, um auf einem Edge-Controller ohne GPU zu laufen, und gleichzeitig genau genug im Vergleich zum Frontier-Modell bei der spezifischen Aufgabe, um autonom zu agieren. Feinabstimmung schloss diese Lücke: ein kompaktes, aufgabenspezialisiertes Modell, das sowohl in der Cloud als auch am Edge bereitstellbar ist.

Überblick über die Lösung

Exowatt begegnete diesen Herausforderungen mit einem Cloud-nativen, serverlosen Ansatz zum Modell-Customizing auf Amazon SageMaker AI. Derselbe Trainingspipeline erzeugt feinabgestimmte Modelle für zwei Bereitstellungsziele: den Edge und die Cloud.

Exowatt implementierte diesen Ansatz für den ersten Anwendungsfall, die Edge-Alarm-Triage, mit dem Qwen3-1.7B-Modell und wandte denselben Ansatz dann auf das Qwen3-14B-Modell für den zweiten Anwendungsfall, die Cloud-Energiemarktanalyse, an. Das Unternehmen plant, diese Lösung wiederzuverwenden, um über die Flotte hinweg kleinere, aufgabenspezifische Modelle zu erstellen.

Abbildung 1: Feinabstimmungs- und Bereitstellungspipeline von Exowatt über die Phasen Build, Cloud-Serving und Edge-Serving

Die folgenden sieben AWS-Services treiben die KI-Pipeline an – ohne Instanzen, Cluster oder Endpunkte zu verwalten:

Der Workflow ist in drei Stufen gegliedert:

Modellanpassung (Cloud): Exowatt feintunt Open-Weight-Basismodelle mit serverlosem Model Customization, Low-Rank Adaptation (LoRA) und supervised fine-tuning (SFT) auf SageMaker AI. Da serverloses Training Kapazität bei Bedarf zuweist, fuhrt das Team mehrere Experimente pro Tag durch, anstatt auf selbst beschaffte GPUs zu warten. Nach der Evaluierung wird das beste Modell in der SageMaker AI Model Registry registriert.

Edge-Deployment: Für latenzempfindliche Arbeiten mit eingeschränkter Konnektivität wie die Alarm-Triage wird das feingetunte Qwen3-1.7B-Modell eingefroren, in das GGUF-Format quantisiert und mit llama.cpp in Kubernetes-Pods am Edge mithilfe von Vor-Ort-Controllern ausgefuhrt. Dieser Weg benotigt keine GPU und funktioniert ohne Internetverbindung.

Cloud-Deployment (elastisch): Für internetverbundene Flottenanalysen wird das feingetunte Qwen3-14B-Energiemarktmodell über Amazon Bedrock Custom Model Import bereitgestellt, was ohne Leerlaufkosten lauft und nur abrechnet, während das Modell aktiv ist.

Warum Amazon SageMaker AI serverless model customization

Der Amazon SageMaker AI serverless model customization Service bietet eine breite Auswahl an Open-Weight-Modellen mit fertigen Fine-Tuning-Rezepten aus der SageMaker Public Hub, sodass das Team darauf verzichten konnte, einen eigenen Trainingscontainer zu erstellen und zu optimieren – eine Arbeit, die sonst Wochen dauern kann. Fur Exowatt verwandelte dies das Feintuning von einem knappen, geplanten Ereignis in eine routinemaßige, bedarfsgesteuerte Aufgabe. Dies macht eine schnelle Experimentier- und Testschleife praktikabel und halt gleichzeitig die Experimentierkosten niedrig.

Feintuning auf bereitgestellten GPUs erfordert die Wahl eines bestimmten Instance-Typs, die Anforderung dieser Kapazitat, das Warten auf ihre Verfugbarkeit, die Ausfuhrung des Jobs und die Bezahlung der Instanz, solange sie vorgehalten wird. Die vorgehaltene Zeit umfasst typischerweise die Leerlaufzeit zwischen Experimenten, wenn eine dedizierte Instanz durchgehend lauft. Fur ein kleines Team, das viele Experimente durchfuhrt, verlangsamt dies die Innovation und erhoht die Kosten. Amazon SageMaker AI serverless model customization verwaltet und orchestriert automatisch die Infrastruktur, die fur die Ausfuhrung des Fine-Tuning-Jobs erforderlich ist, nimmt den Aufwand der Kapazitätsverwaltung und berechnet nur die Zeit, in der der Fine-Tuning-Job lauft.

Anwendungsfall 1: Edge-Alarm-Triage mit Qwen3-1.7B

Exowatt-Standorte losen rund um die Uhr Alarme aus. Ein kompaktes Vor-Ort-Modell liest jeden Alarm zusammen mit dem eigenen Status und der Telemetrie des Standorts und liefert eine von einer kleinen, festen Menge von Klassifikationen mit belegten Nachweisen (z. B. ein Offline-System, eine abgestufte Komponente oder eine Sensorabweichung) oder eine explizite Enthaltung, wenn die Beweise unzureichend sind.

Modellauswahl und Trainingsdaten

Das Team versuchte zunächst Qwen3-8B mit Prompting und Guardrails, was unterhalb des Ziels ins Stocken geriet (0.735 macro-F1). Ein feingetuntes Qwen3-1.7B änderte dies: Es übertraf das Qwen3-8B-plus-Prompting-Setup bei dieser schmalen, einstufigen Aufgabe mit etwa einem Funftel der Parameter und blieb dabei klein genug für GPU-freie Edge-Inferenz. Dreizehn feingetunte Qwen3-8B-Kandidaten über 12 Datensatzversionen hinweg schlugen nie die Prompt-basierte 8B-Baseline. Das kleinere Modell mit abwechslungsreicheren Daten schon.

Der Trainingssatz war klein und kuratiert: 2,522 Beispiele, aufgebaut aus 684 verifizierten Entscheidungen zu generierten Standortszenarien plus 1,838 zertifizierten Paraphrasen, bei denen jede Entscheidung festhielt, während der Text umformuliert wurde. Die Paraphrasen wurden von Qwen3-235B auf Amazon Bedrock fur etwa $3.72 generiert. Jede Paraphrase wurde nur beibehalten, wenn deterministische Prufungen bestatigten, dass Entscheidung, Labels, Belegzitate und jede Zahl unverandert blieben (1,838 von 2,218 Kandidaten bestanden). Eine Fehlerfamilie wurde vollstandig aus dem Training ausgeschlossen, und 320 Falle wurden fur Tests reserviert.

Training und Deployment

Das Training wurde in etwa 32 Minuten auf SageMaker serverless fine-tuning fur etwa $20–$25 abgeschlossen. Auf 8 Bits quantisiert (etwa 1.71 GiB), lauft das Modell offline in einem 6 GiB llama.cpp-Pod auf dem vorhandenen CPU-Server des Standorts. Es lauft auch auf einem t3.2xlarge-Instance-Typ.

Anwendungsfall 2: Cloud-Energiemarktanalyse mit Qwen3-14B

Dispatchbarer Speicher macht Timing zu einer betrieblichen Entscheidung: Jeder Standort muss fortlaufend entscheiden, wie viel gespeicherte Energie fur seine Last vorgehalten und wann sie freigegeben wird, und bei netzverbundenen Standorten fließen Marktbedingungen in diese Wahl ein. Das feingetunte Modell liest ein Sechs-Stunden-Paket von Live-Marktdaten (etwa 90 Zeilen mit Echtzeitpreisen, Day-ahead-Prognosen und Netzhinweisen) und liefert in etwa vier Sekunden eines von funf Marktereignissen (wie einem Preisanstieg oder einem scarcity adder). Jede Aussage ist an eine bestimmte Datenzeile gebunden, um die Dispatch-Strategie zu informieren.

Warum Qwen3-14B

Qwen3-14B wurde gewahlt, weil es von Amazon Bedrock Custom Model Import unterstutzt wird, als SageMaker Public Hub-Modell mit fertiger LoRA-Rezeptur ausgeliefert wird (kein benutzerdefinierter Container oder Instance-Typ zu verwalten) und mit etwa 28 GiB klein genug ist, um kosteneffizient bereitgestellt zu werden.

Trainingsdaten und Prozess

Exowatt feintunte das Modell mit offentlichen Marktdaten des Electric Reliability Council of Texas (ERCOT) aus funf Jahren Historie (etwa 163 Millionen Zeilen über 12 Tabellen). Das Team hat diese Daten regelbasiert in 25,000 Beispiele gelabelt (22,000 fur das Training, 1,000 fur die Validierung und 2,000 fur Tests zuruckgehalten). Anschließend erweiterten sie den Trainingssatz auf 86,281 Zeilen, indem Anthropic's Claude Sonnet 4.6 auf Amazon Bedrock den Text jedes Beispiels umformulierte, wahrend dessen Labels und numerische Felder unverändert blieben.

Das Training bestand aus einer einzigen LoRA-Epoche (Rank 16, Alpha 32) und wurde in etwa 8.5 Stunden verwaltetem serverlosem Fine-Tuning abgeschlossen, wobei bis zu vier Jobs gleichzeitig liefen. Das Team führte in den sechs Tagen vom ersten Plan bis zu einem Champion-Modell, das in Cloud EMS ausgeliefert wurde, 23 Jobs und rund 155 Stunden verwaltetes Training durch.

Die entscheidende Verbesserung kam von der Paraphrasen-Vielfalt: Das Hinzufügen von drei Umschreibungen pro Antwort hob das Macro-F1 von 0.950 auf 0.975. Das Basismodell erreichte nur 0.415 Macro-F1. Es erzeugte gültiges JSON, kannte den Markt aber noch nicht. Das Fine-Tuning behob das.

Bereitstellung

Der zusammengeführte Checkpoint wurde in etwa 14 Minuten zu Amazon Bedrock Custom Model Import importiert. Das Modell läuft ohne Leerlaufkosten und wird mit 6.86 $ pro Stunde nur bei Aktivität abgerechnet.

Benchmark-Ergebnisse

Bei der Edge-Alarmtriage steigerte sich das fine-getunte Qwen3-1.7B von einem Modell, das keine gültige Antwort erzeugen konnte, auf 0.911 Macro-F1 mit 320 Testfällen und lag damit vor jedem Frontier-Baselinemodell. Wendete man dieselbe Fine-Tune-und-Evaluiere-Schleife auf die Energiemarktaufgabe mit 2,000 Testfällen an, erreichte das Qwen3-14B 0.975 Macro-F1, erneut vor der Frontier-Baseline und zu einem Bruchteil der Kosten. In beiden Fällen schlug ein kleines, fine-getuntes Modell deutlich größere Allzweckmodelle bei der spezifischen Aufgabe.

Beide Modelle geben striktes JSON zurück, in dem jede Aussage eine bestimmte Eingabedatenzeile zitiert. Jede nicht belegte Aussage wird verworfen, bevor sie einen Operator erreicht – genau das ermöglicht es dem Team, kleinen Modellen in autonomen, physischen Umgebungen zu vertrauen.

Tabelle 1: Ergebnisse der Edge-Alarmtriage, fine-getuntes Qwen3-1.7B im Vergleich zu Frontier-Modellen

0 $ pro 1,000 Entscheidungen bedeutet, dass keine kostenpflichtigen API- oder GPU-Inferenzkosten anfallen. Das quantisierte Modell läuft auf der vorhandenen CPU des Standorts.

Tabelle 2: Ergebnisse der Cloud-Energymarkt-Analyse, feinabgestimmtes Qwen3-14B im Vergleich zu Frontier-Modellen

Die Kosten sind Amazon-Bedrock-Listenpreise multipliziert mit den gemessenen Tokens pro Antwort. Das Fine-Tuning hob ein offenes Modell vom letzten Platz auf den ersten: +0.35 macro-F1 gegenüber Claude Opus 4.7 (95 Prozent Konfidenzintervall 0.324 bis 0.371) bei etwa 49× niedrigeren Kosten pro 1,000 Antworten ($0.60 gegenüber $29.26). Das Modell erreichte 0.968 macro-F1 auf einem zweiten, späteren Testsatz.

Geschäftsvorteile

Schnellere Iteration und schnellere Markteinführung: Exowatt brachte sein angepasstes Modell in nur neun Tagen von der Experimentierphase in die Produktion. Dieser Prozess hätte Monate dauern können, wenn das Team benutzerdefinierte Container und Trainingsrezepte hätte erstellen und optimieren, GPUs bereitstellen und Infrastruktur verwalten müssen. Mit SageMaker-AI-Serverless-Modellanpassung trainierte das Team Qwen3-1.7B in etwa 32 Minuten und Qwen3-14B in etwa 8.5 Stunden, ohne Kapazitätsanfragen und mit bis zu vier gleichzeitig laufenden Trainingsjobs. Für den Energymarkt-Anwendungsfall führte Exowatt 23 Jobs mit insgesamt etwa 155 Stunden verwaltetem Training aus und gelangte in sechs Tagen vom Basismodell zu einem feinabgestimmten Modell, das in Cloud EMS im Einsatz ist. Der zusammengeführte Checkpoint wurde in etwa 14 Minuten in Amazon Bedrock importiert. Die End-to-End-Pipeline nutzte sieben serverlose AWS-Services, ohne dass Exowatt Instanzen, Cluster oder Endpunkte verwalten musste.

Höhere Genauigkeit im Vergleich zu Frontier-Modellen: Beide feinabgestimmten Modelle schlugen die größeren Frontier-Modelle bei ihrer jeweiligen Aufgabe: Qwen3-1.7B mit 0.911 macro-F1 (gegenüber 0.698 für Claude Sonnet 4.6) und Qwen3-14B mit 0.975 (gegenüber 0.625 für Claude Opus 4.7).

Niedrigere Kosten bei beiden Deployments: In der Cloud serves Qwen3-14B für $0.60 pro 1,000 Antworten gegenüber $29.26 für Claude Opus 4.7 (etwa 49× niedriger), ohne Leerlaufkosten und mit $6.86 pro Stunde nur während der aktiven Nutzung von Amazon Bedrock Custom Model Import. Am Edge läuft das quantisierte Qwen3-1.7B auf der vorhandenen CPU des Standorts ohne Kosten pro Inferenz und ohne Abhängigkeit von Konnektivität.

Fundierte, risikoarme Ausgaben: Bei beiden Modellen entfernte der Evidence-Fence jede unbelegte Aussage (jede Evidence-Zitation, deren Quelle, Feld oder Wert nicht wörtlich mit der Eingabe übereinstimmt), und das Edge-Modell enthält sich lieber, als bei Unsicherheit zu raten. Genau das ermöglichte es dem Team, es autonom im Shadow-Modus auf einer cloudgehosteten Replik eines Standorts zu betreiben.

Erkenntnisse

Für spezifische Aufgaben können kleinere feinabgestimmte große Sprachmodelle große Frontier-Modelle übertreffen: Die feinabgestimmten Modelle Qwen3-1.7B und Qwen3-14B übertrafen jeweils die Frontier-Modelle bei der Ziel Austingabe und lieferten höhere Genauigkeit zu einem Bruchteil der Kosten mit deutlich kleineren Modellen.

Datenqualität und -vielfalt sind wichtiger als reines Volumen und zusätzliche Epochen: Bei eng umrissenen Aufgaben war die Datenqualität wichtiger als Modellgröße oder Datenvolumen. Beim Alarm-Triage-Modell steigerte mehr verifizierte Trainingsvielfalt den macro-F1 von 0.584 (trainiert allein auf den 684 verifizierten Entscheidungen) auf 0.911 (mit dem durch Paraphrasen erweiterten Satz von 2,522 Zeilen). Einfach mehr Epochen über dieselben Zeilen zu laufen, verschlechterte das Ergebnis: Eine Kontrolllauf, die auf den 684 ursprünglichen Zeilen für 11 Epochen (die gleiche Anzahl an Schritten) trainierte, erreichte nur 0.879. Kuratierte Daten waren durchweg wichtiger als die Datensatzgröße.

Das Wegfallen des Bereitstellungsschritts verändert die Arbeitsweise eines Teams: Wenn ein Trainingslauf nicht mehr auf GPU-Kapazität warten muss, wird Fine-Tuning von einem seltenen Ereignis zu einer routinemäßigen, iterativen Tätigkeit.

Eine Trainingspipeline bedient zwei Deployment-Ziele: Die Trennung von Modelltraining und Deployment ermöglicht es Exowatt, dieselbe Pipeline sowohl für das Offline-Edge-Deployment als auch für die vernetzte Flottenanalyse zu nutzen, was den Betrieb vereinfacht und das Modell-Deployment in der Cloud beschleunigt.

Fazit

Exowatt verfügt nun über eine wiederverwendbare KI-Pipeline, die eine Aufgabe von der modellspezifischen Datenaufbereitung bis zum Modell-Deployment führte. Statt ein Modell für verschiedene Aufgaben abzustimmen, plant Exowatt, dieselben Fine-Tuning-Prinzipien auf verschiedene Aufgaben anzuwenden, jeweils mit eigenen Daten, spezifischen Modellen und Evaluierungen, in der gesamten Flotte, wenn neue Gerätetypen und Marktaufgaben hinzukommen.

Das Muster lässt sich über Energiewirtschaftssegmente hinaus verallgemeinern. KI-Ingenieure, Data Scientists und Kunden aus allen Branchensegmenten können dieselben Prinzipien anwenden. Nutzen Sie Amazon SageMaker AI serverless model customization als KI-Pipeline mit geringem Overhead, um kleine, aufgaben­spezifische Modelle feinabzustimmen, und deployen Sie sie dann dort, wo die Arbeit stattfindet: am Edge, wenn Konnektivität oder Latenz es erfordern, und über einen verwalteten Cloud-Endpunkt wie Amazon SageMaker AI für elastische Workloads.

Um mehr zu erfahren, siehe Amazon SageMaker AI serverless model customization und Amazon Bedrock.

Über die Autoren