Exowart 精度比前沿模型更精确，SageMaker 无服务器模型定制

人工智能

Exowart 精度比前沿模型更精确，SageMaker 无服务器模型定制

Exowat构建模块化，可调度的太阳能系统，为AI数据中心等能源密集型应用提供可靠的动力。 其旗舰产品Exowat P3通过光学透镜捕获太阳能，将其储存在长时间热电池中作为热量，并通过热发动机按需发送电力。 与网格式光伏太阳能系统不同，P3功率数据中心直接位于仪表后面，帮助数据中心在多年的网格互联排队中不等待就上线。 Exowat构建了AI agents的机队，用于监控和分解实时警报，并支持经常处于边缘的太阳系的操作决策，其连接性有限或根本没有。 随着其机队规模从试验台向制造和数千个部署的野战部队发展，操作这些系统的情报层必须与之相适应。

在本文中，我们展示了Exowat如何使用Amazon SageMaker AI无服务器模型定制来构建可重复的AI管道。 管道为边缘和云两个部署目标生产任务特定微调模型，实现比前沿模型更高的精度，成本最高为49×.

这里介绍的两个模式是这一管道的最初产出，而不是最终目标。 参与的更持久的结果是管道本身：从原始业务数据到经认证的培训集的可重复路径、经过微调的模式和经过评估的部署文物。 Exowart现在可以在几天而不是几个月内运行这条路径。 警示分类和能源市场分析是许多狭义、高价值的任务中的两个，适用同样的方法。

挑战：关于有形能源基础设施的大赦国际

Exowat的能源管理系统跨越越来越多的业务地点。 每个站点不断产生警报：一个硬件组件运行于光谱之外，一个被丢弃的连接，一个离线电压读取，以及类似事件。 人类操作人员无法实时监控每个地点。 Exowat需要一个AI agent，可以读取每个站点的警报状态，自主和可靠地采取或建议正确的下一步行动。

一个前沿模式无法解决这个问题有三个原因：

- 任务既狭窄又专有 Exowat的EMS的警示分类取决于其具体的硬件、数据和操作逻辑。 通用前沿模式并不具有特殊性。

- 它必须运行在边缘，没有GPU和经常没有互联网。 许多站点的连通性有限或间断，因此agent依赖于对边疆模型的云调制，当连接下降时，操作员会失去覆盖。

- 成本在机队一级并不相称。 将每一项业务决定向数千个地点的前沿模式进行循环，对于不断重复的决定来说是不经济的。

这就是Exowat转向模型定制的地方。 Exowat最初的微调工作流程依赖于选择一个开放量级模型，构建一个容器，并在任何实验能够运行之前创建自定义的培训配方。 这是模型实验的主要阻断器。 此外，他们还得决定微调型号的GPU硬件要求。 随着团队加快实验速度，每次运行首先需要选择特定的GPU实例类型，然后等待这种自选能力到位。 当所选实例类型无法使用时，这可能会延迟运行的开始或完全屏蔽它。

他们需要一个足够小的模型，可以运行在无GPU边缘控制器上，然而与关于具体任务自主行动的前沿模型相比，它足够精确。 微调缩小了这一差距：一种紧凑的、专门的任务模式，既可在云层中部署，也可在边缘部署。

解决方案概述

Exowat在Amazon SageMaker AI上采用了一种云内无服务器的模型定制方法来应对这些挑战。 同样的训练管道为两个部署目标：边缘和云层提供了精细的模型。

Exowat在Qwen3-1.7B模型上对第一使用案例，边缘警报分解应用了这种方法，然后对第二使用案例，云能量市场分析的Qwen3-14B模型采用了同样的方法。 公司计划重新使用这个解决方案，在整个机队建造规模较小，任务特定的模式。

以下7个AWS服务为AI管道提供动力，没有实例，集群，或端点可以管理：

工作流程分为三个阶段：

模型定制(云)：使用无服务器模型定制的Exowat 微调开放量级基模型，低Rank适应(LoRA)，并在SageMaker AI上监督微调(SFT). 由于无服务器培训按需分配能力，团队每天进行多个实验，而不是等待自选的GPU. 经过评价，最佳模式在SageMaker AI模型登记册中注册。

边缘部署：对于对潜伏敏感，连接受限的工作如警报分解，微调后的Qwen3-1.7B型号被冻结，量化为GGUF格式，在边缘使用现场控制器与llama.cpp在Kubernetes舱内运行。 此路径不需要GPU，没有互联网连接即可运行。

