AWS Machine Learning出典公開日

Exowatt、SageMakerサーバーレスモデルカスタマイズでフロンティアモデルを精度で上回る

Exowattは、AIデータセンターなどのエネルギー集約型アプリケーションに信頼性の高い電力を供給する、モジュール式のディスパッチ可能なソーラーシステムを構築しています。主力製品であるExowatt P3は、光学レンズを通じて太陽エネルギーを捕捉し、長時間蓄熱バッテリーに熱として蓄え、熱機関を通じてオンデマンドで電力を供給します。

Exowattは、AIデータセンターなどのエネルギー集約型アプリケーションに信頼性の高い電力を供給する、モジュール式のディスパッチ可能なソーラーシステムを構築しています。主力製品であるExowatt P3は、光学レンズを通じて太陽エネルギーを捕捉し、長時間蓄熱バッテリーに熱として蓄え、熱機関を通じてオンデマンドで電力を供給します。系統連系型の太陽光発電システムとは異なり、P3はデータセンターに直接(メーター後方で)電力を供給するため、データセンターは数年単位の系統接続待ちの順番を待たずに稼働を開始できます。Exowattは、ソーラーシステムの稼働中のアラームを監視・トリアージし、多くの場合エッジ上で、接続が限定的または途絶えた状態でも運用上の意思決定を支援するAIエージェントのフリートを構築しています。テストベンチから製造、そして数千台の現場設備へとフリートが拡大するに伴い、これらのシステムを運用するインテリジェンス層もそれに合わせて拡張する必要があります。

本記事では、ExowattがAmazon SageMaker AIのサーバーレスモデルカスタマイズを使用して、再現可能なAIパイプラインを構築した方法を紹介します。このパイプラインは、エッジとクラウドという2つのデプロイターゲット向けにタスク固有のファインチューニング済みモデルを生成し、フロンティアモデルよりも高い精度を最大49分の1のコストで達成します。

ここで説明する2つのモデルは、そのパイプラインの最初の成果物であり、最終目標ではありません。この取り組みでより持続的な成果となったのはパイプラインそのものです。それは、生の運用データから認証済みのトレーニングセット、ファインチューニング済みモデル、そして評価済みのデプロイ成果物に至る、再現可能な道筋です。Exowattは現在、この道筋を数か月ではなく数日で実行できます。アラームのトリアージやエネルギー市場分析は、同じアプローチが適用できる数多くの限定的で高価値なタスクのうちの2つにすぎません。

課題:物理的なエネルギーインフラ上のAI

Exowattのエネルギー管理システム(EMS)は、拡大を続ける運用サイトのフリート全体で稼働しています。各サイトは継続的にアラームを生成します。仕様外の動作をするハードウェアコンポーネント、接続の切断、範囲外の電圧読み取りなど、同様のイベントです。フリートが数千台の現場設備に拡大すると、人間のオペレーターがすべてのサイトをリアルタイムで監視することはできません。Exowattには、各サイトのアラーム状態を読み取り、正しい次のアクションを自律的かつ確実に実行または推奨できるAIエージェントが必要でした。

フロンティアモデルではこの問題を解決できなかった理由は3つあります。

  1. このタスクは限定的かつ専有的なものだからです。ExowattのEMSにおけるアラームのトリアージは、同社固有のハードウェア、データ、運用ロジックに依存します。汎用のフロンティアモデルはこれに特化していません。
  2. GPUなし、多くの場合インターネットなしでエッジ上で実行する必要があるからです。多くのサイトは接続が限定的または断続的であり、フロンティアモデルへのクラウド呼び出しに依存するエージェントでは、接続が切れたときにオペレーターがサポートを失うことになります。
  3. フリートレベルではコストが拡大しないからです。継続的に繰り返される意思決定のために、数千のサイトにわたるすべての運用上の意思決定をフロンティアモデルにルーティングすることは経済的ではありません。

ここでExowattはモデルカスタマイズに目を向けました。Exowattの初期のファインチューニングワークフローは、オープンウェイトモデルの選択、コンテナの構築、そして実験を開始する前のカスタムトレーニングレシピの作成に依存していました。これはモデル実験における大きな障害でした。さらに、モデルのファインチューニングに必要なGPUハードウェア要件を決定する必要もありました。チームが実験のペースを上げるにつれ、各実行ではまず特定のGPUインスタンスタイプを選択し、そのセルフ選択されたキャパシティが利用可能になるのを待つ必要がありました。選択したインスタンスタイプが利用できない場合、実行の開始が遅れたり、完全にブロックされたりする可能性がありました。

