人工智能
Exowat 以 SageMaker 无服务器模型定制的精度击败前沿模型
Exowat构建模块化，可调度的太阳能系统，为AI数据中心等能耗高的应用提供可靠的动力。 其旗舰产品Exowat P3通过光学透镜来捕捉太阳能，将太阳能作为热能储存在长时间热电池中，并用热能发动机按需发送电力。 与网格式光伏太阳能系统不同，P3功率数据中心直接位于电表后方，帮助数据中心在多年的网格互联排队中不等待而上线。 Exowat构建了AI agents的机队，用于监控和分解活性警报，并支持经常处于边缘的太阳系的操作决策，连接有限或没有。 随着其机队规模从试验台向制造和数千个部署的野战部队发展，操作这些系统的情报层必须与之相适应。
在本文中，我们展示了Exowatt如何使用Amazon SageMaker AI无服务器模型定制来构建可重复的AI管道。 管线为边缘和云两个部署目标生产出针对特定任务的微调模型，以最高49×更低的成本实现比前沿模型更高的精度。
这里描述的两个模式是这一管道的最初产出，而不是最终目标。 参与的更持久的结果是管道本身：从原始业务数据到经认证的训练集的可重复路径、经过微调的模式和经过评估的部署文物。 Exowat现在可以在几天而不是几个月内运行这条路径。 警报分类和能源市场分析是许多狭义、高价值的任务中的两个，适用同一方法。
挑战：关于实际能源基础设施的AI
Exowat的能源管理系统(EMS)跨越越来越多的业务地点。 每个站点不断产生出警报：一个硬件组件运行出光谱，一个被丢弃的连接，一个外程电压读取，以及类似事件。 人类操作人员无法实时监控每个地点。 Exowat需要一个AI agent，可以读取每个站点的警报状态，自主和可靠地采取或推荐正确的下个动作。
一个前沿模式无法解决这个问题有三个原因：
- 任务狭窄，专有。 在 Exowatt 的 EMS 上，一个通用的前沿模型并不适合它。
- 它必须运行在边缘，没有GPU，并且经常没有互联网。 许多站点的连通性有限或间歇性很强，因此agent依赖于对边疆模型的云召唤，当连接下降时，操作员会失去覆盖。
- 成本在机队一级并不相称。 将每一项业务决定逐一推向数千个地点的前沿模式，对于不断重复的决定来说是不经济的。
这就是Exowat转向模型定制的地方。 Exowat最初的微调工作流程依赖于选择一个开放量级模型，建造一个容器，并在任何实验能够运行之前创建自定义培训配方。 这是一个主要的阻塞模型实验。 此外，他们还要决定微调型号的GPU硬件要求。 随着团队加快了实验速度，每次跑先需要选择特定的GPU实例类型，再等待这种自选能力到位。 当所选实例类型不可用时，这可能会延迟运行的开始或完全屏蔽运行。
他们需要一个小到可以运行在无GPU边缘控制器上的模型，然而与具体任务上的前沿模型相比，它足够精确，可以自主行动。 微调缩小了这一差距：一种紧凑的、专门的任务模式，既可在云中部署，也可在边缘部署。
解决办法概述
Exowater公司在Amazon SageMaker AI上采用了一种无服务器的云母模型定制方法来应对这些挑战。 同样的训练管为两个部署目标：边缘和云层提供了精细的模型。
Exowat在Qwen3-1.7B模型上应用了这一方法，用于第一种使用案例，边缘警报分解，然后在Qwen3-14B模型上应用了同样的方法，用于第二种使用案例，云能-市场分析。 公司计划再用这个解决方案来在整个舰队建造更小，任务特定的模型。
以下7个AWS服务为AI管道提供动力，没有实例，集群，或端点可以管理：
工作流程分为三个阶段：
型号定制(云):Exowat 微调开放量级基站型号，采用无服务器型号定制，低Rank适应(LoRA)并被监督的微调(SFT)于SageMaker AI上。 由于无服务器培训按需分配能力，团队每天进行多个实验，而不是等待自选的GPU. 经评价后，最佳模式在SageMaker AI模型登记册上注册。
边缘部署：对于对潜伏敏感，连接受限的工作如警报分解，微调的Qwen3-1.7B型被冷冻，被分解为GGUF格式，并使用现场控制器在边缘与llama.cpp在Kubernetes舱内运行。 此路径不需要 GPU，没有互联网连接即可运行。
云部署 (弹性)：用于互联网联通，机队级分析，微调的Qwen3-14B能源市场模式通过Amazon Bedrock Custom Control 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，再加上在大约五分之一的参数上催生出这个狭长而单转的任务，同时保持了足够小的可以进行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 sock上下线。 它也运行在t3.2x大实例类型上。
使用案例2：云能市场分析与Qwen3-14B
可调度的储存将时间转化为一项业务决定：每个地点必须不断决定储存的能为负荷和何时放出所储存的能，以及连接电网的场址的市场条件为这种选择提供动力。 微调的模型读取了6小时的活市场数据包(约90行的实时价格，日出预测，和网格通知)，并在约4秒后返回了5个市场事件之一(如价格飙升或稀缺增加值). 每一份索赔都与特定的数据行相接，以通报发送策略。
为什么 Qwen3-14B
Qwen3-14B之所以被选取，是因为它得到了Amazon Bedrock Custom Model Introduction的支持，它作为"SageMaker"公共枢纽模型发船，配有现成的LoRA配方(没有自定义的容器或实例类型可以管理)，在大约28个GiB时它足够小，能够以成本效益高的服务。
培训数据和程序
Exowat微调了取自5年历史的德克萨斯州公共电气可靠性委员会(ERCOT)市场数据模型(12个表格的约1.63亿行). 团队将这一数据标记为25 000个实例(22,000个用于培训，1,000个用于验证，2,000个用于测试)。 然后，他们把训练套件扩大到86 281行，在Amazon Bedrock上将Anthropic的Claude Sonnet 4.6重写出每个例子的取词，而其标签和数字字段则保持不变。
训练是单一的LoRA Epoch (排名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 Gem Box. All rights belong to the original author.