云部署(弹性)：用于互联网联通，机队级分析，微调后的Qwen3-14B能源市场模式通过Amazon Bedrock Customal Model Introduction服务，该模式运行时没有闲置成本和账单，仅在模式活动时使用。

为什么 Amazon SageMaker AI 无服务器模型定制

Amazon SageMaker AI服务器无型号定制服务提供大量选择的开放量级模型，配有来自SageMaker公共枢纽的现成微调配方，因此团队避免建造并优化了定制培训容器，否则需要几周时间的工作。 对Exowat来说，这把微调从一个稀少的，预定的活动变成了例行的，点播的。 这使得快速实验和测试循环切实可行，同时保持实验成本低廉。

提供GPU的微调需要选择特定实例类型，要求该能力，等待其可用，运行该工作，并支付所持有的时间。 所持有的时间通常包括实验间在专用实例持续运行时的闲置时间。 对于一个经营许多实验的小团队来说，这减缓了创新的速度，增加了成本。 Amazon SageMaker AI无服务器模型定制自动管理并管理运行微调任务所需的基础设施，消除能力管理的痛苦，并且只收取微调任务运行时的费用。

使用大小写 1：边缘警报分解 Qwen3-1.7B

Exowat网站昼夜发出警报。 一个紧凑的现场模型将每个警报与站点本身的状况和遥测读出，并返回一套带有所引用证据的小型固定分类(例如离线系统、装饰部件或传感器不匹配)，或在证据不足时明确弃权。

示范选择和培训数据

球队首先试制了Qwen3-8B的导轨和护栏，在目标(0.735 macro-F1)以下高原。 一个微调的Qwen3-1.7B改变了：它的表现超过了Qwen3-8B，再加上在大约1/5的参数上催促这个狭义的单转任务设置，同时保持小到足以进行GPU无边缘推论。 12个数据集版本的13个微调Qwen3-8B候选人从未击败被激发的8B基线。 数据更多样化的较小模型确实如此。

培训集规模小，内容丰富：从684项经核实的关于生成的站点情景的决定中积累了2 522个实例，加上1 838个经认证的释义，这些释义保留了每项决定，同时重写了传言。 引文由Qwen3-235B在Amazon Bedrock上生成，售价约3.72美元。 只有在确定性的检查证实决定、标签、证据引用和每个人数没有变化(2 218名候选人中有1 838名通过)时，才保留每个译文。 一个过错家庭完全没有接受培训，有320个案件留作测试。

培训和部署

在大约32分钟内完成了对SageMaker无服务器的微调的培训，培训费用约为20美元-25. 量化为8位(约1.71 GiB)，该型号在网站现有CPU服务器上的6个GiB llama.cpp pock中下线。 它也运行在t3.2x大实例类型上。

使用案例2：云能市场分析与Qwen3-14B

可调度储存将时间变为一项业务决定：每个地点必须不断决定储存的能量可以储存多少，以便装载和何时释放，以及供与电网连接的场址的市场条件可以输入这一选择。 微调的模型读取了6小时的现场市场数据包(约90行实时价格，日前预测，以及网格通知)，并在约4秒内返回了5个市场事件之一(如价格飙升或稀缺增加值). 每项索赔都与特定的数据行挂钩，以通报发送策略。

为什么 Qwen3-14B

Qwen3-14B之所以被选中，是因为它得到了Amazon Bedrock Custom Model Introduction的支持，它作为SageMaker公共枢纽模型载货，配有即时的LoRA配方(没有定制容器或实例类型可以管理)，在大约28GiB时它足够小，能够以成本效益高的服务。

培训数据和程序

Exowat对德克萨斯州公共电力可靠性委员会(ERCOT)市场数据模型进行了微调，该模型取自5年历史(12个表格的约1.63亿行). 团队将这一数据贴上标签，分为25 000例(22,000例用于培训，1,000例用于验证，2,000例用于测试)。 随后，他们将训练集扩大到86 281行，在Amazon Bedrock上将Anthropic的Claude Sonnet 4.6重写每个例子的传言，同时其标签和数字字段保持不变。

训练是单一的LoRA epoc(排名16,α 32)，在8.5小时左右的管理无服务器的微调完成，最多4个工作同时运行。 球队在从初始计划到在Cloud EMS效力的冠军模特儿的6天里，共进行了23个工作，并进行了约155小时的管理训练。

