Exowatt supera a los modelos frontera en precisión con la personalización de modelos serverless de SageMaker

Exowatt construye sistemas solares modulares y despachables que suministran energía confiable para aplicaciones de alto consumo energético, como los centros de datos de IA. Su producto insignia, el Exowatt P3, captura energía solar mediante lentes ópticas, la almacena como calor en una batería térmica de larga duración y entrega electricidad a demanda a través de un motor térmico. A diferencia de los sistemas solares fotovoltaicos conectados a la red, el P3 alimenta los centros de datos directamente detrás del medidor, ayudando a que los centros de datos entren en funcionamiento sin esperar en colas de interconexión a la red de varios años. Exowatt construye una flota de agentes de IA que monitorean y clasifican alarmas en tiempo real y respaldan decisiones operativas para los sistemas solares, a menudo en el edge, con conectividad limitada o nula. A medida que su flota escala desde bancos de prueba hacia la fabricación y miles de unidades desplegadas en campo, la capa de inteligencia que opera estos sistemas debe escalar junto con ella.

En esta publicación, mostramos cómo Exowatt usó la personalización de modelos serverless de Amazon SageMaker AI para construir un pipeline de IA repetible. El pipeline produce modelos fine-tuned específicos para tareas con dos objetivos de despliegue, edge y nube, logrando mayor precisión que los modelos frontera a un costo hasta 49× menor.

Los dos modelos descritos aquí son los primeros resultados de ese pipeline y no el objetivo final. El resultado más duradero del proyecto fue el propio pipeline: una ruta repetible desde datos operativos sin procesar hasta un conjunto de entrenamiento certificado, un modelo fine-tuned y un artefacto de despliegue evaluado. Exowatt ahora puede recorrer esta ruta en días en lugar de meses. La clasificación de alarmas y el análisis del mercado energético son dos de las muchas tareas estrechas y de alto valor donde se aplica el mismo enfoque.

El desafío: IA sobre infraestructura energética física

El sistema de gestión energética (EMS) de Exowatt opera en una flota creciente de sitios operativos. Cada sitio produce alarmas de forma continua: un componente de hardware funcionando fuera de especificación, una conexión caída, una lectura de voltaje fuera de rango y eventos similares. A medida que la flota escala hacia miles de unidades de campo, un operador humano no puede monitorear cada sitio en tiempo real. Exowatt necesitaba un agente de IA que pudiera leer el estado de las alarmas en cada sitio y tomar o recomendar la siguiente acción correcta de manera autónoma y confiable.

Un modelo frontera no podía resolver este problema por tres razones:

1. La tarea es estrecha y propietaria. La clasificación de alarmas en el EMS de Exowatt depende de su hardware, datos y lógica operativa específicos. Un modelo frontera de propósito general no está especializado para ella.
2. Debe ejecutarse en el edge, sin GPU y a menudo sin internet. Muchos sitios tienen conectividad limitada o intermitente, por lo que un agente que dependa de una llamada a la nube a un modelo frontera deja al operador sin cobertura cuando la conexión se cae.
3. El costo no escala a nivel de flota. Enrutar cada decisión operativa a un modelo frontera a lo largo de miles de sitios no es económico para una decisión que se repite continuamente.

Aquí es donde Exowatt recurrió a la personalización de modelos. El flujo de trabajo inicial de fine-tuning de Exowatt se basaba en seleccionar un modelo de pesos abiertos, construir un contenedor y crear una receta de entrenamiento personalizada antes de poder ejecutar cualquier experimento. Esto era un obstáculo importante para la experimentación con modelos. Además, tenían que decidir los requisitos de hardware de GPU para el fine-tuning del modelo. A medida que el equipo aumentaba el ritmo de experimentación, cada ejecución requería primero elegir un tipo específico de instancia de GPU y luego esperar a que esa capacidad autoseleccionada estuviera disponible. Cuando el tipo de instancia elegido no estaba disponible, esto podía retrasar el inicio de una ejecución o bloquearla por completo.

