Exowatt fine-tunes small Qwen3 models on SageMaker to beat frontier models

Why a frontier model was not the answer

Exowatt builds modular, dispatchable solar systems for energy-intensive uses such as AI data centers. Its Exowatt P3 captures sunlight with optical lenses, stores it as heat in a long-duration thermal battery and turns it into electricity on demand through a heat engine. According to the post, P3 powers data centers directly behind the meter, so they do not have to wait in multi-year grid interconnection queues.

Each operational site continuously raises alarms, such as a component running out of spec, a dropped connection or an out-of-range voltage reading. As the fleet grows toward thousands of field units, a human operator cannot watch every site in real time. Exowatt wanted AI agents that read a site's alarm state and take or recommend the right next action.

AWS lists three reasons a frontier model did not fit. The task is narrow and proprietary, since triage depends on Exowatt's own hardware, data and operating logic. The model must run at the edge, with no GPU and often no internet. And routing every repeated operational decision to a frontier model across thousands of sites would not be economical.

A serverless pipeline instead of managed GPUs

Exowatt's earlier fine-tuning workflow required choosing an open-weight model, building a container and writing a custom training recipe before any experiment could start. Teams also had to pick a GPU instance type and wait for that capacity, which could delay or block a run.

With SageMaker AI serverless model customization, the team used ready-made recipes from the SageMaker Public Hub. The service manages and orchestrates the infrastructure and charges only for the time a fine-tuning job runs. According to the post, this lets the team run multiple experiments per day, and Exowatt can now go from raw operational data to a certified training set, a fine-tuned model and an evaluated deployment artifact in days rather than months.

The pipeline uses seven AWS services:

• Amazon S3 for data, manifests, model artifacts and test sets.
• SageMaker AI serverless fine-tuning for every run, launched from Public Hub recipes.
• SageMaker AI serverless evaluation, scoring 2,000 answers per candidate as a managed job.
• SageMaker Model Registry for each completed fine-tune with its evidence and metrics.
• Amazon Bedrock Custom Model Import, which hosts the fine-tuned Qwen3-14B for the Cloud EMS.
• Amazon Bedrock for paraphrasing training data and benchmarking frontier models.
• AWS Lambda and Amazon EventBridge for the evaluation scorer and a scheduled keep-warm call to the custom model.

Training uses Low-Rank Adaptation (LoRA) and supervised fine-tuning (SFT).

Edge alarm triage with Qwen3-1.7B

The first use case is a compact on-site model that reads an alarm together with the site's status and telemetry. It returns one of a small fixed set of classifications with cited evidence, such as an offline system, derated component or sensor mismatch, or it abstains when the evidence is insufficient.

The team first tried Qwen3-8B with prompting and guardrails, which plateaued at 0.735 macro-F1, below the target. Thirteen fine-tuned Qwen3-8B candidates across 12 dataset versions never beat that prompted baseline. A fine-tuned Qwen3-1.7B did, on this narrow, single-turn task, at roughly one-fifth the parameters. The post attributes the result to the smaller model being trained on more varied data.

The training set was small and curated: 2,522 examples, made of 684 verified decisions on generated site scenarios plus 1,838 certified paraphrases that kept each decision fixed while rewriting the prose. The paraphrases were generated on Amazon Bedrock for about $3.72. A paraphrase was kept only if deterministic checks confirmed that the decision, labels, evidence citations and every number were unchanged.

Two deployment targets, one approach

For the edge, the fine-tuned Qwen3-1.7B is frozen, quantized to the GGUF format and run with llama.cpp inside Kubernetes pods on on-site controllers. According to AWS, this path needs no GPU and works without internet connectivity.

For the second use case, cloud energy-market analysis, Exowatt applied the same approach to Qwen3-14B. That model is served through Amazon Bedrock Custom Model Import, which the post says has no idle cost and bills only while the model is active. Energy-market paraphrases for training data were produced with Claude Sonnet 4.6 on Amazon Bedrock.

What it means

AWS presents the two models as first outputs rather than the end goal. Exowatt plans to reuse the pipeline to build smaller, task-specific models across its fleet, and the post describes alarm triage and energy-market analysis as two of many narrow, high-value tasks where the approach applies. For teams with narrow, repeated decisions and limited connectivity, the case study argues that small fine-tuned open-weight models can replace calls to frontier models, with serverless training removing the need to reserve GPU capacity for each experiment. The accuracy and cost figures are AWS's account of Exowatt's results.