同社に必要だったのは、GPUなしのエッジコントローラーで実行できるほど小さく、かつ特定のタスクにおいてフロンティアモデルと比較して自律的に動作できるほど正確なモデルでした。ファインチューニングによってそのギャップが埋まりました。クラウドとエッジの両方にデプロイ可能な、コンパクトでタスクに特化したモデルです。

ソリューションの概要

Exowattは、Amazon SageMaker AI上のクラウドネイティブなサーバーレスモデルカスタマイズアプローチを採用することで、これらの課題に対処しました。同じトレーニングパイプラインが、エッジとクラウドという2つのデプロイターゲット向けのファインチューニング済みモデルを生成します。

Exowattは、最初のユースケースであるエッジアラームトリアージのためにQwen3-1.7Bモデルでこのアプローチを実装し、次に2番目のユースケースであるクラウドエネルギー市場分析のために同じアプローチをQwen3-14Bモデルに適用しました。同社はこのソリューションを再利用して、フリート全体にわたるより小さなタスク固有のモデルを構築することを計画しています。

図1:ビルド、クラウドサービング、エッジサービングの各ステージにわたるExowattのファインチューニングおよびデプロイパイプライン

以下の7つのAWSサービスがAIパイプラインを支えており、管理すべきインスタンス、クラスター、エンドポイントはありません:

AWSサービス 目的
Amazon Simple Storage Service (Amazon S3) データ、マニフェスト、モデルアーティファクト、テストセット
Amazon SageMaker AIサーバーレスファインチューニング Public Hubレシピから起動されるすべてのファインチューニング実行
Amazon SageMaker AIサーバーレス評価 マネージドジョブとして各候補の2,000件の回答をスコアリング
SageMaker Model Registry エビデンスとメトリクスを伴う完了済みのすべてのファインチューニング
Amazon Bedrock Custom Model Import Cloud EMS向けにファインチューニング済みQwen3-14Bをホストし、Cloud EMSサービスからプライベートに呼び出し。アイドルコストなし
Amazon Bedrock (Claude、Qwen3)

言い換え(訓練データ内で回答ごとに3件の書き換え)とフロンティアモデルのベンチマーキング

アラームトリアージの言い換えには、Amazon Bedrock上のQwen3-VL-235Bを使用します。エネルギーマーケットの言い換えには、Amazon Bedrock上のClaude Sonnet 4.6を使用します。

AWS Lambda + Amazon EventBridge サーバーレス評価スコアラーと、カスタムモデルの定期的なキープウォーム起動

このワークフローは3つのステージに整理されています。

モデルカスタマイズ(クラウド): Exowattは、SageMaker AI上でサーバーレスモデルカスタマイズ、Low-Rank Adaptation (LoRA)、および教師ありファインチューニング (SFT) を使用してオープンウェイトのベースモデルをファインチューニングします。サーバーレストレーニングはオンデマンドでキャパシティを割り当てるため、チームはセルフマネージドのGPUを待つのではなく、1日に複数の実験を実行できます。評価後、最良のモデルはSageMaker AI Model Registryに登録されます。

エッジデプロイ: レイテンシが敏感で接続が制約されるアラームトリアージのような作業では、ファインチューニング済みのQwen3-1.7Bモデルをフリーズし、GGUF形式に量子化し、エッジのオンサイトコントローラーを使用してKubernetesポッド内のllama.cppで実行します。この経路はGPUを必要とせず、インターネット接続なしで動作します。

クラウドデプロイ(エラスティック): インターネットに接続されたフリートレベルの分析には、ファインチューニング済みのQwen3-14BエネルギーマーケットモデルをAmazon Bedrock Custom Model Import経由で提供します。これはアイドルコストなしで実行され、モデルがアクティブな間のみ課金されます。

なぜAmazon SageMaker AIのサーバーレスモデルカスタマイズなのか

Amazon SageMaker AIのサーバーレスモデルカスタマイズサービスは、SageMaker Public Hubからすぐに使えるファインチューニングレシピ付きの幅広いオープンウェイトモデルを提供するため、チームは通常数週間かかり得るカスタムトレーニングコンテナの構築と最適化を避けることができました。Exowattにとって、これによりファインチューニングは希少で予定されたイベントから、日常的なオンデマンドの作業へと変わりました。これにより、実験コストを低く抑えながら、迅速な実験とテストのループが実用的になります。

