Exowatt trimmt kleine Qwen3-Modelle auf SageMaker und schlägt damit Frontier-Modelle

Warum ein Frontier-Modell nicht die Antwort war

Exowatt baut modulare, bedarfsgerecht abrufbare Solarsysteme für energieintensive Anwendungen wie KI-Rechenzentren. Das System Exowatt P3 bündelt Sonnenlicht mit optischen Linsen, speichert es als Wärme in einer Langzeit-Thermobatterie und wandelt es bei Bedarf über eine Wärmekraftmaschine in Strom um. Laut dem Beitrag versorgt P3 Rechenzentren direkt hinter dem Zähler, sodass diese nicht in mehrjährigen Warteschlangen für den Netzanschluss ausharren müssen.

Jeder Standort im Betrieb löst fortlaufend Alarme aus, etwa wenn eine Komponente außerhalb der Spezifikation läuft, eine Verbindung abbricht oder ein Spannungswert außerhalb des zulässigen Bereichs liegt. Während die Flotte auf Tausende Einheiten im Feld wächst, kann ein menschlicher Operator nicht jeden Standort in Echtzeit überwachen. Exowatt wollte KI-Agenten, die den Alarmzustand eines Standorts auslesen und die richtige nächste Maßnahme ergreifen oder empfehlen.

AWS nennt drei Gründe, warum ein Frontier-Modell nicht passte. Die Aufgabe ist eng gefasst und proprietär, denn die Triage hängt von Exowatts eigener Hardware, den Daten und der Betriebslogik ab. Das Modell muss am Edge laufen, ohne GPU und oft ohne Internet. Und jede wiederkehrende operative Entscheidung über Tausende Standorte hinweg an ein Frontier-Modell zu leiten, wäre nicht wirtschaftlich.

Serverlose Pipeline statt verwalteter GPUs

Exowatts bisheriger Fine-Tuning-Workflow verlangte, zunächst ein Open-Weight-Modell auszuwählen, einen Container zu bauen und ein eigenes Trainingsrezept zu schreiben, bevor ein Experiment starten konnte. Außerdem mussten die Teams einen GPU-Instanztyp wählen und auf die entsprechende Kapazität warten, was einen Lauf verzögern oder blockieren konnte.

Mit SageMaker AI Serverless Model Customization nutzte das Team fertige Rezepte aus dem SageMaker Public Hub. Der Dienst verwaltet und orchestriert die Infrastruktur und berechnet nur die Laufzeit eines Fine-Tuning-Jobs. Laut dem Beitrag kann das Team dadurch mehrere Experimente pro Tag durchführen, und Exowatt kommt nun in Tagen statt Monaten von rohen Betriebsdaten über einen zertifizierten Trainingsdatensatz und ein feinabgestimmtes Modell zu einem evaluierten Deployment-Artefakt.

Die Pipeline nutzt sieben AWS-Dienste:

• Amazon S3 für Daten, Manifeste, Modellartefakte und Testsets.
• SageMaker AI Serverless Fine-Tuning für jeden Lauf, gestartet aus Public-Hub-Rezepten.
• SageMaker AI Serverless Evaluation, das als verwalteter Job 2.000 Antworten pro Kandidat bewertet.
• SageMaker Model Registry für jedes abgeschlossene Fine-Tuning samt Nachweisen und Metriken.
• Amazon Bedrock Custom Model Import, das das feinabgestimmte Qwen3-14B für das Cloud-EMS hostet.
• Amazon Bedrock zum Paraphrasieren von Trainingsdaten und zum Benchmarking von Frontier-Modellen.
• AWS Lambda und Amazon EventBridge für den Evaluations-Scorer und einen zeitgesteuerten Keep-Warm-Aufruf des Custom Models.

Das Training erfolgt mit Low-Rank Adaptation (LoRA) und Supervised Fine-Tuning (SFT).

Alarm-Triage am Edge mit Qwen3-1.7B

Der erste Anwendungsfall ist ein kompaktes Modell vor Ort, das einen Alarm zusammen mit Status und Telemetrie des Standorts liest. Es liefert eine von wenigen festgelegten Klassifikationen mit belegten Nachweisen zurück, etwa ein Offline-System, eine gedrosselte Komponente oder eine Sensorabweichung, oder es enthält sich, wenn die Beweislage nicht ausreicht.

Das Team probierte zunächst Qwen3-8B mit Prompting und Guardrails, das bei 0,735 Macro-F1 stagnierte und damit unter dem Ziel blieb. Dreizehn feinabgestimmte Qwen3-8B-Kandidaten über 12 Datensatzversionen hinweg schlugen diese Prompting-Baseline nie. Ein feinabgestimmtes Qwen3-1.7B tat es bei dieser eng gefassten Single-Turn-Aufgabe, und das mit etwa einem Fünftel der Parameter. Der Beitrag führt das Ergebnis darauf zurück, dass das kleinere Modell mit vielfältigeren Daten trainiert wurde.

Der Trainingsdatensatz war klein und kuratiert: 2.522 Beispiele, bestehend aus 684 verifizierten Entscheidungen zu generierten Standortszenarien sowie 1.838 zertifizierten Paraphrasen, die jeweils die Entscheidung unverändert ließen und nur den Text umformulierten. Die Paraphrasen wurden auf Amazon Bedrock für rund 3,72 US-Dollar erzeugt. Eine Paraphrase wurde nur behalten, wenn deterministische Prüfungen bestätigten, dass Entscheidung, Labels, Quellenverweise auf die Nachweise und jede Zahl unverändert blieben.

Zwei Einsatzziele, ein Ansatz

Für den Edge wird das feinabgestimmte Qwen3-1.7B eingefroren, in das GGUF-Format quantisiert und mit llama.cpp in Kubernetes-Pods auf Controllern vor Ort betrieben. Laut AWS braucht dieser Weg keine GPU und funktioniert ohne Internetverbindung.

Für den zweiten Anwendungsfall, die Analyse des Energiemarkts in der Cloud, wandte Exowatt denselben Ansatz auf Qwen3-14B an. Dieses Modell wird über Amazon Bedrock Custom Model Import bereitgestellt, das laut Beitrag keine Leerlaufkosten verursacht und nur abrechnet, solange das Modell aktiv ist. Die Paraphrasen für die Trainingsdaten zum Energiemarkt wurden mit Claude Sonnet 4.6 auf Amazon Bedrock erzeugt.

Was das bedeutet

AWS stellt die beiden Modelle als erste Ergebnisse dar, nicht als Endziel. Exowatt plant, die Pipeline wiederzuverwenden, um in der gesamten Flotte kleinere, aufgabenspezifische Modelle zu bauen, und der Beitrag beschreibt Alarm-Triage und Energiemarktanalyse als zwei von vielen eng gefassten, besonders wertvollen Aufgaben, für die der Ansatz taugt. Für Teams mit eng umrissenen, wiederkehrenden Entscheidungen und eingeschränkter Konnektivität argumentiert die Fallstudie, dass kleine, feinabgestimmte Open-Weight-Modelle Aufrufe von Frontier-Modellen ersetzen können, wobei das serverlose Training die Notwendigkeit entfallen lässt, für jedes Experiment GPU-Kapazität zu reservieren. Die Angaben zu Genauigkeit und Kosten sind AWS' Darstellung von Exowatts Ergebnissen.