Exowatt surpassse les modèles de pointe en précision avec la personnalisation de modèles serverless de SageMaker

Exowatt construit des systèmes solaires modulaires et dispatchables qui fournissent une énergie fiable pour des applications à forte consommation énergétique telles que les centres de données d'IA. Son produit phare, l'Exowatt P3, capte l'énergie solaire grâce à des lentilles optiques, la stocke sous forme de chaleur dans une batterie thermique de longue durée et délivre de l'électricité à la demande via un moteur thermique. Contrairement aux systèmes solaires photovoltaïques raccordés au réseau, le P3 alimente les centres de données directement derrière le compteur, aidant ainsi les centres de données à entrer en service sans attendre dans des files d'interconnexion au réseau de plusieurs années. Exowatt développe une flotte d'agents d'IA qui surveillent et trient les alarmes en temps réel et appuient les décisions opérationnelles pour les systèmes solaires, souvent à la périphérie, avec une connectivité limitée ou inexistante. À mesure que sa flotte passe des bancs d'essai vers la fabrication et des milliers d'unités déployées sur le terrain, la couche d'intelligence qui exploite ces systèmes doit évoluer avec elle.

Dans cet article, nous montrons comment Exowatt a utilisé la personnalisation de modèles serverless d'Amazon SageMaker AI pour construire un pipeline d'IA reproductible. Le pipeline produit des modèles affinés spécifiques à des tâches pour deux cibles de déploiement, la périphérie et le cloud, atteignant une précision supérieure à celle des modèles de pointe pour un coût jusqu'à 49 × inférieur.

Les deux modèles décrits ici sont les premiers produits de ce pipeline plutôt que son objectif final. Le résultat le plus durable de cette collaboration a été le pipeline lui-même : un chemin reproductible allant des données opérationnelles brutes à un jeu d'entraînement certifié, un modèle affiné et un artefact de déploiement évalué. Exowatt peut désormais parcourir ce chemin en jours plutôt qu'en mois. Le tri des alarmes et l'analyse du marché de l'énergie sont deux des nombreuses tâches étroites et à forte valeur auxquelles la même approche s'applique.

Le défi : l'IA sur une infrastructure énergétique physique

Le système de gestion de l'énergie (EMS) d'Exowatt fonctionne sur une flotte croissante de sites opérationnels. Chaque site produit en continu des alarmes : un composant matériel fonctionnant hors spécifications, une connexion perdue, une lecture de tension hors plage, et des événements similaires. À mesure que la flotte évolue vers des milliers d'unités de terrain, un opérateur humain ne peut pas surveiller chaque site en temps réel. Exowatt avait besoin d'un agent d'IA capable de lire l'état des alarmes sur chaque site et de prendre ou de recommander la bonne action suivante de manière autonome et fiable.

Un modèle de pointe ne pouvait pas résoudre ce problème pour trois raisons :

1. La tâche est étroite et propriétaire. Le tri des alarmes sur l'EMS d'Exowatt dépend de leur matériel, de leurs données et de leur logique d'exploitation spécifiques. Un modèle de pointe à usage général n'y est pas spécialisé.
2. Il doit fonctionner à la périphérie, sans GPU et souvent sans Internet. De nombreux sites ont une connectivité limitée ou intermittente, de sorte qu'un agent dépendant d'un appel cloud à un modèle de pointe laisse l'opérateur sans couverture lorsque la connexion est perdue.
3. Le coût ne passe pas à l'échelle de la flotte. Router chaque décision opérationnelle vers un modèle de pointe sur des milliers de sites n'est pas économiquement viable pour une décision qui se répète en continu.

C'est là qu'Exowatt s'est tourné vers la personnalisation de modèles. Le flux de travail initial d'affinage d'Exowatt reposait sur la sélection d'un modèle à poids ouverts, la construction d'un conteneur et la création d'une recette d'entraînement personnalisée avant que toute expérience puisse s'exécuter. C'était un obstacle majeur à l'expérimentation de modèles. De plus, ils devaient déterminer les besoins matériels GPU de l'affinage des modèles. À mesure que l'équipe accélérait le rythme de l'expérimentation, chaque exécution nécessitait d'abord de choisir un type d'instance GPU spécifique, puis d'attendre que cette capacité auto-sélectionnée devienne disponible. Lorsqu'un type d'instance choisi n'était pas disponible, cela pouvait retarder le démarrage d'une exécution ou la bloquer entièrement.

