Exowatt beats frontier models on accuracy with SageMaker serverless model customization

Exowatt builds modular, dispatchable solar systems that deliver reliable power for energy-intensive applications such as AI data centers. Its flagship product, the Exowatt 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, P3 powers data centers directly behind the meter, helping data centers come online without waiting in multi-year grid interconnection queues. Exowatt builds a fleet of AI agents that monitor and triage live alarms and support operational decisions for solar systems, often at the edge, with limited or no connectivity. As its fleet scales from test benches toward manufacturing and thousands of deployed field units, the intelligence layer that operates these systems must scale with it. In this post, we show how Exowatt used Amazon SageMaker AI serverless model customization to build a repeatable AI pipeline. The pipeline produces task-specific fine-tuned models for two deployment targets, edge and cloud, achieving higher accuracy than frontier models at up to 49× lower cost. The two models described here are the first outputs of that pipeline rather than the end goal. The more durable result of the engagement was the pipeline itself: a repeatable path from raw operational data to a certified training set, a fine-tuned model, and an evaluated deployment artifact. Exowatt can now run this path in days rather than months. Alarm triage and energy-market analysis are two of many narrow, high-value tasks where the same approach applies. The challenge: AI on physical energy infrastructure Exowatt’s energy management system (EMS) runs across a growing fleet of operational sites. Each site continuously produces alarms: a hardware component operating out of spec, a dropped connection, an out-of-range voltage reading, and similar events. As the fleet scales toward thousands of field units, a human operator can’t monitor every site in real time. Exowatt needed an AI agent that could read the alarm state on each site and take or recommend the correct next action autonomously and reliably. A frontier model couldn’t solve this problem for three reasons: The task is narrow and proprietary. Alarm triage on Exowatt’s EMS depends on their specific hardware, data, and operating logic. A general-purpose frontier model isn’t specialized for it. It must run at the edge, with no GPU and often no internet. Many sites have limited or intermittent connectivity, so an agent that depends on a cloud call to a frontier model leaves the operator without coverage when the connection drops. Cost doesn’t scale at fleet level. Routing every operational decision to a frontier model across thousands of sites is not economical for a decision that repeats continuously. This is where Exowatt turned to model customization. Exowatt’s initial fine-tuning workflow relied on selecting an open-weight model, building a container, and creating a custom training recipe before any experiment could run. This was a major blocker for model experimentation. Additionally, they had to decide GPU hardware requirements of model fine-tuning. As the team increased the pace of experimentation, each run first required choosing a specific GPU instance type and then waiting for that self-selected capacity to become available. When a chosen instance type was unavailable, this could delay the start of a run or block it entirely. They needed a model small enough to run on a no-GPU edge controller, yet accurate enough compared to the frontier model on the specific task to act autonomously. Fine-tuning closed that gap: a compact, task-specialized model that is both deployable in the cloud and at the edge. Solution overview Exowatt addressed these challenges by adopting a cloud-native, serverless model customization approach on Amazon SageMaker AI. The same training pipeline produces fine-tuned models for two deployment targets: the edge and the cloud. Exowatt implemented this approach on the Qwen3-1.7B model for the first use case, edge alarm triage, then applied the same approach to the Qwen3-14B model for the second use case, cloud energy-market analysis. The company plans to reuse this solution to build smaller, task-specific models across the fleet. Figure 1: Exowatt fine-tuning and deployment pipeline, spanning the build, cloud-serving, and edge-serving stages The following seven AWS services power the AI pipeline, with no instances, clusters, or endpoints to manage: AWS Service Purpose Amazon Simple Storage Service (Amazon S3) Data, manifests, model artifacts, and test sets Amazon SageMaker AI serverless fine-tuning Every fine-tune run, launched from Public Hub recipes Amazon SageMaker AI serverless evaluation 2,000 answers per candidate scored as a managed job SageMaker Model Registry Every completed fine-tune with its evidence and metrics Amazon Bedrock Custom Model Import Hosts the fine-tuned Qwen3-14B for Cloud EMS, invoked privately from the Cloud EMS service. No idle cost Amazon Bedrock (Claude, Qwen3) Paraphrase (three rewrites per answer in the training data) and frontier model benchmarking Alarm-triage paraphrases use Qwen3-VL-235B on Amazon Bedrock. Energy-market paraphrases use Claude Sonnet 4.6 on Amazon Bedrock. AWS Lambda + Amazon EventBridge Serverless-evaluation scorer and a scheduled keep-warm invocation of the custom model The workflow is organized into three stages: Model customization (cloud): Exowatt fine-tunes open-weight base models using serverless model customization, Low-Rank Adaptation (LoRA) and supervised fine-tuning (SFT) on SageMaker AI. Because serverless training allocates capacity on demand, the team runs multiple experiments per day rather than waiting for self-selected GPU. After evaluation, the best model is registered in the SageMaker AI Model Registry. Edge deployment: For latency-sensitive, connectivity-constrained work such as alarm triage, the fine-tuned Qwen3-1.7B model is frozen, quantized to the GGUF format, and run with llama.cpp inside Kubernetes pods at the edge using on-site controllers. This path requires no GPU and operates without internet connectivity. Cloud deployment (elastic): For internet-connected, fleet-level analysis, the fine-tuned Qwen3-14B energy-market model is served through Amazon Bedrock Custom Model Import, which runs with no idle cost and bills only while the model is active. Why Amazon SageMaker AI serverless model customization Amazon SageMaker AI serverless model customization service provides a wide selection of open-weight models with ready-made fine-tuning recipes from the SageMaker Public Hub, so the team avoided building and optimizing a custom training container, work that can otherwise take weeks. For Exowatt, this turned fine-tuning from a scarce, scheduled event into a routine, on-demand one. This makes a rapid experimentation-and-test loop practical while keeping experimentation cost low. Fine-tuning on provisioned GPUs requires choosing a specific instance type, requesting that capacity, waiting for it to become available, running the job, and paying for the instance for as long as it is held. The held time typically includes the idle time between experiments when a dedicated instance is kept running. For a small team running many experiments, this slows down innovation and increases cost. Amazon SageMaker AI serverless model customization automatically manages and orchestrates the infrastructure required to run the fine-tuning job, removing the pain of capacity management, and charges only for the time the fine-tuning job runs. Use case 1: Edge alarm triage with Qwen3-1.7B Exowatt sites raise alarms around the clock. A compact on-site model reads each alarm together with the site’s own status and telemetry and returns one of a small fixed set of classifications with cited evidence (such as an offline system, derated component, or sensor mismatch) or an expli