Necesitaban un modelo lo suficientemente pequeño para ejecutarse en un controlador de edge sin GPU, pero lo suficientemente preciso en comparación con el modelo frontera en la tarea específica como para actuar de forma autónoma. El fine-tuning cerró esa brecha: un modelo compacto y especializado en la tarea que se puede desplegar tanto en la nube como en el edge.

Descripción general de la solución

Exowatt abordó estos desafíos adoptando un enfoque de personalización de modelos nativo de la nube y serverless en Amazon SageMaker AI. El mismo pipeline de entrenamiento produce modelos fine-tuned para dos objetivos de despliegue: el edge y la nube.

Exowatt implementó este enfoque en el modelo Qwen3-1.7B para el primer caso de uso, la clasificación de alarmas en el edge, y luego aplicó el mismo enfoque al modelo Qwen3-14B para el segundo caso de uso, el análisis del mercado energético en la nube. La compañía planea reutilizar esta solución para construir modelos más pequeños y específicos para tareas en toda la flota.

Figura 1: Pipeline de fine-tuning y despliegue de Exowatt, que abarca las etapas de construcción, servicio en la nube y servicio en el edge

Los siguientes siete servicios de AWS impulsan el pipeline de IA, sin instancias, clústeres ni endpoints que gestionar:

El flujo de trabajo está organizado en tres etapas:

Personalización del modelo (nube): Exowatt ajusta (fine-tune) modelos base de pesos abiertos usando personalización de modelos serverless, Low-Rank Adaptation (LoRA) y fine-tuning supervisado (SFT) en SageMaker AI. Como el entrenamiento serverless asigna capacidad a demanda, el equipo ejecuta varios experimentos por día en lugar de esperar GPU autoasignadas. Después de la evaluación, el mejor modelo se registra en el SageMaker AI Model Registry.

Despliegue en el borde (edge): Para el trabajo sensible a la latencia y con conectividad limitada, como el triaje de alarmas, el modelo ajustado Qwen3-1.7B se congela, se cuantiza al formato GGUF y se ejecuta con llama.cpp dentro de pods de Kubernetes en el borde usando controladores en el sitio. Esta vía no requiere GPU y funciona sin conectividad a internet.

Despliegue en la nube (elástico): Para el análisis a nivel de flota con conexión a internet, el modelo de mercado de energía ajustado Qwen3-14B se sirve a través de Amazon Bedrock Custom Model Import, que se ejecuta sin costo en reposo y factura solo mientras el modelo está activo.

Por qué la personalización serverless de modelos de Amazon SageMaker AI

El servicio de personalización serverless de modelos de Amazon SageMaker AI ofrece una amplia selección de modelos de pesos abiertos con recetas de fine-tuning listas para usar del SageMaker Public Hub, por lo que el equipo evitó construir y optimizar un contenedor de entrenamiento personalizado, trabajo que de otro modo puede llevar semanas. Para Exowatt, esto convirtió el fine-tuning de un evento escaso y programado en una rutina a demanda. Esto hace práctico un ciclo rápido de experimentación y prueba manteniendo bajos los costos de experimentación.

El fine-tuning en GPU aprovisionadas requiere elegir un tipo de instancia específico, solicitar esa capacidad, esperar a que esté disponible, ejecutar el trabajo y pagar por la instancia mientras se mantenga retenida. El tiempo retenido típicamente incluye el tiempo de inactividad entre experimentos cuando una instancia dedicada se mantiene en ejecución. Para un equipo pequeño que ejecuta muchos experimentos, esto ralentiza la innovación y aumenta el costo. La personalización serverless de modelos de Amazon SageMaker AI gestiona y orquesta automáticamente la infraestructura necesaria para ejecutar el trabajo de fine-tuning, eliminando la carga de la gestión de capacidad, y cobra solo por el tiempo que se ejecuta el trabajo de fine-tuning.