Ils avaient besoin d'un modèle assez petit pour fonctionner sur un contrôleur de périphérie sans GPU, mais assez précis par rapport au modèle de pointe sur la tâche spécifique pour agir de manière autonome. L'affinage a comblé cet écart : un modèle compact et spécialisé pour une tâche, déployable à la fois dans le cloud et à la périphérie.

Présentation de la solution

Exowatt a relevé ces défis en adoptant une approche de personnalisation de modèles native du cloud et serverless sur Amazon SageMaker AI. Le même pipeline d'entraînement produit des modèles affinés pour deux cibles de déploiement : la périphérie et le cloud.

Exowatt a mis en œuvre cette approche sur le modèle Qwen3-1.7B pour le premier cas d'utilisation, le tri des alarmes à la périphérie, puis a appliqué la même approche au modèle Qwen3-14B pour le second cas d'utilisation, l'analyse du marché de l'énergie dans le cloud. L'entreprise prévoit de réutiliser cette solution pour construire des modèles plus petits et spécifiques à des tâches sur l'ensemble de la flotte.

Figure 1 : pipeline d'affinage et de déploiement d'Exowatt, couvrant les étapes de construction, de service cloud et de service en périphérie

Les sept services AWS suivants alimentent le pipeline d'IA, sans instances, clusters ni points de terminaison à gérer :

Le workflow est organisé en trois étapes :

Personnalisation du modèle (cloud) : Exowatt affine des modèles open-weight de base en utilisant la personnalisation de modèles serverless, la Low-Rank Adaptation (LoRA) et le fine-tuning supervisé (SFT) sur SageMaker AI. Comme l'entraînement serverless alloue la capacité à la demande, l'équipe lance plusieurs expériences par jour au lieu d'attendre des GPU libérés. Après l'évaluation, le meilleur modèle est enregistré dans le SageMaker AI Model Registry.

Déploiement en périphérie (edge) : Pour les tâches sensibles à la latence et contraintes par la connectivité, comme le triage des alarmes, le modèle Qwen3-1.7B affiné est figé, quantifié au format GGUF et exécuté avec llama.cpp dans des pods Kubernetes en périphérie à l'aide de contrôleurs sur site. Ce chemin ne nécessite aucun GPU et fonctionne sans connexion Internet.

Déploiement cloud (élastique) : Pour l'analyse au niveau de la flotte avec connexion Internet, le modèle énergétique Qwen3-14B affiné est servi via Amazon Bedrock Custom Model Import, qui fonctionne sans coût au repos et ne facture que lorsque le modèle est actif.

Pourquoi la personnalisation serverless de modèles d'Amazon SageMaker AI

Le service de personnalisation serverless de modèles d'Amazon SageMaker AI offre un large choix de modèles open-weight avec des recettes de fine-tuning prêtes à l'emploi issues du SageMaker Public Hub, ce qui a permis à l'équipe d'éviter de construire et d'optimiser un conteneur d'entraînement personnalisé, un travail qui peut sinon prendre des semaines. Pour Exowatt, cela a transformé le fine-tuning d'un événement rare et planifié en une opération de routine, disponible à la demande. Cela rend une boucle rapide d'expérimentation et de test pratique tout en maintenant un faible coût d'expérimentation.

Le fine-tuning sur des GPU provisionnés nécessite de choisir un type d'instance spécifique, de demander cette capacité, d'attendre qu'elle soit disponible, d'exécuter la tâche et de payer l'instance aussi longtemps qu'elle est retenue. Le temps de rétention inclut généralement le temps d'inactivité entre les expériences lorsqu'une instance dédiée est maintenue en fonctionnement. Pour une petite équipe menant de nombreuses expériences, cela ralentit l'innovation et augmente les coûts. La personnalisation serverless de modèles d'Amazon SageMaker AI gère et orchestre automatiquement l'infrastructure nécessaire à l'exécution de la tâche de fine-tuning, supprimant la pénibilité de la gestion de capacité, et ne facture que le temps d'exécution de la tâche de fine-tuning.

