Exowatt outperforms frontier models in accuracy through SageMaker serverless model customization.

Meta description: Exowatt used Amazon SageMaker AI serverless model customization to fine-tune Qwen3-1.7B and Qwen3-14B for edge alarm triage and energy-market analysis.

Tags: Exowatt, Amazon SageMaker AI, Qwen3, energy operations, AI agents

Featured image: Abstract friendly illustration of a solar thermal system linked to a cloud service and an edge controller, with no people, logos, or text.

Exowatt, the company building modular, dispatchable solar systems such as the Exowatt P3 for energy-intensive applications including AI data centers, has used Amazon SageMaker AI serverless model customization to build a repeatable AI pipeline. The pipeline produced fine-tuned Qwen3-1.7B and Qwen3-14B models for edge alarm triage and cloud energy-market analysis, with the company reporting higher accuracy than frontier models at up to 49× lower cost.

The P3 captures solar energy through optical lenses, stores it as heat in a long-duration thermal battery, and dispatches electricity on demand through a heat engine. Unlike grid-tied photovoltaic solar systems, it powers data centers directly behind the meter, helping them come online without waiting in multi-year grid interconnection queues. As Exowatt moves from test benches toward manufacturing and thousands of deployed field units, the AI agents that monitor alarms and support operational decisions must scale too. The two Qwen3 models are early outputs; the durable result is a path from raw operational data to a certified training set, a fine-tuned model, and an evaluated deployment artifact that Exowatt can now run in days rather than months.

Why a frontier model could not run the fleet

Exowatt’s energy management system runs across a growing fleet of sites. Each site continuously raises alarms: a hardware component operating out of spec, a dropped connection, an out-of-range voltage reading, or similar events. With thousands of field units coming, a human operator cannot watch every site in real time. The company needed an agent that could read each site’s alarm state and either take or recommend the correct next action reliably.

A general-purpose frontier model did not fit for three reasons. The alarm-triage task is narrow and proprietary, depending on Exowatt’s own hardware, data, and operating logic. Many sites run at the edge with no GPU and limited or intermittent internet, so an agent that calls a cloud frontier model loses coverage when connectivity drops. Routing every repeated operational decision to a frontier model across thousands of sites also does not scale economically.

Exowatt’s earlier fine-tuning workflow added another obstacle. The team had to select an open-weight model, build a container, create a custom training recipe, and choose GPU hardware before running an experiment. As experimentation increased, each run required choosing a specific GPU instance type and waiting for that capacity. If the chosen instance type was unavailable, a run could be delayed or blocked. The company needed a model small enough for a no-GPU edge controller but accurate enough to act autonomously. Fine-tuning closed that gap.

A serverless pipeline from data to deployment

Exowatt adopted Amazon SageMaker AI serverless model customization. The same training pipeline produces models for two deployment targets: the edge and the cloud. The first output was a fine-tuned Qwen3-1.7B model for edge alarm triage; the same approach was then applied to Qwen3-14B for cloud energy-market analysis. Exowatt plans to reuse the solution to build smaller, task-specific models across the fleet.

The pipeline uses seven AWS services, with no instances, clusters, or endpoints to manage. Amazon Simple Storage Service stores data, manifests, model artifacts, and test sets. Amazon SageMaker AI serverless fine-tuning runs every fine-tuning job from SageMaker Public Hub recipes. Amazon SageMaker AI serverless evaluation scores 2,000 answers per candidate as a managed job. The Amazon SageMaker AI Model Registry stores every completed fine-tune with its evidence and metrics.

Amazon Bedrock Custom Model Import hosts the fine-tuned Qwen3-14B for the cloud energy management system service, invoked privately from that service with no idle cost. Amazon Bedrock’s Claude and Qwen3 models support paraphrase work, including three rewrites per answer in the training data, and frontier model benchmarking. For alarm-triage paraphrases, the pipeline used Amazon Bedrock Qwen3 models, named in the write-up as Qwen3-VL-235B and Qwen3-235B, at a cost of about $3.72. Energy-market paraphrases used Anthropic’s Claude Sonnet 4.6 on Amazon Bedrock. AWS Lambda and Amazon EventBridge provide a serverless evaluation scorer and a scheduled keep-warm invocation of the custom model.

The workflow has three stages. In cloud model customization, Exowatt fine-tunes open-weight base models on Amazon SageMaker AI using supervised fine-tuning and Low-Rank Adaptation. Because serverless training allocates capacity on demand, the team can run multiple experiments per day rather than waiting for self-selected GPU capacity. After evaluation, the best model is registered in the Model Registry. For edge deployment, the fine-tuned Qwen3-1.7B model is frozen, quantized to the GGUF format, and run with llama.cpp inside Kubernetes pods on-site. This path needs no GPU and can operate without internet connectivity. For elastic cloud deployment, the fine-tuned Qwen3-14B energy-market model is served through Amazon Bedrock Custom Model Import, which bills only while the model is active.