Caso de uso 1: Triaje de alarmas en el borde con Qwen3-1.7B

Los sitios de Exowatt generan alarmas las 24 horas del día. Un modelo compacto en el sitio lee cada alarma junto con el estado y la telemetría del propio sitio y devuelve una de un pequeño conjunto fijo de clasificaciones con evidencia citada (como un sistema fuera de línea, un componente degradado o un desajuste de sensores) o una abstención explícita cuando la evidencia es insuficiente.

Selección del modelo y datos de entrenamiento

El equipo primero probó Qwen3-8B con prompting y barreras de seguridad (guardrails), lo cual se estancó por debajo del objetivo (0.735 macro-F1). Un Qwen3-1.7B ajustado cambió eso: superó la configuración de Qwen3-8B más prompting en esta tarea estrecha de un solo turno con aproximadamente un quinto de los parámetros, manteniéndose lo suficientemente pequeño para inferencia en el borde sin GPU. Trece candidatos de Qwen3-8B ajustados en 12 versiones del conjunto de datos nunca superaron la línea base de 8B con prompting. El modelo más pequeño con datos más variados sí lo hizo.

El conjunto de entrenamiento era pequeño y curado: 2,522 ejemplos construidos a partir de 684 decisiones verificadas sobre escenarios de sitios generados más 1,838 paráfrasis certificadas que mantenían fija cada decisión mientras reescribían la prosa. Las paráfrasis fueron generadas por Qwen3-235B en Amazon Bedrock por unos $3.72. Cada paráfrasis se conservó solo si verificaciones deterministas confirmaban que la decisión, las etiquetas, las citas de evidencia y cada número permanecían sin cambios (1,838 de 2,218 candidatos pasaron). Una familia de fallas se excluyó por completo del entrenamiento, y 320 casos se reservaron para pruebas.

Entrenamiento y despliegue

El entrenamiento se completó en unos 32 minutos con SageMaker serverless fine-tuning por aproximadamente $20–$25. Cuantizado a 8 bits (unos 1.71 GiB), el modelo se ejecuta sin conexión en un pod llama.cpp de 6 GiB en el servidor CPU existente del sitio. También funciona en un tipo de instancia t3.2xlarge.

Caso de uso 2: Análisis del mercado de energía en la nube con Qwen3-14B

El almacenamiento despachable convierte el tiempo en una decisión operativa: cada sitio debe decidir continuamente cuánta energía almacenada retener para su carga y cuándo liberarla, y en los sitios conectados a la red las condiciones del mercado influyen en esa elección. El modelo ajustado lee un paquete de seis horas de datos de mercado en vivo (unas 90 filas de precios en tiempo real, pronósticos del día siguiente y avisos de la red) y devuelve uno de cinco eventos de mercado (como un pico de precios o un recargo por escasez) en unos cuatro segundos. Cada afirmación está vinculada a una fila de datos específica para informar la estrategia de despacho.

Por qué Qwen3-14B

Se eligió Qwen3-14B porque es compatible con Amazon Bedrock Custom Model Import, se distribuye como un modelo del SageMaker Public Hub con una receta LoRA lista (sin contenedor ni tipo de instancia personalizados que gestionar) y, con unos 28 GiB, es lo suficientemente pequeño para servirse de manera rentable.

Datos y proceso de entrenamiento

Exowatt ajustó el modelo con datos públicos de mercado del Electric Reliability Council of Texas (ERCOT) tomados de cinco años de historia (unos 163 millones de filas en 12 tablas). El equipo etiquetó estos datos con reglas en 25,000 ejemplos (22,000 para entrenamiento, 1,000 para validación y 2,000 apartados para pruebas). Luego expandieron el conjunto de entrenamiento a 86,281 filas haciendo que Claude Sonnet 4.6 de Anthropic en Amazon Bedrock reescribiera la prosa de cada ejemplo mientras sus etiquetas y campos numéricos permanecían fijos.