Cas d'utilisation 1 : triage des alarmes en périphérie avec Qwen3-1.7B

Les sites Exowatt génèrent des alarmes jour et nuit. Un modèle compact sur site lit chaque alarme avec l'état et la télémétrie du site et renvoie l'une des classifications d'un petit ensemble fixe avec des preuves citées (comme un système hors ligne, un composant dégradé ou une incohérence de capteur) ou une abstention explicite lorsque les preuves sont insuffisantes.

Sélection du modèle et données d'entraînement

L'équipe a d'abord essayé Qwen3-8B avec du prompting et des garde-fous, ce qui a plafonné sous la cible (0.735 macro-F1). Un Qwen3-1.7B affiné a changé la donne : il a surpassé la configuration Qwen3-8B plus prompting sur cette tâche étroite à tour unique avec environ un cinquième des paramètres, tout en restant assez petit pour l'inférence en périphérie sans GPU. Treize candidats Qwen3-8B affinés sur 12 versions de jeux de données n'ont jamais battu la base de référence 8B avec prompting. Le modèle plus petit avec des données plus variées l'a fait.

Le jeu d'entraînement était petit et organisé avec soin : 2,522 exemples construits à partir de 684 décisions vérifiées sur des scénarios de site générés plus 1,838 paraphrases certifiées qui maintenaient chaque décision fixe tout en réécrivant la prose. Les paraphrases ont été générées par Qwen3-235B sur Amazon Bedrock pour environ 3.72 $. Chaque paraphrase n'a été conservée que si des vérifications déterministes confirmaient que la décision, les étiquettes, les citations de preuves et chaque nombre étaient inchangés (1,838 sur 2,218 candidats ont passé). Une famille de pannes a été entièrement exclue de l'entraînement, et 320 cas ont été réservés pour les tests.

Entraînement et déploiement

L'entraînement s'est achevé en environ 32 minutes sur le fine-tuning serverless de SageMaker pour environ 20 $ à 25 $. Quantifié sur 8 bits (environ 1.71 GiB), le modèle fonctionne hors ligne dans un pod llama.cpp de 6 GiB sur le serveur CPU existant du site. Il fonctionne également sur un type d'instance t3.2xlarge.

Cas d'utilisation 2 : analyse du marché de l'énergie dans le cloud avec Qwen3-14B

Le stockage dispatchable transforme le timing en décision opérationnelle : chaque site doit décider en permanence de la quantité d'énergie stockée à conserver pour sa charge et du moment de la restituer, et pour les sites connectés au réseau, les conditions du marché alimentent ce choix. Le modèle affiné lit un paquet de six heures de données de marché en direct (environ 90 lignes de prix en temps réel, de prévisions day-ahead et d'avis du réseau) et renvoie l'un des cinq événements de marché (comme un pic de prix ou un scarcity adder) en environ quatre secondes. Chaque affirmation est liée à une ligne de données spécifique pour éclairer la stratégie de dispatch.

Pourquoi Qwen3-14B

Qwen3-14B a été choisi parce qu'il est pris en charge par Amazon Bedrock Custom Model Import, qu'il est proposé comme modèle du SageMaker Public Hub avec une recette LoRA prête à l'emploi (aucun conteneur ni type d'instance personnalisé à gérer) et qu'à environ 28 GiB, il est assez petit pour être servi de manière rentable.

Données et processus d'entraînement

Exowatt a affiné le modèle sur des données publiques du marché de l'Electric Reliability Council of Texas (ERCOT) tirées de cinq ans d'historique (environ 163 millions de lignes réparties sur 12 tables). L'équipe a étiqueté ces données par règles en 25,000 exemples (22,000 pour l'entraînement, 1,000 pour la validation et 2,000 mis de côté pour les tests). Elle a ensuite étendu le jeu d'entraînement à 86,281 lignes en faisant réécrire par Claude Sonnet 4.6 d'Anthropic sur Amazon Bedrock la prose de chaque exemple, ses étiquettes et champs numériques restant inchangés.