プロビジョニングされたGPUでのファインチューニングでは、特定のインスタンスタイプを選択し、そのキャパシティをリクエストし、利用可能になるのを待ち、ジョブを実行し、確保している間ずっとインスタンスに支払う必要があります。確保された時間には通常、専用インスタンスを実行し続ける際の実験間のアイドル時間が含まれます。多くの実験を実行する小規模なチームにとって、これはイノベーションを遅らせ、コストを増大させます。Amazon SageMaker AIのサーバーレスモデルカスタマイズは、ファインチューニングジョブの実行に必要なインフラストラクチャを自動的に管理・オーケストレーションし、キャパシティ管理の苦労を取り除き、ファインチューニングジョブが実行されている時間のみ課金します。

ユースケース1:Qwen3-1.7Bによるエッジアラームトリアージ

Exowattのサイトは24時間体制でアラームを発生させます。コンパクトなオンサイトモデルが各アラームをサイト自身のステータスやテレメトリとともに読み取り、引用された証拠(オフラインのシステム、出力低下したコンポーネント、センサーの不一致など)とともに小さな固定分類セットのうちの1つ、または証拠が不十分な場合の明示的な棄権を返します。

モデル選択と訓練データ

チームはまずQwen3-8Bをプロンプティングとガードレール付きで試しましたが、目標(0.735 macro-F1)には届きませんでした。ファインチューニング済みのQwen3-1.7Bがこれを変えました。この狭い単一ターンのタスクにおいて、パラメータ数が約5分の1でありながら、プロンプティング付きのQwen3-8Bのセットアップを上回り、GPUなしのエッジ推論に十分小さいままでした。12のデータセットバージョンにわたる13個のファインチューニング済みQwen3-8B候補は、プロンプティングされた8Bのベースラインを決して上回りませんでした。より多様なデータを使った小さいモデルがそれを成し遂げたのです。

訓練セットは小さく厳選されたもので、生成されたサイトシナリオに対する684件の検証済みの決定と、文章を書き換えながら各決定を固定し続けた1,838件の認定済み言い換えから構成される2,522例でした。言い換えはAmazon Bedrock上のQwen3-235Bによって約3.72ドルで生成されました。各言い換えは、決定、ラベル、証拠の引用、およびすべての数値が変更されていないことを決定論的なチェックが確認した場合にのみ保持されました(2,218候補のうち1,838が合格)。1つの障害ファミリーは訓練から完全に除外され、320ケースがテスト用に確保されました。

訓練とデプロイ

訓練はSageMakerのサーバーレスファインチューニングで約32分で完了し、コストは約20〜25ドルでした。8ビットに量子化された(約1.71 GiB)モデルは、サイトの既存のCPUサーバー上の6 GiBのllama.cppポッドでオフラインで実行されます。t3.2xlargeインスタンスタイプでも実行できます。

ユースケース2:Qwen3-14Bによるクラウドエネルギーマーケット分析

ディスパッチ可能なストレージはタイミングを運用上の意思決定に変えます。各サイトは、負荷のためにどれだけの蓄積エネルギーを保持し、いつ放出するかを継続的に決定しなければならず、系統接続されたサイトでは市場状況がその選択に影響します。ファインチューニング済みモデルは、ライブ市場データの6時間分のパケット(リアルタイム価格、日前予測、グリッド通知を含む約90行)を読み取り、約4秒で5つの市場イベント(価格スパイクや希少性アダーなど)のうちの1つを返します。すべての主張は、ディスパッチ戦略の参考にするため、特定のデータ行に紐付けられます。

なぜQwen3-14Bなのか

Qwen3-14Bが選ばれたのは、Amazon Bedrock Custom Model Importでサポートされていること、すぐに使えるLoRAレシピ付きのSageMaker Public Hubモデルとして提供されており(管理すべきカスタムコンテナやインスタンスタイプがない)、約28 GiBでコスト効率よく提供できるほど小さいためです。

訓練データとプロセス

Exowattは、5年間の履歴から取得した公開のElectric Reliability Council of Texas (ERCOT) 市場データ(12テーブルにわたる約163百万行)を用いてモデルをファインチューニングしました。チームはこのデータにルールベースでラベルを付け、25,000例(訓練用22,000、検証用1,000、テスト用に2,000を確保)を作成しました。その後、AnthropicのClaude Sonnet 4.6をAmazon Bedrock上で使用し、ラベルと数値フィールドは固定したまま各例の文章を書き換えることで、訓練セットを86,281行に拡張しました。