决定性的改进来自句法多样性：每个回答增加三个重写使宏F1从0.950升至0.975. 基建模型只得0.415个宏F1. 它生产了有效的JSON，但还不知道市场。 微调修好了这个

部署

合并后的检查站在约14分钟内被进口到Amazon Bedrock Custom Model Introduction. 该型号运行时没有闲置成本，只在运行时以每小时6.86美元的价格开出账单。

基准测试结果

微调的Qwen3-1.7B从无法产生有效答案的模型，Qwen3-14B在2000个测试案例中，对能源市场任务采用相同的微调-和-评价循环，再次在前沿基线之前并以成本的一小部分达到0.975宏-F1。 在这两种情况下，一个小的、经过微调的模型在具体任务上打败了更大的通用模型。

这两个模型都返回严格的JSON，其中每个索赔都引用一个特定的输入数据行。 任何无佐证的索赔在到达操作员之前都会被放弃，这让团队在自主的物理环境中信任小模型。

表1：边缘警报分解结果，与前沿模型相比，微调Qwen3-1.7B

每1 000个决定中，0.0美元不意味着计量吸入器或GPU推论费用。 量化模型运行在该网站现有的CPU上。

表2：云能市场分析结果，与前沿模型相比，微调Qwen3-14B

成本是Amazon Bedrock列表价格乘以每个答案测量的符号。 微调将一个开放型号从最后一位提升到第一位：+0.35 宏-F1比Claude Opus 4.7(95%的置信间隔0.324至0.371)，每1000个回答约49×低成本(0.60美元，而29.26美元). 该模型持有0.968

本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Artificial Intelligence

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.

The following seven AWS services power the AI pipeline, with no instances, clusters, or endpoints to manage:

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 explicit abstention when the evidence is insufficient.

Model selection and training data

The team first tried Qwen3-8B with prompting and guardrails, which plateaued below the target (0.735 macro-F1). A fine-tuned Qwen3-1.7B changed that: it outperformed the Qwen3-8B plus prompting setup on this narrow, single-turn task at 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. The paraphrases were generated by Qwen3-235B on Amazon Bedrock for about $3.72. 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 and deployment

Training completed in about 32 minutes on SageMaker serverless fine-tuning for roughly $20–$25. Quantized to 8 bits (about 1.71 GiB), the model 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.

Use case 2: Cloud energy-market analysis with Qwen3-14B

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 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.

Why Qwen3-14B

Qwen3-14B was chosen because it is supported by Amazon Bedrock Custom Model Import, it ships as a SageMaker Public Hub model with a ready LoRA recipe (no custom container or instance type to manage), and at about 28 GiB it is small enough to serve cost-effectively.

Training data and process

Exowatt fine-tuned the model on public Electric Reliability Council of Texas (ERCOT) market data drawn from five years of history (about 163 million rows across 12 tables). The team rule-labeled this data into 25,000 examples (22,000 for training, 1,000 for validation, and 2,000 held out for testing). They 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 its labels and numeric fields stayed fixed.

Training was a single LoRA epoch (rank 16, alpha 32), 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 Cloud EMS.

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 produced valid JSON but did not yet know the market. Fine-tuning fixed that.

Deployment

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.

Benchmark results

On the edge alarm-triage task the fine-tuned Qwen3-1.7B went from a model that couldn’t produce a valid answer to 0.911 macro-F1 with 320 test cases, ahead of every frontier baseline. Applying the identical fine-tune-and-evaluate loop to the energy-market task with 2,000 test cases, the Qwen3-14B reached 0.975 macro-F1, again ahead of the frontier baseline and at a fraction of the cost. In both cases a small, fine-tuned model beat far larger general-purpose models on the specific task.

Both models return strict JSON in which every claim cites a specific input data row. Any unsupported claim is dropped before it reaches an operator, which is what lets the team trust small models in autonomous, physical settings.

Table 1: Edge alarm triage results, fine-tuned Qwen3-1.7B compared to frontier models

$0 per 1,000 decisions means no metered API or GPU inference cost. The quantized model runs on the site’s existing CPU.

Table 2: Cloud energy-market analysis results, fine-tuned Qwen3-14B compared to frontier models

Costs are Amazon Bedrock list prices times measured tokens per answer. Fine-tuning lifted an open model from last place to first: +0.35 macro-F1 over Claude Opus 4.7 (95 percent confidence interval 0.324 to 0.371) at about 49× lower cost per 1,000 answers ($0.60 compared to $29.26). The model held 0.968

Auto-fetched and translated by AI Atlas. All rights belong to the original author.