L'entraînement a consisté en une seule époque LoRA (rang 16, alpha 32), réalisée en environ 8,5 heures de fine-tuning serverless géré avec jusqu'à quatre tâches exécutées simultanément. L'équipe a lancé 23 tâches et environ 155 heures d'entraînement géré durant les six jours séparant le plan initial d'un modèle champion servant dans Cloud EMS.

L'amélioration décisive est venue de la diversité des paraphrases : l'ajout de trois réécritures par réponse a fait passer le macro-F1 de 0,950 à 0,975. Le modèle de base n'obtenait que 0,415 de macro-F1. Il produisait du JSON valide mais ne connaissait pas encore le marché. Le fine-tuning a corrigé cela.

Déploiement

Le point de contrôle fusionné a été importé dans Amazon Bedrock Custom Model Import en environ 14 minutes. Le modèle fonctionne sans coût au repos et n'est facturé qu'à 6,86 $ par heure lorsqu'il est actif.

Résultats des benchmarks

Sur la tâche de tri des alarmes en périphérie, le Qwen3-1.7B affiné est passé d'un modèle incapable de produire une réponse valide à 0.911 de macro-F1 sur 320 cas de test, devant toutes les références frontière. En appliquant la même boucle d'affinage et d'évaluation à la tâche de marché de l'énergie avec 2,000 cas de test, le Qwen3-14B a atteint 0.975 de macro-F1, encore devant la référence frontière et pour une fraction du coût. Dans les deux cas, un petit modèle affiné a battu des modèles généraux bien plus grands sur la tâche spécifique.

Les deux modèles renvoient un JSON strict dans lequel chaque affirmation cite une ligne précise des données d'entrée. Toute affirmation non justifiée est écartée avant d'atteindre un opérateur, ce qui permet à l'équipe de faire confiance à de petits modèles dans des environnements physiques autonomes.

Tableau 1 : Résultats du tri des alarmes en périphérie, Qwen3-1.7B affiné comparé aux modèles frontière

0 $ pour 1,000 décisions signifie aucun coût d'inférence API ou GPU facturé. Le modèle quantisé fonctionne sur le CPU existant du site.

Tableau 2 : Résultats de l'analyse du marché de l'énergie dans le cloud, Qwen3-14B affiné comparé aux modèles frontières

Les coûts correspondent aux prix catalogue d'Amazon Bedrock multipliés par les tokens mesurés par réponse. L'affinage a fait passer un modèle ouvert de la dernière à la première place : +0.35 de macro-F1 par rapport à Claude Opus 4.7 (intervalle de confiance à 95 pour cent : 0.324 à 0.371) pour un coût par 1,000 réponses environ 49× inférieur ($0.60 contre $29.26). Le modèle a maintenu 0.968 de macro-F1 sur un second jeu de test, ultérieur.

Avantages métier

Itération plus rapide et mise sur le marché accélérée : Exowatt a fait passer son modèle personnalisé de l'expérimentation à la production en seulement neuf jours. Ce processus aurait pu prendre des mois si l'équipe avait dû créer et optimiser des conteneurs et des recettes d'entraînement personnalisés, provisionner des GPU et gérer l'infrastructure. Avec la personnalisation de modèles serverless de SageMaker AI, l'équipe a entraîné Qwen3-1.7B en environ 32 minutes et Qwen3-14B en environ 8.5 heures, sans demande de capacité et avec jusqu'à quatre tâches d'entraînement exécutées simultanément. Pour le cas d'usage du marché de l'énergie, Exowatt a exécuté 23 tâches totalisant environ 155 heures d'entraînement géré et est passé du modèle de base à un modèle affiné servi dans Cloud EMS en six jours. Le checkpoint fusionné a été importé dans Amazon Bedrock en environ 14 minutes. Le pipeline de bout en bout a utilisé sept services serverless d'AWS, sans aucune instance, cluster ni point de terminaison à gérer pour Exowatt.