トレーニングは単一のLoRAエポック(rank 16、alpha 32)で、最大4ジョブを同時実行するマネージドサーバーレスのファインチューニングにより約8.5時間で完了しました。チームは、最初の計画からチャンピオンモデルがCloud EMSで稼働するまでの6日間に、23ジョブ・約155時間のマネージドトレーニングを実行しました。

決定的な改善は言い換えの多様性からもたらされました。回答ごとに3つの書き換えを追加したところ、macro-F1が0.950から0.975に向上しました。ベースモデルのmacro-F1はわずか0.415でした。有効なJSONは生成できましたが、まだ市場を知らなかったのです。ファインチューニングがそれを解決しました。

デプロイ

マージされたチェックポイントは約14分でAmazon Bedrock Custom Model Importにインポートされました。このモデルはアイドルコストなしで稼働し、アクティブな間のみ1時間あたり$6.86で課金されます。

ベンチマーク結果

エッジのアラームトリアージタスクでは、ファインチューニングされたQwen3-1.7Bは、有効な回答を生成できないモデルから、320のテストケースで0.911のmacro-F1に達し、すべてのフロンティアベースラインを上回りました。同一のファインチューニングおよび評価のループを、2,000のテストケースがあるエネルギー市場タスクに適用したところ、Qwen3-14Bは0.975のmacro-F1に達し、ここでもフロンティアベースラインを上回り、コストはそのわずかな割合で済みました。どちらの場合も、小規模なファインチューニング済みモデルが、特定のタスクではるかに大規模な汎用モデルを上回りました。

両モデルは、すべての主張が特定の入力データ行を引用する厳密なJSONを返します。サポートされていない主張はオペレーターに届く前に削除されるため、チームは自律的な物理環境で小規模モデルを信頼できます。

 

モデル Macro-F1 $ / 1,000 decisions オフライン?
Claude Haiku 4.5 0.519 ~$4.70 いいえ
Claude Opus 4.7 0.680 ~$22 いいえ
Claude Sonnet 4.6 0.698 ~$15 いいえ
ファインチューニング済み Qwen3-1.7B 0.911 $0* はい
ベース Qwen3-1.7B スコアなし(有効性ゲートに不合格)

表1:エッジアラームトリアージ結果、ファインチューニング済みQwen3-1.7Bをフロンティアモデルと比較

1,000デシジョンあたり$0は、従量課金のAPIまたはGPU推論コストがないことを意味します。量子化されたモデルはサイトの既存のCPU上で稼働します。

モデル Macro-F1 Event Acc. 有効なJSON $ / 1,000 answers
ベース Qwen3-14B 0.415 0.54 0.834 $0.64
Claude Sonnet 4.6 0.538 0.584 0.991 $17.79
Claude Opus 4.7 0.625 0.718 0.9995 $29.26
ファインチューニング済み Qwen3-14B 0.975 0.983 1.000 $0.60

表2: クラウドのエネルギー市場分析結果、ファインチューニング済みQwen3-14Bとフロンティアモデルの比較

コストは、回答あたりの実測トークン数にAmazon Bedrockのリスト価格を掛けたものです。ファインチューニングにより、オープンなモデルは最下位から1位に浮上しました。Claude Opus 4.7に対してマクロF1で+0.35(95パーセント信頼区間0.324から0.371)を達成し、1,000回答あたりのコストは約49分の1です($0.60対$29.26)。このモデルは、後日行われた2つ目のテストセットでも0.968のマクロF1を維持しました。

ビジネス上のメリット

より迅速なイテレーションと市場投入までの時間短縮: Exowattはカスタマイズしたモデルを実験から本番環境までわずか9日で移行しました。このプロセスは、チームがカスタムコンテナやトレーニングレシピの構築と最適化、GPUのプロビジョニング、インフラ管理を行う必要があった場合には数か月かかる可能性がありました。SageMaker AIのサーバーレスモデルカスタマイズにより、チームはQwen3-1.7Bを約32分、Qwen3-14Bを約8.5時間でトレーニングし、キャパシティのリクエストなしで、最大4つのトレーニングジョブを同時に実行できました。エネルギー市場のユースケースでは、Exowattは合計約155時間のマネージドトレーニングを行う23のジョブを実行し、6日間でベースモデルからファインチューニング済みモデルをCloud EMSで提供するまで移行しました。マージされたチェックポイントは約14分でAmazon Bedrockにインポートされました。エンドツーエンドのパイプラインは7つのAWSサーバーレスサービスを使用し、Exowattが管理すべきインスタンス、クラスター、エンドポイントはありませんでした。