El entrenamiento fue una única época de LoRA (rank 16, alpha 32), completada en unas 8.5 horas de ajuste fino serverless gestionado con hasta cuatro trabajos ejecutándose a la vez. El equipo ejecutó 23 trabajos y unas 155 horas de entrenamiento gestionado en los seis días transcurridos desde el plan inicial hasta un modelo campeón sirviendo en Cloud EMS.

La mejora decisiva vino de la diversidad de paráfrasis: añadir 3 reescrituras por respuesta elevó el macro-F1 de 0.950 a 0.975. El modelo base solo obtuvo 0.415 de macro-F1. Producía JSON válido pero aún no conocía el mercado. El ajuste fino lo solucionó.

Despliegue

El checkpoint fusionado se importó a Amazon Bedrock Custom Model Import en unos 14 minutos. El modelo se ejecuta sin coste de inactividad y se factura a $6.86 por hora solo mientras está activo.

Resultados del benchmark

En la tarea de triaje de alarmas en el edge, el Qwen3-1.7B ajustado pasó de ser un modelo que no podía producir una respuesta válida a alcanzar 0.911 de macro-F1 con 320 casos de prueba, por delante de todos los modelos frontera de referencia. Al aplicar el mismo bucle de ajuste fino y evaluación a la tarea del mercado energético con 2,000 casos de prueba, el Qwen3-14B alcanzó 0.975 de macro-F1, de nuevo por delante del modelo frontera de referencia y a una fracción del coste. En ambos casos, un modelo pequeño ajustado superó a modelos de propósito general mucho más grandes en la tarea específica.

Ambos modelos devuelven JSON estricto en el que cada afirmación cita una fila específica de los datos de entrada. Cualquier afirmación sin respaldo se descarta antes de llegar a un operador, y esto es lo que permite al equipo confiar en modelos pequeños en entornos autónomos y físicos.

Tabla 1: Resultados del triaje de alarmas en el edge, Qwen3-1.7B ajustado comparado con modelos frontera

$0 por 1,000 decisiones significa que no hay coste de API medido ni de inferencia en GPU. El modelo cuantizado se ejecuta en la CPU existente del sitio.

Tabla 2: Resultados del análisis del mercado energético en la nube, Qwen3-14B ajustado en comparación con modelos frontera

Los costos son los precios de lista de Amazon Bedrock multiplicados por los tokens medidos por respuesta. El ajuste fino elevó a un modelo abierto del último lugar al primero: +0.35 de macro-F1 sobre Claude Opus 4.7 (intervalo de confianza del 95 por ciento de 0.324 a 0.371) a aproximadamente 49× menos costo por 1,000 respuestas ($0.60 en comparación con $29.26). El modelo mantuvo 0.968 de macro-F1 en un segundo conjunto de prueba posterior.

Beneficios para el negocio

Iteración más rápida y menor tiempo de comercialización: Exowatt llevó su modelo personalizado de la experimentación a la producción en solo nueve días. Este proceso podría haber tomado meses si el equipo hubiera tenido que construir y optimizar contenedores personalizados y recetas de entrenamiento, aprovisionar GPU y administrar infraestructura. Con la personalización de modelos sin servidor de SageMaker AI, el equipo entrenó Qwen3-1.7B en unos 32 minutos y Qwen3-14B en unas 8.5 horas, sin solicitudes de capacidad y con hasta cuatro trabajos de entrenamiento ejecutándose simultáneamente. Para el caso de uso del mercado energético, Exowatt ejecutó 23 trabajos que totalizaron unas 155 horas de entrenamiento administrado y pasó del modelo base a un modelo ajustado en servicio en Cloud EMS en seis días. El checkpoint fusionado se importó a Amazon Bedrock en unos 14 minutos. El pipeline de extremo a extremo utilizó siete servicios sin servidor de AWS, sin instancias, clústeres ni endpoints que Exowatt tuviera que administrar.