Précision supérieure par rapport aux modèles frontières : Les deux modèles affinés ont surpassé les modèles frontières plus grands sur leur propre tâche : Qwen3-1.7B avec 0.911 de macro-F1 (contre 0.698 pour Claude Sonnet 4.6) et Qwen3-14B avec 0.975 (contre 0.625 pour Claude Opus 4.7).

Coût réduit sur les deux déploiements : Dans le cloud, Qwen3-14B est servi à $0.60 par 1,000 réponses contre $29.26 pour Claude Opus 4.7 (environ 49× moins cher), sans coût au repos et à $6.86 par heure uniquement lorsqu'il est actif sur Amazon Bedrock Custom Model Import. À la périphérie, le Qwen3-1.7B quantifié s'exécute sur le CPU existant du site sans coût par inférence ni dépendance à la connectivité.

Sorties sourcées et à faible risque : Sur les deux modèles, la barrière de preuves a éliminé toute affirmation non citée (toute citation de preuve dont la source, le champ ou la valeur ne correspond pas littéralement à l'entrée), et le modèle de périphérie s'abstient plutôt que de deviner en cas d'incertitude. C'est ce qui a permis à l'équipe de l'exécuter de manière autonome en mode shadow sur une réplique d'un site hébergée dans le cloud.

Enseignements tirés

Pour des tâches spécifiques, de petits modèles de langage affinés peuvent surpasser les grands modèles frontières : Les modèles Qwen3-1.7B et Qwen3-14B affinés ont chacun surpassé les modèles frontières sur la tâche cible, offrant une précision supérieure pour une fraction du coût avec des modèles nettement plus petits.

La qualité et la variété des données priment sur le volume brut et les époques supplémentaires : Pour des tâches au périmètre étroit, la qualité des données comptait plus que la taille du modèle ou le volume de données. Sur le modèle de triage des alarmes, davantage de variété d'entraînement vérifiée a fait passer la macro-F1 de 0.584 (entraîné sur les 684 décisions vérifiées seules) à 0.911 (avec l'ensemble de 2,522 lignes enrichi par paraphrase). Simplement exécuter plus d'époques sur les mêmes lignes donnait de moins bons résultats : une exécution de contrôle entraînée sur les 684 lignes d'origine pendant 11 époques (le même nombre d'étapes) n'a atteint que 0.879. Les données soigneusement sélectionnées ont compté plus que la taille du jeu de données tout au long du projet.

Supprimer l'étape de provisionnement change la façon de travailler d'une équipe : Lorsqu'une exécution d'entraînement n'exige plus d'attendre une capacité GPU, l'affinage passe d'un événement rare à une pratique routinière et itérative.

Un pipeline d'entraînement sert deux cibles de déploiement : La séparation de l'entraînement du modèle et du déploiement permet à Exowatt d'utiliser le même pipeline à la fois pour le déploiement périphérique hors ligne et l'analyse au niveau de la flotte connectée, simplifiant les opérations et accélérant le déploiement des modèles dans le cloud.

Conclusion

Exowatt dispose désormais d'un pipeline d'IA réutilisable qui a mené une tâche de la préparation des données spécifiques au modèle jusqu'au déploiement du modèle. Plutôt que d'ajuster un seul modèle pour différentes tâches, Exowatt prévoit d'appliquer les mêmes principes d'affinage à différentes tâches, chacune avec ses propres données, modèles spécifiques et évaluations, sur l'ensemble de la flotte à mesure que de nouveaux types d'appareils et de tâches de marché arrivent en ligne.

Le schéma se généralise au-delà des segments de l'industrie de l'énergie. Les ingénieurs IA, les data scientists et les clients de tous les segments industriels peuvent adopter les mêmes principes. Utilisez la personnalisation de modèles serverless d'Amazon SageMaker AI comme pipeline d'IA à faible surcharge pour affiner des modèles petits et spécialisés par tâche, puis déployez-les là où le travail s'effectue : à la périphérie lorsque la connectivité ou la latence l'exige, et via un point de terminaison cloud géré tel qu'Amazon SageMaker AI pour des charges de travail élastiques.

Pour en savoir plus, consultez Amazon SageMaker AI serverless model customization et Amazon Bedrock.

À propos des auteurs