フロンティアモデルと比較した高い精度: ファインチューニング済みの両モデルは、それぞれのタスクでより大きなフロンティアモデルを上回りました。Qwen3-1.7Bは0.911のマクロF1(Claude Sonnet 4.6は0.698)、Qwen3-14Bは0.975(Claude Opus 4.7は0.625)を達成しました。

両方のデプロイメントで低コスト: クラウドでは、Qwen3-14Bは1,000回答あたり$0.60で提供され、Claude Opus 4.7の$29.26と比較して約49分の1です。アイドルコストはなく、Amazon Bedrock Custom Model Importでのアクティブ時のみ1時間あたり$6.86がかかります。エッジでは、量子化されたQwen3-1.7Bがサイトの既存のCPU上で動作し、推論あたりのコストはなく、接続性への依存もありません。

根拠に基づく低リスクな出力: 両モデルを通じて、エビデンスフェンスにより引用のない主張(ソース、フィールド、値が入力と文字通り一致しないエビデンス引用)はすべて排除され、エッジモデルは確信がない場合に推測するのではなく回答を控えます。これにより、チームはサイトのクラウドホスト型レプリカ上でシャドーモードで自律的に実行することができました。

学んだ教訓

特定のタスクでは、より小さなファインチューニング済み大規模言語モデルが大型のフロンティアモデルを上回る可能性がある: ファインチューニング済みのQwen3-1.7BとQwen3-14Bモデルはそれぞれ、対象タスクでフロンティアモデルを上回り、はるかに小さなモデルで、わずかなコストでより高い精度を実現しました。

データの品質と多様性は、生のデータ量や追加のエポックよりも重要: 範囲を厳密に絞ったタスクでは、モデルサイズやデータ量よりもデータ品質が重要でした。アラームトリアージモデルでは、検証済みのトレーニング多様性を増やすことで、マクロF1が0.584(684件の検証済み判断のみでトレーニング)から0.911(パラフレーズで拡張した2,522行のデータセットを使用)に向上しました。同じ行で単に多くのエポックを実行するのは効果がなく、684件の元の行で11エポック(同じステップ数)トレーニングした対照実験は0.879しか達成しませんでした。全体を通じて、キュレーションされたデータがデータセットのサイズよりも重要でした。

プロビジョニングステップの削除がチームの働き方を変える: トレーニング実行のためにGPUキャパシティを待つ必要がなくなると、ファインチューニングは稀なイベントから日常的で反復的な作業へと変わります。

1つのトレーニングパイプラインで2つのデプロイターゲットに対応: モデルのトレーニングをデプロイメントから分離することで、Exowattはオフラインのエッジデプロイメントと接続されたフリートレベルの分析の両方に同じパイプラインを使用でき、運用が簡素化され、クラウドでのモデルデプロイが加速されました。

結論

Exowattは現在、モデル固有のデータ準備からモデルデプロイまでのタスクを担う、再利用可能な1つのAIパイプラインを保有しています。異なるタスクに1つのモデルをチューニングするのではなく、Exowattは新しいデバイスタイプや市場タスクが追加されるにつれて、フリート全体で異なるタスクに対して同じファインチューニングの原則を適用し、それぞれに固有のデータ、特定のモデル、評価を行う計画です。

このパターンはエネルギー業界のセグメントを超えて一般化します。AIエンジニア、データサイエンティスト、およびさまざまな業界セグメントの顧客は、同じ原則を採用できます。Amazon SageMaker AIサーバーレスモデルカスタマイズを低オーバーヘッドのAIパイプラインとして使用し、小規模でタスク固有のモデルをファインチューニングし、作業が行われる場所にデプロイしてください。接続性やレイテンシーが必要な場合はエッジに、弾力的なワークロードにはAmazon SageMaker AIなどのマネージドクラウドエンドポイントを通じてデプロイします。

詳細については、以下を参照してください: Amazon SageMaker AIサーバーレスモデルカスタマイズ および Amazon Bedrock.


著者について

原文の出典

AWS Machine Learning

内容について

原文の公開と権利は出典元に帰属します。

機械翻訳 · 原文をご参照ください