The serverless approach mattered because ready-made SageMaker Public Hub recipes removed weeks of custom container work. Provisioned GPU training requires choosing an instance type, requesting capacity, waiting for it, running the job, and paying while the instance is held, including idle time between experiments. Serverless customization manages the infrastructure and charges only for fine-tuning job run time, turning fine-tuning from a scarce scheduled event into a routine on-demand experiment.

Qwen3-1.7B handles alarms at the edge

At Exowatt sites, alarms run around the clock. The compact on-site model reads each alarm together with the site’s status and telemetry, then returns one of a small fixed set of classifications with cited evidence, such as an offline system, derated component, or sensor mismatch. If the evidence is insufficient, it abstains explicitly.

The team first tried Qwen3-8B with prompting and guardrails. That approach plateaued below the target at 0.735 macro-F1. A fine-tuned Qwen3-1.7B changed the result: it outperformed the Qwen3-8B plus prompting setup on this narrow, single-turn task with roughly one-fifth the parameters, while staying small enough for GPU-free edge inference. Thirteen fine-tuned Qwen3-8B candidates across 12 dataset versions never beat the prompted 8B baseline; the smaller model with more varied data did.

The training set was small and curated: 2,522 examples built from 684 verified decisions on generated site scenarios plus 1,838 certified paraphrases that kept each decision fixed while rewriting the prose. Each paraphrase was kept only if deterministic checks confirmed that the decision, labels, evidence citations, and every number were unchanged; 1,838 of 2,218 candidates passed. One fault family was held out of training entirely, and 320 cases were reserved for testing.

Training completed in about 32 minutes on Amazon SageMaker AI serverless fine-tuning for roughly $20 to $25. Quantized to 8 bits, the model is about 1.71 GiB and runs offline in a 6 GiB llama.cpp pod on the site’s existing CPU server. It also runs on a t3.2xlarge instance type. On the edge alarm-triage task, the fine-tuned Qwen3-1.7B went from a model that could not produce a valid answer to 0.911 macro-F1 across 320 test cases, ahead of every frontier baseline.

Qwen3-14B times energy-market decisions

Dispatchable storage turns timing into an operational decision. Each site must continually decide how much stored energy to hold for its load and when to release it, and for grid-connected sites market conditions feed into that choice. The fine-tuned Qwen3-14B model reads a six-hour packet of live market data, about 90 rows of real-time prices, day-ahead forecasts, and grid notices, and returns one of five market events, such as a price spike or scarcity adder, in about four seconds. Every claim is tied to a specific data row to inform the dispatch strategy.

Qwen3-14B was chosen because Amazon Bedrock Custom Model Import supports it, it ships as a SageMaker Public Hub model with a ready Low-Rank Adaptation recipe, and at about 28 GiB it is small enough to serve cost-effectively. Exowatt fine-tuned it on public Electric Reliability Council of Texas market data drawn from five years of history, about 163 million rows across 12 tables. The team rule-labeled that data into 25,000 examples: 22,000 for training, 1,000 for validation, and 2,000 held out for testing. It then expanded the training set to 86,281 rows by having Anthropic’s Claude Sonnet 4.6 on Amazon Bedrock rewrite the prose of each example while labels and numeric fields stayed fixed.

Training used a single epoch of Low-Rank Adaptation fine-tuning with rank 16 and alpha 32. It completed in about 8.5 hours of managed serverless fine-tuning, with up to four jobs running at once. The team ran 23 jobs and about 155 hours of managed training in the six days from initial plan to a champion model serving in the cloud energy management system. The decisive improvement came from paraphrase diversity: adding three rewrites per answer lifted macro-F1 from 0.950 to 0.975. The base model scored only 0.415 macro-F1. It could produce valid JavaScript Object Notation output but did not yet know the market. Fine-tuning fixed that.

The merged checkpoint was imported to Amazon Bedrock Custom Model Import in about 14 minutes. The model runs with no idle cost and bills at $6.86 per hour only while active. Applying the same fine-tune-and-evaluate loop to the energy-market task with 2,000 test cases, Qwen3-14B reached 0.975 macro-F1.

For Exowatt, the value is not only two models but a repeatable path. Alarm triage and energy-market analysis are two narrow, high-value tasks, and the company says the same approach can be reused as its fleet scales from test benches toward manufacturing and thousands of field units.