Mayor precisión en comparación con los modelos frontera: Ambos modelos ajustados superaron a los modelos frontera más grandes en su propia tarea: Qwen3-1.7B con 0.911 de macro-F1 (en comparación con 0.698 para Claude Sonnet 4.6) y Qwen3-14B con 0.975 (en comparación con 0.625 para Claude Opus 4.7).

Menor costo en ambas implementaciones: En la nube, Qwen3-14B sirve a $0.60 por 1,000 respuestas frente a $29.26 para Claude Opus 4.7 (aproximadamente 49× menos), sin costo inactivo y a $6.86 por hora solo mientras está activo en Amazon Bedrock Custom Model Import. En el borde, el Qwen3-1.7B cuantizado se ejecuta en la CPU existente del sitio sin costo por inferencia y sin dependencia de la conectividad.

Salidas fundamentadas y de bajo riesgo: En ambos modelos, la barrera de evidencia eliminó cada afirmación sin cita (toda cita de evidencia cuya fuente, campo o valor no coincida literalmente con la entrada), y el modelo de borde se abstiene en lugar de adivinar cuando no está seguro. Esto es lo que permitió al equipo ejecutarlo de forma autónoma en modo sombra en una réplica en la nube de un sitio.

Lecciones aprendidas

Para tareas específicas, los modelos de lenguaje más pequeños ajustados pueden superar a los grandes modelos frontera: Los modelos Qwen3-1.7B y Qwen3-14B ajustados superaron cada uno a los modelos frontera en la tarea objetivo, entregando mayor precisión a una fracción del costo con modelos significativamente más pequeños.

La calidad y variedad de los datos superan al volumen bruto y a las épocas adicionales: Para tareas de alcance limitado, la calidad de los datos importó más que el tamaño del modelo o el volumen de datos. En el modelo de clasificación de alarmas, más variedad de entrenamiento verificada elevó el macro-F1 de 0.584 (entrenado solo con las 684 decisiones verificadas) a 0.911 (con el conjunto ampliado con paráfrasis de 2,522 filas). Simplemente ejecutar más épocas sobre las mismas filas dio peores resultados: una ejecución de control que entrenó con las 684 filas originales durante 11 épocas (el mismo número de pasos) alcanzó solo 0.879. Los datos curados importaron más que el tamaño del conjunto de datos en todo el proyecto.

Eliminar el paso de aprovisionamiento cambia la forma de trabajar de un equipo: Cuando una ejecución de entrenamiento ya no requiere esperar capacidad de GPU, el ajuste fino pasa de ser un evento raro a una rutina iterativa.

Un pipeline de entrenamiento sirve a dos objetivos de implementación: Separar el entrenamiento del modelo de la implementación permite a Exowatt usar el mismo pipeline tanto para la implementación en el borde sin conexión como para el análisis conectado a nivel de flota, simplificando las operaciones y acelerando la implementación de modelos en la nube.

Conclusión

Exowatt ahora tiene un pipeline de IA reutilizable que llevó una tarea desde la preparación de datos específicos del modelo hasta la implementación del modelo. En lugar de ajustar un modelo para diferentes tareas, Exowatt planea aplicar los mismos principios de ajuste fino a diferentes tareas, cada una con sus propios datos, modelos específicos y evaluaciones, en toda la flota a medida que se incorporen nuevos tipos de dispositivos y tareas de mercado.

El patrón se generaliza más allá de los segmentos de la industria energética. Los ingenieros de IA, científicos de datos y clientes de todos los segmentos de la industria pueden adoptar los mismos principios. Usen Amazon SageMaker AI serverless model customization como un pipeline de IA de baja sobrecarga para ajustar modelos pequeños y específicos de tarea, y luego implementenlos donde ocurre el trabajo: en el borde cuando la conectividad o la latencia lo requieren, y a través de un endpoint en la nube administrado como Amazon SageMaker AI para cargas de trabajo elásticas.

Para obtener más información, consulte Amazon SageMaker AI serverless model customization y Amazon Bedrock.

Sobre los autores